MTK电视平台刷机实录：破解Android 14 GSI中的Vendor签名死锁

在折腾客制化ROM的道路上，Project Treble一度被视为降低刷机门槛的福音，尤其是对于像小米电视S Pro MiniLED 2024这类基于MTK TV平台的设备。虽然这类设备底层往往运行着澎湃OS 3.0或Android 14，但其特殊的软硬件架构——即64位内核搭配32位用户空间，常常让标准的GSI（Generic System Image）方案水土不服。当我们试图通过DSU或gsi_tool刷入arm32_binder64架构的Android 14 GSI时，设备往往会卡在开机动画，看似是普通的兼容性问题，但深入分析后会发现，这实际上是一场关于系统签名与权限的博弈。

小米电视 S Pro MiniLED 2024，运行澎湃OS 3.0 / Android 14，基于 MTK TV 平台。

当我们使用类似aosp-arm32_binder64-ab-gapps-14.0的镜像进行启动测试时，设备并非完全死机。通过TTL串口或adb shell，我们能够进入console层级，说明内核、init进程以及底层的Vendor分区基本加载正常。然而，系统服务却始终无法就绪，sys.boot_completed一直为空，pm list packages也报错找不到Package服务。通过抓取logcat日志，问题的核心浮出水面：java.lang.IllegalStateException: Signature mismatch on system package com.xiaomi.setupwizard for shared user android.uid.system。

通过TTL串口抓取的启动日志，可以看到内核加载正常但系统服务无法就绪的错误信息。

这个报错揭示了一个在Android 14中极为严格的限制。设备原厂的Vendor分区中预置了位于/vendor/priv-app/MiTVSetupWizard/下的MiTVSetupWizard.apk，这个应用不仅是一个设置向导，更关键的是它在清单文件中声明了android.uid.system共享用户ID。按照Android的安全模型，拥有此ID的应用意味着它与系统核心进程拥有相同的权限。因此，当GSI启动时，PackageManagerService（PMS）在扫描Vendor分区的特权应用时，会将该应用的签名与GSI自带System分区的签名进行比对。由于小米的自有签名与AOSP的标准platform签名不一致，Android 14的PMS不再像旧版本那样宽容，而是直接抛出致命错误，导致system_server进程反复崩溃重启，从而陷入无法进入桌面的死循环。

Logcat日志中核心的报错信息：Signature mismatch on system package com.xiaomi.setupwizard。

针对这种由于签名冲突导致的“死锁”，极客社区通常有几条常规破局路径，但在具体的MTK TV环境下，每一条都充满了挑战。

最直观的想法是“躲”。既然这个APK导致了崩溃，能否在系统启动后、PMS扫描前将其隐藏？这就涉及到了对init.rc的修改。理论上，我们可以在post-fs-data或zygote-start等早期节点，利用tmpfs文件系统挂载并覆盖/vendor/priv-app/MiTVSetupWizard目录，从而拦截原应用。然而，实际测试中，无论SELinux状态如何，无论是直接修改GSI镜像内的init.rc，还是尝试在启动脚本中挂载，mount操作往往因时序问题、权限隔离或Namespace限制而失效，导致system_server在空目录上扫描失败，或者在挂载完成前就已经崩溃。这表明在没有Root权限的DSU环境下，单纯靠修改启动脚本来规避Vendor分区文件是非常困难的。

另一条路径是“降低门槛”。由于Android 14对共享用户ID的签名校验极为严苛，降级尝试Android 12或13的GSI成为了一种验证手段。在旧版本中，这种签名不匹配可能仅被视为Warning而不至于引发Fatal Error。虽然这确实能验证问题成因，但显然不是长久之计，毕竟使用旧版系统意味着放弃了新特性和安全更新，且MTK TV平台对新Android版本的底层适配可能本身就存在未知Bug，盲目降级可能得不偿失。

针对MTK TV平台架构的GSI刷机尝试示意图，展示了系统分区与Vendor分区的交互关系。

既然无法绕过，那只能尝试“强制通过”。这指向了最硬核但也最彻底的解决方案：修改GSI的核心逻辑。这意味着我们需要对GSI镜像中的services.jar或直接对AOSP源码中frameworks/base下的PackageManagerService与ReconcilePackageUtils进行动刀。具体而言，就是通过Smali注入或源码修改，在PMS执行签名比对的关键逻辑处插入判断：一旦遇到MiTVSetupWizard或特定Vendor应用，强制跳过异常抛出或将Fatal降级为Warning。Phh的TrebleDroid项目中曾有过针对类似Vendor冲突的补丁思路，但这通常需要开发者具备较强的逆向能力，能够精准定位到checkSharedSignatures或相关校验函数的Smali代码段，并进行魔改。对于普通玩家来说，编译一个修改后的GSI或许比直接刷入现成镜像要复杂得多，但这在目前看来是解决MTK TV平台强依赖Vendor专用Framework的唯一稳定解。

这个案例再次提醒我们，虽然Android 8.0引入Treble旨在标准化系统分区，但在Vendor分区依然深度定制化的设备——尤其是电视、车载等非手机类终端上，所谓的“通用”系统镜像依然面临诸多私有接口和签名限制的壁垒。对于小米电视S Pro这类设备，如果想要完美运行第三方ROM，可能更需要社区针对MT5879这类SoC进行专门的适配工作，而不仅仅是简单的GSI替换。