.png)
It’s already been a month since Google released the first Android O Developer Preview (time sure flies by fast!), and as with any new version of Android – there’s a lot to dig into. We’ve published plenty of articles about Android O already, but there’s one feature that I feel hasn’t really received the attention it deserves: the Autofill Framework.
Autofill in Android O
Password managers are a dime a dozen these days (though we’re partial to the open-source KeePass), but it’s only with Android O that Google truly officially supports password managers. With Android O, third-party applications can fill the roll of an autofill service, which communicate with apps through the new Autofill Framework. Apps that use standard View elements will work with the Autofill Framework out of the box, though there are additional steps that developers can take to optimize for autofill to ensure that any of the app’s custom Views can be autofilled.
When an autofillable View comes into focus, the Autofill Framework will invoke an autofill request. The autofill service responds by sending back certain Autofill Datasets (such as the username, password, address, credit card numbers, etc.) that the user can then select. The autofill service is specified by the user in Settings –> Apps & Notifications –> Default Apps –> Autofill app.
The explanation of the new Autofill Framework above is just a brief summary of what is happening on both the requesting app’s and the autofill service’s end. What’s most important for your understanding here is not the exact details of how autofill works in Android O, but the fact that the password manager apps themselves no longer handle detecting when a View can be autofilled.
Recommended Reading: AgileBits shows off what Android O’s Autofill Framework will look like
Autofill before Android O
Compare that to how autofill worked before Android O. Before password managers had any sort of official method to detect when a View could be autofilled, each application had to implement an Accessibility Service to scan the current View in order to find autofillable fields.
The use of an Accessibility Service, however, can result in considerable lag under certain conditions. The lag associated with your typical password manager’s Accessibility Service, though, is so apparent that popular services such as LastPass even have support pages up regarding the issue. These support pages typically tell you that your only recourse for dealing with excessive lag caused by their Accessibility Service is to either disable the Accessibility Service or switch to using their own custom input method. Either way, you lose any sort of autofill ability.
But why exactly does LastPass’s Accessibility Service, or any other password manager’s Accessibility Service, seem to cause so much lag? The reason is because of how these password managers have to utilize Accessibility Services to detect input fields. An Accessibility Service’s attributes are defined in an XML resource file within the APK, so we can see how the Service works by decompiling the APK file.
Below is the resource file taken from decompiling the LastPass APK:
<?xml version="1.0" encoding="utf-8"?>
<accessibility-service android:description="@string/accessibility_service_description"
android:accessibilityEventTypes="typeViewFocused|typeWindowContentChanged"
android:accessibilityFeedbackType="feedbackGeneric"
android:notificationTimeout="200"
android:accessibilityFlags="flagReportViewIds"
android:canRetrieveWindowContent="true"
android:canRequestEnhancedWebAccessibility="true"
xmlns:android="http://schemas.android.com/apk/res/android" />From this, we can glean the following information: LastPass’s Accessibility Service requests two Event types to monitor – TYPE_VIEW_FOCUSED and TYPE_WINDOW_CONTENT_CHANGED. It does this because it needs to know when an app/webpage’s content changes or comes into focus, and then it retrieves the current window content to look for any password input fields. But since the service constantly does this on two extremely frequently firing Accessibility Events, it results in lag. For a more in-depth discussion of how Accessibility Services can cause lag, I refer to you my previous article on the matter.
Recommended Reading: “Working as Intended” – An Exploration into Android’s Accessibility Lag
Android O Kills Two Birds with One Stone
Prior to Android O, there’s not really much developers of password managers could do to mitigate this lag. That’s because password managers had no way of knowing when an autofillable input field was on the screen without enabling an Accessibility Service to constantly monitor for them. But thanks to the new Autofill Framework in Android O, these password managers can now retire their Accessibility Services. Instead, the apps that need data entry themselves will request the Autofill Framework to call the autofill service that will then send the data. Thanks to this new framework, not only will password entry become much easier for users since they no longer have to rely on an additional input method, but the lag associated with enabling password managers’ Accessibility Services will be a thing of the past.
I know that for some of you, this fact may not be ground-breaking, but I thought that since the discussion around the Accessibility Service was so mute this topic might have been worth rekindling. Just some food for thought this weekend!
What do you think of Android O’s new Autofill Framework? Let us know in the comments below!
