Android installLocation and BOOT_COMPLETED

I have an Android app that uses the AlarmService开发者_运维百科. According to the docs, I should not allow installing/moving this app to external storage. Users, however, do not understand this (probably due to very little internal storage on some devices) - and demand the option to install on external storage (via low-star ratings).

I need to re-register the alarms on boot and have a BroadcastReceiver listening for BOOT_COMPLETED. This, however, is not called for applications installed on the sd-card since this is not yet mounted then the intent is fired. EXTERNAL_APPLICATIONS_AVAILABLE is, sadly, also not -- hence I get no notification that we have booted and thus have no change to re-set the alarms.

Is there any way around this predicament?

Sorry, no, this is not something you can get around. This is why we say you should not put apps on SD card that do such things.

Worst-case option: create a second app (that would be light-weight enough to not matter that it cannot be installed on the SD Card) that will listen for the BOOT_COMPLETED event on start-up and will trigger your main app when it is available. Tell the user that they have to install that to get your app to work when it is installed to the SD Card.

If there is a event/trigger that occurs when your app is moved to the SD Card, you could pop up a notification telling them to grab this second app from the market.

I understand that this is a terrible option but it would work if you are desperate.

Well, if the reason the users are asking for the move to SD is because of size constraints (i.e. your app requires a large amount of space) then I'd suggest storing the data your app uses on the SD card but restricting the app install location to internal storage.

Explain to your users if they are asking for things that don't make sense or are technically infeasible on the platform you're developing for: if they continue to ask then I'd say just ignore them. Your star rating will take a hit but agonizing over that won't fix the problem.

You already have a few fine answers to the question -- this is to clarify, correct, or otherwise address points you bring up in your comments.

users want this if the app is just a few MB

Some day, users might also decide they want your app to be pink, or in 3D, or be able to interface with their Kenmore dishwasher, none of which may be in your plans. So, I suggest that you come up with a system for communicating with your customers to explain why your app is not pink, not 3D, not dishwasher-ready, and not stored on external storage.

Now, I will readily admit that the Android Market should be providing more help with this sort of communication channel (e.g., replies to comments).

Coming up with long technical explanations (== excuses) is just not the right answer

You are entirely welcome to your opinion. I hope you like pink.

What were they thinking, designing an alarm service that only works until next reboot?

They did not want applications registering alarms and more or less forgetting about them. They wanted users to be able to start with as clean of a slate as possible after a reboot.

Well -- even a "potent" phone like the HTC Desire ships with only 150 MB of user space (en.wikipedia.org/wiki/HTC_Desire). That's pathetic.

Feel free to take this up with HTC. I do not believe that they regularly read StackOverflow.

Android's solution to installing apps here is at best half-hearted

No, it's fundamentally limited by the nature of USB Mass Storage Mode, among other things. The long-term solution is to eliminate the division between internal and external storage, a process that is underway already in Honeycomb.

and users (normal people using phones that are not engineers) are left completely uneducated in the UI

I will agree that something more could be done to help clue users in to why an app might not be movable to external storage.

One wonders why the Android team has added the "move to sd card" option right there in the app settings since this does not really work for a great deal of the apps out there, but fuels an unreasonable remand for features that's not implementable on the platform

It is mostly there for games, the major category of application that have substantial storage needs. They also tend not to need the features for which apps-on-external-storage fails to work especially well.