我拿一台已经解锁 Bootloader 的 Redmi K60 做实验，已经从旧版 LineageOS 换到官方 LineageOS 24，并装上匹配的 Google 服务和 Magisk 30.7。两次受控重启后均确认 UID 0，模块也能自动启动。这篇记录按这台手机的条件整理：先确认设备和镜像，再安装系统，最后验证 root 与后台服务。其他型号应使用自己的官方设备指南，不能直接照搬分区命令。

先把四件事分清楚

解锁 Bootloader，表示设备允许加载自定义镜像；它不会自动给应用 root。LineageOS 是系统，MindTheGapps 提供 Google 服务，Magisk 则通过修补启动镜像提供 root 与模块能力。旧系统允许的 ADB root 只是调试入口，也不能当成 Magisk 已安装。

这次是完整安装，Recovery 的格式化步骤会清除内部存储。现有照片、文件和应用数据需要另行备份。文中保存的启动分区镜像只覆盖启动链，不能代替用户数据备份。

设备和安装材料

项目	本次选择
手机	Redmi K60，型号 23013RK75C，代号 mondrian，ARM64
原系统	LineageOS 23.2，Android 16，2026-07-26 nightly
目标系统	LineageOS 24.0，Android 17，2026-10-12 nightly
Google 服务	MindTheGapps 17.0.0 ARM64，2026-10-06；手机版本
root 工具	Magisk 30.7，官方 APK

系统来自 LineageOS 的 mondrian 下载页；安装步骤以 Redmi K60 官方指南为准。本次 ROM 是完整更新包，payload 包含设备固件；独立下载的启动、DTBO、Recovery、vendor_boot、vbmeta 镜像与 ROM 中对应分区的哈希一致。

Google 服务要同时匹配 Android 大版本与 CPU 架构。这个组合使用 MindTheGapps 17 ARM64，不能拿 Android 16 的包替代，也不要误下 Android TV 版本。Magisk 取自 官方发布页。

校验下载，保留原始启动镜像

先核对官网下载页的 SHA256，再操作手机。校验通过后，另外保留一份官方原始 boot.img；修补镜像和原镜像应使用不同文件名。

sha256sum lineage-24.0-20261012-nightly-mondrian-signed.zip
sha256sum boot.img dtbo.img vendor_boot.img recovery.img
sha256sum MindTheGapps-17.0.0-arm64-20261006_111038.zip
sha256sum Magisk-v30.7.apk

本次 ROM 的 SHA256 是：

7841c8259eb742754e3c9ce17618d6a7c8d6c142f4123320c8edd7d60ba72255

MindTheGapps 的 SHA256 是 6b38929ec345d96b6d64ad82f391869b7a60b3260efb0661b543b109b3ce646d，已与官方发布页及校验文件匹配，ZIP 完整性检查通过；包内版本为 Android 17 / SDK 37、架构 ARM64。系统安装后确认 SDK 37，Google Play 服务包存在，Play 商店能打开到登录界面；本次没有登录 Google 账号，也没有验证 Play Integrity。后续如果改用更新构建，应重新记录文件名、版本、哈希和验证结果，不能混用不同日期的 boot.img。

这台旧版 LineageOS 允许临时 ADB root，因此我额外备份了两个槽位的 boot、dtbo、vendor_boot、recovery 和 vbmeta，并逐一比较手机端原分区与电脑端文件的哈希。普通未 root 的系统未必开放这个入口；不能为了照搬这一步假设所有手机都有同样权限。

WebUSB 是什么，和 fastboot 有什么关系

LineageOS Flash Tools把 ADB、fastboot 等操作放进浏览器。浏览器仍通过 USB 与手机通信，设备必须处于相应模式。网页上的“连接”不等于已经刷入系统，也不会替你解锁 Bootloader。

使用浏览器 ADB 前，应停止电脑端占用 USB 的 ADB server。切换到 Bootloader 或 Recovery 后，可能需要重新连接。遇到浏览器原生的 USB 设备选择器，要确认选中的是目标手机。具体用法见 官方 Web Flash Tools 说明。

本次使用 Chrome 打开官方 Flash Tools，实际通过 WebUSB 连接到 Bootloader，并读取到 mondrian、当前槽位等设备信息。选择镜像文件时，浏览器扩展因未启用本地文件访问而无法完成上传，所以网页没有执行任何分区写入。随后关闭网页连接，改用 Google Platform-Tools 37.0.1 完成刷写。这个结果说明 WebUSB 连接可用，不能记作“通过网页完整刷机成功”。下面记录实际采用的命令行步骤。

安装系统：先启动相关镜像，再进入 Recovery

进入 Bootloader 后，先检查产品代号、当前槽位和解锁状态。确认仍是 mondrian，Bootloader 已解锁，电量充足且 USB 稳定，再按照设备指南写入镜像。

fastboot devices
fastboot getvar product
fastboot getvar current-slot

按设备指南处理准备镜像。本次安装前活动槽为 b，因此实际明确写入 boot_b、dtbo_b、vendor_boot_b 和 recovery_b；下例使用工具解析当前槽位的分区名，仍需逐项核对 fastboot 的实际写入输出：

fastboot flash boot boot.img
fastboot flash dtbo dtbo.img
fastboot flash vendor_boot vendor_boot.img
fastboot reboot bootloader
fastboot flash recovery recovery.img
fastboot reboot recovery

Recovery 启动后，应看见 LineageOS 标识。选择 Factory Reset → Format data / factory reset 完成完整安装所需的格式化，再选择 Apply update → Apply from ADB，传入已校验的 ROM。

adb sideload lineage-24.0-20261012-nightly-mondrian-signed.zip

本次 ROM 和 GApps 的 sideload 均返回退出码 0、Total xfer: 1.00x。电脑端在约 47% 暂停是 sideload 中可能出现的进度表现，应以 Recovery 的最终安装结果为准，不能仅根据进度条判断成功。官方 ROM 本体若出现签名校验失败，应停止安装，排查文件和设备匹配关系。本次指南没有要求额外擦除 super，也没有要求通过刷写 vbmeta 关闭校验，因此不加入这些操作。

MindTheGapps 必须放在首次系统开机之前

ROM 安装完成后，先重启到 Recovery，让它使用新系统对应的槽位和环境，再安装 Google 服务；此时不要先进入系统。A/B 更新可能切换活动槽位，不能继续沿用安装前记录的槽位。

adb sideload MindTheGapps-17.0.0-arm64-20261006_111038.zip

附加包的签名提示应按设备指南处理，并以来源和哈希已经核验为前提。LineageOS 的 Google Apps 说明明确要求在系统安装后立即安装 GApps；如果已经先启动 LineageOS，再补装通常需要恢复出厂设置，否则可能崩溃。全部附加包安装成功后，才首次启动系统。

用 Magisk 修补这台手机自己的 boot.img

Magisk 的启动镜像选择要看设备结构。这台 mondrian 有 boot 分区，没有 init_boot 分区；本次官方 boot.img 包含 ramdisk，因此修补的是 boot.img。不能根据“Android 版本较新”就一律选 init_boot，也不要下载别人分享的预修补镜像。

常规操作是安装官方 Magisk APK，在“安装”中选择“选择并修补一个文件”，选取与刚安装 ROM 完全对应的官方 boot.img，再把生成的文件取回电脑。应使用 adb pull 直接传输，并核对文件哈希。流程参考 Magisk 官方安装文档。

本次准备阶段利用这台手机原有的临时 ADB root，运行官方 APK 内的工具在同一台手机上完成修补。重新解包后，确认保留加密和 verity 的标志，且内核内容与原始镜像一致；随后将修补镜像写入新系统活动槽位 boot_a，实际启动并授权 Shell 后，确认 uid=0(root)；SELinux 仍为 Enforcing。

新系统首次开机确认正常后，再回到 Bootloader 查询当前槽位，把修补镜像写入该槽位对应的 boot。命令行工具对 boot 的实际槽位选择必须在输出中核对；不应同时覆盖两个槽位，也不能拿旧系统的 boot 镜像混刷。

fastboot getvar current-slot
fastboot flash boot magisk_patched.img
fastboot reboot

启动后打开 Magisk，确认主程序已安装。应用申请 root 时再按用途授权。本机的 su 位于 /debug_ramdisk/su，普通 ADB shell 的 PATH 没有它。使用下列命令，并在 Magisk 中按需授权 Shell：

adb shell '/debug_ramdisk/su -c "id"'

这次修补保留了 verity 和强制加密相关标志，没有要求关闭 SELinux。Magisk 首次通知权限界面期间观察到一次额外重启，原因未确定；后续两次受控重启均完成开机、root 和模块启动验证。它是本次设备的观察记录，不能代替后续系统更新后的检查。

让后台服务随开机恢复，也能随时停下来

这次还通过一个自制 Magisk 模块启动 Komari 探针和 frp-panel 客户端。它使用 late_start 的 service.sh，等待系统启动完成；只有一个监督进程，负责防止重复启动、处理崩溃后的有限退避和限制日志体积。标准的模块停用、卸载，以及动作按钮都能停止服务。

Linux ARM64 静态程序不一定直接适配 Android。本次发现 frp 缺少可用的系统 DNS 配置，所以给两个进程建立私有挂载命名空间和兼容运行目录，保留真实网络与设备指标视图。旧 Android 16 上先做了运行预检；换到 Android 17 后重新验证了模块启动、防多开、stop、disable 与卸载脚本清理，并从服务端确认真实采样和 FRP 在线。

配置与凭据单独保管，不放进公开模块。TLS 证书校验和 SELinux 保持开启，不长期持有唤醒锁；接入探针和 FRP 也不等于要开放手机的 ADB、SSH 或文件端口。启动脚本的机制参考 Magisk 开发指南。

本次实测结果（2026-10-16）

检查项	结果
镜像、ROM、GApps 校验	官方哈希匹配；10 个旧启动分区备份匹配
WebUSB	连接和读取设备信息成功；文件上传受扩展权限限制，刷写使用官方 CLI
新系统	24.0-20261012-NIGHTLY-mondrian，Android 17 / SDK 37，活动槽 a
GApps	Google Play 服务包存在，Play 商店显示登录页；未测试账号登录和完整性认证
Magisk	30.7（30700），Shell UID 0，SELinux Enforcing
再次重启	root、模块、已保存 Wi-Fi 和两个客户端自动恢复
服务端	FRP 独立客户端在线、零隧道；Komari 至少两次手机采样递增
停止与清理	stop、disable、卸载脚本清理以及重新配置启动通过

本文使用的模块为 1.1，仅适配 mondrian。下载模块脚本源码与构建工具（约 9 KB，无二进制和凭据）。解压后先阅读 README.txt，运行 python3 build_module.py，工具会从官方发布地址下载固定版本的两个 ARM64 程序、检查哈希并生成可安装 ZIP；在 Magisk 的模块页安装生成的 ZIP，写入自己的私有配置后重启。源码包 SHA256：1d94fb8f8b379173396e2f6679ca3c5ba7c474afd02e94cbb043371adbfeb5f4。两个上游程序各自遵循其许可证；公开源码包没有重新分发它们的二进制。

还有一个与客户端无关的故障：系统把当前 Wi-Fi 判为“无互联网”，把保存的配置永久禁用，导致重启后不自动连接。本次确认 HTTPS 实际可达后，记住“仍然连接”并重新启用该配置；修复后息屏关闭 Wi-Fi 12 秒再打开，约 6.3 秒自动连回，之后重启也能自动连接。仅为这个网络保存选择，没有关闭全局网络验证。其行为可对照 Android 的无互联网网络确认界面源码。

本次短时测试全程由 USB 供电，验证了息屏、断网、重启和控制脚本。尚未做拔线后的长时间深度休眠或耗电对照，因此不能据此保证全天在线或某个续航数值。

后续更新和恢复

系统更新可能替换 boot。每次更新都应对照当前 ROM 重新处理 Magisk，不要把这次的修补镜像长期当成通用文件。若刷入 Magisk 镜像后无法启动，优先回到 Bootloader，恢复与当前系统同版本的官方 boot.img，再排查兼容性；旧版本启动分区备份不能跨版本盲目恢复。

本次不重新上锁 Bootloader。root 权限授予具体应用时按需要选择，后台服务也保留明确的退出入口。系统更新后应再次确认 boot 对应版本、root 授权、联网与服务端采样。