Android O Background Limitations: Not Just for targetSdkVersion 'O'
In Monday’s post on ODP2, I wrote:
The biggest concern is “Even for apps not targeting O, users can use the Settings screen to enable background execution limits.” This implies that all developers need to concern themselves with the changes in
Servicebehavior, the semi-ban on implicit broadcasts, and the changes in background location behavior. Previously, this was limited to developers who jumped to
Oor higher. However, I cannot find where in Settings that the user can make this change. I cannot even find it in Developer Options. So, it is unclear how much of an issue this is.
Yesterday, Oasis Feng pointed out that the place in Settings where the user can apply background limitations to apps is in the Battery screen, for apps that are listed there as big battery consumers.
(of course, it’s not every app, as the Google App does not have that option)
From the standpoint of whether or not users toggling this setting will become
common, this Settings location is not bad. Users will have limited ability
to apply the background limitations to apps. However, it is possible, and
so developers who are not planning on shipping a
right away need to test this scenario.
However, developers cannot use the Settings app to apply this limitation, unless their app happens to be in the battery blame list, which ideally doesn’t happen. So, I updated my issue to request some instructions for how developers can toggle this by other means.
And, today, I received a response.
Apparently, developers can do the same thing that users can, but to any app,
via the undocumented
adb shell appops command:
adb shell appops set your.application.id.here RUN_IN_BACKGROUND ignore
your.application.id.here is your app’s
I say “apparently”, as I have no good way of confirming that this “appop” is the same as what users can do from the battery blame list, but I’ll take it on faith that it is the same thing.
Based on my testing,
the behavior of an app with
O and an app with a lower
targetSdkVersion but affected by this appop is slightly different:
In either case, you cannot receive broadcasts of implicit
Intentobjects via manifest-registered receivers
In either case, a background unbound service (i.e., started via
startService()), will be stopped after ~1 minute
targetSdkVersion 'O'case, you will not be able to start a service via
startService()after ~1 minute (“Background start not allowed”), but in the appop case, you still can start services in this state
The argument about why this is not documented anywhere is:
We are not generally advertising this for development because it does not behave the same in many important ways as an app that is targeting O, so you need to actually target O to test your app against background check. (And generally we are not wanting to encourage developers to mess around with how broken their app may be with the background app op restriction imposed on it, but instead target O so they work within the new background limits and don’t need to worry about the user trying to do this to them.)
However, developers routinely do not move to the latest
soon as it is released. For example, here are some better-known apps from my “daily driver”
device that are not on
targetSdkVersion of 25 (the now-current latest version):
- Adobe Reader: 24
- Amazon Kindle: 24
- Barcode Scanner: 19
- Fastmail: 21
- Foxit PDF: 22
- Mozilla Firefox: 23
- TripIt: 23
- United Airlines: 21
- VLC: 23
- Vonage: 23
And so on.
Now, plenty of app developers do aim for the latest
targetSdkVersion. But it is
certainly not all. Google should be aware of this; I have to imagine that
they have metrics on the state of apps in the Play Store.
An attitude of “we don’t want
to document this because developers should always use the latest
is unrealistic and, IMHO, unfortunate.
So — once again, IMHO — here’s what you should do:
If your app will ship with a
Oturns into) shortly after Android O ships, hopefully you are already testing how your app behaves with the background limitations, and so you know how it will affect your app.
If you plan on sticking with a lower
targetSdkVersionfor a while, and you are really really sure that your app will not show up on the battery blame list, and you want to ignore the background limitations for now, that’s your decision to make.
If, however, you plan on sticking with a lower
targetSdkVersionand your app does tend to consume a fair bit of battery life, you should test your app with the
adb shell appopscommand cited above. If nothing else, you can identify the likely symptoms that users will experience if they limit your background work through the Battery screen in Settings. That way, if you get customer service calls/emails/texts/Play Store comments/candygrams about those symptoms, you can better advise users about what to do.
Meanwhile, the War on Background Processing continues.
Learn second-generation Android app development — with Kotlin and the Android Jetpack — through CommonsWare’s Android app development training!