2.1 仓库根目录新建 .pages.yml#

这是 Pages CMS 的唯一配置文件，它读取内容集合、字段、媒体目录全靠它。一份能直接用的完整配置在第四节，抄进去先跑通，再看第五节的逐段讲解按需调整。

2.2 建好媒体上传目录#

配置里会把上传图片的目录指到 public/images，空目录 Git 不会跟踪，先放一个占位文件：

1
mkdir -p public/images
2

3
touch public/images/.gitkeep

2.3 打开 CMS 确认#

登录 app.pagescms.org（用 GitHub 账号授权），选中你的仓库和分支，左侧就会出现配置里定义的内容集合和 Media 面板。侧边栏 Admin 里的 Configuration 页面显示的就是 .pages.yml 本身，以后想改配置也可以直接在这个输入框里改，保存即提交。

5.1 media：图片传到哪、URL 长什么样#

Firefly 的封面和正文图片同时支持相对路径、/ 开头的 public 路径和远程 URL，所以 input: public/images + output: /images 是最省事的组合：所有图片统一进 public，写进文章的就是 /images/xxx.png，本地和线上都能直接访问。

5.2 filename：新文件的命名规则#

• {year} {month} {day} {hour} {minute} {second}：创建时间，零填充；
• {primary}：列表视图的主字段（一般是标题），会做 slug 化处理；
• field: create：新建时弹出文件名输入框。

文章的文件名（去掉扩展名）就是 URL 的一部分，所以发布后尽量别再改名。动态这类短内容用纯时间戳命名，完全不用操心。

5.3 view：列表怎么排#

fields 是列表里显示的列，primary 是主标题列，default.sort + order 控制默认排序。文章按发布日期倒序，符合直觉。

5.4 exclude：把图片从条目列表里藏起来#

Pages CMS 的集合会递归列出目录下的所有文件——包括 png。不处理的话，文章列表里会混进一堆「空条目」。exclude 按精确文件名匹配（不支持通配符），把已有配图的文件名列进去就好；新图片一律走 Media 上传到 public/images，别再往内容目录里放。

5.5 operations：给危险操作上锁#

create / rename / delete 三个开关控制集合的新建、重命名、删除。独立页面的路由在主题里是写死的（about.astro、friends.astro、guestbook.astro 分别读固定文件），误删一个页面就是 404，所以全部禁用。

5.6 date 字段的 options#

1
- name: published
2
  type: date
3
  options:
4
    time: true                        # 带时间选择器
5
    format: 'yyyy-MM-dd HH:mm:ss'     # 写入文件的格式（date-fns 语法）

default: '' 可以阻止日期字段自动填当前时间——updated 用得上，需要时再手动选。

6.1 日期必须保持「裸格式」，否则构建直接炸#

Firefly 的内容 schema 里 published 是 z.date()，Astro 解析 front matter 时只把不带引号的日期识别成 Date：published: 2026-09-12 没问题，published: "2026-09-12" 会变成字符串，构建报错。

Pages CMS 的 date 字段默认写裸日期，正常用不会出事。风险点在于绕过 CMS 手改文件：在 GitHub 网页上编辑时手一抖给日期加了对引号，下次部署就炸。这是静态博客 + 任何 CMS 组合的共性坑，遇到构建失败先查日期。

6.2 空字段不会写出 null，但必填字段别空着#

CMS 保存时会自动省略值为空的键，正好符合 Astro schema 的默认值语义，image、updated 这类可选字段留空即可。但 title、published 这种 schema 里没有默认值的字段一定要填——配置里给它们标了 required: true，保存时 CMS 会先拦一道。

6.3 纯中文标题生成不了文件名#

{primary} 生成文件名时会做 slug 化，纯中文标题 slug 化后是空字符串。所以文章的 filename 模板用日期打头、并在新建时弹出输入框让你自己起名（中英文都行，Firefly 对中文文件名的 URL 处理是正常的）。

6.4 MDX 文件别用富文本编辑器#

friends.mdx 这类 MDX 文件里可能有 JSX 注释和组件语法，富文本编辑器（Tiptap）往返一遍很可能弄乱结构。所以配置里独立页面的正文用 type: text——一个纯文本框，所见即所得地编辑原始 Markdown，保存时一个字节都不会动。

6.5 复杂 Markdown 建议切到 source 模式#

文章正文的富文本编辑器右上角可以切换 editor / source 两种模式。日常写段落、插图用 editor 方便；写 callout（> [!NOTE]）、复杂表格、大量代码块时切到 source 模式，保存的是原始 Markdown，最稳。

6.6 「via Pages CMS」的提交会规范化文件格式#

用 CMS 保存过的文件会被重新序列化：front matter 的行内数组会变成块列表、表格对齐会被重排、多余的空行会被整理。这些都是合法的等价改写，git diff 大不代表内容变了。但如果两个配置的字段列表不一致，就会有第三节的「字段被删」问题——这就是为什么字段要配全。

7.1 写一篇新文章#

1. 侧边栏 → 文章 → 右上角新建；
2. 弹出文件名输入框，填一个 2026-09-12-my-post 风格的名字；
3. 填标题（必填）、发布日期默认今天，标签是一行一个；
4. 正文用富文本编辑器写，需要图片就点工具栏的插图按钮直接上传，图会传到 public/images 并插入 /images/xxx.png；
5. 保存。此时 GitHub 上多一个 commit，部署平台开始构建，一两分钟后线上可见。

7.2 草稿流程#

没写完的文章把「草稿」勾上（draft: true），主题不会把它渲染进列表和详情页，可以放心保存占位。写完取消勾选再保存即发布。

7.3 改独立页面#

关于页、友链、留言板都在「独立页面」里，正文是原始 Markdown 源码模式，改完直接保存。新增独立页面需要先在主题里加路由，光建 md 文件没用，所以配置里禁掉了新建。

播放器本身#

• 多 Meting 源并发竞速拉歌单，谁先返回用谁，单源故障无感
• 每首歌自动在多个源之间探测可用播放链接，断链/过期自愈，全败自动跳下一首
• 歌单本地缓存 6 小时，进面板秒开；预载但不自动出声，点了播放才响
• 歌词同步滚动居中，点歌词行跳转进度

为什么要接洛雪音源#

公共 Meting 接口有个绕不过去的边界：VIP / 版权受限曲目拿不到完整直链——它给的是一段能正常播的 30 秒试听片段，不报错、很难察觉。于是把本地的洛雪音源解析搬到 serverless 上，让「点播放」这件事有一个更可靠的后端。

请求链路#

1
浏览器                       Vercel 边缘
2
   │
3
   │ ① 拉歌单（多源并发竞速）
4
   ├──────────────────────────────► 公共 Meting × N
5
   │ ◄── 谁先返回用谁
6
   │
7
   │ ② 取直链（同源，无 CORS）
8
   ├──────────────────────────────► /api/url
9
   │                                  │
10
   │                                  ├─ 命中 CDN 缓存？直接返回（不进函数）
11
   │                                  │
12
   │                                  └─ 未命中 → 函数内并发多音源解析
13
   │                                                  │
14
   │                                                  ├─ 按成绩分波对冲
15
   │                                                  ├─ 赢家一出即掐断其余
16
   │                                                  ├─ 直链探活
17
   │                                                  └─ 连续失败熔断
18
   │ ◄── 完整直链 ────────────────────────────────────┘
19
   │
20
   │ ③ 解析不到 → 自动降级回 Meting（开着也不影响原本能用的）
21
   ▼
22
<audio> 播放

落到代码里，几个关键设计：

• 自定义音源脚本跑在 Vercel 函数里（api/ + lib/，跟主页一起部署），多音源按成绩分波对冲、赢家一出即掐断其余、直链探活、连续失败熔断
• 前端调同源的 /api/url：不需要额外域名、证书、CORS 配置，也不用再养一台服务器
• 直链缓存在 CDN 边缘（15 分钟），命中缓存的请求根本不进函数，不消耗调用次数
• 解析不到时自动降级回 Meting，开着也不影响原来能用的情况

config.js 里两个开关：

1
musicSource: "proxy",    // "meting" = 只走公共 Meting；"proxy" = 走自带的 serverless 解析
2
musicQuality: "320k",    // 128k / 320k / flac / flac24bit

音源脚本放 sources/ 一起部署；也可以配 SOURCE_URLS 环境变量指向在线脚本——改完远端脚本请求一次 /api/health?refresh=1，函数立刻重装全部音源，连重新部署都不用。部署后打开 /api/health 能看到装上了哪些音源、各自的平台与失败原因。

提醒：函数默认跑在香港（hkg1，离国内接口最近），实测与国内出口的成功率一致；但这类「直链解析」本身在灰区，建议自用、别公开分发。

平台托管（推荐）#

Vercel / Netlify / Cloudflare Pages 均可，Framework 选 Vite，根目录 ./、输出目录 dist、构建命令 npm run build，零环境变量（免 Key 接口的好处）。

本地开发#

1
git clone https://github.com/you-github-name/homepage.git
2
cd homepage
3
npm install
4
npm run dev     # http://localhost:5173，配置热更新

配套介绍页#

仓库之外还有一个独立的介绍页站点，把「这东西是干什么的、能干什么、怎么装」在一页里讲完，比翻 README 快得多：

介绍页： storage.zlion.top

页面结构大致是：

1
介绍页 (fileserver.zlion.top)
2
├─ 首屏       一句话定位 + 一键部署命令 + Release 下载入口
3
├─ 功能总览   分片上传 / 分享链接 / WebDAV / 相册视图 …逐项配截图
4
├─ 部署方式   直接运行 / 一键脚本 / Docker 三条路径并列对比
5
├─ 安全设计   PBKDF2、AES-GCM、路径越权防护等实现说明
6
└─ 常见问题   反代 127.0.0.1、413、别名冲突 …就地给排查方向

定位上它是「软件的门面」，承担三件事：讲清楚是什么（省得用户读完 README 还在猜）、给出最快的上手路径（首屏就放 curl 一键部署）、沉淀文档（安全设计、故障排查这些正文不适合塞进 README 的内容）。介绍页与本文内容同源，改动软件时两边一起更新。

4.1 相册视图#

管理图片目录时点「相册」，列表切换为缩略图网格——服务端依旧只返回原图字节，由浏览器懒加载，不增加服务器负担。翻图点开即看，不用先下载到本地。

4.2 分享别名#

创建分享时可自定义链接尾段，把默认的随机 token 换成可读的短词：

1
默认：  https://files.example.com/s/a7f3c9e21b8d4f06
2
别名：  https://files.example.com/s/发布会-materials

发到网站 / 公众号里体面得多。别名全局唯一，原 token 链接保持兼容；别名段同样计入有效期与下载次数限制，不额外开权限口子。

4.3 防盗链#

对公开外发的链接可单独按分享开启 Referer 校验：其他网站的页面引用直接返回 403，而直接在浏览器打开链接、用 IDM / aria2 这类下载工具拉取都不受影响——防的是被别站白嫖流量，不是防真实访客。

5.1 直接运行#

从 Releases 下载对应架构的二进制，赋予执行权限后运行：

1
chmod +x fileserver
2

3
./fileserver --port 16666 --dir /data/files --user admin --pass 你的密码

打开 http://服务器IP:16666 即可使用。不设 --user/--pass 时无认证，仅建议纯内网使用。

5.2 常用启动参数#

同名环境变量（PORT、ROOT_DIR、AUTH_PASS 等）同样生效，命令行优先。

6.1 一键部署到 Linux（推荐）#

部署脚本自动识别 CPU 架构、从 Release 下载二进制、放行防火墙、注册 systemd 开机自启：

1
curl -fsSL https://raw.githubusercontent.com/Zlion-Y/fileserver/main/install-remote.sh -o install-remote.sh
2

3
sudo bash install-remote.sh --dry-run
4

5
sudo FS_USER=admin FS_PASS=你的密码 bash install-remote.sh

装好后的常用运维操作：

配置文件在 /etc/fileserver.env，改完 systemctl restart fileserver 生效。

6.2 Docker 部署#

1
cp .env.example .env
2

3
docker compose up -d

docker-compose.yml 默认只监听 127.0.0.1:16666，由 Nginx / Caddy 反代后对外。数据落在 ./files 与 ./data，容器重建不丢。

2.1 硬件规格#

2.2 CPU 能力（最重要的事实）#

由 cat /proc/cpuinfo 实测，CPU features 为：

1
half thumb fastmult edsp thumbee tls

对照 ARMv7 完整特性集，结论如下：

2.3 串口 IP 逆向#

E2631 的调试串口是 ZTE 定制的 PL011 兼容 IP，基地址 0x94404000，earlycon=zteuart 可输出引导日志，periphid 为 0x001feffe。它与标准 PL011 的寄存器偏移不同（与 ZX279133 是同一 IP）：

2.4 与 SR1010 的外设差异#

本项目基于 cnjn 的 SR1010 主线移植（linux-mainline-zte-zxslc-sr1010），但 E2631 的外围方案与 SR1010 不同，SoC 周边芯片不能直接照搬：

所以设备树、网卡/PHY 驱动、闪存驱动都需要针对 E2631 单独适配，这也是”待办与未来工作”一章里列出的主要缺口。

3.1 加密与密钥#

原厂固件的 kernel 分区使用 AES-128-ECB 加密，密钥常量为 E263111559d0dfde。解密后即得到标准 uImage（ih_load 为 0x40008000，这也是后面 XIP 陷阱的根源）。

3.2 分区布局#

128MB SPI NAND 上的功能分区（具体偏移以固件 dump 为准）：

3.3 kmodule 解包与 vendor 运行库#

把 kmodule 分区按 JFFS2 解包后，拿到两样关键资产：

• busybox v1.17.2（原厂用户态，后续 initramfs 直接复用）；
• uClibc 0.9.33.2 运行库（libc.so.0 / libm.so.0 / libresolv.so.0 等）。

4.1 进入 U-Boot#

上电后立即连续按 1 进入引导菜单，输入密码 5cE080@fyBD，回车后停在 U-Boot 命令行（自动启动已被停止）。原厂 U-Boot 支持 tftp / bootm / md / mw 等常用命令，可以直接用来引导主线内核。

1
# 电脑端准备一个 TFTP 服务器（仓库里的 e2631-tools/tftpd2.py 即可）
2

3
# 串口里配置网络并下载内核
4
setenv serverip 192.168.1.100
5

6
setenv ipaddr 192.168.1.1
7

8
tftp 0x43000000 uImage-e2631.img
9

10
bootm 0x43000000

4.2 XIP 陷阱（本项目最大的坑）#

4.3 完整引导链路#

5.1 环境组成#

项目在纯 Windows 上完成了整个内核构建，环境如下：

5.2 Windows 构建的强制限制#

构建命令（对应 build.sh / build.bat 的核心）：

1
make ARCH=arm CROSS_COMPILE=arm-none-eabi- zx279128s_e2631_defconfig
2

3
make ARCH=arm CROSS_COMPILE=arm-none-eabi- -j4

5.3 踩过的编译坑（均已修复并固化在仓库）#

6.1 关键特性（全部 =y 并已上板验证）#

6.2 netfilter 配置丢失的修复#

内核默认配置做”平台精简”时会把 netfilter 相关选项丢掉，需要在 olddefconfig 之后显式重新打开：

1
make ARCH=arm CROSS_COMPILE=arm-none-eabi- olddefconfig
2

3
scripts/config -e NETFILTER -e XTABLES_LEGACY -e IP_NF_IPTABLES_LEGACY
4

5
make ARCH=arm CROSS_COMPILE=arm-none-eabi- olddefconfig

6.3 嵌入式 initramfs#

initramfs 内容（由 e2631-tools/initramfs-src/ 构建）：

• init：musl 静态编译，O_RDWR 打开 console、TIOCSCTTY 接管终端、spawn busybox sh；
• busybox v1.17.2（vendor 版，经 uClibc 库支撑）；
• uClibc 0.9.33.2 运行库（经 .symlink 修复后的真实 ELF）；
• 设备节点：console / null / tty / ttyAMA0(204<64>) / zero / random（pack2.py 递归 cpio 打包）。

7.1 启动结果#

主线内核 6.18.38 从 U-Boot 引导成功，earlycon=zteuart 输出完整启动日志，最终进入交互式 busybox shell。板上实测日志：

1
=== E2631 mainline bring-up init reached userspace ===
2
[init] kernel booted, zteuart console OK
3
[init] Features : half thumb fastmult edsp thumbee tls
4
[init] handing console to busybox shell
5
/ # iptables -t mangle -L PREROUTING    # 正常
6
/ # ip rule add fwmark 1 lookup 100     # 正常
7
/ # busybox cat /proc/net/ip_tables_targets
8
...
9
TPROXY
10
TPROXY
11
MASQUERADE
12
REDIRECT
13
...

7.2 特性验证命令#

1
# 验证 TPROXY / REDIRECT / MASQUERADE / MARK 等目标已编进内核
2
cat /proc/net/ip_tables_targets
3

4
# 确认 CPU 特性（无 VFP / NEON / idiv）
5
cat /proc/cpuinfo
6

7
# 确认内存识别
8
cat /proc/meminfo

/proc/net/ip_tables_targets 中能看到 TPROXY 等目标，说明透明代理内核路径完整可用；策略路由（ip rule fwmark）也已在板上实测通过。

8.1 二进制选择#

由于 CPU 无 VFP / NEON / idiv，mihomo 必须使用 armv5 软浮点 二进制：

1
mihomo-linux-armv5      # GOARM=5，软浮点

8.2 内核侧已就绪#

mihomo 需要的内核能力已全部 =y 编入（见第六章）：TUN、TPROXY（v4/v6）、xt_socket、nftables（nft_tproxy/socket/compat）、iptables-legacy、conntrack、NAT、策略路由、IPv6、zram。无需任何外部内核模块。

8.3 部署与预期#

部署方式：通过 tftp / 串口把 armv5 二进制与配置文件拷入，挂到 TUN 或 TPROXY 模式即可。注意这台机器没有 USB，所以文件传输只能走网络或串口。

9.1 仓库结构#

仓库 Zlion-Y/e2631-mainline-zx279128s 本身就是完整的内核源码树（Linux 6.18.38 + E2631 平台适配全部落树），不再需要单独拉基础树再套补丁。默认分支 main：

1
e2631-mainline-zx279128s/                       # 完整内核源码树（GitHub）
2
├── arch/arm/boot/dts/zte/zx279128s-e2631.dts       # E2631 板级设备树
3
├── arch/arm/configs/zx279128s_e2631_defconfig      # 精简 defconfig（initramfs 已内嵌）
4
├── initramfs-e2631.cpio.gz                         # 嵌入式 initramfs（busybox + uClibc + init）
5
├── e2631-tools/
6
│   ├── tftpd2.py          # 简易 TFTP 服务器（UDP 69，服务父目录）
7
│   ├── pack_uimage.py     # uImage 打包（load/entry 0x40008000）
8
│   ├── serial_ctl.py      # 串口驱动（驱动 U-Boot 用）
9
│   ├── bootflow2.py       # 脚本化 tftp + bootm 串口序列
10
│   ├── mkconfig.sh        # MSYS2 构建步骤
11
│   ├── cleanbuild3.sh     # MSYS2 清理重建
12
│   ├── mihomobuild.sh     # mihomo 相关构建
13
│   ├── initramfs-src/     # init.c + pack2.py
14
│   └── README.md
15
├── upstream-series/                             # cnjn 的 ZX279133 16 补丁集（6.18.38 基线，参考）
16
├── research.md                                 # 内核版本调研笔记
17
├── README.md / README_EN.md / README           # 中英文说明 + 内核自带 README
18
├── build.sh                                    # Linux / WSL 一键编译
19
├── build.bat                                   # Windows / MSYS2 一键编译
20
└── .github/workflows/build.yml                 # CI：main + v* tag + 手动触发

编译产物由 CI 直接发布到 GitHub Release：v0.1.1 已包含 uImage-e2631.img（约 13.3MB，zImage + DTB 拼接，DTB 在末尾），可直接下载后 tftp 引导。

9.2 复现步骤#

Linux / WSL（树内直接构建，无需套补丁）：

1
git clone https://github.com/Zlion-Y/e2631-mainline-zx279128s.git
2

3
cd e2631-mainline-zx279128s
4

5
./build.sh

Windows（MSYS2，首次运行自动装 MSYS2 与交叉工具链，再树内构建）：

1
git clone https://github.com/Zlion-Y/e2631-mainline-zx279128s.git
2

3
cd e2631-mainline-zx279128s
4

5
build.bat

GitHub Actions：fork 后 push（或手动 workflow_dispatch）即可，产物在 Actions 页面 / Release 下载。

编译产物 uImage-e2631.img 按第四章的姿势引导：

1
tftp 0x43000000 uImage-e2631.img
2

3
bootm 0x43000000

9.3 CI 与 Release#

build.yml 触发条件：main 分支 push、v* tag push、手动 workflow_dispatch；并显式声明 permissions: contents: write 以便创建/更新 Release。流程为：装依赖 → 装 Arm GNU Toolchain 10.3（arm-none-linux-gnueabihf-）→ zx279128s_e2631_defconfig → zImage → 单目标 zte/zx279128s-e2631.dtb → e2631-tools/pack_uimage.py 打包 → 上传 artifact → 在 tag 上挂到 Release。

当前状态：v0.1.1 已发布（2026-08-31），Release 附件 uImage-e2631.img 为 Actions 验证产物（zImage + DTB），可直接下载引导。

9.4 参考项目#

2.1 缩小范围：排除 TCL 安全守护#

先怀疑的是 TCL 安全守护 com.tcl.guard，但实测它的启停与拦截无关；只有禁用 com.android.packageinstaller 才能放行安装，说明拦截逻辑在安装器应用自身。

2.2 复现拦截并抓取日志#

保持安装器启用状态，安装一个真实 APK 并抓取系统日志：

1
adb logcat -c
2

3
adb install -r xxx.apk
4

5
adb logcat -d > block.log

日志中出现关键线索：

1
Start proc com.android.packageinstaller for broadcast
2
  {com.android.packageinstaller/com.android.packageinstaller.verifier.VerifierReciver}
3
Foreground service started ...: service com.android.packageinstaller/.verifier.StrategyService
4
Config:Grabber:InstallConfig: Currrent content from Db is ：[{"enable":"true","strategies":[...]}]
5
D ConfigProvider: feature:content://com.tcl.providers.config/InstallConfig

拦截者浮出水面：TCL 在系统安装器里内置了一个验证组件，其策略来自一个内容提供者。

2.3 拉取安装器 APK 分析#

1
adb shell pm path com.android.packageinstaller
2

3
MSYS_NO_PATHCONV=1 adb pull /system/priv-app/PackageInstaller/PackageInstaller.apk .
4

5
unzip -o -q PackageInstaller.apk -d apk

提取 dex 字符串确认：

• com.android.packageinstaller.verifier.VerifierReciver 监听 android.intent.action.PACKAGE_NEEDS_VERIFICATION，持有 android.permission.PACKAGE_VERIFICATION_AGENT 权限（全系统仅它持有）；
• StrategyService 每次安装时从 content://com.tcl.providers.config/InstallConfig 读取策略 JSON。

查询该配置：

1
adb shell content query --uri content://com.tcl.providers.config/InstallConfig

1
Row: 0 project_id=InstallConfig, config_content=[{"enable":"true","strategies":[
2
  {"name":"safeStrategy","enable":"true","priority":"0"},
3
  {"name":"blackListStrategy","enable":"true","packages":[],"priority":"1"},
4
  {"name":"thridStrategy","enable":"false","packages":[...],"priority":"2"},
5
  {"name":"launcherStrategy","enable":"true","packages":[],"priority":"3"},
6
  {"name":"overDueStrategy","enable":"true","packages":[],"priority":"4"},
7
  {"name":"pmStrategy","enable":"true","priority":"5"}]}]

1. 开启Telnet#

从路由器网页管理后台导出配置文件config.bin，与一键开启Telnet脚本放在一起，双击脚本运行得到config-telnet-enable.bin，将其再从管理后台还原回去，路由器会自动重启，Telnet就打开了，默认的账密为admin。

2. 扩容分区#

使用MobaXterm新建Telnet会话连接路由器，执行下面的命令，扩容 /var 目录。

1
mount -o remount,size=32M /var

3. 修改设备型号#

将设备型号Z500/Z503/Z507通通改为中兴的公版型号Z506。

设置MobaXterm的TFTP服务

命令中的 192.168.5.7请替换为电脑当前的局域网 IP。

1
cat /dev/mtdblock2 > /tmp/tag.bin
2
tftp -p -l /tmp/tag.bin -r tag.bin 192.168.5.7

1
tftp -g -l /tmp/tag.bin -r tag-E2631.bin 192.168.5.7
2
cat /tmp/tag.bin > /dev/mtdblock2

4. 上传公版固件#

进入路由器管理后台，找到系统更新固件上传zxhnze50x_hv100_fv1002b28000_firmware-20230615093954.bin ,确认升级即可。重启完毕后就成功刷为公版系统了。

5. 重置#

升级完成后可以恢复出厂设置一次。

2.1 产品功能范围#

六大核心功能一个都不能少：

1. 基础遥控（方向、确认、返回、主页、菜单、音量、电源）
2. App 安装推送
3. 远程输入法（IME）
4. 电视清理 / 加速
5. 远程应用管理（启动 / 卸载）
6. 基于传感器的 TV 端浮动光标

2.2 技术约束#

• 手机与电视在同一局域网，走 HTTP（TCP）+ UDP 自研协议
• TV 端覆盖层窗口必须由 AccessibilityService 上下文创建
• 传感器数据驱动光标，位移采用 0..1000 归一化坐标，TV 端按分辨率缩放

2.3 设计目标#

一句话：让用户拿起手机的三秒内，就能完成一次电视操作。

5.1 按键布局的取舍#

实体遥控器按 键隔离 布局，手机屏幕按 使用频率 布局：

• 方向与确认是最高频操作，占据视觉中心
• 音量键做成横向长条，天然对应「左右/上下滑动调音量」的心智模型
• 电源键放在角落，防止误触——误触电源把电视关了，是这类 App 差评的重灾区

5.2 按键到协议的映射#

每个按键最终都会转成一条 HTTP 指令发往 TV 端：

1
{
2
  "type": "key",
3
  "action": "down_up",
4
  "keycode": 82
5
}

常用键值映射：

6.1 第一版：绝对坐标（失败）#

最初的设计是把手指位置直接映射到 TV 屏幕坐标：手指按在触控板左上角，TV 端光标就出现在屏幕左上角。

真机测试发现致命问题：触控板面积只有巴掌大，映射到 55 寸电视上，精度完全不够——想点一个设置按钮，手指 1mm 的抖动在电视上就是几十像素的偏移，根本点不中。

6.2 第二版：相对位移 + 虚拟鼠标（成功）#

改为笔记本电脑触控板的心智模型：TV 端自己维护一个光标位置，手机只上报位移量。

协议设计：

1
{
2
  "dx": 120,
3
  "dy": -45,
4
  "show": true
5
}

• dx / dy：0..1000 归一化相对位移，TV 端按屏幕分辨率缩放为像素
• show：true 显示光标，false 隐藏，缺省保持当前状态

抬手后光标保持原位这一点尤为关键——用户可以分多次滑动，把光标「挪」到目标上再点按确认，这正是触控板体验的精髓。

7.1 传感器选型#

手机竖直持握时，加速度计三个轴的物理含义：

光标速度映射：

其中 ax0a_{x0}ax0​、az0a_{z0}az0​ 是校准基准（开始控制时记录），kkk 是灵敏度系数。

7.2 防抖设计#

手持必然有抖动，两个参数直接决定手感：

• 死区：倾斜量小于 0.6 m/s² 时视为静止，过滤手部微抖
• 灵敏度系数：倾斜 1 m/s² 对应光标移动速度，当前取值 4 倍基准灵敏度

完整控制流程：

7.3 TV 端光标渲染#

TV 端用 TYPE_ACCESSIBILITY_OVERLAY 窗口绘制光标：白色圆形主体 + 深色描边 + 中心蓝点 + 柔和光晕，直径 40px，在深浅背景上都能看清。

3.1 临时停用 com.tcl.guard#

1
adb -s 192.168.5.2:5555 shell pm disable-user --user 0 com.tcl.guard

结果：com.tcl.guard 可以进入 disabled-user 状态，但 Google 三件套仍不能正常运行。之后已恢复：

1
adb -s 192.168.5.2:5555 shell pm enable --user 0 com.tcl.guard

3.2 安装 Google 三件套#

针对设备的 Android 11、32 位 armeabi-v7a 和 Android TV 环境，尝试安装：

1
com.google.android.gsf
2

3
com.google.android.gms 26.24.34
4

5
com.android.vending 52.0.20

结果：三个 APK 均可被系统识别，但 Play Store 无法正常进入，Google 相关进程也不能稳定运行。

3.3 修改 freeze 配置（2026-08-29 已打通）#

最初普通 ADB shell 下的 JSON 写入没有成功，原始配置保持不变。

1
J=$(cat /data/local/tmp/freeze.json)
2

3
E=$(echo "$J" | sed 's/:/\\\\:/g')
4

5
content update --uri content://com.tcl.providers.config/freeze --bind "config_content:s:$E" --where "project_id='freeze'"

用同样的方法可以查询和回写配置（原始配置已备份）。同一技巧也解决了另一台 TCL 电视的 ADB 安装拦截问题，见《TCL/雷鸟电视 ADB 安装拦截排查与永久放行》。

3.4 查询或调用 TCL 特殊接口#

尝试使用 cmd feature 等接口进一步查询或修改 TCL 配置。

结果：相关功能需要更高权限或 debug 模式，普通 ADB shell 无法完成写入。

3.5 修改系统组件或刷写固件#

未执行以下高风险操作：

• 修改 com.tcl.tcore.apex。
• 修改 FreezeManager 或 freezeProcessList。
• 修改 boot、system、vendor、product、system_ext 分区。
• 刷入其他版本 TCL 固件。

原因：这些操作涉及系统签名、分区校验和变砖风险，且没有证据表明仅修改其中一处就能恢复 Google 三件套运行。

4.1 实验环境#

在另一台同固件的 TCL 电视（tcl_mt5879_cn，192.168.5.6:5555）上完成：

1. 使用 MindTheGapps 11.0.0-arm-ATV（匹配 Android 11 + armeabi-v7a + Android TV）。
2. 通过 ADB 安装 GoogleServicesFramework.apk 与 PrebuiltGmsCorePano.apk（即 com.google.android.gms），均安装成功。

4.2 触发方式#

国内固件开机后没有任何东西会拉起 GMS：没有 Play Store 和 setup wizard 作为触发源，且 ADB 安装的包处于 stopped 状态，收不到开机广播。需要主动拉起 GMS 的可用 Activity（如 com.google.android.gms/.ads.settings.AdsSettingsActivity）。

4.3 现象：崩溃-重启死循环#

进程以前台（TOP）状态被反复拉起、随即死亡，约 300ms 一次：

注意这不是冻结——冻结只会暂停进程，不会杀进程；这里的进程死因是自身初始化抛异常。

4.4 根因：signature|privileged 权限缺失#

从 dumpsys dropbox --print data_app_crash 拿到完整堆栈，两个包各死于一个系统权限：

GSF 的崩溃堆栈（GoogleSettingsProvider 初始化）：

1
java.lang.RuntimeException: Unable to get provider
2
    com.google.android.gsf.settings.GoogleSettingsProvider:
3
    java.lang.SecurityException: You need MANAGE_USERS permission to: get the profile parent
4
        at com.google.android.gsf.settings.GoogleSettingsProvider.onCreate(GoogleSettingsProvider.java:158)
5
        at UserManager.getProfileParent(UserManager.java:3564)

GMS 的崩溃堆栈（Application 初始化）：

1
java.lang.RuntimeException: Unable to create application co.g.App:
2
    java.lang.SecurityException:
3
    addOnPermissionsChangeListener: Neither user 10094 nor current process
4
    has android.permission.OBSERVE_GRANT_REVOKE_PERMISSIONS

MANAGE_USERS 与 OBSERVE_GRANT_REVOKE_PERMISSIONS 都是 signature|privileged 级权限，只能授予 /system/priv-app 内、且在 privileged-permissions 白名单中的应用。ADB 安装的 APK 位于 /data，永远拿不到这两个权限，于是 provider / Application 初始化必然抛 SecurityException，系统反复拉起 → 无限闪退。

4.5 A/B 验证：与冻结无关#

控制变量实验——同一台电视、同一组 APK、只切换 freeze 配置：

结论：三件套的闪退与冻结机制无关，是确定性的权限缺失，ADB 层面无解。

1.1 Config.bin的加解密#

config.bin 不是明文 XML，而是 ZTE 的 Type-4 外层容器。E2631 中使用的是 AES-256-CBC。 中兴巡天及其套娃机的值有多组，这里仅展示一组：

解包流程如下：