This issues is *not* about platform broadcasts, such as "android.intent.action.PACKAGE_REPLACED" and other events broadcasted by privileged Android components. It is about custom broadcasts, used by individual apps, such as "com.example.MY_EVENT_TYPE". According to my reading of https://developer.android.com/preview/features/background.html such implicit broadcasts are also affected by described behavioral changes: it won't be possible to register them in AndroidManifest and they won't be invoked by implicit broadcasts.

I believe, that such broadcasts should not be subjected to Android O limitations for reasons explained below.

Most importantly, those limitations are completely pointless for third-party broadcast senders. As long as PackageManager still provides means to filter apps based on manifest details, people will be able to send targeted broadcasts, period. They might have to manually iterate over the list of targets, but authors of poorly written apps (who, I believe are targeted by these changes) won't be stopped.

If you simply want to avoid round-trip via system service for such broadcast, you can just implement manual iteration over broadcast filters within existing Context#sendBroadcast API.

I also don't believe that third-party implicit broadcasts contribute to battery issues to any visible extent. Android builtin framework components are guilty of holding permanent "wakelocks", so they are the ones causing most performance issues. Third party apps already has to be alive (via wakelock or otherwise) in order to send a broadcast. If they abuse broadcast receivers to send "second order" broadcasts, prohibit sending nested broadcasts from within BroadcastReceiver receiver wakelocks.

If you truly believe, that custom broadcasts may be an issue, please make sure, that you aren't misguided by your statistical data. Sure, broadcasts and their wakelocks are highly-visible… But aren't foreground components too? Aren't they responsible for like 90% of battery consumption? But foreground components perform useful work! They are visible to user, aren't they? But aren't broadcasts often "visible" too? If my broadcast is sent by my foreground app as means of starting work in service or another foreground app, should it really be restricted in any way? Can I please give those apps my blessing as long as my own app is in foreground? I'd rather prefer framework developers to work on better mechanisms of wakelock delegation, not scrapping "problematic" pieces of your Binder system.

If BroadcastReceiver wakelocks are so much of issue, give apps better control over those wakelocks and/or lower the time limit for holding them. Bad design of IPC, relying on everyone holding a wakelock for lengthily amount of time, is a poor excuse for removing the IPC completely. Personally, I would prefer being threatened with my process being killed on short notice, to not having it running in the first place.

If apps perform lengthily tasks in BroadcastReceivers, such as reading/writing huge files, punish those apps, not everyone. Or better yet, give people means to measure/avoid such performance issues. When will Google finally warn people, that creating a SharedPreferences instance always involve disk access?!? Even disk writes should not be much of issue, as far as battery is concerned: the data is usually stored in OS disk cache anyway. How often does ext4 flush everything to disk in Android? How often does vFAT driver do? Since apps don't usually die themselves, you can flush their stuff when necessary, not every N seconds or each time an apply() is called. Simply fiddling with flush rate and dirty page ratio should give you better battery savings than killing off entire broadcast system. Has this already been done?

I would like to see any kind of data proving that app own broadcasts constitute significant performance issue. If such data exists, Google Play should contact authors of guilty apps (which should be few) and requests them to directly resolve their issues. For some reason, I suspect, that the biggest perpetrators in this case will be Google's own Play Services. But lack of internal communication within Google is not a reason to remove crucial functionality from platform.

In addition to reasons above, please remember, that Android is not always in unplugged/battery-starved state. Do such "amazing" optimizations really make sense for Chrome OS, notebooks, media players or pretty much anyone else, when their device is plugged to AC? You are crippling entire OS for sake of single specific scenario. Is it important? Sure. But blindly optimizing for it *forever* sounds too much like desperate move. Isn't there still a lot that can be done elsewhere? You can force processes to single core via affinities. You can punish overly disk-happy apps by lowering their IO niceness. Most importantly, you can educate people, which, I believe, still has a long way to go. How many lint warnings currently cover battery usage?

By forcing people to use manual broadcast dispatch you are reducing your degree of your control, not improving it. I don't think, that explicit broadcast filters + statistics are worse than just statistics for the same reasons why properly configured static IP routing can not be worse then fully dynamic one. Should not you use that static data in manifests for optimizing instead of forcing people to remove it?

For reasons listed above, please re-consider imposing broadcast limitations on custom broadcast in Android O.

Issue 36496703

Links (2)

Issue metadata