As you may already know, we plan to update some of our latest devices to Android Oreo. As a result of this upgrade, we’ve had to update our apps to target this new Android version in order to take advantage of the new features provided by the OS, as well as adjust some of our applications’ behaviour to comply with the new specifications defined by Google.

In this article we want to focus on the major changes included in Android Oreo and on our experience in implementing these in our apps in order to make them compatible.

Adaptive icons

One of the biggest UI changes in Android Oreo is the inclusion of adaptive launcher icons. In summary, adaptive icons allow developers and designers to create application icons that can be morphed using masks defined by the device’s launcher app, like our BQ Launcher. This allows launcher apps to normalise icon shapes and provide a more visually appealing experience.

Adaptive icons composition, source: https://developer.android.com/guide/practices/ui_guidelines/icon_design_adaptive.html

To do this, we have to split our application icon into two separate layers:

  • A background layer: a solid colour, a gradient…
  • A foreground layer: typically contains the application’s main icon, which can be a raster image or a VectorDrawable.

Using these two layers, launchers apply a mask over them to display the final icon with a defined shape (circles, squares or more complex shapes, like squircles or teardrops). This also allows compatible launcher apps to animate both layers with different effects such as parallax.

Example of adaptive icon using our Camera app icon

We didn’t experience much trouble implementing the new icon format in our apps, especially since we already use VectorDrawables and drawables with layers in our applications to reduce their size (and to save our designers some headaches along the way 🙂 ). It should be relatively simple to reuse your existing launcher icons and adapt them to this new scheme.

Notification channels

Starting in Android Oreo, notification channels have been added to allow fine-grained control over how and when certain notifications should be displayed to the user. This also lets users manage which notifications they want to receive as well as how they want them to be displayed.

Google has already implemented notification channels for their apps, one example is Google Chrome

The process of creating and using a notification channel is quite simple:

  • Create a NotificationChannel with a unique ID and initial display settings: description, importance, sound, vibration, lights, privacy settings…
  • Provide this NotificationChannel to the NotificationManager via NotificationManager.createNotificationChannel().
  • Build your Notification the usual way (for example, we use NotificationCompat to support older Android versions).
  • Publish your Notification using the NotificationManager and your notification channel ID.

Keep in mind that it’s mandatory to implement at least one notification channel if your app targets Android Oreo. This is really important because when we first tested targeting Android Oreo, our notifications weren’t displayed at all!

Alert windows and overlays changes

In order to fortify the OS security measures, some functionality and behaviour changes have been made to avoid Android APIs being used with malicious intentions. One of these changes involves the use of alert windows and draw overlays.

The “alert windows” feature is a way to display views over other applications. Two of the most famous uses of this feature are the chat heads used in the Facebook Messenger app, which let users quickly see incoming messages and start conversations with their friends, and the “Tap to translate” feature in Google Translate, that lets users translate texts with a few taps without having to open the app.

Google Translate shows an overlay icon over other apps (such as Chrome) when using “Tap to translate”

This feature is not to be confused with the new Picture-In-Picture mode also added to Android Oreo, which focuses on video playback over other apps.

One of the advantages of using this feature up to Android Oreo was that we could draw over any interface element, including the notification bar, to enhance user experience. This was used by apps such as Twilight or Status to add new functionality on top of the current system capabilities. However, apps that now use these kinds of overlays and target Android Oreo must use a specific Window type (TYPE_APPLICATION_OVERLAY) that breaks drawing over system UI elements or the keyboard, for example. Furthermore, existing apps that use alert windows in Android Oreo (even without explicitly targeting it) won’t be able to draw over system UI elements either.

Keep this in mind if you want to target Android Oreo in your applications that have this kind of functionality because these changes may affect their behaviour, or even cause them to malfunction.

File Uris and permission changes

A new restriction was added starting from Android Nougat prevented developers from exposing file:// Uris in given contexts, giving a FileUriExposedException reminding us that we can’t use file:// Uris and that we should use content:// Uris with the correct permissions for other apps to use them.

In Android Oreo these restrictions seem to be more severe, causing us some trouble with sharing files that are stored in an app’s private storage (for example, when users send internal app logs via email for us to analyse).

To resolve this issue, we had to implement a FileProvider to expose our private files using a content:// Uri, and then generate our Uris with FileProvider.getUriForFile() to get Uris that external applications can read by adjusting the permissions granted to them.

Final thoughts

Adapting current applications to newer Android versions can be somewhat daunting, especially when major changes are introduced, however, in doing so, full advantage can be taken of the new features included in these versions, and users will be sure to get the best experience possible when using our devices. Many other changes have been introduced in Android Oreo that haven’t been covered in this post (beware background execution limits, among others), however, these key points will give you a good idea on where to start should you decide to prepare your apps to target Android Oreo.

References

Portions of this page are reproduced from work created and shared by the Android Open Source Project and used according to terms described in the Creative Commons 2.5 Attribution License.