Android O: Impact On Running Apps And Developer Viewpoint

April 16, 2017

It’s been just about a year since Google released Android Nougat. In the next version of its Android operating system, it revealed the first developer preview of Android O (Hoping it’ll named Android Oreo) on 21 March 2017.

In this article, we are going to discuss all the important features and changes of Android O from developer’s perspective.

The Android O release will be known as Android 8.0. The final version of Android 8.0 will be out sometime in Q3 of 2017 and before that Google has plan to rollout DP #4.

Based on DP #1, here are list of major behavioral changes which will impact on all currently running applications when run on Android O platform.

· Background execution limits

· Background location limits

· Handles identifiers(Android ID) differently

· Account Access

· Notification Channel

· Logging of uncaught exceptions

· Locales and internationalization

· Security changes

And many more…

Android O introduces a variety of new features and capabilities for users and developers.

· Redesigned notification bar

· Autofill Framework

· Picture-in-Picture mode

· Fonts in XML

· Adaptive icons

· New account access and discovery APIs

· New Wi-Fi features

· Pinning shortcuts and widgets

· Permissions

· Media enhancements

And many more…

Let’s get started

Let’s discuss on some of the important changes which can impact your running applications.

Service limitation

As we all know that service is an application component that can perform long-running operations in the background, and it does not provide a user interface. Also there are three types of the service:

· Scheduled Service — A service is scheduled when an API such as the JobScheduler.

· Started Service — A service is started when an application component (such as an activity) calls startService().

· Bound Service — A service is bound when an application component (such as an activity) binds to it by calling bindService().

The Android system force-stops a service only when memory is low. You can also create a foreground service in Android. A foreground service is a service that the user is actively aware of and is not a candidate for the system to kill when low on memory.

To request that your service run in the foreground you have to call startForeground().

Limitation in Android O

While an application is idle, there are limits to its use of background services and Android system will stop all the background services of application. If you call startService() on Android O, you will end up with llegalArgumentException.

There are some circumstances when a background app is placed on a temporary whitelist for several minutes like –

· Handling a high-priority Firebase Cloud Messaging (FCM) message.

· Receiving a broadcast, such as an SMS/MMS message.

· Executing a PendingIntent from a notification.

Note: This will not affect Bound service.

Why restriction on background services?

Whenever an application runs in the background, it consumes device's limited resources, like RAM and results impaired user experience and quick battery drain, especially if the user is using a resource-intensive apps (Games or video streaming). Most of the applications have long running background services, which basically runs for the infinite time. These services constantly consume memory and also cause battery drain.

How to do?

Option 1: If application has supports below API level 21 then use Firebase Job Dispatcher to schedule the job. Firebase Job Dispatcher is supported upto API 9.

Option 2: From API level 21, JobScheduler API introduced to perform background tasks. Benefit to use these API is that android system will batch all the services from different applications and run them together in some particular timeframe. This also reduces the usage of CPU and radio wakes up by batching the tasks together. This will consume less battery and maintains system health.

Option 3: Create a foreground service for long running task then none of the above background execution limitations will apply. So instead of startForeground() use NotificationManager.startServiceInForeground() to create foreground service.

Broadcast limitation

Broadcast receiver allows to register for system or application events and all the registered receivers for an event are notified by once this event happens. You can register it from your application in two ways–

· Implicit broadcast

· Explicit broadcast

Android Nougat placed some restrictions on Broadcast Receivers, but Android O makes them even stricter.

From Android O you cannot register implicit broadcasts in your application manifest. There are few exceptions like-

ACTION_BOOT_COMPLETED, ACTION_TIMEZONE_CHANGED etc.

Application can continue to register for explicit broadcasts in their manifests or at runtime.

Why restriction?

This is a very judicious decision as there are lots of unnecessary broadcasts sent to apps which don’t even need to listen to them at the current moment, thereby wasting a lot of battery juice.

How to do?

Application can register the implicit broadcast receiver at runtime using the registerReceiver() method. In many cases, apps that previously registered for an implicit broadcast can get similar functionality by using a JobScheduler job.

To reduce the power consumption, Android O limits on the frequency to retrieve current location. If your app is in the background then it cannot retrieve location updates more than a few times each hour and this restriction is applicable to all apps irrespective of their target SDKs.

If you need to receive faster location updates, consider moving your app to the foreground, or create foreground service or use the GeoFencingApi which is optimized for battery consumption.

As we all know the ANDROID_ID is used as a unique identifier for the lifetime of the user's device and its value is unique to each user. To improve privacy, now from Android O, it handles the identifiers differently. Values of ANDROID_ID are now scoped per-app instead of per-user and this value will persist even after app reinstall. In other words ANDROID_ID is now different for each application as well.

For a simple, standard system to monetize apps, use Advertising ID. Advertising ID is a unique, user-resettable ID for advertising, provided by Google Play services.

Android O no longer supports SSLv3. When establishing an HTTPS connection with TLS protocol, HttpsURLConnection no longer falling back to earlier TLS protocol versions and retrying.

Now from Android O, WebView objects cannot access websites over HTTP. Each WebView object must use HTTPS instead.

Below is a video explains new features and changes in Android O for developers.

Android O certainly brings a lot of new features and improvements for the developers. Above explanation is to give you idea of what Android O is going to be like and time to think the impact of these changes on your application.

If you are eager to know in more details, please visit official Android documentation.

To find more interesting topics on Software development follow me at Medium.

Twitter GitHub