十年前的老平板也能编译 LineageOS：Galaxy Tab S 8.4（klimtwifi）源码实战

2014 年的 Galaxy Tab S 8.4（SM-T700，代号 klimtwifi）今天还在被不少人当阅读器、监控屏或者车载屏用。官方早已停更，但它的 LineageOS 14.1（Android 7.1，分支 cm-14.1）设备树是公开的，整条编译链路完整可跑。换句话说：只要有一台像样的 x86 服务器，你完全可以自己给它出一版带最新安全补丁的卡刷包。

这篇教程把整条线走一遍：环境怎么装、源码怎么拉、机型怎么接、blobs 怎么补、编完怎么拿回来刷。老工具链的坑也会逐个列出，避免你在 5 小时的编译跑到 90% 时才看到一行红字。

编译老机型 ROM 属于典型的「耗时但不难」的活。真正让人卡住的从来不是命令本身，而是几年前的工具链在今天默认配置下集体失效。

先看清要准备什么

整套流程对硬件的要求比想象中高。Android 7.1 时代的源码已经有 30GB 上下，加上 out/ 中间产物和 ccache，磁盘给少了必然中途报 No space left on device。

为什么强调 Debian 9？因为 Debian 10 起官方源里已经没有 OpenJDK 8 了，而 cm-14.1 的 Jack／javac 链路只认 8。省事的选择是直接开一台 Debian 9 的云主机；已经装了 Debian 10 的机器，要么换系统，要么自己补 JDK 8 的源，不建议硬撑。

另外提醒一句：能连到设备再动手。编译只需要源码，但补厂商 blobs 时往往要从机器里抽二进制文件，或者至少需要一个能刷 TWRP 的平板做验证。

第一步：搭一套能用的编译环境

1. 安装依赖

先更新系统，然后一次性把编译所需的库装上。这些包名在 Debian 9 上是可以直接 apt 到的：

sudo apt update && sudo apt upgrade -y

sudo apt install -y bc bison build-essential ccache curl flex \
  g++-multilib gcc-multilib git gnupg gperf imagemagick \
  lib32ncurses5-dev lib32readline-dev lib32z1-dev liblz4-tool \
  libncurses5 libncurses5-dev libsdl1.2-dev libssl-dev \
  libwxgtk3.0-dev libxml2 libxml2-utils lzop pngcrush rsync \
  schedtool squashfs-tools xsltproc zip zlib1g-dev \
  openjdk-8-jdk python2.7 screen

2. 把 Java 固定到 8

环境变量写在 ~/.bashrc 里最稳，注意别让系统自带的 JDK 配置覆盖它：

export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64
export PATH=$JAVA_HOME/bin:$PATH
java -version   # 必须输出 1.8.0_xxx

如果 java -version 显示的是 11 或 17，常见原因是安装 JDK 时 /usr/lib/jvm/java-8-openjdk-amd64 这个软链被解引用替换掉了。可以直接重建链接，让所有引用它的脚本都指回 8：

sudo ln -sfn /usr/lib/jvm/adoptopenjdk-8-hotspot-amd64 \
  /usr/lib/jvm/java-8-openjdk-amd64
update-alternatives --config java

3. 处理 Python 2 与 ccache

cm-14.1 的很多脚本 #!/usr/bin/env python 仍然指向 Python 2。Debian 9 默认只有 python3，所以要显式装 2.7 并切换默认：

sudo update-alternatives --install /usr/bin/python python /usr/bin/python2.7 1
python --version   # Python 2.7.x

ccache 能让第二次编译快上几倍，务必在拉源码前就打开：

export USE_CCACHE=1
export CCACHE_DIR=$HOME/.ccache
export CCACHE_EXEC=/usr/bin/ccache
ccache -M 50G

第二步：同步 cm-14.1 源码

装 repo 工具，然后初始化仓库。这里分支要选 cm-14.1，不是 lineage-20 那种新分支：

mkdir -p ~/bin
curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo
chmod a+x ~/bin/repo
export PATH=$HOME/bin:$PATH

mkdir -p ~/android/lineage && cd ~/android/lineage
repo init -u https://github.com/LineageOS/android.git -b cm-14.1 --depth=1
repo sync -c -j8 --force-sync --no-clone-bundle --no-tags

几个经验值：--depth=1 只拉最新一次提交，能省掉一大半体积；-j8 是并发数，按 CPU 核数给；同步中断了直接重跑 repo sync，它是增量续传的，不会从头再来。

同步期间强烈建议挂在 screen 里：

screen -S build
# 断线后重新连接
screen -r build

30GB 的源码按网络状况要跑几十分钟到几小时。不必盯着，但要确认最后一条是 Syncing work tree: 100%。

第三步：接上 klimtwifi 机型与厂商 blobs

源码只是一个通用框架，真正让它认识这块平板的是设备树和厂商闭源文件。cm-14.1 的 breakfast 会自动去清单里找 klimtwifi 对应的 device tree，并拉到一个本地分支：

cd ~/android/lineage
source build/envsetup.sh
breakfast klimtwifi

执行完应该看到 device/samsung/klimtwifi 和 device/samsung/exynos5420-common 两个目录。如果没有，说明分支或代号写错了，先回上一步检查。

补齐 proprietary 文件

接下来是整条流程最容易失败的地方。设备树里引用了大量厂商二进制（相机、传感器、音频、蓝牙），这些东西不进 AOSP 仓库，需要单独放到 vendor/samsung/klimtwifi。两条路：

• 从本机抽取：平板进 TWRP，连 USB，执行设备树里的 extract-files.sh，脚本会自动把 /system 下的相关文件复制到 vendor 目录。
• 直接拉现成的 proprietary 仓库，放入 vendor/samsung/ 下，确认目录结构是 vendor/samsung/klimtwifi/proprietary/...。

这里缺文件不会在同步阶段报错，只会在编译后期以 ninja: error ... missing and no known rule to make it 的形式炸出来。尤其注意音频相关的 libaptX-1.0.0-rel-Android21-ARMv7A.so 这类名字很长的库，一旦漏掉就得从头再跑一遍 make。

判断是否齐全的笨办法：把 vendor/samsung/klimtwifi 的体积和一份已知完整的包对比，差距超过几十 MB 基本就是漏了。

第四步：开始编译

一切就绪后，一条命令开跑：

cd ~/android/lineage
source build/envsetup.sh
breakfast klimtwifi
brunch klimtwifi

首次编译在 4 核 16G 的机器上通常需要 5 到 8 小时。中途可以看 out/ 的增长判断进度，也可以用：

tail -f out/verbose.log.gz 2>/dev/null | grep -i error
watch -n 30 'du -sh out/'

如果中断了，不必重新 make clean，直接再执行一次 brunch klimtwifi 就是增量编译，已完成的模块会被跳过。

看到下面这行就说明成功了：

#### build completed successfully (05:47:12 (hh:mm:ss)) ####

out/target/product/klimtwifi/
├── lineage-14.1-20260404-UNOFFICIAL-klimtwifi.zip
├── recovery.img
└── system.img

卡刷包一般 400MB 左右，recovery.img 可以用来更新 TWRP。若你只需要 zip，其余文件可以忽略。

第五步：把产物拿回来并刷入

1. 跨机器传输

云主机上的产物别用浏览器下载，几十 KB/s 会很痛苦。用 gcloud compute scp、rsync -avP 或对象存储中转都可以：

gcloud compute scp \
  instance-1:~/android/lineage/out/target/product/klimtwifi/lineage-14.1-*.zip \
  ./ --zone=asia-east1-b

md5sum lineage-14.1-*.zip

传输完先算一次 md5，并和服务器上的值比对，避免压缩包在传输中损坏导致刷机失败。

2. 刷入

1. 平板电量 50% 以上，备份照片、聊天记录与 EFS 分区。
2. 进 TWRP，执行 Wipe → Advanced Wipe，勾选 Dalvik / Cache / Data / System。
3. 把 zip 推到内置存储，Install 选中刷入。
4. 需要 Google 服务的话，同一轮再刷一个 arm / 7.1 / pico 的 GApps 包。
5. 重启。首次开机 5 到 10 分钟属于正常现象，别急着强制断电。

如果刷完卡在开机动画超过 15 分钟，先回 TWRP 双清再试；仍然不行，检查是不是漏刷了 GApps 对应的架构与版本，或者 boot 分区被旧内核占用。

老工具链的四个必踩坑

下面这四类报错几乎每次都会遇到，先看图再对照处理，能省掉大半排查时间：

还有一类不算报错但很折磨人的问题：编译比下载还快。在带宽只有几 MB/s 的实例上，拉源码和拉 blobs 花掉的时间可能超过编译本身。选机房时优先挑离源码 CDN 近的区域，或者先在本地同步好再打包上传。

时间与资源参考

最后几点建议

• 先跑通再改：第一次编译不要动设备树里的任何配置，确保能出包，再考虑加特性或改内核。
• 保留 vendor 目录：vendor/samsung/klimtwifi 是最难复原的部分，迁机器时优先备份。
• 记录提交号：出包后把 repo manifest -r 的输出存一份，出问题能精确回滚。
• 别在主力机上试：老平板刷坏还有救，但 EFS 丢了就真的没信号，务必先备份分区。

如果你还不熟悉「解锁 BL → 刷 Recovery → 刷包」这条基础链路，建议先看 类原生 AOSP 刷机全流程；用 adb sideload 刷包卡住的话，可以对照 sideload 常见失败原因；想先了解通用的源码编译流程，也可以从 LineageOS 编译入门 开始。

一台十年前的老平板，配上一条完整的编译链，其实还能再战很久。编译这件事本身并不神秘，难的是把那些散落在各处的旧工具链细节一次性对齐。