Android 的 Auto Fill 服务安全性，密码管理器的新要求
Android 的 Auto Fill 服务安全性，密码管理器的新要求
Android 15 的 Developer Preview 放出来之后，我扫了一遍 Autofill 相关的 API diff。没发现什么振奋人心的大更新，但字里行间透着一股微妙的引导意味。Google 官方文档里开始出现越来越多这样的句式：「对于新应用，建议迁移至 Credential Manager」，「Autofill Framework 仍受支持，但部分功能已被 Credential Manager 取代」。翻译成人话就是：那个从 Android 8.0 开始让第三方密码管理器能接入系统层的 Autofill Framework，现在虽然还没被钉上 deprecated 的标签，但已经被抬进了 ICU。更耐人寻味的是，这轮交接被包装成了「安全性升级」和「用户隐私保护」的叙事。可如果你仔细翻看过去两年 Google 对密码管理器生态的动作，会发现事情没那么单纯。
Autofill Framework 的八年之痒
把时间拨回 2017 年，Android 8.0（API 26）引入了 AutofillService。这套框架的设计思路在当时看相当合理：系统维护一个全局的自动填充服务列表，当用户聚焦到带有 autofillHints 的输入框时，框架通过 onFillRequest 把当前界面的 AssistStructure 打包发给用户指定的密码管理器。第三方应用拿到这个结构体，解析出域名和字段类型，匹配本地保险库里的条目，再把候选数据通过 Dataset 和 FillResponse 回传给系统，最终以悬浮窗或内嵌建议的形式呈现给用户。
1Password、Bitwarden、Dashlane 这些老牌工具迅速跟进，在 Android 上终于拥有了与 iOS Keychain 对等的系统级入口。那时候的体验虽然比不上苹果生态的丝滑，但至少第三方密码管理器能以一个相对平等的身份待在系统设置里，用户选中谁，谁就是系统默认的填充引擎。服务厂商自己掌控 UI 渲染、数据加密逻辑和匹配算法，系统只负责传递请求和展示授权过的内容。
但这套架构从诞生起就拖着几条瘸腿。最棘手的是 AssistStructure 这个黑箱子。为了告诉密码管理器「这里有个用户名框、那里有个密码框」，系统几乎要把目标 App 的整棵 View Tree 序列化后塞给填充服务。字段多了、界面复杂了，Binder 传输数据量暴涨，直接触发 TransactionTooLargeException 的情况在早几年屡见不鲜。很多开发者应该都见过这种崩溃堆栈：明明用户在正常登录，结果密码管理器的填充弹窗死活刷不出来，logcat 里一片红。
另一个老毛病是 WebView 的支持。Chrome 自己当然没问题，它内部跟 Google Password Manager 有私底下的 API 通信。但第三方密码管理器面对嵌套了 WebView 的客户端时，经常解析不出正确的 domain，导致匹配逻辑失灵。更别说国内那一大堆把 H5 塞进壳子里的超级 App，它们对 autofillHints 的支持堪称灾难，很多干脆把 importantForAutofill 设成 noExcludeDescendants，直接拒绝任何填充服务读取。
即便如此，Autofill Framework 好歹给第三方保留了一个完整的、端到端的控制闭环。从数据读取、生物识别验证，到最终把明文密码塞进目标输入框，全过程由密码管理器自己负责。用户信任的是 1Password 或者 Bitwarden 的安全模型，而不是 Google 的。这种架构上的独立性，正是 2024 年这轮「新要求」所要瓦解的东西。
Credential Manager：打着安全旗号的中间商
2022 年 Google I/O 上，Credential Manager 作为 Jetpack 库正式亮相。表面上的卖点很光鲜：把传统的用户名密码、Passkey 和联邦登录（比如 Google Sign-In）统一到一个入口，降低开发者的集成成本，让用户不用再纠结底弹出的是密码管理器还是 Google 账号选择器。听起来像是基础设施的善意升级。
但魔鬼藏在实现细节里。Credential Manager 在架构上干了一件非常微妙的事：它把凭证填充从「系统服务与第三方应用直接对话」改成了「所有请求先经过 Google 控制的调度层」。在 Android 14 之前，这个调度层对 Passkey 的支持是排他的——只有 Google Password Manager 能做 Passkey 的 provider。1Password、Dashlane 们被挡在门外。这意味着，如果用户在 Android 13 设备上想用 1Password 保存和同步 Passkey，根本走不通系统级 API，只能靠自家的键盘输入法模式或者 Accessibility 服务来绕弯子。
这不是技术限制，这是平台策略。Passkey 作为 FIDO2 的落地实现，理论上应该由用户自己选择的身份提供商托管。Google 却借 Credential Manager 的推出，把 Passkey 的 root of trust 先一步锁进了自己的生态。第三方密码管理器要么沦为只处理传统密码的二等公民，要么就得等 Google 开放接口。
开放了吗？Android 14（API 34）确实开放了。在欧盟 DMA（Digital Markets Act）的施压下，Google 不情不愿地在 AOSP 里加入了第三方 CredentialProvider 的注册入口。1Password 在 2023 年底发布博客，宣布开始适配 Android 原生的 Passkey 支持。Bitwarden 也跟进提交了相关 PR。但如果你看过 AOSP 14 的实现，会发现第三方 provider 的地位跟系统级 Autofill Service 时期完全不对等。以前的 Autofill Service 是自己跑一个独立服务，系统发请求过来，第三方全权处理 UI 和数据。现在的 Credential Provider 更像是给 Credential Manager 这个「中间商」供货的插件——最终展示什么 UI、怎么排列选项、甚至生物识别弹窗的样式，控制权都在系统层。
Google 官方的说辞是，统一 UI 能减少钓鱼攻击。毕竟