Back on June 30, a developer posted a possible issue
BOOT_COMPLETED broadcast. I think
the question got caught up in moderation, and it showed up on the
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
What I confirmed is that if you install an application that registers a
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
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
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-discuss Google Groups.
Learn second-generation Android app development — with Kotlin and the Android Jetpack — through CommonsWare’s Android app development training!