手里有一张可插拔的 eSIM 卡，想换个号码、想看看卡里到底装了几个配置，结果还得先装厂商那个 App、注册账号、跟着它的下载次数走，挺别扭的。8bercue 就是冲着这件事来的：一个开源、独立、不用 Root 的 Android 工具，让你用自己的手机直接读卡、下载配置、切换配置。项目还很新，目前是 Beta，但有中文界面，文档写得意外地细。下面把能查到的东西捋一遍，能做什么、不能做什么、怎么上手，都说明白。
一、这个项目能做什么？
简单说，8bercue 是一个跑在 Android 上的 LPA（Local Profile Assistant，本地配置助手）客户端，专门管可插拔 eUICC 卡里的 eSIM 配置。注意是”可插拔”的物理卡，不是手机主板上焊死的那个内置 eSIM。
它能干的事：把卡里的配置列出来，查看卡片信息，启用、停用、重命名、删除配置，还能通过二维码、图片或者激活码下载新的配置。整个流程不经过卡片厂商的 App，也不需要厂商账号。官网那句口号就是「你的 eSIM，自己管理」。
开发者叫 sid，是个人开发者，仓库挂在 github.com/sidnvy/8bercue，官网是 8bercue.sidnvy.com，支持邮箱 [email protected]。仓库 2026 年 10 月 19 日建，10 月 26 日推了最后一个正式版本，主体是 Java，底层还带 native 代码、LPAC 和 BoringSSL。许可证是 AGPL-3.0-only，另外为在本机 ADB 配对里链接固定版本的 BoringSSL 加了一条有限的第 7 条附加许可，不是把第三方代码重新授权。
项目一开始就明确写了自己独立于文中提到的所有卡厂商，产品名只是用来标识卡片和兼容性报告，不代表合作或背书。这点态度挺清楚：它不是谁的官方客户端，是个第三方独立实现。
技术上最核心的一件事，是它怎么拿到卡的访问权。普通 App 走 OMAPI 去开 ISD-R 小程序时，Android 会按卡片 ARA-M 里的访问规则，检查这个 App 的签名证书和目标 AID。厂商可以用这套规则只放行自家 App。8bercue 换了一条路：让用户主动授权 ADB 或 Shizuku，启动一个跑在 Shell（UID 2000） 下的本机辅助服务，在 ROM 允许的机器上直接调 Secure Element HAL，或者走可用的 Telephony 接口，从普通应用那道 OMAPI 检查的下面过去。OMAPI 仍然存在，但只是回退路径，照样受访问规则约束。
这里得把边界说死，别误解成”破解”：项目文档自己写明，这改变的是 Android 侧的访问路径，不会改写 ARA-M、不会解锁卡片固件、也不会替代运营商认证。独立管理可以避开只做在厂商 App 或账号服务里的注册要求和下载计数，但不等于无限下载——卡的容量、固件限制、激活码使用规则、运营商资格和 SM-DP+ 配置服务器策略，全部照旧生效。用之前最好先看清自己运营商的条款和当地规定。
二、Github 项目代码库供哪些人使用？
先报数据：截至 2026 年 11 月 10 日，仓库 19 个 Star、5 个 Fork、9 个处于 open 状态的 Issue。典型的早期项目规模，别拿它跟动辄几千星的成熟工具比。
谁会用得上？我觉得是这三类人：
- 手上有可插拔 eUICC 卡的人。项目从 5ber 卡起步，现在把 9eSIM、Nekoko、海豚卡以及其他可插拔 eUICC 都放进兼容性工作范围，而且明确说没有厂商白名单。
- 不想被厂商账号绑住的人。隐私说明里写得很直白：不需要 5ber 账号，也不会把你的激活信息发给 5ber 服务。
- 愿意折腾 ROM 适配、想提交兼容性报告的开发者。项目专门做了适配器指南和设备报告模板，甚至写明”一次成功的新机型报告可以只更新兼容性表，不用改运行时代码”。
门槛不算低。你得有一台 ARM64、Android 9 及以上的手机；想用本机无线 ADB，还得 Android 12+ 和 Wi-Fi。更关键的是，光看 Android 版本和手机品牌判断不了能不能用——ROM 有没有暴露可访问的卡片接口、卡片本身答不答应，都得实测。项目把结果按「手机、ROM、卡片、具体操作」四件事分开记，这个拆法其实挺专业：读卡成功不等于能写，能写也不等于能上网。
知识上，你至少得知道什么是 ADB 调试、怎么开无线调试、配对码怎么填，或者会用 Shizuku。完全没碰过这些的话，第一次配置会有点绕。但官方文档把每一步都写出来了，照着做不算难。还有一条硬要求：别拿主力卡和主力号码做实验，贡献指南里专门提醒，测试写操作请用一次性配置，事先想好怎么恢复。
三、有哪些有亮点的特色功能和服务？
不用 Root，三种连接方式随你挑
这是最实在的亮点。App 本身始终是普通应用，不申请 Root。它提供三条路启动同一个本机 Shell 辅助服务：本机无线 ADB、电脑 USB ADB、已经跑起来的 Shizuku。Shizuku 是可选第三项，只有检测到兼容服务在跑才出现，而且要求 server API 13 以上、以 ADB/Shell 身份启动；用 Root 起的 Shizuku 和 Sui 不支持。三条路只是”怎么把辅助服务拉起来”的区别，后面卡片能不能访问，另说。
无线配对做在通知里
这个细节能看出是认真做过真机调试的。Android 的配对码窗口一旦被切到后台，配对服务就会关掉，所以 8bercue 没有单独开一个输入页面，而是让你展开它的通知、直接点「输入配对码」把六位数字填进去，设置页可以一直开着。配对一次会记住客户端身份，以后在 App 里点「在本机连接」就能重连。要是键盘弹不出来，文档建议改用电脑方式，并去查这台机器的输入法/SystemUI 行为——App 没法强行让另一个应用的键盘渲染出来。
电脑方式不下载任何额外工具
选电脑 ADB 时，App 会显示一条固定命令，你在两分钟窗口里复制到可信电脑的终端跑一下就行。这条命令会解析手机上已安装的 APK、启动它固定的连接入口，不下载单独的 helper，也不需要 Python。多设备同时连着时记得指定序列号，窗口过期就重新点一次”开始连接”。终端会明确回报认证过的 Binder 连接是否建立，光”启动成功”不算成功。
中断后的恢复逻辑很克制
启用或停用配置可能触发 SIM REFRESH，把原来的逻辑通道弄失效，结果就是”命令可能执行了，但 App 没收到可信回执”。8bercue 把这种状态叫 unknown outcome，不猜、不重试状态变更命令、也不回滚。它重新连上后独立读同一张卡，只有在两次稳定读取、完整卡片身份、之前预提交的目标、以及完整的前置配置清单全都对得上时，才自动确认之前那次启停的结果，并另存一张持久的观察回执，原始 unknown 记录原样保留。下载、重命名、删除不走这条自动推断路径。这套保守做法在 eSIM 这种写错了很麻烦的场景里，是对的方向。
中文界面、明暗主题、隐私收得紧
界面有英文和简体中文，配浅色、深色主题。README 还有中、英、日三语版本。隐私说明里：EID 和配置标识在屏幕上打码，激活码和确认码不进诊断日志和事务日志，离开 App 会清掉输入的激活码草稿；相机只在扫激活二维码时用，图片在本机解码；没有广告和行为分析 SDK；崩溃上报可选，默认关闭。确认安装时，本机服务才会按激活码里的运营商地址走 HTTPS，把 eSIM 开通流程必需的凭据、协议消息、卡片身份证书交给运营商——这一段是协议本身要求的，运营商的隐私政策同样适用。
兼容性表按”组合”记，不吹品牌
它没有”支持某某品牌”这种含糊话，而是列具体组合。比如 Motorola edge 70 / Android 17 配两张 Nekoko 卡，在 0.20.0-beta.7（APK55）下验证了签名升级保数据、无线身份重连、电脑 ADB 命令、Shizuku 授权、读两张卡、自动确认一次不确定的启用结果，以及四次一次性配置的启停。同时明确写出这一轮没验的东西：物理 USB 传输、全新配对、新下载、重命名/删除、移动网络服务。Pixel 10 Pro XL / Android 17 那条是更早的 beta.2，只验到升级、通知配对、三次重启重连和读卡，也标了”历史结果，不代表 APK55 的资质”。这种把未验证范围一并写出来的做法，比一句”全面支持”可信得多。
四、如何使用工具和服务？
1、有没有演示网址？
有官网 8bercue.sidnvy.com，页面把定位、三步上手和兼容性共建讲清楚了，也直接给了 Beta APK 下载和 GitHub 源码入口。不过它是介绍页，不是在线 Demo——真要用，得把 APK 装到自己的 Android 手机上，配一张真实的卡。官网给出的当前版本是 v0.20.0-beta.7 / APK55。
2、安装部署这个项目对环境有哪些要求？
- 手机：ARM64 架构，Android 9（API 28）及以上。
- 本机无线 ADB：Android 12（API 31）及以上，还要有 Wi-Fi；它的 TLS 实现依赖这个版本。
- 电脑 ADB：打开 USB 调试，一台你信任的、装了 ADB 的电脑。
- Shizuku：服务必须已经在跑，且以 ADB / Shell（UID 2000）身份启动，server API 13 以上；只是装了 Shizuku 没启动不算。
- 卡片：一张你自己能控制的可插拔 eUICC；ROM 还得暴露可用的 Secure Element / Telephony / OMAPI 接口。
- 不涉及服务端：没有云主机、数据库、Docker 要求，也不需要注册账号。运营端只在下载配置时按激活码连到运营商的服务器。
所以”能不能部署到 Cloudflare 或 Vercel”这个问题在这儿不成立——它是个装在手机上的本地工具，不是 Web 服务。真要自建，指的是从源码编译 APK，那需要 JDK 17、Android SDK platform 36、build-tools 35.0.0、NDK 27.3.13750724，以及 Gradle 和随仓库锁定的原生源码。
3、如何安装部署？
普通用户走 APK 就行，四步：
- 从 Releases 下载 v0.20.0-beta.7 的签名 APK，装到 ARM64 / Android 9+ 手机上。升级时直接覆盖安装官方版本，能保留应用数据和配对身份，别先卸载。
- 打开 App 的连接与授权，从本机无线 ADB、电脑 USB ADB、Shizuku 里选一种。无线方式要开系统「无线调试」→「使用配对码配对设备」，保持那个窗口别关，展开 8bercue 通知点「输入配对码」填六位数字，再回 App；电脑方式就复制 App 显示的命令，在两分钟窗口里跑掉；Shizuku 方式选中后在它的授权弹窗里允许即可。
- 连上后，如果提示有多张卡，明确选要管的那张。内置 eUICC 和可插拔卡是两回事，别凭 SIM 标签猜物理卡槽。
- 等一份新的配置清单读出来，先核对是不是这张卡、内容对不对，再决定动不动它。想重读就点刷新。官方建议第一次只做只读检查，别上来就下载或切换。
想从源码构建的话，仓库给了三条命令：先跑 android-app/tools/build_android_lpac.sh 用锁定的源码重编 LPAC 及依赖，再跑 build_adb_crypto_source.sh 重编固定版本的 BoringSSL/JNI 并暂存 Release 输入，最后用 Gradle 执行 :app:assembleRelease :app:lintRelease。第二个脚本会在校验前清掉暂存目录，构建失败不会拿旧的 JNI 凑数。发布包里还带了完整对应源码、构建脚本、原生源码归档与补丁、许可证、隐私说明、公钥证书和 SHA256 校验值——AGPL-3.0-only 分发要求跟着源码，这点它做得很规范。
4、使用的大模型是什么？
没有大模型。这一点得说清楚，别被”AI 工具站”的惯性带跑。8bercue 是一个按 GSMA eUICC / SGP.22 那套协议工作的本地配置助手客户端，靠 Java + native 代码、LPAC、BoringSSL、Android 的 Secure Element 接口跟卡片打交道，全流程不涉及 LLM、不调 AI API、不需要 API Key。README 里那张 mermaid 流程图和几份架构文档，讲的是 OMAPI 应用检查、ARA-M 规则、HAL 通道、运营商认证这些分层，是通信与权限问题，不是模型推理。如果你在找”AI 管 eSIM”，那不是这个项目；它的价值恰恰在于把这件事做成本地、可审计、不依赖账号的普通 Android 应用。
5、举例说明基本使用方法
举个最典型的：你有一张可插拔 eUICC，想看看里面装了什么、再临时启一个测试配置。装好 APK，用本机无线 ADB 配好对，App 连上 Shell 辅助服务后会自动读卡，首页列出配置清单和各自状态，点进去能看详情和当前通道允许的操作。先别急着改，点一次刷新确认清单稳定。要启用某个配置，在详情里选启用，等它给出明确结果；万一中途断了、状态停在”待确认”，别反复点——按文档重连，让它自己重新读卡，只有证据齐全才会自动确认，否则就保持 unknown 并保留记录。想加新配置，就走二维码、图片或激活码下载，注意激活码只在本地输入、别截图外传。整个过程不需要厂商账号，也不上传 EID 给项目方。
再举个反馈场景：你换了台手机，跑通了只读检查，可以在 设置 → 帮助与反馈 → 连接详情 里看当前用的后端（AIDL / HIDL / Telephony / OMAPI），然后按设备报告模板提交一条组合记录，写明 App 版本、机型、ROM 版本、卡系列、后端和”只读成功”。项目特别强调：读成功就只报读成功，别顺手宣称下载、切换或移动数据也测过了。
6、最近升级或者增加了哪些新的功能？
当前版本 0.20.0-beta.7（versionCode 55，2026-10-26），主要变化：
- 启用/停用触发 SIM REFRESH 时，允许在旧管理会话退场前，对同一张卡做一次有边界的独立读取；结果精确吻合才算已验证，清单缺失或变化仍记 unknown，绝不重放状态变更命令。
- 断线重连后的自动确认，要求两次稳定读取、完整卡片身份、预提交目标和完整前置清单指纹，并另存持久回执，原 unknown 记录逐字节保留。
- 选卡界面改用简短 SIM 标签，不再把 Secure Element reader 的内部名称甩给用户。
- 电脑 USB ADB 和本机无线 ADB 变成平级选项；Shizuku 作为可选第三种，只在选中后才申请权限。
- 管理会话重建后的恢复会尊重你选的连接方式：无线和已授权的 Shizuku 可直接重连，电脑方式提示再跑一次固定命令；服务停止或被撤销权限不会偷偷换到别的配对。
上一个公开版本是 0.19.1-beta.3（APK48，2026-10-20），那一版加进了简体中文、按能力选择卡片访问、只读恢复，以及可选的 GlitchTip 崩溃上报（默认关闭，报告可预览后显式提交）。从 10 月 20 日到 26 日这一周，提交记录密集落在无线配对重连、中断恢复、多卡选择、下载被拒后的清理、文档多语言这些地方，能看出是个在认真收口的 Beta，而不是一次性放出来的 Demo。
7、它还有哪些资源和工具？
仓库里的文档比代码规模给人的印象厚得多：
- 上手类：README 中 / 英 / 日三语、ADB_CONNECTION.md（连接与排错）、NEW_DEVICE_CHECK.md（只读新机检查）、COMPATIBILITY.md（卡片与机型兼容性表）、BETA-POLICY.md 与 BETA-READINESS.json。
- 技术类：ARCHITECTURE.md（从 App 到卡的分层与权限边界）、ADAPTERS.md（AIDL / HIDL / Telephony / OMAPI 适配层与代码入口）、READ_ONLY_RECOVERY.md（中断操作恢复）、LOCALIZATION.md、AUTOMATIC_COMPATIBILITY.md。
- 协作类：CONTRIBUTING.md、CODE_OF_CONDUCT.md、FEEDBACK_AND_COMPATIBILITY.md，以及
.github/ISSUE_TEMPLATE/device-compatibility.yml设备报告模板。 - 合规类：PRIVACY.txt、LICENSING.md、COPYING、SHA256.json、BUILDING.md、toolchain-notices、release 源码清单与公钥证书。
- 图片素材：docs/images 下有应用图标和两张界面截图（配置清单、配置详情），README 直接引用。
贡献方式也写得很具体，三条：按只读检查流程提交手机+卡组合报告（成功和可复现的失败都要）、按适配器指南定位失败接口并带回归测试提交可复用修复、或者改进 App 与文档翻译。公开报告只收敛结果，别贴完整 EID / ICCID、激活码或原始协议记录。
五、需要哪些资源支持？
用起来其实很轻，重的是”组合条件”而不是硬件堆料：
- 一台手机：ARM64、Android 9+；本机无线配对要 Android 12+ 和 Wi-Fi。
- 一张卡：你自己能控制的可插拔 eUICC。5ber 是起点，Nekoko 有 APK55 的实测记录，9eSIM 和海豚卡目前只有作者的早期成功报告——9eSIM 后来一次只读测试返回了空清单，文档特别说明：那几张卡原本有没有配置未知，所以空清单既不能证明兼容，也不能证明不兼容。
- 一条授权通道：本机无线 ADB、可信电脑 + USB 调试 + ADB，或者已运行的 Shell 模式 Shizuku，三选一。都不给 Root。
- 下载配置时：需要网络，按激活码里的地址连运营商服务器，还要有有效的激活码/二维码。
- 不需要：云主机、VPS、Docker、数据库、Redis、对象存储、常驻后台服务，也没有 SaaS 账号。Cloudflare / Vercel 那套部署方式跟它无关。
- 自己编译才需要：JDK 17、Android SDK platform 36、build-tools 35.0.0、NDK 27.3.13750724、Gradle，以及随仓库锁定的 LPAC 与 BoringSSL 源码；有填好的 Gradle 缓存还能
--offline构建。
换句话说，它的成本主要花在”试”上：手机、ROM、卡片、具体操作的四元组，换任何一个都可能重来一遍。项目也没打算做一个手机品牌白名单，而是按实际发现的服务和卡片响应来判断，ROM 一更新还可能变。所以别指望装好就一定能用，先看兼容性表，再按只读检查走一遍。
六、网友提出了哪些常见问题
下面五条是从公开 Issues、兼容性文档和发布说明里归纳的高频疑问，每条都给答案。
Q1：需要 Root 吗？会不会把手机搞坏？
不需要 Root。三种连接方式启动的都是同一个 Shell（UID 2000）本机辅助服务，App 本身始终是普通应用。但”不 Root”不等于”零风险”：这是 Beta，写操作作用于真实的 eSIM 配置，卡和 ROM 反应各不相同。别拿在用的主力号码试，别为了验证就切走能用的订阅、消耗激活码或删配置，先做只读检查。
Q2：支持哪些卡？能管手机内置的 eSIM 吗？
定位是可插拔 eUICC。项目不设厂商白名单，5ber 起步，Nekoko 在 APK55 下有读卡和一次性配置启停的验证记录，9eSIM、海豚卡有作者的早期成功报告但信息不全。内置 eUICC 也可能被发现，所以多卡时必须明确选卡；Issue #33 正在处理 Pixel 10 Pro XL 上”插了可插拔卡后内置 eSIM 配置被隐藏”的可见性问题。别把手机内置 eSIM 的 MEP 能力，当成可插拔卡也支持双配置。
Q3：读卡成功，是不是就能下载、切换、正常上网了？
不是。文档把安装、辅助服务连接、读卡、写配置、移动网络服务拆成互相独立的结果，读成功只代表这一项通过。APK55 的验收范围明确没有覆盖全新配对、新下载、重命名/删除和移动网络服务；配置显示为已启用，也不代表已注册网络、能打电话或能上网。
Q4：是不是可以绕开运营商限制、无限次下载？
不能这么理解。它绕开的是 Android 侧普通应用的 OMAPI 访问检查，以及只做在厂商 App / 账号服务里的注册和下载计数；不会改写 ARA-M、不解锁卡片固件、不替代运营商认证。卡的存储容量、固件限制、激活码规则、运营商资格和配置服务器策略照样适用。项目自己也写了「不承诺无限下载」。
Q5：能同时启用两个配置吗？多卡手机方便吗？
当前每张卡只支持一个已启用配置，没实现 MEP 双配置同时运行。多卡手机在选择管理会话被替换后，目前还得重新选一次卡（发布说明里列为剩余限制）。另外状态显示”待确认”时别反复点启用——项目专门修过一次 related 的死锁问题（Issue #14：enable 停在 unknown 且无隔离标记，导致写操作长期被挡），后来是靠自动精确观察与恢复流程解决的。
七、用户评价怎么样？
先打个预防针：项目才建三周、19 个 Star，公开讨论基本集中在 GitHub Issues 和作者自己写的兼容性记录里，没有大规模社区口碑可引。下面五条是从这些公开记录归纳出的反馈方向，不是虚构的网友留言。
正面：真的有人把读写跑通并交了完整报告
Issue #12 有人提交 realme RMX3310（GT2）/ Android 15 配 5ber 可插拔卡的报告，把机型、ROM 指纹、ABI、卡片通道、EID 掩码、APK 的 SHA-256 都列齐了，读写都验证过。这种”带证据的组合报告”正是项目想要的，也说明它不只是作者单机自测。
正面：无线配对和重连这条最难的路走通了
Issue #17 记录了 Pixel 10 上首次用通知输入配对码完成配对，之后三次 App 独立重启重连、各自读卡都通过，不用再输码、不用电脑引导。对”免 Root 且不想每次连电脑”的使用场景，这是最实用的一条进展。
正面：中断恢复不瞎猜，这点很受认可
Issue #28 和 beta.7 发布说明把规则写得很硬：不重放状态变更命令、不自动回滚、下载/重命名/删除不靠推断，只有两次稳定读取加完整前置清单全部吻合才自动确认，还另存回执保留原始 unknown 记录。eSIM 写操作最怕”不确定就重试”，这套保守设计是加分项。
正面：文档和 Beta 边界透明到有点较真
三语 README、按手机/ROM/卡/操作拆开的兼容性表、把”这一版没验什么”逐条列出来的发布说明、独立的隐私说明与 Beta 分发政策，还有 SHA256 与完整对应源码。对一个个人开发者的早期项目来说，这种透明度比喊”稳定好用”更让人放心。
负面：兼容性覆盖面窄，Beta 味道仍然很重
这是最集中的短板。9eSIM 出现过只读返回空清单、且无法据此判断兼容与否；APK55 的验收没覆盖新下载、重命名/删除、物理 USB 传输和移动网络服务；每卡只能启用一个配置、不支持 MEP；多卡手机要重选卡；Issue #33 还记着内置 eSIM 可见性的坑。另外 Issue #14 那种”状态卡在待确认、写操作被永久挡住”的问题虽然已修，但也说明真实机型上的边界情况不少。想当日常主力工具用，现在还早。
八、与同类型项目对比有哪些亮点和不足？
挑三个常见参照物，说人话对比一下。
| 对比对象 | 8bercue 更强的地方 | 8bercue 不如的地方 |
|---|---|---|
| OpenEUICC / EasyEUICC estkme-group 的开源 LPA，Apache-2.0，非特权版 EasyEUICC 可当普通应用装，支持可插拔 eSIM 与 USB 读卡器，Android 9+，有现成预编译 APK |
靠用户授权的 Shell 通道直接够到底层 HAL，绕开普通应用的 OMAPI 证书检查，不要求卡片预先把它加进 ARA-M 签名白名单；没有厂商品牌白名单，按实际接口发现能力；隐私与中断恢复的边界文档更细 | 项目年轻得多，19 Star、只有 Beta 预发布；兼容性表目前就寥寥几组机型；没有稳定版，也没有 USB 读卡器这类额外通路；社区规模、长期维护和现成 APK 的便利性都不如对方 |
| 卡厂商官方 App 5ber、9eSIM 等随卡提供的客户端与账号体系 |
开源可审计（AGPL-3.0-only，发布附带完整对应源码），不需要账号、不向厂商服务发送激活信息，能避开只做在厂商 App / 账号里的注册与下载计数，中英双语、本地管理 | 没有官方适配、客服和质保，出了问题得自己在 Issue 里复盘；Beta 明确不保证下载、切换和上网；厂商端通常对自家卡的固件特性、开通流程掌握得更全，兼容性工作更省事 |
| lpac / 桌面 CCID 读卡器方案 在电脑上用命令行或读卡器管理 eUICC |
直接在手机上使用，不用额外买读卡器、不用开电脑；有图形界面、中文、扫码下载和状态恢复；无线 ADB 配对一次后可重连 | 强依赖 ROM 暴露的 Secure Element 接口，换台手机或升个 ROM 就可能失效；桌面方案跨平台、可脚本化、更便于开发调试和留日志，8bercue 目前做不到这一层 |
一句话收尾：8bercue 值得关注，不是因为它现在多好用，而是它把”我的卡凭什么只能由厂商 App 管”这个问题，用一条用户授权、不 Root、开源可审计的路径认真做了一遍，还老老实实把没验证的部分标了出来。如果你手上有可插拔 eUICC、愿意折腾 ADB 或 Shizuku，可以先拿它做只读检查、顺手提交一份设备报告；如果你的目标是一台装上就能稳定切号的日常主力机，那还是等它把下载、删除、网络服务这些验收补齐再说。测试时记得用一次性配置，保管好 EID、ICCID 和激活码，别公开。
相关软件
暂无评论...