AutofillService

public abstract class AutofillService
extends Service

java.lang.Object
   ↳ android.content.Context
     ↳ android.content.ContextWrapper
       ↳ android.app.Service
         ↳ android.service.autofill.AutofillService

An AutofillService is a service used to automatically fill the contents of the screen on behalf of a given user - for more information about autofill, read Autofill Framework.

An AutofillService is only bound to the Android System for autofill purposes if:

  1. It requires the android.permission.BIND_AUTOFILL_SERVICE permission in its manifest.
  2. The user explicitly enables it using Android Settings (the Settings.ACTION_REQUEST_SET_AUTOFILL_SERVICE intent can be used to launch such Settings screen).

Basic usage

The basic autofill process is defined by the workflow below:

  1. User focus an editable View.
  2. View calls AutofillManager.notifyViewEntered(android.view.View).
  3. A ViewStructure representing all views in the screen is created.
  4. The Android System binds to the service and calls onConnected().
  5. The service receives the view structure through the onFillRequest(android.service.autofill.FillRequest, android.os.CancellationSignal, android.service.autofill.FillCallback).
  6. The service replies through FillCallback.onSuccess(FillResponse).
  7. The Android System calls onDisconnected() and unbinds from the AutofillService.
  8. The Android System displays an autofill UI with the options sent by the service.
  9. The user picks an option.
  10. The proper views are autofilled.

This workflow was designed to minimize the time the Android System is bound to the service; for each call, it: binds to service, waits for the reply, and unbinds right away. Furthermore, those calls are considered stateless: if the service needs to keep state between calls, it must do its own state management (keeping in mind that the service's process might be killed by the Android System when unbound; for example, if the device is running low in memory).

Typically, the onFillRequest(android.service.autofill.FillRequest, android.os.CancellationSignal, android.service.autofill.FillCallback) will:

  1. Parse the view structure looking for autofillable views (for example, using AssistStructure.ViewNode.getAutofillHints().
  2. Match the autofillable views with the user's data.
  3. Create a Dataset for each set of user's data that match those fields.
  4. Fill the dataset(s) with the proper AutofillIds and AutofillValues.
  5. Add the dataset(s) to the FillResponse passed to FillCallback.onSuccess(FillResponse).

For example, for a login screen with username and password views where the user only has one account in the service, the response could be: 

 new FillResponse.Builder()
     .addDataset(new Dataset.Builder()
         .setValue(id1, AutofillValue.forText("homer"), createPresentation("homer"))
         .setValue(id2, AutofillValue.forText("D'OH!"), createPresentation("password for homer"))
         .build())
     .build();

But if the user had 2 accounts instead, the response could be: 

 new FillResponse.Builder()
     .addDataset(new Dataset.Builder()
         .setValue(id1, AutofillValue.forText("homer"), createPresentation("homer"))
         .setValue(id2, AutofillValue.forText("D'OH!"), createPresentation("password for homer"))
         .build())
     .addDataset(new Dataset.Builder()
         .setValue(id1, AutofillValue.forText("flanders"), createPresentation("flanders"))
         .setValue(id2, AutofillValue.forText("OkelyDokelyDo"), createPresentation("password for flanders"))
         .build())
     .build();

If the service does not find any autofillable view in the view structure, it should pass null to FillCallback.onSuccess(FillResponse); if the service encountered an error processing the request, it should call FillCallback.onFailure(CharSequence). For performance reasons, it's paramount that the service calls either FillCallback.onSuccess(FillResponse) or FillCallback.onFailure(CharSequence) for each onFillRequest(android.service.autofill.FillRequest, android.os.CancellationSignal, android.service.autofill.FillCallback) received - if it doesn't, the request will eventually time out and be discarded by the Android System.

Saving user data

If the service is also interested on saving the data filled by the user, it must set a SaveInfo object in the FillResponse. See SaveInfo for more details and examples.

User authentication

The service can provide an extra degree of security by requiring the user to authenticate before an app can be autofilled. The authentication is typically required in 2 scenarios:

When using authentication, it is recommended to encrypt only the sensitive data and leave labels unencrypted, so they can be used on presentation views. For example, if the user has a home and a work address, the Home and Work labels should be stored unencrypted (since they don't have any sensitive data) while the address data per se could be stored in an encrypted storage. Then when the user chooses the Home dataset, the platform starts the authentication flow, and the service can decrypt the sensitive data.

The authentication mechanism can also be used in scenarios where the service needs multiple steps to determine the datasets that can fill a screen. For example, when autofilling a financial app where the user has accounts for multiple banks, the workflow could be:

  1. The first FillResponse contains datasets with the credentials for the financial app, plus a "fake" dataset whose presentation says "Tap here for banking apps credentials".
  2. When the user selects the fake dataset, the service displays a dialog with available banking apps.
  3. When the user select a banking app, the service replies with a new FillResponse containing the datasets for that bank.

Another example of multiple-steps dataset selection is when the service stores the user credentials in "vaults": the first response would contain fake datasets with the vault names, and the subsequent response would contain the app credentials stored in that vault.

Data partitioning

The autofillable views in a screen should be grouped in logical groups called "partitions". Typical partitions are:

  • Credentials (username/email address, password).
  • Address (street, city, state, zip code, etc).
  • Payment info (credit card number, expiration date, and verification code).

For security reasons, when a screen has more than one partition, it's paramount that the contents of a dataset do not spawn multiple partitions, specially when one of the partitions contains data that is not specific to the application being autofilled. For example, a dataset should not contain fields for username, password, and credit card information. The reason for this rule is that a malicious app could draft a view structure where the credit card fields are not visible, so when the user selects a dataset from the username UI, the credit card info is released to the application without the user knowledge. Similarly, it's recommended to always protect a dataset that contains sensitive information by requiring dataset authentication (see Dataset.Builder.setAuthentication(android.content.IntentSender)), and to include info about the "primary" field of the partition in the custom presentation for "secondary" fields—that would prevent a malicious app from getting the "primary" fields without the user realizing they're being released (for example, a malicious app could have fields for a credit card number, verification code, and expiration date crafted in a way that just the latter is visible; by explicitly indicating the expiration date is related to a given credit card number, the service would be providing a visual clue for the users to check what would be released upon selecting that field).

When the service detects that a screen has multiple partitions, it should return a FillResponse with just the datasets for the partition that originated the request (i.e., the partition that has the AssistStructure.ViewNode whose AssistStructure.ViewNode.isFocused() returns true); then if the user selects a field from a different partition, the Android System will make another onFillRequest(android.service.autofill.FillRequest, android.os.CancellationSignal, android.service.autofill.FillCallback) call for that partition, and so on.

Notice that when the user autofill a partition with the data provided by the service and the user did not change these fields, the autofilled value is sent back to the service in the subsequent calls (and can be obtained by calling AssistStructure.ViewNode.getAutofillValue()). This is useful in the cases where the service must create datasets for a partition based on the choice made in a previous partition. For example, the 1st response for a screen that have credentials and address partitions could be: 

 new FillResponse.Builder()
     .addDataset(new Dataset.Builder() // partition 1 (credentials)
         .setValue(id1, AutofillValue.forText("homer"), createPresentation("homer"))
         .setValue(id2, AutofillValue.forText("D'OH!"), createPresentation("password for homer"))
         .build())
     .addDataset(new Dataset.Builder() // partition 1 (credentials)
         .setValue(id1, AutofillValue.forText("flanders"), createPresentation("flanders"))
         .setValue(id2, AutofillValue.forText("OkelyDokelyDo"), createPresentation("password for flanders"))
         .build())
     .setSaveInfo(new SaveInfo.Builder(SaveInfo.SAVE_DATA_TYPE_PASSWORD,
         new AutofillId[] { id1, id2 })
             .build())
     .build();

Then if the user selected flanders, the service would get a new onFillRequest(android.service.autofill.FillRequest, android.os.CancellationSignal, android.service.autofill.FillCallback) call, with the values of the fields id1 and id2 prepopulated, so the service could then fetch the address for the Flanders account and return the following FillResponse for the address partition: 

 new FillResponse.Builder()
     .addDataset(new Dataset.Builder() // partition 2 (address)
         .setValue(id3, AutofillValue.forText("744 Evergreen Terrace"), createPresentation("744 Evergreen Terrace")) // street
         .setValue(id4, AutofillValue.forText("Springfield"), createPresentation("Springfield")) // city
         .build())
     .setSaveInfo(new SaveInfo.Builder(SaveInfo.SAVE_DATA_TYPE_PASSWORD | SaveInfo.SAVE_DATA_TYPE_ADDRESS,
         new AutofillId[] { id1, id2 }) // username and password
              .setOptionalIds(new AutofillId[] { id3, id4 }) // state and zipcode
             .build())
     .build();

When the service returns multiple FillResponse, the last one overrides the previous; that's why the SaveInfo in the 2nd request above has the info for both partitions.

Package verification

When autofilling app-specific data (like username and password), the service must verify the authenticity of the request by obtaining all signing certificates of the app being autofilled, and only fulfilling the request when they match the values that were obtained when the data was first saved — such verification is necessary to avoid phishing attempts by apps that were sideloaded in the device with the same package name of another app. Here's an example on how to achieve that by hashing the signing certificates: 

 private String getCertificatesHash(String packageName) throws Exception {
   PackageManager pm = mContext.getPackageManager();
   PackageInfo info = pm.getPackageInfo(packageName, PackageManager.GET_SIGNATURES);
   ArrayList hashes = new ArrayList<>(info.signatures.length);
   for (Signature sig : info.signatures) {
     byte[] cert = sig.toByteArray();
     MessageDigest md = MessageDigest.getInstance("SHA-256");
     md.update(cert);
     hashes.add(toHexString(md.digest()));
   }
   Collections.sort(hashes);
   StringBuilder hash = new StringBuilder();
   for (int i = 0; i < hashes.size(); i++) {
     hash.append(hashes.get(i));
   }
   return hash.toString();
 }

If the service did not store the signing certificates data the first time the data was saved — for example, because the data was created by a previous version of the app that did not use the Autofill Framework — the service should warn the user that the authenticity of the app cannot be confirmed (see an example on how to show such warning in the Web security section below), and if the user agrees, then the service could save the data from the signing ceriticates for future use.

Ignoring views

If the service find views that cannot be autofilled (for example, a text field representing the response to a Captcha challenge), it should mark those views as ignored by calling FillResponse.Builder.setIgnoredIds(AutofillId...) so the system does not trigger a new onFillRequest(android.service.autofill.FillRequest, android.os.CancellationSignal, android.service.autofill.FillCallback) when these views are focused.

Web security

When handling autofill requests that represent web pages (typically view structures whose root's AssistStructure.ViewNode.getClassName() is a WebView), the service should take the following steps to verify if the structure can be autofilled with the data associated with the app requesting it:

  1. Use the AssistStructure.ViewNode.getWebDomain() to get the source of the document.
  2. Get the canonical domain using the Public Suffix List (see example below).
  3. Use Digital Asset Links to obtain the package name and certificate fingerprint of the package corresponding to the canonical domain.
  4. Make sure the certificate fingerprint matches the value returned by Package Manager (see "Package verification" section above).

Here's an example on how to get the canonical domain using Guava: 

 private static String getCanonicalDomain(String domain) {
   InternetDomainName idn = InternetDomainName.from(domain);
   while (idn != null && !idn.isTopPrivateDomain()) {
     idn = idn.parent();
   }
   return idn == null ? null : idn.toString();
 }

If the association between the web domain and app package cannot be verified through the steps above, but the service thinks that it is appropriate to fill persisted credentials that are stored for the web domain, the service should warn the user about the potential data leakage first, and ask for the user to confirm. For example, the service could:

  1. Create a dataset that requires authentication to unlock.
  2. Include the web domain in the custom presentation for the dataset value.
  3. When the user selects that dataset, show a disclaimer dialog explaining that the app is requesting credentials for a web domain, but the service could not verify if the app owns that domain. If the user agrees, then the service can unlock the dataset.
  4. Similarly, when adding a SaveInfo object for the request, the service should include the above disclaimer in the SaveInfo.Builder.setDescription(CharSequence).

This same procedure could also be used when the autofillable data is contained inside an IFRAME, in which case the WebView generates a new autofill context when a node inside the IFRAME is focused, with the root node containing the IFRAME's src attribute on AssistStructure.ViewNode.getWebDomain(). A typical and legitimate use case for this scenario is a financial app that allows the user to login on different bank accounts. For example, a financial app my_financial_app could use a WebView that loads contents from banklogin.my_financial_app.com, which contains an IFRAME node whose src attribute is login.some_bank.com. When fulfilling that request, the service could add an authenticated dataset whose presentation displays "Username for some_bank.com" and "Password for some_bank.com". Then when the user taps one of these options, the service shows the disclaimer dialog explaining that selecting that option would release the login.some_bank.com credentials to the my_financial_app; if the user agrees, then the service returns an unlocked dataset with the some_bank.com credentials.

Note: The autofill service could also add well-known browser apps into an allowlist and skip the verifications above, as long as the service can verify the authenticity of the browser app by checking its signing certificate.

Saving when data is split in multiple screens

Apps often split the user data in multiple screens in the same activity, specially in activities used to create a new user account. For example, the first screen asks for a username, and if the username is available, it moves to a second screen, which asks for a password.

It's tricky to handle save for autofill in these situations, because the autofill service must wait until the user enters both fields before the autofill save UI can be shown. But it can be done by following the steps below:

  1. In the first fill request, the service adds a client state bundle in the response, containing the autofill ids of the partial fields present in the screen.
  2. In the second fill request, the service retrieves the client state bundle, gets the autofill ids set in the previous request from the client state, and adds these ids and the SaveInfo.FLAG_SAVE_ON_ALL_VIEWS_INVISIBLE to the SaveInfo used in the second response.
  3. In the save request, the service uses the proper fill contexts to get the value of each field (there is one fill context per fill request).

For example, in an app that uses 2 steps for the username and password fields, the workflow would be: 

  // On first fill request
  AutofillId usernameId = // parse from AssistStructure;
  Bundle clientState = new Bundle();
  clientState.putParcelable("usernameId", usernameId);
  fillCallback.onSuccess(
    new FillResponse.Builder()
        .setClientState(clientState)
        .setSaveInfo(new SaveInfo
             .Builder(SaveInfo.SAVE_DATA_TYPE_USERNAME, new AutofillId[] {usernameId})
             .build())
        .build());

  // On second fill request
  Bundle clientState = fillRequest.getClientState();
  AutofillId usernameId = clientState.getParcelable("usernameId");
  AutofillId passwordId = // parse from AssistStructure
  clientState.putParcelable("passwordId", passwordId);
  fillCallback.onSuccess(
    new FillResponse.Builder()
        .setClientState(clientState)
        .setSaveInfo(new SaveInfo
             .Builder(SaveInfo.SAVE_DATA_TYPE_USERNAME | SaveInfo.SAVE_DATA_TYPE_PASSWORD,
                      new AutofillId[] {usernameId, passwordId})
             .setFlags(SaveInfo.FLAG_SAVE_ON_ALL_VIEWS_INVISIBLE)
             .build())
        .build());

  // On save request
  Bundle clientState = saveRequest.getClientState();
  AutofillId usernameId = clientState.getParcelable("usernameId");
  AutofillId passwordId = clientState.getParcelable("passwordId");
  List fillContexts = saveRequest.getFillContexts();

  FillContext usernameContext = fillContexts.get(0);
  ViewNode usernameNode = findNodeByAutofillId(usernameContext.getStructure(), usernameId);
  AutofillValue username = usernameNode.getAutofillValue().getTextValue().toString();

  FillContext passwordContext = fillContexts.get(1);
  ViewNode passwordNode = findNodeByAutofillId(passwordContext.getStructure(), passwordId);
  AutofillValue password = passwordNode.getAutofillValue().getTextValue().toString();

  save(username, password);

Privacy

The onFillRequest(android.service.autofill.FillRequest, android.os.CancellationSignal, android.service.autofill.FillCallback) method is called without the user content. The Android system strips some properties of the view nodes passed to this call, but not all of them. For example, the data provided in the ViewStructure.HtmlInfo objects set by WebView is never stripped out.

Because this data could contain PII (Personally Identifiable Information, such as username or email address), the service should only use it locally (i.e., in the app's process) for heuristics purposes, but it should not be sent to external servers.

Metrics and field classification

The service can call getFillEventHistory() to get metrics representing the user actions, and then use these metrics to improve its heuristics.

Prior to Android Build.VERSION_CODES.P, the metrics covered just the scenarios where the service knew how to autofill an activity, but Android Build.VERSION_CODES.P introduced a new mechanism called field classification, which allows the service to dynamically classify the meaning of fields based on the existing user data known by the service.

Typically, field classification can be used to detect fields that can be autofilled with user data that is not associated with a specific app—such as email and physical address. Once the service identifies that a such field was manually filled by the user, the service could use this signal to improve its heuristics on subsequent requests (for example, by infering which resource ids are associated with known fields).

The field classification workflow involves 4 steps:

  1. Set the user data through AutofillManager.setUserData(UserData). This data is cached until the system restarts (or the service is disabled), so it doesn't need to be set for all requests.
  2. Identify which fields should be analysed by calling FillResponse.Builder.setFieldClassificationIds(AutofillId...).
  3. Verify the results through FillEventHistory.Event.getFieldsClassification().
  4. Use the results to dynamically create Dataset or SaveInfo objects in subsequent requests.

The field classification is an expensive operation and should be used carefully, otherwise it can reach its rate limit and get blocked by the Android System. Ideally, it should be used just in cases where the service could not determine how an activity can be autofilled, but it has a strong suspicious that it could. For example, if an activity has four or more fields and one of them is a list, chances are that these are address fields (like address, city, state, and zip code).

Compatibility mode

Apps that use standard Android widgets support autofill out-of-the-box and need to do very little to improve their user experience (annotating autofillable views and providing autofill hints). However, some apps (typically browsers) do their own rendering and the rendered content may contain semantic structure that needs to be surfaced to the autofill framework. The platform exposes APIs to achieve this, however it could take some time until these apps implement autofill support.

To enable autofill for such apps the platform provides a compatibility mode in which the platform would fall back to the accessibility APIs to generate the state reported to autofill services and fill data. This mode needs to be explicitly requested for a given package up to a specified max version code allowing clean migration path when the target app begins to support autofill natively. Note that enabling compatibility may degrade performance for the target package and should be used with caution. The platform supports creating an allowlist for including which packages can be targeted in compatibility mode to ensure this mode is used only when needed and as long as needed.

You can request compatibility mode for packages of interest in the meta-data resource associated with your service. Below is a sample service declaration: 

 <service android:name=".MyAutofillService"
              android:permission="android.permission.BIND_AUTOFILL_SERVICE">
     <intent-filter>
         <action android:name="android.service.autofill.AutofillService" />
     </intent-filter>
     <meta-data android:name="android.autofill" android:resource="@xml/autofillservice" />
 </service>

In the XML file you can specify one or more packages for which to enable compatibility mode. Below is a sample meta-data declaration: 

 <autofill-service xmlns:android="http://schemas.android.com/apk/res/android">
     <compatibility-package android:name="foo.bar.baz" android:maxLongVersionCode="1000000000"/>
 </autofill-service>

Notice that compatibility mode has limitations such as:

  • No manual autofill requests. Hence, the FillRequest flags never have the FillRequest.FLAG_MANUAL_REQUEST flag.
  • The value of password fields are most likely masked—for example, **** instead of 1234. Hence, you must be careful when using these values to avoid updating the user data with invalid input. For example, when you parse the FillRequest and detect a password field, you could check if its input type has password flags and if so, don't add it to the SaveInfo object.
  • The autofill context is not always committed when an HTML form is submitted. Hence, you must use other mechanisms to trigger save, such as setting the SaveInfo.FLAG_SAVE_ON_ALL_VIEWS_INVISIBLE flag on SaveInfo.Builder.setFlags(int) or using SaveInfo.Builder.setTriggerId(AutofillId).
  • Browsers often provide their own autofill management system. When both the browser and the platform render an autofill dialog at the same time, the result can be confusing to the user. Such browsers typically offer an option for users to disable autofill, so your service should also allow users to disable compatiblity mode for specific apps. That way, it is up to the user to decide which autofill mechanism—the browser's or the platform's—should be used.

Summary

Constants

String EXTRA_FILL_RESPONSE

Name of the FillResponse extra used to return a delayed fill response.

String SERVICE_INTERFACE

The Intent that must be declared as handled by the service.

String SERVICE_META_DATA

Name under which a AutoFillService component publishes information about itself.

Inherited constants

Public constructors

AutofillService()

Public methods

final FillEventHistory getFillEventHistory()

This method was deprecated in API level 36. Use instead

final IBinder onBind(Intent intent)

Return the communication channel to the service.

void onConnected()

Called when the Android system connects to service.

void onCreate()

Called by the system when the service is first created. If you override this method you must call through to the superclass implementation.

void onDisconnected()

Called when the Android system disconnects from the service.

abstract void onFillRequest(FillRequest request, CancellationSignal cancellationSignal, FillCallback callback)

Called by the Android system do decide if a screen can be autofilled by the service.

abstract void onSaveRequest(SaveRequest request, SaveCallback callback)

Called when the user requests the service to save the contents of a screen.

void onSavedDatasetsInfoRequest(SavedDatasetsInfoCallback callback)

Called from system settings to display information about the datasets the user saved to this service.

void onSessionDestroyed(FillEventHistory history)

Called when an Autofill context has ended and the Autofill session is finished.

Inherited methods

Constants

EXTRA_FILL_RESPONSE

Added in API level 33 
public static final String EXTRA_FILL_RESPONSE

Name of the FillResponse extra used to return a delayed fill response.

Please see FillRequest.getDelayedFillIntentSender() on how to send a delayed fill response to framework.

Constant Value: "android.service.autofill.extra.FILL_RESPONSE"

SERVICE_INTERFACE

Added in API level 26 
public static final String SERVICE_INTERFACE

The Intent that must be declared as handled by the service. To be supported, the service must also require the Manifest.permission.BIND_AUTOFILL_SERVICE permission so that other applications can not abuse it.

Constant Value: "android.service.autofill.AutofillService"

SERVICE_META_DATA

Added in API level 26 
public static final String SERVICE_META_DATA

Name under which a AutoFillService component publishes information about itself. This meta-data should reference an XML resource containing a <autofill-service> tag. This is a a sample XML file configuring an AutoFillService: 

 <autofill-service
     android:settingsActivity="foo.bar.SettingsActivity"
     . . .
 />

Constant Value: "android.autofill"

Public constructors

AutofillService

public AutofillService ()

Public methods

getFillEventHistory

Added in API level 26
Deprecated in API level 36 
public final FillEventHistory getFillEventHistory ()

This method was deprecated in API level 36.
Use instead

Gets the events that happened after the last onFillRequest(android.service.autofill.FillRequest, android.os.CancellationSignal, android.service.autofill.FillCallback) call.

This method is typically used to keep track of previous user actions to optimize further requests. For example, the service might return email addresses in alphabetical order by default, but change that order based on the address the user picked on previous requests.

The history is not persisted over reboots, and it's cleared every time the service replies to a onFillRequest(android.service.autofill.FillRequest, android.os.CancellationSignal, android.service.autofill.FillCallback) by calling FillCallback.onSuccess(android.service.autofill.FillResponse) or FillCallback.onFailure(CharSequence) (if the service doesn't call any of these methods, the history will clear out after some pre-defined time). Hence, the service should call getFillEventHistory() before finishing the FillCallback.

Returns
FillEventHistory The history or null if there are no events.
Throws
RuntimeException if the event history could not be retrieved.

onBind

Added in API level 26 
public final IBinder onBind (Intent intent)

Return the communication channel to the service. May return null if clients can not bind to the service. The returned IBinder is usually for a complex interface that has been described using aidl.

Note that unlike other application components, calls on to the IBinder interface returned here may not happen on the main thread of the process. More information about the main thread can be found in Processes and Threads.

Parameters
intent Intent: The Intent that was used to bind to this service, as given to Context.bindService. Note that any extras that were included with the Intent at that point will not be seen here.
Returns
IBinder Return an IBinder through which clients can call on to the service.

onConnected

Added in API level 26 
public void onConnected ()

Called when the Android system connects to service.

You should generally do initialization here rather than in onCreate().

onCreate

Added in API level 26 
public void onCreate ()

Called by the system when the service is first created. Do not call this method directly. If you override this method you must call through to the superclass implementation.

onDisconnected

Added in API level 26 
public void onDisconnected ()

Called when the Android system disconnects from the service.

At this point this service may no longer be an active AutofillService. It should not make calls on AutofillManager that requires the caller to be the current service.

onFillRequest

Added in API level 26 
public abstract void onFillRequest (FillRequest request, 
                CancellationSignal cancellationSignal, 
                FillCallback callback)

Called by the Android system do decide if a screen can be autofilled by the service.

Service must call one of the FillCallback methods (like FillCallback.onSuccess(FillResponse) or FillCallback.onFailure(CharSequence)) to notify the result of the request.

Parameters
request FillRequest: the request to handle. See FillResponse for examples of multiple-sections requests. This value cannot be null.
cancellationSignal CancellationSignal: signal for observing cancellation requests. The system will use this to notify you that the fill result is no longer needed and you should stop handling this fill request in order to save resources. This value cannot be null.
callback FillCallback: object used to notify the result of the request. This value cannot be null.

onSaveRequest

Added in API level 26 
public abstract void onSaveRequest (SaveRequest request, 
                SaveCallback callback)

Called when the user requests the service to save the contents of a screen.

If the service could not handle the request right away—for example, because it must launch an activity asking the user to authenticate first or because the network is down—the service could keep the request and reuse it later, but the service must always call SaveCallback.onSuccess() or SaveCallback.onSuccess(android.content.IntentSender) right away.

Note: To retrieve the actual value of fields input by the user, the service should call AssistStructure.ViewNode.getAutofillValue(); if it calls AssistStructure.ViewNode.getText() or other methods, there is no guarantee such method will return the most recent value of the field.

Parameters
request SaveRequest: the request to handle. See FillResponse for examples of multiple-sections requests. This value cannot be null.
callback SaveCallback: object used to notify the result of the request. This value cannot be null.

onSavedDatasetsInfoRequest

Added in API level 31 
public void onSavedDatasetsInfoRequest (SavedDatasetsInfoCallback callback)

Called from system settings to display information about the datasets the user saved to this service.

There is no timeout for the request, but it's recommended to return the result within a few seconds, or the user may navigate away from the activity that would display the result.

Parameters
callback SavedDatasetsInfoCallback: callback for responding to the request This value cannot be null.

onSessionDestroyed

Added in API level 36 
public void onSessionDestroyed (FillEventHistory history)

Called when an Autofill context has ended and the Autofill session is finished. This will be called as the last step of the Autofill lifecycle described in AutofillManager.

This will also contain the finished Session's FillEventHistory, so providers do not need to explicitly call getFillEventHistory()

This will usually happens whenever AutofillManager.commit() or AutofillManager.cancel() is called.

Parameters
history FillEventHistory: This value may be null.