BroadcastReceiver behavior when phone is asleep

Question

I am not quite certain what the behavior of a BroadcastReceiver, registered in the manifest and enabled via PackageManager, is when the phone is asleep. The question arose because I need a receiver registered for broadcasts from WifiManager

<receiver
    android:name=".receivers.ScanResultsReceiver"
    android:enabled="false" >
    <intent-filter>
        <action android:name="android.net.wifi.SCAN_RESULTS" />
        <action android:name="android.net.wifi.WIFI_STATE_CHANGED" />
    </intent-filter>
</receiver>

but what I want to know (as in links to the docs or some authoritative post in google groups) is which broadcasts are guaranteed to wake up a receiver when the phone has fallen asleep (as in left alone for quite some time) and keep the phone awake as long as onReceive() runs (which of course should not be too long to avoid ANR).
The receiver might well be the only component of the app running
As a bonus, I recently learned that some intents, flagged with FLAG_RECEIVER_REGISTERED_ONLY, are only delivered to dynamically registered Receivers - is there any place listing those intents ?

score 2 · Accepted Answer · answered Apr 27 '13 at 16:58

2

I am not quite certain what the behavior of a BroadcastReceiver, registered in the manifest and enabled via PackageManager, is when the phone is asleep.

Most broadcasts do not wake up the device.

which broadcasts are guaranteed to wake up a receiver when the phone has fallen asleep (as in left alone for quite some time)

I doubt that you will find a definitive list somewhere. The only broadcasts that I can recall that fit your description are SMS_RECEIVED and any triggered via AlarmManager and a broadcast PendingIntent.

and keep the phone awake as long as onReceive() runs

It is possible that SMS_RECEIVED has this behavior, but I do not know that for certain. The AlarmManager scenario definitely does.

(which of course should not be too long to avoid ANR).

It needs to be far shorter than that, as it will freeze your UI, if you happen to have the foreground activity. Anything more than a couple of milliseconds needs to be delegated to a service with a background thread, such as my WakefulIntentService.

As a bonus, I recently learned that some intents, flagged with FLAG_RECEIVER_REGISTERED_ONLY, are only delivered to dynamically registered Receivers - is there any place listing those intents ?

No, beyond the source code. Ones that come to mind include: ACTION_SCREEN_ON, ACTION_SCREEN_OFF, and ACTION_BATTERY_CHANGED.

answered Apr 27 '13 at 16:58

CommonsWare

986,068
189
2,389
2,491

Uh oh - so my receiver registered to receive `android.net.wifi.SCAN_RESULTS` and `android.net.wifi.WIFI_STATE_CHANGED` won't be woken up ? (the receiver is enabled in a WakefulIntentService, started by a Receiver woken up by AlarmManager - and this part works as it should). I would hold a lock but once the service enables the (ScanResults) receiver it dies and it is the (ScanResults) receiver who starts it again when WIFI_STATE_CHANGED (enabled) and then when SCAN_RESULTS are available. – Mr_and_Mrs_D Apr 27 '13 at 17:11
@Mr_and_Mrs_D: If the device falls asleep, WiFi goes to sleep as well, and so I have no idea what the expected behavior is if there is an outstanding scan going on. – CommonsWare Apr 27 '13 at 17:34
I did ask a [question](http://stackoverflow.com/questions/16137268/wifimanager-getscanresults-clarifications-automatic-scans-sleep-etc) about the behavior of `getScanResults()` - but in the wakeful service that enables the (ScanResults) receiver I do acquire a wifilock (of type `WIFI_MODE_SCAN_ONLY`) also (after I get the WIFI_STATE_CHANGED (enabled) in the ScanResults receiver, as wifilocks are meaningless if wifi is disabled, AFAIK) - it does work sometimes - but all depends on the receiver getting the broadcasts for wifi state and results – Mr_and_Mrs_D Apr 27 '13 at 17:46
Would using timeout locks provide a workaround ? Do they keep the device awake till they time out or are wiped away when my process is killed (likely to be once my service finishes execution) – Mr_and_Mrs_D Apr 27 '13 at 17:50
1

@Mr_and_Mrs_D: You're deeper in the woods on the WiFi stuff than I have wandered to date. This is one of those undocumented-behavior areas that can bite you due to OS version or manufacturer changes to the source code. "Do they keep the device awake till they time out or are wiped away when my process is killed (likely to be once my service finishes execution)" -- AFAIK, they go away if the process is terminated, regardless of timeout, but I have not attempted to test that theory. – CommonsWare Apr 27 '13 at 17:51

BroadcastReceiver behavior when phone is asleep

1 Answers1

Linked