Autofill Services Android Part-2

We learned how to make your apps suitable for Autofill services in the earlier installment of this series. This section demonstrates how to create our own Autofill Service. This post was influenced by Google’s Autofill sample project. Although the example project includes a variety of sophisticated situations, we’ll focus on a simple use case in which our Autofill service fills in basic user information such as username and password and saves the data when the user submits the answer.

The first step is to extend the AutofillService class and develop our own implementation of the autofill service.

After creating a service, we need to declare the same in the AndroidManifest.xml

“android.permission.BIND AUTOFILL SERVICE” is added to the android:permission attribute. After granting this permission, our app can be utilized as an Autofill Service, which must be enabled in the device settings by the user. We must also declare the <intent-filter> as required, which is used to specify the AutofillService action.

We’ll need to write some code to read the metadata from the incoming request and determine heuristic information about the edit text, such as if it accepts email, passwords, credit card numbers, and so on.
Take a look at the following example.

In this case, the Android system delivers an AssistStructure object as part of the FillRequest object. AutoFillHelper is a custom helper class that parses the structure of the view hierarchy and extracts the heuristic information.

To get the autofill data necessary to satisfy the request, autofill services can explore the ViewNode objects in the AssistStructure. Methods of the ViewNode class, such as getAutofillId(), can be used by a service to access autofill data. To see if it can satisfy the request, a service should be able to explain the contents of a view. The autofillHints property should be used first when describing the contents of a view by a service. Client apps, on the other hand, must explicitly include the property in their views before the service may use it. If a client app doesn’t supply the autofillHints property, the service should describe the contents using its own heuristics.

The required data is saved in a custom object called ParsedStructure, which can be used later to generate a FillResponse Object containing the Dataset. The service sends a FillResponse object to the onSuccess() method, which contains the Dataset objects.

SaveType

To store the data, the service must declare that it wants to keep it for future use. There is a fill request before the Android system sends a request to save the data, which allows the service to fill out the views. The service adds a SaveInfo object to the response of the previous fill request to indicate that it is interested in saving the data. At the very least, the SaveInfo object contains the following information:

• The type of information that would be saved about the user.
• The bare minimum of views that must be modified in order to initiate a save request. To trigger a save request, a login form, for example, normally requires the user to update the username and password views.

In the onSaveRequest() method, which is normally called when the client activity stops or when the client app calls commit, the autofill service can add logic to save the user input. The onSaveRequest() method is demonstrated in the following code:

Before persisting sensitive data, it is recommended that the autofill services should encrypt it.

We’ve covered the basics of autofill services so far, but there are some more advanced features available, such as requesting user authentication (biometric) before filling data, paginated data sets, and more. For the purposes of this post, we’ll keep it basic. If you’re interested in learning more about these advanced concepts, please let me know. I will plan to write about the same topics.

You can find the complete example here:

https://github.com/abhishekvichare/AndroidAutofillServiceDemo