100 块的 CPDAY3,被我从 Android 16 一路刷回了 12.1

wl 发布于 14 天前 36 次阅读 折腾记录


AI 摘要

100块的CPDAY3,本来只是上课交手机用的,结果我把它刷遍了Android 16、14、12.1、11,还拆了MTK Sensor HAL。网上传的CPU没一个对,真身是MT6768。最后停在12.1,值了。

前年上大学的时候,老师上课要求统一交手机。我不想把自己的主力机交上去,就去闲鱼找了一台便宜的二手机,最后 100 块钱包邮买了这台 CPDAY3。

它在学校那段时间几乎没被我正常用过。上课前交出去,下课拿回来,没电就充一会儿,下一节课继续交。配置、系统、拍照这些我都没认真看过,能开机就够了。

后来不用再交手机了,它也就一直放着。

最近重新翻出来,真正拿起来用,我才发现原厂系统里的广告和推广多得有点受不了。以前开机就往讲台上一放,当然感觉不到这些东西。现在自己点设置、开应用,各种东西全冒出来了。

反正当年才花了 100 块钱,里面也没有什么需要保留的数据,我就想把原厂系统整个换掉。

网上搜了一圈,连它是什么 CPU 都没说对

一开始我还是正常上网搜。

CPDAY3 刷机、Root、ROM、救砖、第三方系统,能想到的关键词基本都试过。结果几乎没有完整教程,也没有那种别人已经整理好的工具包。

中间倒是找到过一个收费的相关资源,但里面到底有什么、对我这台机器有没有用,我也不知道,最后没买。

再往下搜也没多少东西,我就转去问 GPT,准备根据真机一点点查。

真机信息和网上写的完全不是一回事。

有些页面把 CPDAY3 的处理器写成紫光展锐 T616,手机自己的某些系统信息里又能看到 Android 13。单看这些东西,很容易把它理解成一台 Android 13 时代的展锐机器。

接上 ADB 后,读出来的是:

ro.board.platform=mt6768
ro.hardware=mt6768
ro.boot.hardware=mt6768
ro.product.board=k69v1_64

后面 MTKClient 真正进了 BROM,识别为 MT6768/MT6769 这一平台家族。再结合 ADB 读到的 mt6768,至少我手里这台实际用的是 MT6768,和网上写的 T616 没什么关系。

系统底子也比表面看到的 Android 13 老得多:

ro.vndk.version=30
ro.product.first_api_level=30

Kernel 是:

4.14.186

真正开始刷 GSI 前,我已经知道这台机器大概是什么情况了:MT6768,Android 11 / API 30 时代的 Vendor,再配一个 4.14 Kernel。

CPDAY3 又几乎找不到靠谱的原厂包,我也不敢拿 GSI 直接往里面灌。先把 MTKClient 折腾通,进 BROM,把重要分区尽量读出来:

super_stock.bin

boot_a.bin
boot_b.bin

nvram.bin
nvdata.bin
nvcfg.bin

seccfg.bin

vbmeta_a.bin
vbmeta_b.bin

super_stock.bin 是完整的 8 GiB Super 分区,后面分析 System 和 Vendor,用的也一直是自己这份备份。

备份留好以后,我又通过 MTKClient 处理了 seccfg,把 Bootloader 解锁。后面一直保持 unlocked,也没有再重新上锁。

到这里才开始真正刷系统。

Android 16:能开机,仅此而已

第一版我直接选了 Android 16,LineageOS 23.2 GSI。

它真能启动。

但拿起来操作,很快就能感觉出这版本不适合这台手机。设置里滑动、页面切换、应用打开都有明显卡顿,整个系统一直有种拖着跑的感觉。

蓝牙也出了问题。

当时蓝牙服务不能正常稳定工作,后面在 PHH Treble Settings 里试了几项 MTK 兼容设置:

Use System Wide BT HAL
Bluetooth workarounds = Mediatek
Disable LE APCF Extended features

调完以后,蓝牙 HAL 才能正常初始化。

底下毕竟还是 Android 11 时代的 Vendor 和 4.14.186 Kernel。Android 16 能开机已经挺意外,真拿来长期用就没必要硬撑了。

于是换 Android 14。

14 比 16 好一点,但也只是好一点。卡顿还在,兼容问题也没有明显少到让我愿意留下来。

我没继续在 Android 14 上浪费时间,直接换成了 Android 12.1。

这次差别很明显。

滑设置、切页面、开应用都顺了很多。它当然还是一台很便宜的老机器,但至少不会让我每操作一下都感觉系统在跟不上。

到这时候,我基本已经准备留在 LineageOS 19.1 了。

结果后面检查传感器,发现距离、光线和磁力相关的东西都没了。

SensorService 里没有 Proximity,没有 Light,标准 Magnetic 也没出现。DisplayManager 里距离传感器直接是空的。

这个问题最后让我又刷了一次 Android 11。

Android 11 只是拿来查传感器

原厂 Vendor 本来就是 API 30,所以刷 Android 11 正好可以做一次对照。

如果刷进 Android 11 GSI 后,传感器能回来,就继续查 Android 12.1 和 Vendor 之间的兼容;如果还是没有,继续换 ROM 也没什么用了。

结果系统还没刷进去,先出了两次乌龙。

Android 11 镜像下载下来是 .xz。第一次用 Python 解压时,引号写出了问题,IMG 根本没有正确生成。当时那套命令又是分段跑的,前面已经失败,后面的 fastboot -w 还继续执行。

系统没刷进去,userdata 和 metadata 先被擦了。

这也是整次折腾里最尴尬的一次失误。

后面再跑这种带 wipe 的操作,我就不敢把命令拆着执行了。关键步骤会检查退出状态,前面任何一步没成功,后面的刷写和 wipe 都不再继续。

第二次是镜像已经正确解出来了,我又按照 raw EXT4 的方式去检查,看到结果不对,一度以为镜像坏了。

后来直接看文件头:

3A FF 26 ED

才发现这是标准 Android Sparse Image。

fastboot 本来就能直接刷。

最终 Android 11 正常进了 system_b,开机确认 SDK 30,再去看那几个传感器。

还是没有。

ROM 版本这条线到这里就停了,接下来开始往 Vendor 里面找。

Android 11 这版 GSI 可以开 Rooted debugging,adb root 以后就能直接看底层,当时也就没急着装 Magisk。

MTK 的 Sensor HAL 服务一直在:

android.hardware.sensors@2.0-service-mediatek

对应的库也在:

/vendor/lib64/hw/sensors.mt6768.so

/dev 下面还能看到一堆相关节点:

/dev/als_ps
/dev/m_ps_misc
/dev/m_als_misc
/dev/m_mag_misc
/dev/msensor
/dev/sensorlist

接下来的重复命令、日志整理和二进制分析,我基本都交给 Codex 跑,自己主要盯结果。

最后真正有用的是 /dev/sensorlist

把 HAL 拆开以后发现,它启动时会从这里读取 112 Bytes。实际内容只有:

mxc4005x
NULL
NULL
NULL
NULL
NULL
NULL

mxc4005x 是加速度计,剩下几个槽全是 NULL。

HAL 里刚好又有对应的删除逻辑。某个槽是 NULL,就把对应的 Sensor 从列表里删掉。

我先试着伪造了一份 /dev/sensorlist,把 Proximity 的位置填成 Vendor 里能找到的 cm36558_p。但 /dev/sensorlist 是字符设备,用普通文件去 bind,最后直接报 I/O error。

改输入没走通,就直接改 sensors.mt6768.so

改动很小,只让 Proximity 在对应槽位是 NULL 的情况下先别被删掉。补丁也没有直接写进 Vendor,放在 /data/local/tmp,通过 mount namespace 临时挂到原 HAL 路径。

Sensor HAL 重新起来以后,SensorService 从:

Total 14 h/w sensors

变成了:

Total 15 h/w sensors

多出来的正是:

PROXIMITY
MTK
android.sensor.proximity(8)

这一步看起来挺漂亮。

然后拿手遮住手机顶部。

数值没动。

移开,还是没动。

名字确实塞回去了,Near/Far 数据根本没有。

手机一重启,临时挂载消失,原版 HAL 回来,SensorService 也恢复成 14 个。这个实验到这里就结束了。

最后刷回 12.1

重新刷回 LineageOS 19.1 后,我就没再动 ROM。

这样绕了一圈,顺序其实是 Android 16、14、12.1、11,最后又回到 12.1。

Android 11 上那个 Proximity 补丁也没有带回来。实际 Near/Far 没数据,把它永久挂在那里也没什么用。

等系统版本彻底确定以后,最后才装 Magisk。

用的是最开始通过 MTKClient 从这台手机里读出来的原始 boot_b.bin,用 Magisk 30.7 修补后,再刷回 boot_b

开机正常,没有 Bootloop,Magisk 的 su 能用,SELinux 还是 Enforcing。

现在这台 CPDAY3 跑的是 Android 12.1。

后摄能正常预览和拍照,ADB 正常,系统能识别出 60Hz 和 90Hz 两种屏幕模式,普通充电也没问题。距离、光线和磁力相关的功能还是缺着,我没有再继续修。

100 块买回来专门拿去交手机的机器,最后被我刷遍了 Android 16、14、12.1 和 11,还顺手拆了一次 MTK Sensor HAL。

现在系统干净,日常用着也顺。传感器的问题就留在那里吧,折腾到这里已经够本了。

最后更新于 2026-08-21