Android 11调用addAccountExplicitly报SecurityException偶现崩溃怎么解决？

根因分析 #

1 Android 11 平台变更直接触发该异常 #

Android 11（API 30）针对AccountManager做了两处核心规则调整，刚好匹配所有崩溃都出现在Android 11的特征：

• AUTHENTICATE_ACCOUNTS权限正式废弃，第三方应用调用addAccountExplicitly的前提变为：调用方App的签名必须和注册对应accountType的身份验证器的App签名完全一致，签名不匹配直接抛出该SecurityException。
• 新增包可见性限制，如果要访问其他App注册的accountType，必须在当前App的manifest中通过<queries>标签声明目标App包名，否则系统会判定对应accountType不存在，触发相同异常。

2 多包名、多构建变种是偶现的核心诱因 #

两个不同包名、签名不同的App刚好符合上述规则的触发条件：

• 若package.name1的App尝试添加accountType为package.name2的账号，两个App签名不同就会直接崩溃；反过来也成立。
• 多构建变种容易出现配置错配：比如debug变种用了release的accountType常量、变种包名变更后没有同步更新account-authenticator中的android:accountType配置，只有用到错配变种的用户会触发崩溃，符合偶现特征。

3 权限动态申请遗漏也会导致偶现 #

GET_ACCOUNTS属于Android 6.0+需要动态申请的通讯录权限组，若用户拒绝该权限，调用addAccountExplicitly也会触发相同异常，只有拒绝权限的用户会遇到问题，进一步提升了偶现概率。 #

修复方案 #

• 严格绑定构建变种的accountType：不要写死accountType常量，代码中动态读取当前App包名作为accountType，同时保证所有变种的account-authenticator配置中的android:accountType和当前变种包名完全一致。
• 调用前增加校验逻辑：在Android 11及以上版本调用addAccountExplicitly前，先检查两项条件：
  • 是否已获得GET_ACCOUNTS动态授权
  • 遍历accountManager.getAuthenticatorTypes()确认当前App已注册目标accountType
    任意一项不满足就不要调用该方法，走降级登录流程。
• 多App互通配置：如果两个App需要共享账号，首先保证两个App使用完全相同的签名，其次在两个App的manifest中新增<queries>标签声明对方的包名，示例如下：

<queries>
    <package android:name="package.name1" />
</queries>

• 增加异常捕获：给addAccountExplicitly调用逻辑加try-catch捕获SecurityException，捕获后引导用户重新登录或跳转系统账号添加页面，避免直接崩溃。

内容的提问来源于stack exchange，提问作者Juan Gil