Keeping your application running when the device wants to sleep – updated for Android 10

11th October 2019 0 By darryncampbell

Over the last few years, since Android Marshmallow, I have been publishing details about how you can keep an android application running when the device wants to sleep. Marshmallow and Nougat introduced iterations of Doze Mode, Oreo introduced Background Restrictions and Pie added a slew of other power management features.  Android background restrictions are cumulative and so with each new release of Android it becomes more difficult to keep track of all the various power management improvements present in the OS so it is often easier to just run some tests to understand the behaviour. Unlike previous versions of Android, 10 only documents minor changes to a background app’s behaviour, specifically the ability to launch activities from the background.

My previous posts on the subject are as follows:

Back in December 2018 I also spoke at a Google Developer Group (GDG) on the subject: Slides.

Each of these previous developer posts have a similar format, I run some tests with my test application , observed how that application behaves with various wake lock and doze mode whitelisting settings and see which combination(s) allow the application to run in the background for an extended period of time.

Test setup

The test setup is as follows (this architecture is unchanged from previous posts on this topic):

A single application on the test device spawns both an HTTP client and an HTTP server.

  • The HTTP server can respond to requests from a web browser running on a remote machine, this shows the application is able to respond to network requests and simulates a push message (though in reality push messages are not implemented with HTTP)
  • The HTTP client is spawned in a background service (an IntentService) and will continually send HTTP POSTs to a remote server, this tests the applications ability to perform CPU work as well as the longevity of the background service and the ability to establish an outbound network connection.

The application is available from my personal github (recently updated to target API level 29) and is provided without any guarantees or warranties.

Some considerations before re-running the tests under Android 10:

  • Tested with Android Build number QP1A.191005.007.A1; Patch level 6 October 2019 and Google Play System update 2019-08-01 on a Pixel 2XL device
  • As I mentioned in my previous post Google have removed the ‘Keep WiFi on during sleep’ option and therefore these tests do not consider WiFi locks (since the WiFi will always remain on when the device sleeps)
  • The test application is built to target API 29 (Android 10) with a compileSdkVersion of 29.  Minimum SDK version is 21 (Lollipop)

Testing results under Android 10

Results can be found in the following table.  The ability for the CPU to run in the specified configuration is given by the first column (HTTP POST); the ability for the device to receive network traffic is given in the second column (HTTP GET).

In all tests the device was connected to WiFi whilst it was idle / sleeping.

Note 1: If the application receives a network packet the CPU may be woken up momentarily to deal with the network request, if supported by the hardware (“wake on wifi”).

Note 2: It is important to ensure that no other application on the device is taking a wake lock which can lead to confusing results, you can test for these with ‘adb shell dumpsys power’

Note 3: Closing the application by swiping it away from the recently used list or ‘force stopping’ it will cease all communication with the remote PC.

ConfigurationApplication processing can continue? (HTTP POST)Application can respond to network requests (HTTP GET)
Wake lock: Not acquired
Application whitelisted: No
No.
Application will stop processing a few seconds after the screen turns off (Same behaviour as Nougat, Oreo and Pie)
No.
Embedded server became unresponsive after about 3 minutes (Same behaviour as Pie)
Wake lock: Acquired
Application whitelisted: No
No.
Application will stop processing about 60 seconds after the screen turns off (Same behaviour as Pie)
No.
Embedded server became unresponsive after about 3 minutes (Same behaviour as Pie)
Wake lock: Not acquired
Application whitelisted: Yes
No.
Application will stop processing a few seconds after the screen turns off (Slightly more aggressive than the behaviour I observed under Pie)
Yes.
Application will continue responding to network requests indefinitely (Different than the behaviour I observed under Pie but does match Oreo)
Wake lock: Acquired
Application whitelisted: Yes
Yes.
Application will continue processing indefinitely (Same behaviour as Nougat, Oreo and Pie)
Yes.
Application will continue responding to network requests indefinitely (Same behaviour as Nougat, Oreo and Pie)

Conclusions from testing on Android 10

  • Most of the test results were similar or identical to Pie, the one exception being the behaviour when the application is whitelisted but does not hold a wake lock.  I can’t account for this difference – since it matches the Oreo behaviour it is perhaps an error with my previous Pie testing but I would not depend on this behaviour moving forward.
  • It IS STILL possible to have a background service run continually on an Android 10 device as long as the application is whitelisted and holds a partial wake lock.  There are of course battery implications to whitelisting your application and “Google Play policies prohibit apps from requesting direct exemption from Power Management features unless the core function of the app is adversely affected” [source]. Applications holding long running wake locks can also be flagged by Android as having “Stuck partial wake locks“. Although I have never personally seen or heard of a whitelisted application being flagged as mis-behaving by Android Vitals (more information on restricted apps) I can’t say this will remain the case forever.