IssueTracker

As is noted in https://issuetracker.google.com/issues/36496703#comment7, the ban on implicit broadcasts in Android O is to reduce process churn. The issue on which that comment was posted asked for limiting the ban to system-sent broadcasts, which was rejected, on the grounds that developer-sent broadcasts also contribute to process churn.

However, developer-sent broadcasts will continue to contribute to churn, simply because developers will perform a manual fanout, using queryBroadcastReceivers() on PackageManager and sending N explicit broadcasts (one per registered receiver) rather than 1 implicit broadcast.

If you want to eliminate process churn, rather than banning implicit broadcasts (which, despite assertions to the contrary, have their uses), implement a store-and-forward model:

- Running processes with registered receivers (whether registered in the manifest or via registerReceiver()) receive the implicit broadcast in near-real-time, as they do today

- Manifest-registered receivers in apps that do not have a current process will receive the implicit broadcast soon, for some value of "soon"

In the short term, simply rate-limiting the delivery (e.g., one fresh-process receiver every N seconds) may suffice. In the future, more draconian approaches might be employed, up to perhaps "only when the process is started for other reasons is the implicit broadcast delivered".

Benefits over the implicit-broadcast ban include:

- Better limits process churn, both from system-sent broadcasts and from developer-sent broadcasts, since developers will not need to resort to manual fanout or similar workarounds.

- Breaks fewer apps. Apps that rely on a broadcast being received at the same time as some real-world event that triggered it may require changes. But apps that simply need to know that an event occurred (e.g., ACTION_PACKAGE_ADDED, to know that a new app was installed) would require no modifications.

- Eliminates polling, which appears to be the recommended workaround (e.g., have to periodically scan for all installed apps and perform a delta to determine what has been added), despite the fact that polling itself will contribute both to process churn and unnecessary battery consumption.

Unfortunately, we cannot reliably implement a store-and-forward mechanism ourselves, due to limited app process lifetime and the fact that an Intent is not necessarily persistable.

Thanks for considering this!