BOOT_COMPLETED Regression

Back on June 30, a developer posted a possible issue with the BOOT_COMPLETED broadcast. I think the question got caught up in moderation, and it showed up on the android-developers list yesterday. I ran some tests and can confirm the core symptom: BOOT_COMPLETED will not work out of the box on Android 3.1 until the user uses your app.

For those of you just tuning in, Android sends around a BOOT_COMPLETED broadcast around the time the home screen appears. You can register to receive that, assuming you hold the appropriate permission. Mostly, this should be used for registering AlarmManager schedules.

What I confirmed is that if you install an application that registers a BOOT_COMPLETED receiver, and simply restart the Android 3.1 device, the receiver does not get control at boot time. The original person reporting the problem indicates that the user has to start up an activity in that application first (e.g., from the launcher) before Android will start delivering BOOT_COMPLETED Intents to that application.

I do not find this change that surprising. Google has long said that users should launch an activity from the launcher first, before that application can go do much. That’s why your app does not receive the ACTION_PACKAGE_INSTALLED broadcast, for example. Preventing BOOT_COMPLETED from being delivered until the first activity is launched is a logical extension of the same argument.

However, it is a regression.

I expect that most apps will be OK. For example, if your boot receiver is there to establish an AlarmManager schedule, you also needed to establish that schedule when the app is first run, so the user does not have to reboot their phone just to set up your alarms. That pattern does not change – it’s just that if the user happens to reboot the phone, it will not set up your alarms, until the user runs one of your activities.

However, if your application relied upon BOOT_COMPLETED working without user intervention (e.g., you have no activities, only an app widget), you may encounter problems.

I have filed an issue, to either fix the bug (if this is supposed to work as before) or to fix the bug (if this is merely a documentation issue). DO NOT STAR THE ISSUE unless you want to be notified of updates. DO NOT COMMENT ON THE ISSUE to argue whether or not the current behavior is OK; only comment if you have additional evidence that pertains to the behaviors cited. Many people think that the Android public issue tracker is some sort of blog comment stream and therefore feel inclined to post “me too!” comments or rants about how Google is teh evil. The Android public issue tracker is mostly a one-way dead-letter drop for problems — if you want to hold discussions about it, pick someplace else more appropriate, such as the android-developers or android-discuss Google Groups.