Android API 22以下设备替代Autofill Framework的实现方案咨询

针对API Level 22及以下设备，完全可以避开GET_ACCOUNTS权限（该权限权限范围冗余，还会触发联系人访问提示），采用以下更优的实现方式：

1. 本地加密存储+自定义填充逻辑 #

这是最通用、可控性最高的方案：

• 核心思路：将用户需要填充的敏感信息（如账号、密码、地址等）加密后存储在本地（推荐用EncryptedSharedPreferences，API 11+支持；或自行实现AES加密后存入SharedPreferences/SQLite），在需要填充的输入框触发焦点事件时，主动提供填充选项。
• 具体实现：
  • 监听EditText的onFocusChange事件，当输入框获取焦点时，弹出自定义弹窗/下拉列表展示已保存的可填充内容；
  • 根据输入框的类型（如通过android:inputType判断是用户名、密码还是地址输入框），自动匹配本地存储的对应数据，一键填充。
• 优势：无需任何系统权限，数据存储在本地，隐私安全可控，适配所有API 11+设备。

2. 对接第三方密码管理器（兼容性有限） #

如果你的应用需要跨场景填充，可以对接主流第三方密码管理器的低版本适配接口：

• 核心思路：部分第三方密码管理器在API 22以下提供了自定义的填充协议，通过Intent或绑定服务的方式，从这些应用中获取已保存的账号信息并填充。
• 具体实现：检测设备上是否安装了支持该协议的应用，若存在则调用其提供的接口请求填充数据，再将数据写入输入框。
• 优势：无需自己维护存储和加密逻辑，借助成熟的第三方服务实现跨应用填充；
• 局限：依赖用户设备上已安装对应第三方应用，兼容性无法保证。

3. 应用内账号数据直接复用 #

如果仅需实现应用内场景的自动填充，这是最轻量化的方案：

• 核心思路：利用应用自身的账号系统，在用户登录后，将其常用的关联数据（如收货地址、常用手机号）存储在应用的用户数据模块中，当进入对应页面时直接读取填充。
• 具体实现：比如用户在个人中心设置了默认收货地址，进入下单页面时，自动将地址字段填充为默认值；登录页面在用户成功登录后，下次打开自动填充用户名。
• 优势：完全基于应用自身数据，无需额外权限，用户体验连贯，适配所有版本设备。

额外说明 #

GET_ACCOUNTS权限本身的设计目的是获取系统账号列表，仅能获取账号名称，无法获取密码等敏感信息，用来实现自动填充不仅权限范围过大（触发联系人访问提示），功能上也无法满足完整的填充需求，因此上述方案均优于该实现方式。

内容的提问来源于stack exchange，提问作者Ritika Pahwa