Smart apps for customers from the automotive sector or industry - this is what the app development team at in-tech deals with. The spectrum ranges from machine control via smartphone to mobile payment and music control in cars. In order to be able to use the latest technologies and offer customers the best solution, the app developers at in-tech are constantly looking at the latest systems and versions, in this case Android Oreo.

Google promises longer battery life and smoother operation from restrictions in Android 8, which affect background services in particular. This is a consistent continuation of the path begun under Android 7 to restrict possibilities for developers that can have a negative impact on the performance of the device and on battery life.

The focus of the changes in Android 7 was to prevent a large number of initially inactive apps from going into action simultaneously during certain events, overloading the system and thus disrupting the operation of the device. In order to avoid such situations, both the transmission and reception of certain broadcasts have been restricted. The broadcasts CONNECTIVITY_ACTION, ACTION_NEW_PICTURE and ACTION_NEW_VIDEO are affected by this.[1]

With Android 8, broadcasts are further restricted. In addition, background services and the frequency of position requests by background services are limited.

Background services

The restrictions on background services only apply to apps that use Android 8 as a target platform (targetSDK = 26) and that are in the background. An app is in the background if it is neither visible nor running a foreground service or another app is communicating with it in the foreground. If an app goes into the background, the system can stop its background services after a few minutes.

To ensure that an app can also perform necessary tasks in the background, you can use foreground services instead of background services where it makes sense to do so. Another possibility is to use the Android JobScheduler, which was introduced with Android 5 (API level 21). The JobScheduler can be given tasks that are processed either once or periodically by the system. A possibly necessary form of network connection can also be specified, so that it is possible, for example, to start a task only if a WLAN connection is available. As an additional condition, it can be specified that the device must otherwise be unused at the time of execution. If it is not possible to execute a task successfully, the Job Scheduler can restart the task later. It is also possible to let the times between the execution attempts increase exponentially or linearly.

Apps that also need to support systems with an API level below 21 cannot use the JobScheduler. Instead, the Firebase JobDispatcher[2] or the Android job library from Evernote[3] can be used. The Firebase JobDispatcher can be used on systems from API level 9 (Android 2.3), but requires Google Play Services. Evernote's Android job library can be used from API level 14 (Android 4.0) and does not require Google Play Services. Apps that use Evernote's library therefore also run on devices with custom ROMs, which often do without Google Play Services, and on Amazon Fire hardware. Both libraries are licensed under the Apache License 2.0, which allows them to be used in both free and proprietary software.

Position queries in background services

A frequent point of criticism from users is the high battery consumption of apps as a result of frequent position queries via GPS. As of Android 8, apps in the background can no longer query the position as frequently as was previously the case. Apps in the foreground continue to behave as usual.

An app in the background will now only receive position updates a few times per hour, even if the app has requested them more frequently. This affects all apps that run on devices with Android 8, not only apps that were created specifically for Android 8. It is therefore advisable to also check the behaviour of older apps on Android 8 in order to pre-empt any user complaints.

In order to continue to receive the position in the background more frequently than a few times per hour, you can use a foreground service instead of a background service. This has the advantage for users that the foreground service is visible through a notification and can be stopped when it is no longer needed. Another alternative is to use the geofencing api of Google Play Services. With it, it is possible to request a notification from the system when the device is moved into or out of a predefined area.

If the app only receives position data passively in the background by requesting a LocationProvider with the provider name PASSIVE_PROVIDER from the LocationManager, the behaviour does not change with Android 8. However, the app only receives position data in the background if another app in the foreground has registered to receive position data from the location provider.

Broadcasts

Like the changes concerning the behaviour of background services, the changes concerning broadcasts also only affect apps that used Android 8 (API level 26) as a target platform.

As of Android 8, apps can no longer register implicit broadcasts in the manifest. Implicit broadcasts are relatively unspecific messages, such as ACTION_BATTERY_CHANGED. This broadcast simply indicates that the battery status has changed, but not exactly what change has occurred. Explicit broadcasts are more specific in what they describe, such as ACTION_BATTERY_LOW. A broadcast of this type indicates that the battery has reached a low state of charge. An app can react to this immediately without having to make further requests. Explicit broadcasts can still be registered in the manifest. Implicit broadcasts must be registered by the app during runtime using Context.registerReceiver().

Which broadcasts count as explicit broadcasts and which are implicit broadcasts is unfortunately only partially clear from the Android documentation. To make things even more confusing, there are numerous exceptions that are described in the API Guide.[4]

Conclusion

Even if the changes in Android 8 mean a certain amount of work for developers, the necessary adjustments should be manageable in most cases. Since in most cases alternatives to the previous approach already exist, it is not worth putting off the changes. Although not much will change in the behaviour of the apps that is immediately apparent to users, overall the restrictions for developers will hopefully lead to an improvement in battery life and a smoother interface of Android devices with fewer jerks. In addition, developers can use this opportunity to rethink the necessity of background actions of apps, leave well-trodden paths and strive for a more resource-saving behaviour of their own apps.

Further information:

https://developer.android.com/about/versions/oreo/background.html

https://developer.android.com/about/versions/oreo/background-location-limits.html

[1] More information about the changes in Android 7: https://developer.android.com/topic/performance/background-optimization.html and https://www.youtube.com/watch?v=vBjTXKpaFj8

[2] https://github.com/firebase/firebase-jobdispatcher-android

[3] https://github.com/evernote/android-job

[4] https://developer.android.com/guide/components/broadcast-exceptions.html