Getting Android’s Autofill to Work for You
Oreo (8.0) added framework support for autofill, allowing users to easily autofill login credentials, addresses, and more. For the most part, the autofill APIs work very well, but there are a few quirks to watch out for.
The benefits are well worth the development cost. Our browsers have been autofilling that information for us for years, so why can’t our apps? Similarly, users who use a password manager have to switch between apps to get the right password. Anything you can do to simplify these processes will make you users much happier!
Using autofill
I won’t go in depth on how to add basic autofill support for your apps because Google already has excellent documentation on getting started here.
For many use cases autofill will simply work out of the box on Oreo.
If autofill doesn’t work as you expect it to, you will need to do some work to tell autofill how to work with your layout. You do this using the new android:autofillHints attribute to tell autofill what type of content you expect, and android:importantForAutofill to tell autofill which views you want (or do not want) to be filled.
How autofill works
Autofill works with two primary components.
- An Autofill Service, which is an app on the user’s device that can provide data to fill in other apps.
- Your app, which provides hints to the autofill service about what types of data your Views are interested in
Note that while your user may have multiple autofill services installed, only one can be active at a time.
When focus in your app moves to a View that supports autofill, the autofill service will get an opportunity to provide content. Autofill services rely on a variety of attributes to determine what content to provide. Services should use the autofillHints first, but if the hints aren’t clear enough, they might also use the View’s hint text, ID, type, or other properties.
If you want to learn more about how that process works, check out Google’s Build an Autofill Service documentation.
Not all autofill services are equal
One problem you may run into is that not all autofill services are capable of filling the same types of content. While Google’s autofill service can fill in credentials, addresses, phone numbers, credit card information, and more, Dashlane only supports credentials (at the time of writing this article).
This means that based on which autofill service your user selects, they may or may not get autofill options for your app.
Unfortunately there is no getting around this inconsistency. I hope that Google will encourage developers to support a greater (and more consistent) range of content, but that’s tricky to do. It would be nice if you could select a different service for different content types, but I don’t anticipate that happening.
Parsing inconsistency
Each autofill service is responsible for creating its own heuristics for parsing your inputs to determine what content to fill in.
Google’s service is really good at this. It can take a set of fields marked as address fields and correctly determine where to put each component of the address.
Other services may not perform as well. They will almost certainly use different heuristics, and that may result in inconsistent behavior.
As an example of when this might be a problem, think about an address form. This form might be split up into multiple Views- the street address, the city, the state, and the ZIP code. The only address-related autofill hint that Android offers is postalAddress, so all those Views will get the same postalAddress autofill hint. A smart autofill service will then look at the ordering of the Views, the hint text on those fields, and other indicators to figure out which components of the address belong in which View. I have a feeling this complexity is part of why not all autofill services support addresses and other data types.
The approach I took to mitigate this risk was to provide extra autofill hints. Google’s documentation suggests that you use the View.AUTOFILL_HINT_ constants for your hints. However, you can add as many hints as you want . In XML you separate items with commas, in Java/Kotlin you just pass a list. On the web Chrome supports a wide range of hints, for example breaking up name into family-name and given-name. You can provide these hints in addition to Android’s pre-defined hints and other services may consider using those hints as well.
Data formatting
One last issue may run into is that the data the autofill service provides may not be in a format that is usable in your application.
For example, Google’s autofill service may fill in a phone number that includes the country code (e.g. “+1 (555) 555–5555”). Your application may not want to display or consume the country code.
Unfortunately there is no good framework approach to sanitizing data coming from autofill. You can however work around it by creating a custom view and overriding the new autofill() method:
I would really like to see a more flexible approach from the Android team that allows for doing this type of sanitation on any type of view. There is an open feature request here if you are interested in a solution as well.
Testing suggestions
One last note: When testing your app with autofill, I highly recommend running Google’s sample autofill service. It has very basic parsing heuristics for determining how to fill inputs and it supports a wide variety of data types. Because you have access to the source you can see exactly what is happening and debug the behavior.
The biggest problem with a production autofill service when testing your app is that it is a black box. You don’t know what it is doing to determine what data to fill in. The sample autofill service allows you to pull back that curtain, and also lets you manage the data more easily. Google’s autofill service for example doesn’t make it particularly easy to manage your addresses for autofill, but you can easily generate data with the sample service.
Hopefully with these tips you will be able to better manage and work with Android’s autofill framework!
