It’s that time of year again when we get ready for the new Android OS version. Each Android version has plenty of small, nice, nice-to-have changes and one big major change. Lollipop brought us ART, Marshmallow brought us Runtime Permissions, and Nougat brought us multi-window. Now, Android’s cracking down on battery wastage and background activity.
Even though you might think OS upgrade is slow in the Android ecosystem (Nougat, for example, is “only” used by 11.5% of the user base), keeping your app updated is very important. First, 11.5% of the population is no small pickings. If you’re still bent on supporting Jelly Bean devices, no reason you shouldn’t support Nougat or O. Second, if you intend your app to run on a Pixel device (no reason why you wouldn’t), you better make sure your app is O-compatible, because some of the changes will affect *all* apps on these devices. And third, numbers are often deceiving. 11.5% of the global market may not apply to you. Your personal user base may very well reach as many as 95% using the latest and greatest.
So it’s settled then. You should make sure you’re compatible.
But what is it really all about? Android O is about being through being nice. For too long, Android has been a wild wild west of manufactures tweaking the OS, apps doing pretty much whatever they wanted and users constantly complaining that their battery runs out too fast. Well, no more.
Background Activity Limitation
The #1 cause for battery drain is excessive background activity. And that’s the biggest thing Android’s changing.
There are no new strict limitations to when the app is in foreground. It can start and run as many services as it wants. But, when in background, its services will be stopped. That’s right, after a small grace period, any service still running in background will be killed by the OS.
Some specific tasks will get longer grace periods (to the extent of several minutes). What makes a task special? That is does something the user eventually sees and/or interacts with. Such tasks include the handling of high-priority messages via Firebase Cloud Messaging, starting a VpnService or handling a legitimate broadcast receiver or notification.
Anything else you want to be doing while in background is now prohibited. If you want to check users’ Facebook status, location, or swing any other kind of background activity, you must use JobScheduler. In a nutshell, JobScheulder was introduced in Lollipop to help the device sleep better, save battery and only perform small works in controlled maintenance windows. It has now been enhanced to take over background and intent services. Best practice then, a must now.
Background Location Limitations
As mentioned, background activity is restricted. Background location activity is restricted as well. Now, this deserves a whole section for itself because background location activity is often the bread and butter of many apps and libraries, such as navigation apps.
In background, location access will be restricted to a few times per hour only. This is a major change, to the app code itself as well as to the 3rd party SDKs that rely on constant location reads. And how much do they read location in background? The following is an illustration taken from the SafeDK Dashboard of an ordinary app:
SDKs accessing Location in background, almost 3 reads per user per minute!
This, by the way, is one of those “affects all” kind of changes. All apps running on an Android O device, regardless of whether they are compatible or not, will have restricted background activity. And specifically restricted background location-access activity.
Some Implicit Broadcast Receivers Were Harmed in the Making of this Android
Part of the wild wild west we were talking about, allowed apps to register Broadcast Receivers via the manifest file and request to be notified of changes on the device. Network changes, Wi-Fi changes, chargers being plugged in and out etc. The result was that even if the app was dead, the OS had to wake it up or even recreate it in order to relay the message. These are known as “implicit broadcast receivers”.
On the contrary, apps could register receivers dynamically in code. This means that they’ll only be notified as long as the app is alive, but the app will not be resurrected once it was dead.
Android O is no longer just encouraging you to use dynamic Broadcast Receivers. It forces you. Many implicit receivers will simply no longer be called. So you better clear those battery hogging classes from your manifest and start explicitly registering them in code. You can find the list of restricted receivers here and adjust your app accordingly.
The main reason for this change, as mentioned before, is improving battery life, by disallowing multiple apps broadcast receivers to be all awoken at the same time.
Prepare for the Change – It’s a Big One!
Here’s the big thing you must understand. The changes in Android O are not background changes (pardon my pun) and are no small potatoes. They will actively disrupt app’s activities.
And you may think your app doesn’t rely on background services and implicit broadcast receivers that much. And you might even be right. But what about the 3rd party libraries and external tools you’re using? They may rely on it more than just a bit. Sometimes their whole product is based on this and they may stop working or giving you what you want. So you have to check your SDKs made the necessary adjustments and that you’re using their updated versions, the Android-O compatible ones, if and when they become available.
In many cases, using incompatible SDKs means you’re harming your app and losing users and money over it. Make sure you’re ready for the change. You and your partners – the SDKs.