As part of the Android 8.0 (API level 26) background execution limits, apps that target the API level 26 or higher can't register broadcast receivers for implicit broadcasts in their manifest. However, several broadcasts are exempted from these limitations. Apps can continue to register listeners for the following broadcasts, no matter what API level the apps target.
- Exempted because these broadcasts are sent only once, at first boot, and many apps need to receive these broadcasts, such as to schedule jobs and alarms.
- Privileged permissions protect these broadcasts, so most normal apps can't receive them anyway.
- Clock apps might need to receive these broadcasts to update alarms when the time, timezone, or alarms change.
- Only sent when the locale changes, which is not often. Apps might need to update their data when the locale changes.
- When an app needs to know about these USB-related events, there is no good alternative to registering for the broadcast.
- User experience is not likely to suffer if apps receive broadcasts for these Bluetooth events.
- OEM telephony apps might need to receive these broadcasts.
- Some apps need to know about changes to login accounts so they can set up scheduled operations for the new and changed accounts.
- Apps that have visibility into an account receive this broadcast when the
account is removed. If this is the only account change that the app needs
to act on, we recommend that the app use this broadcast
instead of the deprecated
- Only sent when the user explicitly clears their data from Settings, so broadcast receivers are unlikely to significantly affect user experience.
Some apps need to update their stored data when another package is removed. For those apps, there is no good alternative to registering for this broadcast.
Note: Other package-related broadcasts (such as
ACTION_PACKAGE_REPLACED) are not exempted from the background execution restrictions. These broadcasts are common enough that there is a potential performance impact to exempting them.
Apps that take action in response to users placing calls need to receive this broadcast.
This broadcast is not sent very often. Some apps need to receive it, so that they know that the device's security status changed.
Sent by the calendar provider to post an event reminder to the calendar app. Since the calendar provider doesn't know what the calendar app is, this broadcast must be implicit.
These broadcasts are sent as a result of the user's physical interactions with the device, like installing or removing storage volumes, or as part of boot initialization, as available volumes get mounted. They aren't a common occurrence, and are usually under the user’s control.
SMS recipient apps rely on these broadcasts.