Diving Deeper into Android O

by Aman Alam

It’s Google I/O season, and that means announcements. In my previous post, Google I/O 2017: What’s New for Android Developers, I hit the high points, and in this post I want to go deeper into what Android offers developers, some problems that have been solved, and the changes you need to make to your apps.

Let’s look at some exciting changes in detail.

The Autofill Framework

Android developers and designers have had to come up with various workarounds to autofill. And so it’s with some relief that Android O introduces a system-wide Autofill Framework that prompts the user with a drop-down list of suggestions. Pretty much like how it happens on the web.

It’s not clear from the documentation where the Autofill Framework learns the suggestions, but I can guess it’s from the logged-in user’s Chrome usage, and similar usage on other apps.

Autofill will work across the system by default, but you can specify which of your input fields correspond to what kind of data, by “hinting” the OS. This can be done from the xml-layout, as well as from the code.

An example of where this will work great is on a payments screen where you ask the users their credit card information. You can give a hint in the EditText as android:autofillHints="creditCardNumber" in the XML of the view, and as AUTOFILL_HINT_CREDIT_CARD_NUMBER if you want to set this from the code.

Android will display a range of credit card numbers they have entered earlier. For the specific XML layout of the above credit card example see the code sample.

You can find the full documentation on Autofill Framework here.

Emoji Compat Library

Admit it, we live with a new language – emojis. If you’re building apps which facilitate text communication between users, you have to deal with text messages transmitting emojis. Currently, if your users uses the emoji keyboard to send an emoji and your app doesn’t support it, they’d see a ☐ instead of the emoji.

Android O introduces an EmojiCompat library to help developers support displaying emojis. It’s a Compat library, so it supports Android versions 4.4 (API level 19) and up, which means almost all of your users should be covered.

The EmojiCompat library requires you to add its dependency in your build.gradle file to use it:

After this, you have to initialize the EmojiCompat with a configuration, so that it can download the appropriate font to display emojis. Here’s a graphic from developer.android.com showing how the process works:

The EmojiCompat library also introduces new widgets that you can use in your XML, such as EmojiTextView and EmojiEditText. Learn more about how to use widgets with EmojiCompat library, here.

There’s more information like this, along with how to initialize and use the EmojiCompat library, in the EmojiCompat Library documentation, here.

Downloadable Fonts

You can now download fonts in the apps instead of bundling them with your app. This reduces your APK size, increasing the chances of people installing your apps. (This is also true of the EmojiCompat library.)

The process can also be accomplished by using the Support Library 26, which backports this capability all the way down to API 14, which is Android 4.0.1 Ice Cream Sandwich.

The architecture is designed in a way that your app, along with other apps, requests a particular font to be downloaded, by making a FontRequest to a FontProvider which will get the font for you if it’s not already available.

A FontProvider is something like Google Fonts, which should support providing fonts to Android apps, and you can think of it as very similar to how Google Fonts works on the web. Google Fonts has detailed how to use it as a provider in Android apps, you might want to check that out, it’s a great start.

Do keep in mind that your app has to make an explicit request to download the fonts before you can use them. You can also specify this in the manifest, so that the system downloads these fonts for you.

You can use these fonts in XML definitions of widgets, as well as in the code, and it’s failsafe, so if the font download is not successful, the views fallback on the default font.

These and more details here.

Fonts in XML

This is my personal favorite. If you’ve ever tried to set a custom font in your Text related views from XML, you’d have found it’s impossible. Vexed? You weren’t alone. Thousands of developers felt that way, and this was one of the oldest and most requested feature request. The original Android issue tracker request was opened in 2008.

If you’ve been using any of the popular third-party libraries to set fonts on TextViews from XML, like Calligraphy, the process will look very straight-forward – drop your custom fonts in the res/fonts folder, make a font-family, and refer it from the XML.

You can use these fonts in your XML, as well as in your code. Although with downloadable fonts, this shouldn’t be required most of the time, but we still have an option.

To know details on how to get this to work, refer to the documentation here.

Cherry on the cake: You can even preview these fonts in the design window of your XML layouts!

Room Persistence Library

If you’ve used any of the ORM libraries such as GreenDAO or SugarORM, the same functionality is now supported natively with Android O. This is good news, since your APK size will shrink, and you can expect good support from Google on it.

The process is very similar too, and uses annotations heavily to define columns and their attributes inside a Java class. It uses another Java class as a Data Access Object (DAO), supported with annotations, again, to run operations on the database.

For example, the following snippet, borrowed from Android documentation, represents a table’s schema in SQLite database:

And further, you can create DAOs to do operations on this table/entity. I deal with persistence-heavy apps a lot, and I’m super excited about how intuitive this is.

This very neat and detailed guide is available in the Android documentation to get you started quickly. And if you’ve been abstracting your apps’ codebase effectively, it shouldn’t take you too long to switch to Room.

Improvements to Job Scheduler

Starting from Android O, there are tougher restrictions on what your app’s background services can do. To support a smoother functioning of all of your app’s features, Android O introduces quite a few improvements to Job Scheduler.

Job Scheduler can now take a queue of requests, and keep continuing to process them one by one, much like how a queue of IntentService used to do earlier. It also introduces new parameters to let you check whether storage is available, whether battery is too low, or if the user is on a metered network such as mobile data, to specify whether the Job Scheduler should execute a job or not.

A good overview of improvements to Job Scheduler, is here.


You may not call all of these really new features, but definitely some very important optimizations. Some will help you reduce your app’s APK size, or have a more engaging and efficient app, which means more happy users. I am personally excited about these announcements, and they bode well for both new and existing Android apps.

The latest Android version, Android O, is scheduled for a Developer Preview Update by July, and this means you should have plenty of time to review and implement the changes before the official rollout in Q3.

Categories: Events, Technology

Suggested Article