Learn about the Autofill Framework introduced in Android O.
Users can save time filling out forms by using autofill in their devices. Android O makes filling forms, such as account and credit card forms, easier with the introduction of the Autofill Framework. The Autofill Framework manages the communication between the app and an autofill service.
Benefits
Filling out forms is a time-consuming and error-prone task. Users can easily get frustrated with apps that require these type of tasks. The Autofill Framework improves the user experience by providing the following benefits:
- Less time spent in filling fields Autofill saves users from re-typing information.
- Minimize user input errors Typing is prone to errors, especially in mobile devices. Removing the necessity of typing information also removes the errors that come with it.
Prerequisites
Before apps can work with the Autofill Framework, an autofill service must be enabled in the system settings. Users can enable or disable autofill as well as change the autofill service in Settings > Apps & Notifications > Default apps > Autofill app.
An app can serve the role of the autofill service, which manages autofill data and fills other apps' fields. For more information about how to build an autofill service, see Autofill Framework sample.
An autofill service can require the user to authenticate before the autofill data can be used to complete fields in your app. You don't need to update your app to handle this scenario because this authentication happens on the service.
Optimizing your app for autofill
Apps that use standard views work with the Autofill Framework out of the box. However, you can take some steps to optimize how your app works with the framework.
Ensuring data is available
In some special cases, you need to take additional steps to make sure that the
data is available to the Autofill Framework to save. For example, an activity
can present a layout with standard text views, but then destroy the layout and
replace it with one without child views, such as
GLSurfaceView.
In this case, the data in the original layout is not available to the framework.
To make the data available to the framework you should call
reset() on the
AutoFillManager object before replacing the
original layout.
Support for custom views
Custom views can specify the metadata that is exposed to the Autofill Framework by using the autofill API. Some views act as a container of virtual children, such as views that contain OpenGL rendered UI. These views must use the API to specify the structure of the information used in the app before they can work with the Autofill Framework.
If your app uses custom views, you must consider the following scenarios:
- The custom view provides a view structure by default, which is referred to as a standard view structure in this document.
- The custom view has a view structure that is not available to the Autofill Framework. This type of view structure is referred to as virtual structure.
Custom views with standard view structure
Custom views can define the metadata that autofill requires to work. You should make sure that your custom view manages the metadata appropriately to work with the Autofill Framework. Your custom view should take the following actions:
- Handle the autofill value that the framework sends to your app.
- Provide the autofill type and value to the framework.
When an autofill event is triggered, the Autofill Framework sends the autofill
value to your view. You should specify how your custom view handles this value
by implementing autoFill(AutoFillValue).
Your view should specify an autofill type and value by overriding the
getAutoFillType() and
getAutoFillValue() methods respectively. This ensures
that your view can provide appropriate autofill type and value to the framework.
Finally, autofill shouldn't fill the view if the user can't provide a value for
the view in its current state (for example, if the view is disabled). In these
cases, getAutoFillType() and
getAutoFillValue() should return null and
autoFill(AutoFillValue) should do nothing.
The following cases require additional steps to properly work within the
framework:
- The custom view is editable.
- The custom view can be marked as sanitized or not sanitized.
If the view is editable, you should notify the Autofill Framework about changes
by calling valueChanged(View) on the
AutoFillManager object.
If the view contains personally identifiable information (PII) —sensitive data,
such as email addresses, credit card numbers, and passwords—, then it should be
marked as not sanitized. In contrast, if the view doesn't contain PII, then
it should be marked as sanitized. In general, views whose content come from
static resources are sanitized, but views whose content is dynamically set is
not. For example, a label that contains type your user name is sanitized,
while a label that contains Hello, John is not. To mark the view as sanitized
or not sanitized, implement onProvideAutoFillStructure(ViewStructure, int)
and call setSanitized(boolean) on the
ViewStructure object.
The following code example shows an example of how to determine whether the view structure should be sanitized or not:
@Override
public void onProvideAutoFillStructure(ViewStructure structure, int flags) {
super.onProvideAutoFillStructure(structure, flags);
// Content that comes from static resources should be marked as sanitized.
boolean sanitized = contentIsSetFromResources();
structure.setSanitized(sanitized);
}
Custom views with virtual structure
The Autofill Framework requires a view structure before it can start saving and filling the UI in your app. There are some situations where the view structure is not available to the framework, for example:
- The app uses a low-level rendering engine, such as OpenGL, to render the UI.
- The app uses a
Canvasto draw the UI.
In these cases, you can specify a view structure by implementing
onProvideAutoFillVirtualStructure(ViewStructure, int) to add children by
using the addChildCount(int) and
newChild(int, int, int) methods and adding
relevant properties such as the autofill value and type. If the virtual children
are sanitized, you should pass true to
setSanitized(boolean) or false otherwise.
The following code example shows how to create a new child in the virtual structure:
@Override
public void onProvideAutoFillVirtualStructure(ViewStructure structure, int flags) {
super.onProvideAutoFillVirtualStructure(structure, flags);
// Create a new child in the virtual structure.
structure.addChildCount(1);
ViewStructure child =
structure.newChild(childIndex, childVirtualId, childFlags);
// Populate the child by providing properties such as value and type.
child.setAutoFillValue(childAutoFillValue);
child.setAutoFillType(childAutoFillType);
// Some children can provide a list of values. For example, if the child is
// a spinner.
child.setAutoFillOptions(childAutoFillOptions);
// Just like other types of views, mark the child as sanitized if
// appropriate.
boolean sanitized = contentIsSetFromResources();
child.setSanitized(sanitized);
}
Finally, you should notify the framework about changes in the structure by performing the following tasks:
- If the focus inside the children changes, call
virtualFocusChanged(View, int, Rect, boolean)on theAutoFillManagerobject. - If the value of a child changes, call
virtualValueChanged(View, int, AutoFillValue)on theAutoFillManagerobject. - If the view hierarchy is no longer available (for example, when an HTML page
is submitted), call
reset()on theAutoFillManagerobject.
Known issues
- A known bug causes the system to stop responding when the user selects
the autofill UI of a non-text field (like a
Spinner,CheckBox, orRadioGroup) that is part of the data sent by the autofill service. - The "Android System app displaying on top" card displays in the notification drawer when there is an autofill dialog present. Ignore this card and avoid selecting "TURN OFF" (doing so will disable autofill indefinitely).