microG 登录卡死时，最可疑的“罪魁祸首”清单

结合 microG（GmsCore、GsfProxy、FakeStore 等）实现与 Google 的 Check-in / FCM / 账号链路，最常见会“卡住”的是下面这些文件/数据库（括号里是典型路径）。它们一旦出现不匹配/残留/签名变化，就可能导致必须“恢复出厂”才能一次性全清：

AccountManager 账号库

accounts_ce.db / accounts_de.db（/data/system_ce/0/ 与 /data/system_de/0/）
- 症状：系统层面仍“认着”旧的 Google 账号/Token 记录，但 microG 的包签名、权限或 check-in 信息已变，结果凭证校验链断裂，授权页死循环或直接失败。

microG 的 Check-in / 设备 ID 缓存（GmsCore 包，com.google.android.gms）

shared_prefs/checkin.xml：androidId、securityToken 等
shared_prefs/com.google.android.gms.appid.xml：FCM/InstanceID 相关
databases/gcm.db / databases/flags.db / databases/droidguard.db（具体文件名可能因版本不同而异）
- 症状：更换 ROM、切换网络/时区、替换签名伪造方案或重复装卸 microG 后，旧的 AndroidID / securityToken 与服务器侧状态不一致，导致登录/注册设备失败。

GSF（Services Framework Proxy）的 ID/配置（com.google.android.gsf，microG 的 GsfProxy）

databases/gservices.db、shared_prefs/ 下的配置
- 症状：GSF ID 与 GmsCore 记忆的 AndroidID/Token 不一致；或历史遗留的 flag 配置影响后续认证。

包签名与“签名伪造（Fake Package Signature）”授予状态

/data/system/packages.xml、/data/system/users/0/runtime-permissions.xml
- 症状：切 ROM / 切补丁方式（如不同版本的 Signature Spoofing 实现、Magisk 模块、patchrom 等）后，旧的授予状态与新 APK 的签名不一致，microG 的自检“打勾”但底层校验不过，登录/授权页异常。

WebView/Chrome 的 cookie / local storage

清空浏览器内核数据可解决某些 SSO / reCAPTCHA / OAuth 跳转失败（尤其使用内置或外部浏览器完成 Google 登录流程时）。

为什么“恢复出厂”能一把梭？

因为上面 1~5 全在 /data，一次格式化就把账号库、ID、Token、签名状态、cookie全部重置，设备重新走 check-in / 账号授权，全链路干净。

逐一实验, 发现确实是 WebView所在的APP com.android.webview的存储数据有问题导致. 从设置里清空应用 com.android.webview的所有数据就OK了.

完整对话如下:

https://chatgpt.com/share/690308e0-a3b8-8013-bdb9-c1cadf6f875d

AI是越来越牛了!

microG Services can't log in to Google servers

microG 登录卡死时，最可疑的“罪魁祸首”清单