Android's Autofill Framework is the system mechanism that lets a password manager or other autofill service fill credentials, addresses, and other fields in your app. Like the iOS equivalent, it is both a usability feature and a security one: it makes strong, manager-stored passwords the easy path, which is good for everyone. For your app, supporting it well means telling the system what your fields are for so legitimate autofill works, while excluding sensitive fields that should not be saved or filled. And if you build an autofill service, you hold credentials across every app, an extraordinary responsibility. Here is how the Autofill Framework works and how to handle both sides.
Short answer
The Android Autofill Framework lets a user's chosen autofill service, typically a password manager, fill fields in your app and save new ones. Per Android, you support it by marking your fields with autofill hints so the service can recognize them, which enables strong, manager-stored credentials, and by controlling which fields participate, excluding sensitive fields that should not be saved or autofilled. Your app's field structure is exposed to the autofill service the user selected. If you build an autofill service, you handle credentials and personal data across all apps, a serious responsibility under Google Play's policy, so never misuse that data. Support autofill for legitimate fields, exclude sensitive ones from it, and if providing autofill, handle the data with great care.
What you should know
- Autofill fills fields via the user's autofill service: usually a password manager.
- Mark fields with autofill hints: so the service recognizes them.
- It enables strong, manager-stored credentials: a security benefit.
- Exclude sensitive fields that should not be saved: control participation.
- Building an autofill service is high-trust: you see fields across apps.
How does autofill work, and what are the two angles?
A system service fills and saves fields, and you are on one of two sides. The table summarizes.
| Aspect | Detail |
|---|---|
| Autofill service | The user's chosen service, often a password manager |
| Autofill hints | Markings that tell the service what a field is for |
| Field structure | Your app's fields exposed to the autofill service |
| Excluding fields | Marking sensitive fields not to participate |
| Building a service | Seeing and filling fields across all apps |
The Autofill Framework works through an autofill service the user has chosen, commonly a password manager, which the system invokes to offer values for fields and to save newly entered ones. For your app to participate well, you mark your fields with autofill hints that describe what each is, a username, a password, an address, so the service can recognize and fill them correctly. In doing so, your app's field structure is made available to the autofill service the user selected, which is the trusted component on that side. The first angle is being an app that uses autofill, where the work is enabling it for legitimate fields and excluding sensitive ones. The second angle is building an autofill service, where your service sees and fills fields across every app the user uses, an entirely different level of trust. Both come back to credentials and personal data flowing through the framework.
How do you support autofill securely in your app?
Enable it for legitimate fields, and exclude what should not be saved. Mark your sign-in and form fields with the appropriate autofill hints so the user's password manager can recognize and fill them, which is good for security because it makes strong, unique, manager-stored credentials the easy path rather than encouraging weak, reused passwords. For password fields, ensure they are treated as the sensitive fields they are. At the same time, control which fields participate: exclude from autofill any sensitive field whose value should not be saved by an autofill service or offered later, for example a one-time value or a field holding data you do not want retained, by marking it as not important for autofill. The goal is that legitimate credentials and form data autofill smoothly, while fields that should not be captured are kept out of the autofill flow. Combine this with your broader handling of sensitive input. The principle is to embrace autofill where it helps users adopt strong credentials, and to deliberately exclude the specific fields that should not be saved or filled, rather than leaving participation to chance.
What if you build an autofill service?
Then you hold credentials across all apps, and the bar is very high. An autofill service you build is invoked to fill and save fields in every app the user uses, so it sees usernames, passwords, addresses, and other personal data across the whole device, which is one of the most sensitive positions an app can hold. The responsibility is to handle that data with great care: store the credentials and personal data it manages securely, never capture or transmit field data beyond what the service's function requires, be transparent about how it works, and comply with Google Play's policy for autofill services, which governs how they may handle user data. A service offering cloud sync of credentials must protect that data in storage and transit. Apply least privilege and never treat the access as an opportunity to harvest. The principle mirrors other high-trust capabilities: an autofill service is trusted with a user's credentials everywhere, so it must handle them minimally, securely, transparently, and within policy.
What to watch out for
The first trap, on the using side, is not marking fields with autofill hints, so password managers cannot fill them and users fall back to weaker passwords, or failing to exclude a sensitive field that should not be saved. The second, on the providing side, is building an autofill service that captures or transmits field data beyond its purpose, which violates trust and Google Play policy. The third is mishandling the sensitive credentials and data the framework carries. Autofill participation and any service are implemented in your app, so a pre-submission scan such as PTKD.com (https://ptkd.com), which reads the compiled APK or AAB against OWASP MASVS, assesses your data handling and, for a service, its permissions, while marking fields and handling autofill data are yours to implement.
What to take away
- The Android Autofill Framework lets a user's autofill service, usually a password manager, fill and save fields in your app, exposing your field structure to that chosen service.
- Support it by marking fields with autofill hints so legitimate fields fill, which encourages strong manager-stored credentials, and exclude sensitive fields that should not be saved or autofilled.
- If you build an autofill service, you hold credentials and personal data across all apps, so handle them securely and minimally, be transparent, and follow Google Play's policy.
- Use a pre-submission scan such as PTKD.com to assess your data handling and, for a service, its permissions, and implement autofill participation deliberately.
