简介：一份面向红米3S/3X设备的LineageOS 17.1第三方固件包，基于Android 10（Q）构建，适用于已经解锁Bootloader、希望绕过原厂系统限制并体验更高版本安卓的用户。压缩包共14个文件，整体约747.39MB，核心内容包含system.new.dat.br与vendor.new.dat.br两个Brotli压缩的分区镜像、vendor.patch.dat与system.patch.dat补丁文件、transfer.list刷机列表、boot.img启动镜像，以及META-INF目录下的刷机脚本和compatibility.zip兼容性组件，各文件用途明确，覆盖刷机所需的主要环节。已有808人学习下载，适合具备一定刷机基础、想把红米3S稳定升级到Android 10的玩机者参考，通过理解镜像、补丁和刷机脚本的配合关系，可以更安全地完成刷入操作，并有效降低因操作不当导致设备变砖的风险。
1. 红米3S刷LineageOS 17.1：这份固件包到底怎么用
如果你手里还有一台红米3S（land/3X），大概率已经被官方系统拖到卡顿、应用不兼容的境地了。这个lineage-17.1-红米3S-3X-land_2.zip并不是普通意义上“解压安装”的刷机包，而是一整套基于 Android 10 的 LineageOS 17.1 增量/全量升级方案。压缩包里的system.new.dat.br、vendor.patch.dat、boot.img各司其职，DSU 特性、动态分区、Brotli 压缩、transfer list 增量逻辑全部编排在里面。适合两类人：一是想给老设备续命、愿意折腾的日常用户，二是想研究 Android 自定义 ROM 打包结构和刷机脚本的开发者。前提只有一个——Bootloader 必须已解锁，否则 Recovery 阶段直接失败。接下来我从文件结构讲起，把每个组件的真正用途、刷入顺序和常见失败点拆开说清楚。
2. 固件包内部结构与分区映射：从 transfer list 到 dat.br 的读写逻辑
2.1 为什么是 .dat.br 而不是 .img：Brotli 压缩与动态分区的关系
Android 10 开始，Google 在系统镜像分发包中逐步用.dat.br取代裸.img。system.new.dat.br和vendor.new.dat.br本质上是system与vendor两个分区的文件系统镜像（ext4），经过 Brotli 算法压缩后得到的二进制流。system分区存放 Android 框架、系统应用、库文件，vendor分区则存放硬件抽象层（HAL）、厂商专有驱动和配置。这两个分区在动态分区（Dynamic Partition）架构下由 super 分区动态管理，所以刷机时不能像老机型那样直接把.imgdd 到固定分区号，必须由 Recovery 根据transfer list把数据解包、重组并写入正确槽位。
system.new.dat.br的解压过程不是简单的解压到内存再写入。刷机脚本会先调用sideload或 Recovery 内置的install流程，读取.dat.br文件头，使用 Brotli 解码器还原出system.new.dat（未压缩的 sparse image），然后交给block_image_update函数。你看到的backuptool.sh和backuptool.functions会在系统写入前备份当前 ROM 的/system和/vendor下增量更新的部分（如 GApps 的 addon.d 脚本），写入后再恢复，确保你刷完 ROM 后 Google 套件不丢。
2.2 transfer list 的每行含义：range 集合与分区重放
system.transfer.list和vendor.transfer.list并非简单的文件清单，而是block_image_update的指令序列。第一行是版本号（常见为 1 或 2），第二行是本次总共要操作的文件块数量，后续每行以new、zero、erase或free开头，后跟分块区间。
比如system.transfer.list里可能出现的片段：
1 12 new 5860 1866 2048 4095 4096 zero 64 6144 6208 erase 128 0 128逻辑说明：第一行1表示 transfer list 版本；12表示后续有 12 条操作记录。new 5860表明接下来有 5860 个 block 的新数据，后面的1866 2048是源块区间（以 512 字节 block 为单位），表示从旧的system分区读取这些块，配合.patch.dat做增量合并。zero 64表示把目标分区某段清零，erase 128则表示擦除区段。整份 list 的作用是让 Recovery 精确知晓哪些块需要从 data 流解压写入、哪些块可以复用旧分区内容。
参数要点：如果你自己制作 ROM 包，用img2sdat生成 transfer list 时，-v 2会生成版本 2 格式，支持增量 patch；-v 1则是全量镜像。红米3S 的 land 机型常用版本 2 的system.transfer.list，因为 baseband 等分区不动，系统更新只需要替换用户空间块，能省去大量下载流量。
2.3 vendor.patch.dat 与 system.patch.dat：增量补丁的 diff 机制
如果你之前刷过完整 ROM 包，会发现这里多出了system.patch.dat和vendor.patch.dat。这两个文件配合 transfer list 里的new操作，实现一种“增量刷机”能力。举个实际场景：假设你已经安装过 LineageOS 17.1 的上一个 build（比如 2025 年 1 月版），这次的land_2.zip只是 OTA 全量包中包含了对旧版本的 diff 补丁。patch.dat存储的是二进制差量，格式一般为 bsdiff 或 imgdiff 变种。Recovery 脚本会读取旧分区对应块，与patch.dat合成新数据，再写入目标分区。
我用一个简化命令模拟其合成逻辑（非实际设备执行，仅供理解）：
# 合成伪代码示意：将旧镜像与 patch.dat 合并 bsdiff old_system.img system.patch.dat > new_system.img逻辑说明：bsdiff是经典的二进制差分工具，它根据旧文件与补丁文件生成新文件。在实际刷机中，Recovery 内部的applypatch二进制完成类似工作，它还会对合成后的块做 SHA-256 校验，与system.transfer.list中记录的哈希比对。
参数说明：applypatch的命令行参数通常包括-s（源文件）、-t（目标文件）、-p（补丁文件）和-c（校验值）。例如：
applypatch -b /dev/block/bootdevice/by-name/system \ -p /sdcard/system.patch.dat \ -t /data/update/system_new.img \ -c 3aef...9f2c如果校验失败，Recovery 会直接抛出failed to apply patch错误，此时你需要在电脑上重新校验 zip 的完整性。
3. 刷机前准备与 Recovery 刷入流程：从解锁到 sideload 的完整实操
3.1 Bootloader 解锁与 Recovery 环境要求
红米3S 的 Bootloader 解锁需要小米官方解锁工具，登录账号并绑定设备，等待 7 天左右。解锁完成后，刷入第三方 Recovery 是必须步骤。常见选择是 TWRP 3.3.1 及以上版本，因为 Android 10 的动态分区补丁需要较新的 Recovery 支持。如果你使用旧版 TWRP 3.2.x，刷入时大概率报Error 7——原因是 Recovery 的 addon.d 兼容脚本不识别当前系统版本。
启动到 fastboot 模式：
adb reboot bootloader检查设备是否被识别：
fastboot devices正常输出类似xxxxxxxx fastboot。如果显示no permissions，在 Linux 下需要给 udev 规则添加设备 ID；Windows 下确认驱动处于 fastboot 模式而非 adb 模式。
刷入 TWRP：
fastboot flash recovery twrp-3.3.1-0-land.img fastboot boot twrp-3.3.1-0-land.img这里我推荐第一次用fastboot boot临时引导 TWRP，而不是直接 flash 到 recovery 分区，防止镜像不兼容导致无法进入 Recovery。临时引导成功后，再在 TWRP 里安装镜像到 Recovery 分区。
3.2 双清分区选择：你不需要清 vendor
红米3S 的 data 分区是 ext4，但启用 FBE（文件级加密）后，TWRP 需要输入密码解密 data。若忘记密码，只能在 TWRP 中格式化 data 分区。常规双清命令：
# TWRP 内操作，依次点击或使用 adb 命令 adb shell twrp wipe cache adb shell twrp wipe dalvik adb shell twrp wipe data注意：不要清除vendor分区，因为 LineageOS 17.1 的 vendor 由包内vendor.new.dat.br单独重刷，手动 wipe 可能导致分区表异常。清除 cache 和 dalvik 是安全的，data 清除后内部存储会被重置，提前备份/sdcard里的照片和下载内容。
3.3 通过 adb sideload 刷入固件
当 TWRP 主界面选择Advanced -> ADB Sideload，系统会进入 sideload 模式，此时用电脑执行：
adb sideload lineage-17.1-红米3S-3X-land_2.zip传输完成后，TWRP 会自动执行包内的META-INF/com/google/android/updater-script。该脚本会依次执行以下动作：挂载 system 与 vendor 分区；运行backuptool.sh备份 addon.d 文件；调用block_image_update处理system.new.dat.br与vendor.new.dat.br；最后写入boot.img至 boot 分区。
逻辑说明：updater-script采用 edify 语法，命令package_extract_file("boot.img", "/dev/block/bootdevice/by-name/boot")直接写镜像。如果脚本执行到一半报E:Error in /sdcard/xxx.zip (Status 7)，通常是两种原因：一是你的机型不匹配 updater-script 头部assert语句中的 ro.product.device 检查，二是 TWRP 版本过旧。红米3S 的land设备名会被校验，必须是land或3X才予以放行。
3.4 刷入后首次启动与加密行为
刷完重启，系统首次启动会进行 dex2oat 预编译，耗时约 5～10 分钟。不要强制重启，否则可能损坏 data 分区。LineageOS 17.1 默认开启 FBE，如果之前 data 分区是未加密状态，首次启动会自动加密，这一过程在设置锁屏密码后触发。如果你希望保持未加密状态，在刷机完成后立即进入 TWRP 执行：
adb shell twrp decrypt adb shell touch /data/.noselinux但这会导致设备失去文件级加密保护，不建议日常使用。这里只是提一下存在该选项。
4. 刷机后处理与常见错误排查：Zip 损坏、分区空间不足、FBE 解密失败
4.1 刷机报错could not find EOCD或Error reading zip archive
很多人解压 zip 正常，但 sideload 时提示could not find EOCD，这是 ZIP 文件中央目录缺失或传输被截断。常见做法是先核对 zip 的 SHA-256：
sha256sum lineage-17.1-红米3S-3X-land_2.zip将结果与发布页提供的哈希比对。网络下载时若中途断开，下载工具会误报已完成。另一个坑是 zip 内文件使用非标准压缩算法，但 LineageOS 官方包不会出现这种情况，你可以用unzip -t快速验证：
unzip -t lineage-17.1-红米3S-3X-land_2.zip输出末尾应显示No errors detected in compressed data of xxx.zip。如果 zip 校验没问题但 sideload 仍报 EOCD，问题可能出在 USB 线缆或 adb 版本过旧。我一般会顺手把 adb 更新到 1.0.41：
adb version低于 1.0.36 时传输不稳定，建议升级到 platform-tools 最新版。
4.2 分区空间不足：system分区 resize 失败
红米3S 的系统分区原厂大小约 2.5GB，LineageOS 17.1 完整包解压后system分区占用约 2.8GB，直接写入会报No space left on device。解决思路是启用动态分区调整，在 TWRP 中执行：
adb shell twrp resize2fs /dev/block/bootdevice/by-name/system如果 resize2fs 不支持该分区类型（因为动态分区由 super 管理），你需要先查看当前分区表：
adb shell ls -l /dev/block/bootdevice/by-name/supersuper分区是 Android 10 动态分区的宿主分区，system、vendor等子分区在它之上逻辑划分。红米3S 的super大小是 5GB 左右，正常情况下足够 LineageOS 17.1 + GApps 使用。如果你先前刷入了过大的 vendor 镜像挤占空间，可以删除 vendor 逻辑分区再重建。但普通用户更建议采用干净重刷方案：在 TWRP 中Wipe -> Format Data，然后用 fastboot 刷入官方线刷包恢复分区表，再重新操作。
4.3 刷完开机卡在 LineageOS 启动动画：logcat 排查
卡启动动画通常与 SELinux 策略或 HAL 服务崩溃有关。进入启动循环后，连接 adb 抓取 log：
adb wait-for-device adb root adb shell logcat -b all -d > boot_log.txt重点搜索FATAL EXCEPTION、avc: denied、vendor服务名。land 机型常见问题出在指纹 HAL 和传感器 HAL，如果你的备份中没有原厂 vendor 模块，LineageOS 可能只支持基础功能。我的惯用手段是备份原机/vendor/etc下的所有*_idc、*_kl文件和固件库，刷机后恢复。但注意这些文件在 Android 10 的 vendor 分区里是只读挂载，需要先 remount：
adb root adb remount adb push key_original.kl /vendor/usr/keylayout/ adb shell chmod 644 /vendor/usr/keylayout/key_original.kl adb reboot不过这种做法仅对特定型号有效，红米3S 在 LineageOS 官方适配中一般已包含必要的驱动，遇到卡动画先尝试清除/data下的system缓存。
5. 基于 backuptool 实现 ROM 升级保留 Magisk 与 GApps：addon.d 脚本实战
5.1 backuptool.sh 的执行时机与变量传递
backuptool.sh本质是 shell 脚本，由刷机脚本在preinstall和postinstall阶段调用。它扫描/system/addon.d目录下所有以数字开头的脚本文件，以环境变量C区分执行阶段。升级 ROM 时，Recovery 在写入新系统前执行backuptool.sh backup，备份 GApps 的etc、framework、priv-app等文件；写入完成后执行backuptool.sh restore恢复备份。这套机制保证你刷入新版 LineageOS 后，不用重新刷入完整的 Open GApps 包。
如果你想保留 Magisk，需要把 Magisk 的卸载/恢复逻辑写成 addon.d 脚本。常见做法是：
#!/sbin/sh # 文件路径：/system/addon.d/95-magisk.sh case "$1" in backup) cp /data/adb/magisk/magisk.db /tmp/magisk.db ;; restore) cp /tmp/magisk.db /data/adb/magisk/magisk.db ;; esac这段脚本的逻辑是：备份阶段把 Magisk 的数据库复制到临时目录，还原阶段再拷回。仅保留文件还不够，因为升级会覆盖 boot.img，Magisk 的补丁会丢失。更推荐在升级完成后重新安装 Magisk APK，再执行：
adb reboot sideload方式重现修补 boot。或者使用 Magisk 的magisk --install命令：
adb shell magisk --install /sdcard/Download/magisk.zip5.2 自定义 addon.d 脚本保留内核参数
红米3S 上部分用户会调整内核参数优化触控采样率或电量管理，这些通常通过sysfs节点设置。写一个 addon.d 脚本在 boot 后自动设置，会比每次手动 echo 可靠。
在/system/addon.d/99-tweaks.sh中写入：
#!/sbin/sh # 恢复部分内核参数 file=/tmp/tweaks.conf case "$1" in backup) cat /sys/devices/virtual/input/input0/event0/sec_touchscreen/tsp_threshold > $file ;; restore) threshold=$(cat $file) echo $threshold > /sys/devices/virtual/input/input0/event0/sec_touchscreen/tsp_threshold ;; esac参数说明：tsp_threshold是触控屏的按压阈值，数值越小越灵敏。红米3S 常见默认值在 60 左右，可以调到 45 但可能增加误触。backup阶段读取当前 sysfs 节点值，restore阶段写回。注意 sysfs 节点路径因内核版本差异可能不同，实际使用前需要先确认：
adb shell find /sys -name "*threshold*"如果输出为空，说明你的内核没有编译该导出节点，脚本不会生效，需要寻找其他可调参数。
5.3 验证 backuptool 是否正常运行
刷机后想确认 addon.d 是否被调用，检查/tmp/recovery.log。在 TWRP 中执行：
adb shell cat /tmp/recovery.log | grep -E "backuptool|addon.d|magisk"正常应看到类似：
I:/system/addon.d/95-magisk.sh: backing up files... I:/system/addon.d/99-tweaks.sh: restoring tweaks...如果没有任何输出，说明 backuptool 未执行或脚本权限不对（需要 755 权限）：
chmod 755 /system/addon.d/*.sh5.4 OTA 升级与底包匹配的坑：failed to copy spatial iop zip的类似报错
红米3S 从 LineageOS 16 直接 OTA 到 17.1 时，如果底包的 vendor 仍是旧版，刷机过程中可能出现failed to copy spatial iop zip这样的提示，实则是因为 vendor 分区内缺少 Android 10 要求的spatial iop文件（升级包解压时尝试复制该文件到/vendor/etc/iop/失败）。解决办法是刷入完整包前先手动格式化 vendor：
adb shell twrp wipe vendor或者用 fastboot 刷入对应版本的 vendor.img，然后重新刷入 LineageOS 17.1。注意格式化 vendor 后必须马上刷入该包，否则手机无法正常引导。
6. 用arecord与tinymix验证音频 HAL：刷机后必测的硬件项
6.1 检查音频节点与 mixer 路径
红米3S 的音频 Codec 是 WCD9335，由 vendor 分区内的audio.primary.msm8937.so驱动。刷完 LineageOS 17.1 后，如果扬声器无声或麦克风失灵，先检查 mixer 状态。连接 adb 后运行：
adb shell tinymix该命令会列出所有 mixer 控件。关注RX1 MIX1 INP1、RX2 MIX1 INP2以及PRI_MI2S_RX等节点。正常处于播放状态时，RX1 MIX1 INP1应设为DEC1或DEC2，而不是ZERO。如果看到ZERO，说明音频路由没有正确建立，可能是 HAL 库不匹配。
6.2 用 arecord 录制验证麦克风通路
测试录音：
adb shell arecord -D plughw:0,0 -f S16_LE -r 44100 -c 2 -d 5 /sdcard/test.wav参数说明：plughw:0,0表示 card 0 设备 0，红米3S 的 PCM 设备号通常是 0；S16_LE是 16 位小端 PCM；44100是采样率；-c 2双声道；-d 5录制 5 秒。录制完成后拉到电脑用 Audacity 打开，看波形是否有声音。若全是静音，继续排查：
adb shell cat /proc/asound/pcm检查是否有0: [DMIC]节点。如果没有，说明 Dmic 驱动未加载，这时要查 dmesg：
adb shell dmesg | grep -i "dmic\|wcd9335"如果是wcd9335: failed to get supplies，多半是 regulator 节点缺失，原厂 vendor 的msm_dailink配置与新内核不匹配。解决方法是重新刷入与 LineageOS 17.1 构建版本匹配的 vendor 镜像，不要混用别的固件包里的 vendor。
6.3 扬声器单项测试与 boot.img 内核的关系
播放测试声音：
adb push test.mp3 /sdcard/ adb shell am start -a android.intent.action.VIEW -d file:///sdcard/test.mp3 -t audio/mp3如果没有应用能播放，下载一个命令行播放器：
adb shell toybox play /sdcard/test.mp3toybox play是 LineageOS 内置的简易播放器，支持 PCM。如果播放无声音，但 tinymix 显示通路正确，怀疑boot.img里的内核驱动问题。红米3S 的音频编解码芯片通过 I2C 控制，若内核配置了错误的i2c-gpio引脚，会导致 Codec 无法初始化。这时更稳妥的做法是换用 LineageOS 官方的boot.img，而不是第三方内核。
6.4 刷机后 Wi-Fi MAC 地址变化问题的规避
红米3S 刷第三方 ROM 后，部分用户会发现 Wi-Fi MAC 地址变成02:00:00:00:00:00，原因在于persist分区内的 WCNSS 配置文件未正确挂载。检查：
adb shell ls -l /persist/WCNSS_qcom_cfg.iniLineageOS 17.1 的vendor镜像会在启动时从/persist复制该文件到/vendor/etc/wifi/。你可以在/system/addon.d/下加一个脚本来强制固定 MAC：
#!/sbin/sh # 设置固定 MAC case "$1" in restore) ip link set wlan0 address 00:11:22:33:44:55 ;; esac不过该脚本在 boot 阶段执行太晚，wlan0 可能已初始化。更可靠的路径是在init.rc中增加 service，但普通用户不建议动 init，直接接受随机 MAC 即可，不影响功能。
最后提一个容易被忽略的点：刷完系统后，如果你要给其他机器也装这个包，不要直接复制 zip 里的backuptool.sh到别处用，它会依赖backuptool.functions里定义的分区挂载点（/system、/vendor），在 A/B 设备上路径完全不同。红米3S 是 A-only 架构，这里的逻辑只适用于 A-only 动态分区设备。把这个差异记在心里，以后适配其他机型时能少踩不少坑。
本文还有配套的精品资源，点击获取
