PICO 4 Ultra 临时 Root + 真 GMS + Google Play 登录完整教程（2026-11 实测）

一句话结论：PICO 4 Ultra 国行（bootloader 锁定、不能刷机）可以用「每次开机临时 root」的方式把真实 GMS 以系统特权应用挂进 /system，从而登录 Google 账号、正常使用 Play 商店；GMS 必须固定在 24.06.16（26.x 会因缺少 SystemUI 凭据确认 UI 而登录失败）。配合 auto-boot APK 与模块自动 rescan，开机解锁后约 30 秒自动恢复，不需要再手动点 ROOT 或跑模块。

本文是 2026-11-08 在真机上完整实测后的整理，包含根因、步骤、实测时间线、日志和排错。不刷机、不解锁、不降级、不清数据。

0. 适用条件与红线

适用设备（本文实测基线）

四条红线（犯一条就要重来）

1. 不要把 GMS 升到 26.x：26.x 的「添加账号」流程依赖 SystemUI 的设备凭据确认 UI，PICO 没有该组件，登录会转圈/退回。
2. 不要清 Play / GMS 数据：会丢账号与设备认证。
3. 不要刷机 / 解锁 / 降级：本机型没有公开可行的解锁路径，盲试极易变砖。
4. 不要设全局 http_proxy、不要把 GMS/Play 标成 VR：两者都实测有害。

本文只记录本机实测。不同批次、地区版本或 OTA 后，内核与系统组件可能变化；升级系统后请重新评估，不要直接套用旧结论。

1. 问题：Google Play 登录转圈/退回

1.1 现象

GMS 三件套已经以系统特权应用方式挂载成功，Play 商店能打开、能拉配置，但点「登录」后：转圈 → 退回上一页，有时闪退。用下面命令也能复现同样的 GMS 登录流程：

adb shell 'am start -a android.settings.ADD_ACCOUNT_SETTINGS --esa account_types com.google'

1.2 根因：GMS 26.x 的「设备凭据确认」没有 UI 可显示

实测日志（GMS 26.43.30）：

BiometricService/PreAuthInfo: getCanAuthenticateInternal Modality: 1 AuthenticatorStatus: 9
BiometricService: handleAuthenticate: modality(1), status(14), ...
    BiometricRequested: true, CredentialRequested: true,
    CredentialAvailable: false
Auth: [AddAccount, PreAddAccountActivity] GmsBiometricPrompt authentication error with code 14

链路是这样的：

1. Play 商店 → GMS 登录 Activity 链（UnpackingRedirectActivity → AccountIntroActivity → WrapperControlledActivity → PreAddAccountActivity）都能正常创建、绘制、拿到焦点；
2. 但 GMS 26.x 在「添加账号」流程里引入了 GmsBiometricPrompt（auth_accountMandatoryBiometrics），要求确认设备锁屏凭据；
3. Android 的 BiometricPrompt 凭据确认 UI 由 SystemUI（AuthController）负责显示，而 PICO 固件里没有 com.android.systemui（只有 com.picovr.keyguard 和 Settings 的 ConfirmDeviceCredentialActivity）；
4. 没设锁屏凭据时报 error 14（ERROR_NO_DEVICE_CREDENTIAL）；设了 PIN 后则会创建凭据会话但 UI 无人接收，卡在 State 9，最终 error 5（canceled）/ 超时退回。

注意：网上常见的「登录页没有 surface/面板没焦点」的猜测是错的。实测中 GMS 登录页在 1600×900 的 2D 面板上正常绘制、正常获焦；真正卡住的是凭据确认 UI。而把 GMS/Play 加进 PICO 的 VR 白名单会让 Play 商店崩溃，不要试。

1.3 修复：把 GMS 回退到 24.06.16

GMS 24.06.16 没有这套 GmsBiometricPrompt 逻辑，登录会走自带的 WebView 登录页（com.google.android.gms/.auth.uiflows.minutemaid.MinuteMaidActivity，标题「登录 - Google 账号」）。回退命令：

# 前提：当前有 root，且 gms_privapp 模块已挂载（系统版 GMS 可见）
adb shell 'pm uninstall-system-updates com.google.android.gms'

验证：

adb shell 'dumpsys package com.google.android.gms | grep -E "versionName=|versionCode=|codePath=|pkgFlags=" | head -4'

期望输出：

versionName=24.06.16 (190408-612568414)
versionCode=240616039 minSdk=31 targetSdk=34
codePath=/system/priv-app/GmsCore
pkgFlags=[ SYSTEM HAS_CODE ALLOW_CLEAR_USER_DATA ALLOW_BACKUP RESTORE_ANY_VERSION ]

回退后重新打开 Play 商店点登录，就会看到 GMS 自带的 WebView 登录页（1600×900 面板），输入账号密码即可。本文实测账号已正常登录（邮箱打码），Play 商店可搜索、安装、更新应用。

⚠️ 回退不会删除账号和数据（/data/data/com.google.android.gms 保留）。但如果 Play 之后又把 GMS 自动升级到 26.x，登录会再次失败；本文后面的模块会加「开机自动回退」守卫。

2. 整体方案总览

2.1 为什么必须「临时 root + 系统特权 GMS」

• GMS 必须以 priv-app / SYSTEM 特权应用运行（需要 INSTALL_PACKAGES 等签名级权限、persistent 进程等），普通用户应用装不了；
• 本机 /system 是 erofs + dm-verity 只读，overlayfs 不可用（内核没开 TMPFS_XATTR，f2fs upper 也被拒），无法把 GMS 写进系统分区；
• 只能靠 root 在内存里 bind mount 替换 /system/priv-app，再让 PackageManager 重新扫描（kill -9 system_server），GMS 才会被重新认定为 SYSTEM 特权应用；
• 所有这一切依赖 root，而本机 root 只能靠漏洞临时拿到（重启失效）。

2.2 为什么不存在「真正免 root 持久化」

所以最终形态只能是：一次性搭建好，之后每次开机由 App 自动重新拿 root 并恢复 GMS。这就是第 4 章的 auto-boot 方案。

2.3 最终形态

一次性搭建：
  临时 root → 安装 gms_privapp 模块 → 固定 GMS 24.06.16 → 登录 Google 账号

每次开机：
  开机解锁 → BOOT_COMPLETED → auto-boot APK 自动跑 exploit
  → ksud late-load 自动执行模块脚本（挂载 /system/priv-app）
  → 检测到 GMS 缺 SYSTEM 特权 → 自动重启框架重扫
  → GMS/Play 可用（账号保留）

3. 一次性搭建（首次约 30–60 分钟）

3.1 取得临时 root

本文不重复展开临时 root 的编译与适配细节，见我之前的文章：《PICO 4 Ultra 临时 Root 与刷机流程说明》 。

关键点：

• 使用与固件精确匹配的 DFRoot 适配包 + KernelSU/SukiSU Ultra 管理器；
• 安装 APK 用 --no-incremental（本机 IncFS 会导致管理器识别失败）；
• 触发后验证：

adb shell 'su -c id'
# 期望：uid=0(root) gid=0(root) ... context=u:r:ksu:s0

临时 root 只在内存，重启消失，这是后面要自动恢复的原因。

3.2 安装 gms_privapp 模块

模块思路（低挂载数方案）：

1. 把真实 GMS 三件套（GmsCore 24.06.16、Phonesky 39.9.31、GoogleServicesFramework 14）与权限白名单放进模块的 system/ 载荷；
2. 首次启动时把整棵 /system/priv-app（约 2.8 GB）镜像到 /data/local/gms/rootfs，之后只做 1 次 bind mount（/system/priv-app）+ 4 个配置目录 bind，共 5 个挂载点；
3. 挂载数必须压到很低：PICO init 会为每个挂载点生成 dev.mnt.* 属性，早期 84 个 bind 曾耗尽属性区，导致 system_server 崩溃；
4. 脚本链：post-fs-data.sh（挂载主流程）→ service.sh（兜底）→ boot-completed.sh（检查特权，缺则自动 rescan.sh）→ action.sh（管理器的 Action 按钮，自愈但不重启框架）。

安装后在管理器里启用模块，或手动执行一次挂载脚本。状态文件：

adb shell "su -c 'cat /data/local/tmp/gms_status.txt'"
# 期望：OK ... | 挂载正常 | 系统特权正常

3.3 固定 GMS 版本

回退命令见 1.3 节。建议同时：

• 在 Play 商店里关闭「自动更新应用」；
• 模块 v1.8 的 boot-completed.sh 会做版本守卫：每次拿到 root 后若发现 GMS 是 26.x，就自动 pm uninstall-system-updates 回退到系统内置的 24.06.16。

3.4 锁屏 PIN（可选，按需）

Google 登录在 GMS 24.06.16 下不需要锁屏 PIN；PIN 只是设备安全习惯。

注意：PICO 固件禁止通过 adb 设置锁屏密码。locksettings set-pin 会返回成功但实际不生效——PICO 在 LockSettingsShellCommand 里用 disableAdbSetPassword() 禁掉了（条件：!ro.debuggable 且 keyguard 启用）。要设只能在头显的设置里操作。

3.5 登录 Google 账号

前置：GMS 24.06.16、gms_status.txt 为 OK、设备网络可达 Google（不要设全局 http_proxy）。

1. 打开 Play 商店，点登录；
2. 出现 GMS 的 WebView 登录页（标题「登录 - Google 账号」）→ 输入邮箱 → 下一步 → 密码 → 两步验证；
3. 成功后 Play 显示已登录，可以安装应用。命令行确认：

adb shell 'dumpsys account | grep -F "type=com.google"'
# 期望：Account {name=你的账号@gmail.com, type=com.google}

设备未认证（Play 提示「设备未通过认证」）不影响登录与安装；如需要，可用 GSF ID 到 https://www.google.com/android/uncertified/ 注册。GSF ID 查看方式因 GMS 版本而异，本文不展开。

4. 每次开机自动恢复（重点）

目标：开机解锁后什么都不用做，约半分钟内 GMS/Play 自动恢复。

4.1 实现原理

开机 → 解锁
  → BOOT_COMPLETED 广播
  → df.root.vr 的 BootReceiver（VR 应用，PICO ProcessIntercept 第一条分支放行冷启动）
  → BootService（前台服务，specialUse 类型，持有 wakelock）跑 DirtyFrag exploit
  → root 建立 → ksud late-load 自动执行 gms_privapp 模块脚本
  → 挂载 /system/priv-app，检查 GMS pkgFlags
  → 缺 SYSTEM 特权 → 自动 rescan.sh（kill -9 system_server）
  → 框架重启（界面/锁屏闪一下）→ GMS 恢复 SYSTEM 特权 → Play 可用

关键设计：

• APK 声明成 VR 应用：PICO 的 ProcessIntercept 会拦截第三方应用的「开机广播冷启动」，但 VR/3D 应用是最高优先级放行。在 <application> 里加 <meta-data android:name="com.picovr.type" android:value="vr"/> 即可。
• 入口 Activity 再声明 2D：应用级 VR 标记会让 PICO 的 VR 壳劫持 Activity 启动；给 .RunActivity 单独加 com.picovr.type=2d，am start 才能正常拉起并清掉 stopped 状态。
• 用前台服务而不是广播里直接跑：BroadcastReceiver 回调窗口只有约 10 秒，exploit 需要更久；前台服务（specialUse + wakelock）保证进程不被回收。Android 14 允许从 BOOT_COMPLETED 启动 specialUse 前台服务（dataSync 等类型反而被禁止）。
• 模块自动 rescan：开机时 PackageManager 早已扫描完，挂载后必须重启框架重扫。boot-completed.sh 检测 pkgFlags 后自动执行 rescan.sh，把原来手动的一步自动化。

4.2 安装 auto-boot APK

包名 df.root.vr（手动版 df.root 可共存）。安装后用全类名启动一次（df.root.RunActivity，不能简写成 .）：

adb install -r -g --no-incremental DFRoot_4.7-vr_vr.apk

# 首次必须手动跑一次：清掉 stopped 状态，否则 Android 不投递 BOOT_COMPLETED
adb shell 'am start -n df.root.vr/df.root.RunActivity'
sleep 60
adb shell 'su -c id'

# 校验：VR 标记、版本、stopped、接收器
adb shell 'dumpsys package df.root.vr | grep -E "isVrApp|versionName=|stopped="'
adb shell 'dumpsys package df.root.vr | grep -E "df.root.BootReceiver|BOOT_COMPLETED|enabled="'

期望：isVrApp: true、versionName=4.7-vr、stopped=false，且 df.root.BootReceiver 为 enabled=true、intent filter 含 BOOT_COMPLETED / LOCKED_BOOT_COMPLETED。

要点：

• 首次必须手动跑一次：stopped 状态的应用收不到 BOOT_COMPLETED；
• LOCKED_BOOT_COMPLETED 到达时会主动跳过，等解锁后的 BOOT_COMPLETED 再开始（保证用户数据可用）；
• 不要打开 df.root.vr 的 MainActivity 来「测试」，它会关闭 BootReceiver；手动触发请用 RunActivity；
• 两包共存时 /dev/df 哨兵可防止重复加载。

4.3 实测时间线（2026-11-08，真机重启）

11:14:28  开机完成、锁屏出现（本次约 15 秒内被解除）
11:14:43  设备解锁 → 系统发出 BOOT_COMPLETED
11:14:46  df.root.vr BootReceiver → BootService 启动（先 staging ksud/exploit）
11:14:51  DirtyFrag exploit 完成：rc=0，root 建立（约 5 秒）
11:14:51  模块 post-fs-data.sh 开始挂载（复用已有 3.7 GB 镜像，秒级）
11:14:54  检测到 GMS 缺 SYSTEM 特权 → 自动调用 rescan.sh
11:15:01  新 system_server 起来，UI/锁屏短暂重启（正常）
11:15:09  界面恢复、GMS 特权恢复
11:15:1x  GMS/Play 可用；账号保留，无需重新登录

解锁 → Play 可用约 27 秒；整个开机到恢复完成不到 1 分钟。exploit 在开机场景实测约 5 秒（比手动冷启动快，因为 ksud 和镜像已在 /data 缓存）。

实测证据（节选）：

# /sdcard/Android/data/df.root.vr/files/boot.log
2026-11-08 11:14:46 boot: BootService start, action=null
2026-11-08 11:14:47 === exploit (patching files) ===
2026-11-08 11:14:50 ksud start: SUCCESS
2026-11-08 11:14:51 boot: exploit rc=0 (0=success)

# /data/local/tmp/gms_heal.log
=== boot-stage heal Sun Nov  8 11:14:51 HKT 2026 ===
privilege missing -> auto rescan
[gms] [3/3] 重启框架（界面会短暂消失，属正常）
=== heal finished ===

重扫完成后：

pkgFlags=[ SYSTEM HAS_CODE ALLOW_CLEAR_USER_DATA ALLOW_BACKUP RESTORE_ANY_VERSION ]
Account {name=你的账号@gmail.com, type=com.google}

本次开机锁屏在约 15 秒内被解除（PIN/面部或设备自动解锁）。如果你的设备开机停在锁屏，先正常解锁，之后 BOOT_COMPLETED 就会触发，流程一致。

4.4 状态与日志

# 模块状态（一行结论）
adb shell "su -c 'cat /data/local/tmp/gms_status.txt'"
# OK ... | 挂载正常 | 系统特权正常 | 自动恢复完成

# 开机自愈日志
adb shell "su -c 'tail -30 /data/local/tmp/gms_heal.log'"

# 挂载 6 步日志
adb shell "su -c 'tail -30 /data/local/tmp/gms_module.log'"

# auto-boot APK 自己写的开机日志（推荐，重启后仍在）
adb shell 'cat /sdcard/Android/data/df.root.vr/files/boot.log'

# DFRoot logcat（可能被环形缓冲冲掉，以 boot.log 为准）
adb logcat -d -s dfroot | tail -20

4.5 没有自动恢复怎么办

① boot.log 没有文件 / 没有 "BootService start"
   → 开机广播没到：检查 isVrApp=true、stopped=false、BootReceiver enabled；
     手动 am start -n df.root.vr/df.root.RunActivity 后重启再试。

② 有 "BootService start" 但没有 "exploit rc=0"
   → exploit 失败：重启重试；确认同一时间只有一个 KernelSU 系 LKM；
     确认 SukiSU/KernelSU 管理器还在（ksud 从它取）。

③ su 有 root，但 gms_status.txt 不是 OK
   → 手动 su -c 'sh /data/adb/modules/gms_privapp/rescan.sh'，等 20–30 秒再看。

④ 都不行
   → 手动兜底：am start -n df.root/df.root.RunActivity（手动版）→ 等挂载 → 必要时 rescan。
   → 再不行就重启设备，数据不丢。

5. 验证清单

D=PA921JMGJ9130855G   # 换成你的 adb 序列号

# 1) root
adb -s $D shell 'su -c id'
# uid=0(root) ... context=u:r:ksu:s0

# 2) 模块状态
adb -s $D shell "su -c 'cat /data/local/tmp/gms_status.txt'"
# OK ... | 挂载正常 | 系统特权正常

# 3) GMS 版本与特权
adb -s $D shell 'dumpsys package com.google.android.gms | grep -E "versionName=|codePath=|pkgFlags=" | head -4'
# 24.06.16 / /system/priv-app/GmsCore / pkgFlags 含 SYSTEM

# 4) GMS / Play 版本
adb -s $D shell 'dumpsys package com.android.vending | grep -m1 versionName='
adb -s $D shell 'dumpsys package com.google.android.gsf | grep -m1 versionName='

# 5) 账号
adb -s $D shell 'dumpsys account | grep -F "type=com.google"'

# 6) 进程
adb -s $D shell 'ps -A | grep -E "com.google.android.gms$|com.android.vending$"'

# 7) 全局代理应为 null（不要设）
adb -s $D shell 'settings get global http_proxy'

6. 故障排查

7. 已知限制与风险

1. 临时 root 只在内存：重启消失；auto-boot 只是把它自动化，不是持久化 root。
2. GMS 版本必须钉住：26.x 会破坏登录；模块 v1.8 会在开机提权后自动回退，但运行期请关闭 Play 自动更新。
3. PICO 系统 OTA 会改变内核/系统组件：升级后 exploit、模块镜像与权限白名单都可能失效；升级前建议备份并重新评估。
4. 锁屏 PIN：设备级凭据，忘记会很麻烦；本文实测的重启会自动解锁，但不保证所有固件行为一致。
5. 数据安全：不要清 Play/GMS 数据；重要数据建议定期备份。
6. 本方案不刷机、不解锁：所有改动只在运行时内存与 /data，系统分区保持原厂状态。

8. FAQ

Q：能不能做到真正「一次搞定，永久生效」？
A：本机型不行。bootloader 锁定、system 只读且 dm-verity 强制，没有 boot-time root 通道。能做到的是「开机自动恢复」，日常使用无感。

Q：auto-boot APK 安全吗？
A：它是开源的 DFRoot 适配版（本机修改版），只是把原本手动点的 ROOT 改成开机自动跑；风险与手动版相同。不放心可以只用手动版。

Q：为什么不用 microG？
A：microG 不能正常登录/使用官方 Play 商店与依赖 GMS 的应用。本文用真实 GMS。

Q：Play 安装的应用重启后还在吗？
A：在。应用装在 /data/app，账号与 GMS 数据在 /data；只要自动恢复成功，重启不影响。

Q：可以同时登录多个 Google 账号吗？
A：理论上可以加多个账号，但本文只实测了单账号；建议先保证一个账号稳定。

9. 附录

9.1 版本表

9.2 关键路径

模块：        /data/adb/modules/gms_privapp/
镜像：        /data/local/gms/rootfs
状态：        /data/local/tmp/gms_status.txt
模块日志：    /data/local/tmp/gms_module.log
自愈日志：    /data/local/tmp/gms_heal.log
自动开机日志：/sdcard/Android/data/df.root.vr/files/boot.log
哨兵：        /dev/df

9.3 模块脚本

9.4 本文实测结论

2026-11-08 在 PICO 4 Ultra（A9210 / 5.15.8 / 内核 5.10.198）上完成：真实 GMS 以系统特权运行、Google 账号登录成功、Play 正常安装应用；真机重启后 auto-boot 全自动完成 root → 挂载 → 重扫 → GMS 恢复，解锁到可用约 27 秒，账号与 Play 应用保留。未刷机、未解锁、未降级、未清数据。

相关资料

• 《PICO 4 Ultra 临时 Root 与刷机流程说明》 ：临时 root 的原理、编译、适配与刷机风险说明
• KernelSU 官方项目
• SukiSU Ultra
• DFRoot（DirtyFrag）
• Google 设备认证

本文仅为个人设备实测记录，不构成对任何设备的刷机或破解建议；操作风险自负。