Busy ~ very busy recently.

Busy I even SystemUI series of articles advance at a snail’s pace ~

This article takes a moment to document the broadcast restrictions on Android8.0.

Recently in the Android 8.1 based system project useful static register broadcast to listen to broadcast. However, whether I install Apk or noble push to the corresponding system/priv-app/ directory, I will not receive this broadcast. Mentality, DUANG, explode.

Then a flash of inspiration, pull out the memory corner of Android7.0 broadcast restrictions, quickly Google. ** After Android8.0, when App targetSDK >= 26, almost all implicit broadcast static registration listening is disabled. ** in particular in this record, to prevent me from forgetting.

This article is mainly about the following content, please pick up a small bench, bring a good snack, come to watch:

  • Android Broadcast Popular Science
  • Background restrictions on Android8.0
  • List of specific broadcasting restrictions and corresponding pardons
  • Adaptation/solution

Popularizing the knowledge of broadcasting

Come on, first popular science, broadcast two listening/receiving registration methods and two types, take a small notebook to write down, remember!

Registration method:

  • Static registration: Also known as manifest registration, is a broadcast registered in androidmanifest.xml. This type of broadcast receiver can receive the broadcast when the application is not started.
  • Dynamic registration: Also known as run-time registration, this is used to register broadcast receivers with context.registerReceiver () in a Service or Activity component. Such broadcast receivers are registered by code after the application has been started.

Two types:

  • Explicit Broadcast: The sent Intent is a Broadcast that displays the Intent. This is done by specifying the name of the Intent component, which is typically used to invoke the following methods knowing the name of the target component. The intent is explicit, specifying which component to activate, and is typically implemented within the same application.
Intent.setComponent()
Intent.setClassName()
Intent.setClass()
new Intent(A.this,B.class)
Copy the code
  • Implicit Broadcast: Implemented with an Intent Filter. It is used when the target component name is not explicitly specified. The Android system finds the most appropriate component to handle an implicit intent based on the actions (actions), categories (categories), and data (URIs and data types) set in the intent. This is typically used between different applications.

Background execution restrictions on Android8.0

TargetSDK >= 26; if targetSDK < 26, it will not be affected

In Oreo, to further improve the user experience and save power, further restrictions are placed on what applications can do while running in the background.

  • Background service restriction: Limits the background services of applications in idle state. For example, statically registering to receive a startup broadcast (assuming your device is not customized to receive ~) and starting a Service in the onReceive method is not allowed and will cause an error on API 26. Of course, this limitation does not exist for front desk services. It’s official: Front-desk services are easier to notice.

  • Broadcast restrictions: With limited exceptions, applications cannot receive implicit broadcasts using manifest registration (static registration).

    • For these implicit broadcasts, however, they can be registered through run-time registration (dynamic registration).
    • For explicit broadcasts, you can still listen through a manifest register (static register)

Here, too, Android phones are running flat, largely due to apps abusing and selfishly using all sorts of tricks (permissions abuse, broadcast registration, backend service residency, etc.) to keep things alive or do PY things. Google clearly recognized this early on and has been gradually introducing restrictions such as runtime permissions and Doze since Android 6.0.

List of specific broadcasting restrictions and corresponding pardons

If an application registers a broadcast receiver, the application’s broadcast receiver consumes resources such as RAM, CPU, and so on every time a broadcast is sent. If there are many applications registering broadcast receivers for system event broadcasts, this…. , will be very card!

So starting with Android 7.0 (API level 24), there are some restrictions on broadcasting:

  • API24 and above application, the static radio receiver can’t monitor network changes: the registered android.net.conn.CONNECTIVITY_CHANGE
  • App cannot send or receive ACTION_NEW_PICTURE and ACTION_NEW_VIDEO broadcasts on Android7.0 devices.

However, in Android8.0, the restriction is further enhanced, except for the following implicit broadcasts, all other implicit broadcasts cannot be registered to listen in androidmanifest.xml. Refer to the official website.

// Unrestricted implicit broadcast on Android 8.0
ACTION_LOCKED_BOOT_COMPLETED Intent.ACTION_BOOT_COMPLETED */
"Retention reason: These broadcasts are sent only once when first started, and many applications need to receive them for scheduling jobs, alarms, and so on."

/ * * add or delete user Intent. ACTION_USER_INITIALIZE "android. Intent. Action. USER_ADDED" "android. Intent. Action. USER_REMOVED" * /
"Retention reason: These broadcasts can only be listened to by apps with specific system permissions, so most normal apps cannot receive them."
    
/ * * time zone changes, ALARM "android. Intent. Action. TIME_SET" intent. ACTION_TIMEZONE_CHANGED AlarmManager.ACTION_NEXT_ALARM_CLOCK_CHANGED */
"Reason for retention: The clock application may need to receive these broadcasts in order to update the alarm when time or time zone changes."

ACTION_LOCALE_CHANGED */ intent.action_locale_changed */
"Retention reason: send only when the locale changes, infrequently. Applications may need to update their data as the locale changes.

ACTION_USB_ACCESSORY_ATTACHED USbManager.action_usb_accessory_detached UsbManager.ACTION_USB_DEVICE_ATTACHED UsbManager.ACTION_USB_DEVICE_DETACHED */
"Retention reason: There is currently no viable alternative to registering broadcasts if applications need to know about these USB-related events."

/** Bluetooth status-related BluetoothHeadset.ACTION_CONNECTION_STATE_CHANGED bluetootha2dp. ACTION_CONNECTION_STATE_CHANGED BluetoothDevice.ACTION_ACL_CONNECTED BluetoothDevice.ACTION_ACL_DISCONNECTED */
"Reason for retention: Applications receiving broadcasts of these Bluetooth events are unlikely to affect the user experience."

/ * * a Telephony related CarrierConfigManager ACTION_CARRIER_CONFIG_CHANGED TelephonyIntents. ACTION_ * _SUBSCRIPTION_CHANGED TelephonyIntents.SECRET_CODE_ACTION TelephonyManager.ACTION_PHONE_STATE_CHANGED TelecomManager.ACTION_PHONE_ACCOUNT_REGISTERED TelecomManager.ACTION_PHONE_ACCOUNT_UNREGISTERED */
"Retention Reason: Equipment manufacturer (OEM) telephony applications may need to receive these broadcasts"

/** AccountManager.LOGIN_ACCOUNTS_CHANGED_ACTION */
"Retention reason: Some applications need to know about login account changes in order to schedule actions for new and changed accounts."

ACTION_PACKAGE_DATA_CLEARED */
"Retention reason: only sent when the user has explicitly cleared their data from Settings, so the broadcast receiver is unlikely to significantly affect the user experience."
    
Intent.action_package_fully_removed */
"Retention reasons: Some applications may need to update their stored data when another package is removed; No viable alternative to registering this broadcast has been found for these applications."

Intent.action_new_outgoing_call */
"Reserved reason: Applications that perform operations in response to user calls need to receive this broadcast."
    
/ * * when equipment owner is set up, change or remove a DevicePolicyManager. ACTION_DEVICE_OWNER_CHANGED * /
"Reserved reason: This broadcast is not sent very often; Some applications need to receive it to know that the security status of the device has changed."
    
/** CalendarDraft.action_event_reminder */
"Reserved Reason: Sent by the Calendar provider to publish event alerts to the calendar application. Because the calendar provider does not know what the calendar application is, this broadcast must be implicit.
    
ACTION_MEDIA_MOUNTED Intent.ACTION_MEDIA_CHECKING Intent.ACTION_MEDIA_EJECT Intent.ACTION_MEDIA_UNMOUNTED Intent.ACTION_MEDIA_UNMOUNTABLE Intent.ACTION_MEDIA_REMOVED Intent.ACTION_MEDIA_BAD_REMOVAL */
"Reason for retention: These broadcasts are sent as a result of the user's physical interaction with the device: installation or removal of storage volumes or as part of initiation initialization (when available volumes are loaded), so they are not very common and are usually under the user's control."

/ * * Sms, WAP PUSH relevant Telephony in Sms. The Intents. SMS_RECEIVED_ACTION Telephony. Sms. The Intents. WAP_PUSH_RECEIVED_ACTION note: Need to apply for permission to receive "android. Permission. RECEIVE_SMS" "android. Permission. RECEIVE_WAP_PUSH" * /
"Reserved reason: THE SMS messaging application needs to receive these broadcasts"
Copy the code

Whew, finally finished, above. It can be said that the official website is also full of ~

Suggest collect a wave to prevent later use of ha.

The solution

As officially recommended, for implicit broadcasts, do the following.

  • Dynamically by callingContext.registerReceiver()Register broadcast receivers instead of declaring receivers in the manifest.
  • Use JobScheduler.

I choose dynamic registration to deal with this problem.

Okay, so much for the chatter about Oreo’s broadcast restrictions.

Recently inspired by a small partner, get a sentence: hard people, luck and opportunities are often not bad!

‘!

Finally, welcome to follow the wechat public account: Ape Wet Xoong happy Android high quality dry goods to share

Refer to the link

[1] Android Oreo background restrictions on https://developer.android.com/about/versions/oreo/background#broadcasts

[2] Android Oreo Implicit Broadcast Exceptions https://developer.android.com/guide/components/broadcast-exceptions

[3] to the characteristics of explicit and implicit intent in Android and the difference between https://blog.csdn.net/u014177843/article/details/50596863

[4] Android O behavior change – implicit broadcasting restrictions on https://blog.csdn.net/hqocshheqing/article/details/76850164