8

Now that the final API for Android O is released and none of the following broadcasts is whitelisted I have the following problem:

In my application (targets API 25) I currently have a BroadcastReceiver which listens for system events of ACTION_POWER_CONNECTED and ACTION_POWER_DISCONNECTED. Now I would like to update my app to target Android O but with this release comes a huge change in broadcast behaviors:

Apps that target Android O can no longer register broadcast receivers for implicit broadcasts in their manifest. An implicit broadcast is a broadcast that does not target that app specifically.

Since both broadcasts are implicit I can only register for them via the Context.registerReceiver() method but with this comes the problem: As soon as the process of my app is killed by the system or as soon as system clears my app's memory (as a result of low-memory of device) the broadcast registration will be lost.

To avoid this problem I can use the JobScheduler API with the setRequiresCharging method for ACTION_POWER_CONNECTED but for ACTION_POWER_DISCONNECTED I have to use the registerReceiver method.

Since my app controls the volume of the device (based on these events) it's really important that none of these events is missed. So how can I safely listen for disconnected power events in Android O?

Btw. I have the same problem with WIFI disconnect events.

EDIT: I would love to do this without a notification from a foreground service

Cilenco
  • 6,951
  • 17
  • 72
  • 152
  • 1
    This limitation was introduced in order to enhance battery usage. Having [on average 95 apps](https://thenextweb.com/apps/2014/08/26/android-users-average-95-apps-installed-phones-according-yahoo-aviate-data/) installed, imagine how many of them maybe potentially interested in that event. Now if each and every interested app would be given the opportunity to react to that event, that would dramatically affect battery usage. Instead, Google suggests us, developers, to poll the state during some windows that JobScheduler would be fit in. Create your job, make assertion within that window. – azizbekian Jun 14 '17 at 09:44
  • Can broadcast receivers for the power intents be registered dynamically? I am trying to register them in my already-present foreground service, but they don't seem to ever be triggered. – mike47 Apr 27 '19 at 19:34

3 Answers3

2

Jobs can be delayed without any constraint by the system. The setOverrideDeadline method uses just a best-effort policy, so in this case you can keep your target SDK to 25 or use a foreground service. Foregournd services can be killed by the system but with really low probability.

greywolf82
  • 21,813
  • 18
  • 54
  • 108
2

This may be overkill, but you could register for those broadcasts in a foreground Service that is started by ACTION_BOOT_COMPLETED.

Kevin Krumwiede
  • 9,868
  • 4
  • 34
  • 82
-3

You can register a background job with the JobScheduler using the "requires charging" constraint. At least this is the official solution suggestion.

artkoenig
  • 7,117
  • 2
  • 40
  • 61