Skip to content

Most visited

Recently visited


Autofill Framework

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.


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:


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:

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:

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:

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:

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();

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:

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:

public void onProvideAutoFillVirtualStructure(ViewStructure structure, int flags) {
    super.onProvideAutoFillVirtualStructure(structure, flags);

    // Create a new child in the virtual structure.
    ViewStructure child = 
        structure.newChild(childIndex, childVirtualId, childFlags);

    // Populate the child by providing properties such as value and type.

    // Some children can provide a list of values. For example, if the child is
    // a spinner.

    // Just like other types of views, mark the child as sanitized if
    // appropriate.
    boolean sanitized = contentIsSetFromResources();

Finally, you should notify the framework about changes in the structure by performing the following tasks:

Known issues

This site uses cookies to store your preferences for site-specific language and display options.


This class requires API level or higher

This doc is hidden because your selected API level for the documentation is . You can change the documentation API level with the selector above the left navigation.

For more information about specifying the API level your app requires, read Supporting Different Platform Versions.

Take a one-minute survey?
Help us improve Android tools and documentation.