1. 先想清楚第三方ROM移植和GSI刷机到底差在哪玩安卓刷机这件事说白了就是一场和系统分区、内核、驱动打交道的长期拉锯战。很多人是从给老手机刷个第三方ROM入门的后来听说还有个叫GSI的东西一个通用镜像能刷进一大票设备于是蠢蠢欲动。我一开始也是这么想的结果第一次把GSI刷进一台骁龙机器开机卡在logo上转圈转了四十分钟最后靠一串logcat才找到是vendor的音频HAL没被识别。这篇文章就围绕安卓第三方ROM移植和第三方GSI系统修复bug这两条线把我在实际搞机过程中总结的思路、方法和踩过的坑一次性摊开讲。如果你属于下面这几类人这篇内容对你有用手上有几台吃灰的老设备想折腾玩过TWRP和Magisk但没系统性地处理过底层兼容问题给盒子或者旧手机刷了安卓9、安卓11的移植包结果卡在某个功能上或者单纯对为什么换个system分区就能跑新系统这件事感到好奇。这些问题的答案一半藏在Project Treble的架构设计里一半藏在日志文件里。1.1 GSI到底是什么和普通第三方ROM有什么本质区别先说清楚概念不然后面全是糊涂账。GSI全称Generic System Image直译是通用系统镜像。从Android 8.0开始谷歌推了一套叫Project Treble的架构把原本糊在一起的系统拆成了两块一块是system分区装着AOSP框架、系统应用、系统服务另一块是vendor分区装着芯片厂商和整机厂商写的驱动、HAL硬件抽象层、固件和配置。拆开的好处很直白。以前每次升级大版本芯片厂商必须重新适配一遍所有驱动一个中低端机器等半年都等不到更新。拆开之后只要设备的vendor分区满足Treble要求理论上你把任意一个符合规范的system镜像刷进去系统就能起来因为驱动那部分原地不动。GSI就是官方按这套规范做出来的system镜像一个包能刷进一堆不同品牌的Treble设备。普通第三方ROM是另一条路。它通常由社区开发者基于AOSP或者LineageOS这类源码配合设备树device tree、内核源码和从官方固件里提取的vendor文件一起编译出来的整包。它不是通用的一个包只对应一款或者几款设备因为它把设备相关的适配全都编译进去了。打个比方GSI像是一套标准尺寸的西装只要你的身材在某个范围内穿上都能看第三方ROM是量身定制的剪裁合体但换个人就穿不上。所以你会看到GSI普遍有些小毛病——某个传感器不灵、相机打不开、手电筒没反应这都很正常因为它不认识你设备的具体硬件。1.2 移植第三方ROM的两条主流路子如果你是想给一台没有被官方社区支持的设备做移植那思路一般分两条。第一条是源码编译。流程大致是找一颗和你设备芯片平台相同的、已经有社区支持的机型做参考把它的设备树拿过来改主要改BoardConfig.mk里的分区尺寸、内核命令行、以及vendor blobs的引用路径然后从官方固件包里提取vendor分区内容生成vendor blobs列表配置好内核这部分最难涉及defconfig、dtb、驱动补丁最后repo sync、source build/envsetup.sh、lunch、mka。第一次编译大概率跑不通报错一行一行啃这活儿的门槛主要就在这儿。第二条是底包拼装也就是常说的移植包。拿一个同芯片平台的其他机型已经能正常运行的第三方ROM做底包把它的system分区分出来替换掉里面设备相关的部分把vendor覆盖成你自己设备的把boot.img换成你设备能用的内核改一改build.prop里的机型标识和部分属性重新打包。这条路门槛低很多不需要完整的编译环境适合手头只有一台机器、没有服务器资源的人。但它有个硬伤如果底包机型和你的设备在硬件上有差异那些差异会变成bug你只能靠打补丁一个个磨。第三条其实也算拼装的一种就是直接刷GSI再逐个修bug。这条路最省事也最脏因为它把适配工作从编译期推到了运行期。本篇重点讲的就是这条路——GSI刷进去之后怎么通过日志定位问题、怎么打补丁、怎么绕过不兼容。1.3 开搞之前必须确认的三件事不管你走哪条路动手前把这三件事确认清楚能省掉大量返工。第一件设备是否满足Treble。判断方法很简单刷之前用adb跑adb shell getprop ro.treble.enabled返回true说明支持。或者直接看设备目录里有没有/vendor分区、有没有/vendor/etc/vintf/manifest.xml。Android 8.0之后出厂且通过了Google认证的设备基本都是Treble的。第二件分区布局是不是动态分区。Android 10开始大量设备用了super分区把system、vendor、product、odm塞进一个物理分区里。这类设备刷GSI不能直接fastboot flash system得先删掉逻辑分区再刷。第三件bootloader能不能解锁以及AVB怎么处理。很多设备解锁之后刷入未签名的镜像会直接拒绝启动因为Android Verified BootAVB校验不过。这一步的通用做法是刷一个被处理过的vbmeta把verity和verification关掉。注意解锁bootloader会触发数据清空也会影响部分厂商的保修和部分金融类应用的使用。搞机之前先想清楚这台机器是不是你的主力机别拿日常用的手机上来就开干。2. 出问题之前先把家伙事备齐工具链与日志通道刷机这事儿有个反直觉的地方修bug的能力八成取决于你出问题之前有没有把日志通道打通。很多人设备一黑屏就开始瞎试重刷、换包、清数据折腾一晚上什么都没解决因为压根不知道挂在哪儿。我现在的习惯是动手之前先把日志和回滚方案铺好后面出任何问题都不慌。2.1 工具清单和各自负责什么先把工具列一下别到用的时候发现缺东西。工具用途使用场景adb / fastboot命令行通信、刷写分区全流程平台专用刷机工具救砖、线刷底层分区高通用QFIL联发科用SP Flash Tool晶晨用USB Burning Tool海思用HiToolTWRP 或同类恢复刷zip包、备份分区、挂载读取刷GSI前做全盘备份Magisk打系统级补丁、修改props处理SELinux、属性覆盖文本编辑器 抓包工具改配置、看网络请求修WiFi、修网络类问题一台能正常上网的电脑查资料、下镜像全程高通平台的QFIL走的是9008端口需要短接或者特定按键组合进EDL模式联发科的BROM模式一般靠音量键组合或者短接晶晨S905系列这类盒子用USB Burning Tool刷img包工具报错码是有规律可循的。我遇到过晶晨盒子线刷报0x223的情况排查下来基本绕不开三个方向固件包本身和芯片型号/内存颗粒不匹配、烧录工具版本太老不认新包的签名头、USB线和接口供电不足导致传输中断。这几个方向逐个排掉大多数情况能解决。提示盒子和手机的刷机逻辑不完全一样。盒子类设备很多没有bootloader解锁这一说但它们的固件包通常带加密和签名校验包里换个system分区可能导致整包校验失败。所以盒子这一类更推荐用官方线刷包作底再考虑用卡刷的方式替换。2.2 打通日志通道三类日志缺一不可设备起不来的时候你能拿到的信息就只剩日志。三种日志各有分工学会一起看。第一种是内核日志也就是dmesg。它记录的是内核启动阶段的硬件探测过程能告诉你哪个驱动初始化失败、哪个设备节点没起来。开机卡在logo阶段的时候多半就是内核或者init早期的活儿没干完。adb shell dmesg dmesg.txt adb shell cat /proc/kmsg # 实时滚动如果系统已经完全起不来连adb都连不上那就得靠pstore。内核如果开了ramoops支持崩溃前的日志会被写到一块保留内存里重启之后还在。adb shell su -c ls /sys/fs/pstore/ adb shell su -c cat /sys/fs/pstore/console-ramoops-0第二种是系统日志也就是logcat。系统能起来但功能不正常的时候它是主要信息源。注意别只看默认的main缓冲区events和system两个缓冲区经常藏着关键信息。adb logcat -b all -v threadtime logcat.txt adb logcat -b events | grep -i avc第三种是SELinux拒绝日志。这个东西单独拿出来说因为它是最容易被忽略、又最常导致服务起不来但不报错的元凶。后面第4章会专门展开。2.3 备份和回滚给自己留条后路动手之前务必做两件事。第一用TWRP做一次完整备份至少覆盖boot、vendor、system、product这几个分区。注意TWRP默认不备份super分区里的逻辑分区需要手动勾选。备份文件建议拷到电脑上一份别留在设备里设备万一彻底开不了机TWRP也可能进不去。第二把官方原厂固件包完整下载一份放到电脑上。线刷工具能救回来的场景前提是你手里有原厂包。我见过太多人刷之前没存包最后只能去论坛翻别人分享的链接版本对不上又要重新折腾。第三记录下当前设备的基线信息后面排查很有用adb shell getprop | grep -E ro.product|ro.vndk|ro.treble|ro.build.version adb shell ls -l /vendor/lib64/hw/ vendor_hal_list.txt/vendor/lib64/hw/这个目录的列表尤其重要它就是你设备支持的所有HAL实现清单。GSI起来之后如果某个功能不工作第一件事就是对照这个列表看system侧期望的HAL版本和vendor侧提供的对不对得上。3. 按现象修bug从开不了机到没声音GSI刷进去之后的bug按看到的症状分类是最实用的思路因为你能看到的东西就那么几样黑屏、卡logo、无限重启、某个功能没反应。下面按症状拆开讲。3.1 黑屏、卡logo、无限重启的定位顺序这类问题占了我遇到的所有GSI问题的一半以上。定位顺序建议固定下来能少走很多弯路。第一步确认是不是压根没刷进去。重新进fastbootfastboot getvar all看下当前分区的容量和名称确认system真的写进去了。动态分区设备上如果忘了删product或者system_ext刷system的时候会报空间不足但有些工具不会明确提示只是静默失败。第二步看内核有没有起来。接USB看电脑能不能识别到设备的VID/PID。识别得到但adb连不上说明内核起来了但init卡住了完全识别不到那就是内核或者boot阶段就挂了。这个阶段只能靠pstore日志或者换一个确定能用的boot.img做对照测试。第三步看init阶段。把设备接上电脑用adb logcat抓早期日志或者从recovery里抓重点看这几类报错Failed to start service—— 某个HAL服务起不来通常是vendor的HAL和system期望的对不上。Cannot find native binding—— 这行报错我印象很深第一次遇到的时候整个人是懵的。它本质上是VNDK层面的库找不到或者依赖链断掉了。后来发现根因经常是system侧的某个库依赖了一个vendor侧不存在的符号或者VNDK版本区间不匹配。avc: denied—— SELinux拦住了后面细讲。Fatal signal—— 某个native进程崩了往上翻能看到backtrace。第四步判断是不是AVB。如果刷完之后设备直接回bootloader或者提示校验失败那就是vbmeta没处理。命令要带两个参数fastboot --disable-verity --disable-verification flash vbmeta vbmeta.img有些设备尤其是国产定制ROM的机器在fastboot flash vbmeta之后还需要额外刷一个patch过的vbmeta或者用fastboot flashing unlock_critical打开关键分区。这块每个厂商差异很大最好先去对应机型的社区帖子里确认。注意不要一遇到卡logo就去清data、清cache。清数据能解决的是用户数据残留导致的兼容问题在没定位清楚之前就清等于把变量扩大了后面再复现问题就难了。我的习惯是先抓日志判断清楚再动手。3.2 基带、WiFi、蓝牙射频类的三件套这三个功能在GSI上出问题的概率特别高因为它们都依赖vendor侧的专有实现。没有信号、SIM卡不识别一般出在RILRadio Interface Layer上。AOSP的RIL实现和芯片厂商的rild之间要能对上话。GSI通常自带一套AOSP的radio HAL实现如果你的vendor提供的rild版本差异太大就会连不上。排查方法adb logcat -b radio -v threadtime adb shell getprop | grep -i ril adb shell dumpsys telephony.registry | head -50如果radio日志里刷的都是RIL_REQUEST_GET_SIM_STATUS超时或者Radio not available基本就是HAL层不匹配了。解法通常有三个换成另一个版本的GSI有些开发者会针对不同Treble版本做分支把vendor侧的rild相关blob保留并确保权限正确或者用Magisk模块在系统侧注入属性覆盖。WiFi打不开是另一个高频问题。GSI自带的wpa_supplicant和你的vendor固件可能对不上。排查次序adb shell dmesg | grep -i wlan\|wifi\|bcmdhd\|qcacld adb shell ls /vendor/etc/wifi/ adb shell ls /vendor/firmware/重点看三样东西vendor下有没有WiFi固件文件.bin或者.nvm有没有配置文件wpa_supplicant.conf、p2p_supplicant.conf以及内核模块有没有加载成功。我遇到过一种情况是固件文件在但GSI的init没有触发加载对应的内核模块因为GSI的init.rc里没有你设备专有的insmod语句。这种可以在Magisk模块里补一个post-fs-data.sh手动把模块插进去。蓝牙打不开相对好修一些。蓝牙一般走HAL 1.0或1.1接口GSI大多数情况下能兼容出问题多半是固件.hcd或者.bin没放对位置或者bluetooth.default.so的路径不对。检查adb shell ls /vendor/lib64/hw/ | grep -i blue adb shell ls /vendor/etc/bluetooth/ adb logcat | grep -i bluetooth3.3 相机、音频、传感器、指纹HAL缺失的典型修法这四个功能有个共同点它们都对应明确的HAL接口接口版本对不上就直接罢工而且往往不报明显的错误只是没反应。相机打不开最典型。从Android 8开始相机走的是Camera HAL 2.4及以后的版本Android 9之后是3.xAndroid 11之后是2.4/3.x混用。GSI的相机provider期望某个AIDL或HIDL接口你的vendor提供的是另一套那就只能黑屏。检查手段adb shell ls -l /vendor/lib64/hw/ | grep -i camera adb shell getprop | grep -i camera adb logcat | grep -iE camera|CameraProvider典型的报错是CameraProvider: Could not find camera HAL或者Failed to get service camera.provider。这种情况基本没救只能换一个和你的Treble版本更贴的GSI或者找别人做好的相机补丁包。音频问题通常表现为完全没声音、只有一边响、通话对方听不到。音频HAL的版本跨度也很大Android 8是2.010之后是5.x/6.x/7.x。日志里搜audio_hw或者AudioFlinger能看到关键信息adb logcat | grep -iE audio|AudioFlinger|audio_hw一个常见的坑是音频路由配置。GSI自带的mixer_paths.xml是通用版本和你的硬件不匹配结果就是扬声器有声、耳机没声或者反着来。如果vendor分区里保留了原厂的mixer配置可以尝试用RRO覆盖或者直接在GSI的/system/etc/下替换有Magisk的情况下可以用模块挂载。传感器和指纹这两个可以放一起说。它们的问题高度相似传感器走sensors HAL 2.x指纹走biometrics HALGSI里如果缺少对应的实现就直接没反应。判断方法adb shell dumpsys sensorservice | head -40 adb shell ls /vendor/lib64/hw/ | grep -iE sensor|fingerprint|biometric adb shell ls /vendor/etc/permissions/ | grep -i sensor有两种修法。一是把vendor侧的HAL实现完整保留并且确保被system加载到二是用Magisk模块往/system/lib64/hw/里塞一份vendor的HAL库。第二种做法有个前提接口版本必须兼容如果GSI是Android 12的AIDL接口而你的vendor只有HIDL实现那塞进去也没用。提示判断HAL接口是HIDL还是AIDL最直接的办法是看/vendor/etc/vintf/manifest.xml。里面写了hal formathidl还是hal formataidl也写了具体版本号。这个文件是你判断兼容性的第一手资料比任何论坛帖都准。3.4 显示、亮度、状态栏导航栏这类界面异常这类问题不影响能不能用但很影响心情。常见的几种亮度调节无效、自动亮度乱跳、状态栏和导航栏高度不对、刘海区域显示错位、分辨率识别成默认值。亮度调节无效一般是lights HAL没加载或者背光调节的sysfs节点路径和GSI默认的不一样。AOSP默认用的是/sys/class/leds/lcd-backlight/brightness如果你的设备是/sys/class/backlight/...之类就要靠RRO覆盖或者init脚本去改。状态栏和导航栏异常在Android 11之后可以通过overlay机制处理adb shell cmd overlay list | grep -i navigation adb shell cmd overlay enable --user 0 package分辨率不对通常是因为GSI没能从vendor侧读到正确的显示参数。可以临时用wm命令验证一下adb shell wm size adb shell wm density adb shell wm size 1080x2340 adb shell wm density 400这个设置是临时的重启就恢复。要永久生效得改build.prop里的ro.sf.lcd_density或者通过overlay。4. 三个最容易卡住人的硬骨头SELinux、VNDK、动态分区上面讲的都是看症状开药这一章讲的三个东西是底层机制理解了它们上面一大堆问题你会发现根因其实很集中。4.1 avc denied的正确读法和策略取舍SELinux在Android上默认是enforcing模式。它的作用是给每个进程划定能访问哪些文件、能调用哪些接口的权限。GSI是通用镜像它的sepolicy规则是按AOSP通用场景写的不包含你设备特有的那些文件和设备节点于是就出现了进程被拦住、功能直接失效、但日志里只有一行冷冰冰的avc denied。看avc日志要抓全信息不要只看那一行adb shell dmesg | grep avc adb logcat -b events | grep avc一行完整的avc denied长这样avc: denied { read } for pid1234 commwificond namewifi_mac devsysfs ino12345 scontextu:r:wificond:s0 tcontextu:object_r:sysfs:s0 tclassfile permissive0读的时候抓四个要素scontext谁tcontext对什么tclass什么类型的对象{ }里是缺什么权限。这四个要素凑一起才能理解这条规则该怎么补。临时验证用permissive模式最快adb shell su -c setenforce 0 adb shell getenforce变成Permissive之后功能恢复了就确认是sepolicy的问题。但长期跑permissive是不推荐的一是安全上有隐患二是部分应用尤其是金融类、企业类会直接拒绝在permissive的设备上运行。正式的修法是把规则补进sepolicy。用Magisk的思路是在模块里放一个编译好的sepolicy patch工具链上通常用magiskpolicymagiskpolicy --live allow wificond sysfs file { read }或者在模块的sepolicy.rule文件里写规则重启后自动生效。更彻底的做法是在AOSP源码里改device/vendor/device/sepolicy/下的te文件重新编译但这要求你有完整的编译环境。注意不要看到avc denied就把整条规则开放成allow xxx self *。SELinux规则放宽是有连锁反应的一条过宽的规则可能让本来被隔离的进程拿到不该有的权限导致行为异常。一条一条按需补是最稳的做法。4.2 VNDK版本不匹配的三种应对VNDK全称Vendor Native Development Kit是Treble架构里保证system和vendor之间库版本兼容的一层机制。简单说官方把一批稳定的native库做了版本快照标成VNDK-28、VNDK-29之类的。vendor侧编译时依赖某个版本的VNDKsystem侧运行时要提供对应版本的库。如果GSI的VNDK版本和你设备vendor声明的版本区间不重叠就会出现各种诡异问题HAL加载失败、native进程崩溃、报cannot find native binding这类的错。先看当前状态adb shell getprop ro.vndk.version adb shell getprop ro.product.vndk.version adb shell getprop ro.vndk.litero.vndk.version是system侧的版本ro.product.vndk.version是vendor侧声明的。如果这两个数值差得太远就要处理了。三种应对方式按侵入性从低到高第一种换GSI。这是最省心的。很多GSI发布页会明确标注支持的VNDK版本范围选一个和你设备对得上的。第二种属性覆盖。通过Magisk模块或者resetprop把ro.vndk.version强行改成vendor期望的数值。这招有效是因为VNDK的兼容检查有一部分是看属性值但要注意属性改了不代表库真的存在如果system侧缺乏对应版本的库文件改了也白改。第三种刷VNDK Lite。部分设备支持ro.vndk.litetrue这种模式下system不提供额外的VNDK库全部用vendor侧的。老设备或者低内存设备常见这个配置GSI如果支持lite模式兼容性反而更好。adb shell su -c resetprop ro.vndk.lite true4.3 动态分区和vbmeta的正确处理姿势Android 10之后super分区成了主流。system、vendor、product、system_ext、odm这些逻辑分区都在一个物理super分区里。这种布局下刷GSI和以前完全不一样很多人卡在这一步。刷之前先看清楚当前的分区布局fastboot getvar all 21 | grep -i partition adb shell ls -l /dev/block/by-name/动态分区设备的刷写流程大致是这样fastboot reboot fastboot fastboot delete-logical-partition product_a fastboot delete-logical-partition system_ext_a fastboot flash system system.img fastboot -w fastboot reboot注意fastboot reboot fastboot这一步它进的是fastbootd和bootloader里的fastboot不是一回事。动态分区的创建和删除必须在fastbootd里做在bootloader的fastboot里操作会报错。delete-logical-partition的作用是腾出空间。super分区的总容量是固定的你要往里面塞一个体积更大的GSI system镜像就必须先删掉一些不用的逻辑分区。product和system_ext一般是可以删的删掉之后部分功能会缺失比如某些Google服务、某些厂商定制应用但不影响系统启动。vbmeta的处理前面提过这里补充一个细节如果刷完GSI之后设备进不了系统、直接回bootloader先试试fastboot --disable-verity --disable-verification flash vbmeta vbmeta.img如果还不行有些设备需要刷入GSI发行方提供的、已经打过补丁的vbmeta。这两种vbmeta的区别在于后者把AVB的校验链整个绕过了而不仅仅是关掉校验标志位。提示fastboot -w会清空用户数据。刷GSI的第一次建议清因为从旧系统的数据分区迁移过来很容易出问题尤其是加密方式不一样的时候。具体表现是开机之后卡在锁屏反复重启日志里能看到vold相关的报错。5. 常见问题速查表与踩坑记录前面按症状和机制都过了一遍这一章把高频问题整理成速查表再补几条我自己踩出来的经验。5.1 高频问题速查现象最可能的根因第一步怎么查卡logo不动HAL服务起不来 / init阶段失败pstore日志、adb logcat早期输出无限重启AVB校验失败 / 关键分区缺失检查vbmeta处理、fastboot getvar all无信号RIL版本不匹配adb logcat -b radioWiFi打不开固件缺失 / 内核模块未加载dmesg | grep wlan、看/vendor/firmware相机黑屏Camera HAL版本不兼容看/vendor/lib64/hw/里的camera库没声音audio HAL或路由配置不匹配logcat | grep audio_hw传感器全无sensors HAL未加载dumpsys sensorservice亮度不能调lights HAL缺失或sysfs路径不符看/sys/class/leds/和/sys/class/backlight/功能正常但报错刷屏SELinux拦截dmesg | grep avc应用崩溃、native报错VNDK版本不匹配对比ro.vndk.version和ro.product.vndk.version刷不进去、报空间不足动态分区未腾空间进fastbootd删逻辑分区5.2 几条用时间换来的经验关于换包这件事。修bug修到一定程度你会发现有些问题是修不动的比如相机HAL这种强绑定的东西。这时候止损换一个GSI分支比死磕效率高得多。我现在判断一个GSI值不值得继续修会先花二十分钟把十个核心功能过一遍如果超过四个不工作且都是HAL层面的就直接换。关于日志的保存习惯。每次刷机前我都会在电脑上建一个以日期和设备型号命名的文件夹把logcat、dmesg、getprop全量输出、/vendor/lib64/hw/列表都存一份。这个习惯的价值在于等你刷了十个包之后再回头对比能很快定位出哪个包在哪个环节变好了而不是凭记忆猜。关于Magisk模块的写法。修GSI的问题Magisk模块是最灵活的载体因为它可以在不改动system分区的前提下做属性覆盖、挂载文件、注入sepolicy规则。一个最小可用的模块结构是这样的MyFixModule/ ├── module.prop ├── post-fs-data.sh ├── service.sh └── system/ └── etc/ └── some_config.xmlpost-fs-data.sh在早期启动阶段跑适合放resetprop和文件挂载service.sh在启动后期跑适合放需要等服务起来的操作。注意脚本要有可执行权限且第一行写#!/system/bin/sh。关于盒子类设备的特殊性。给晶晨、海思这类平台的电视盒子刷安卓9或者移植包和手机刷GSI的差异挺大。盒子基本没有fastboot这一套主要靠线刷工具USB Burning Tool、HiTool和卡刷。线刷报错的时候先把工具版本、固件包、USB线和接口这三个变量逐个替换验证。我遇到过一次报0x223换了三根线才好根因是USB线供电不足导致eMMC写入过程中断。关于双系统的思路。有人喜欢在同一台设备上做双系统一个原厂一个GSI。这个思路在手机上行不通因为system分区只有一个但在支持多引导的盒子上或者用sd卡引导的设备上是可以做的。SD卡引导的关键是bootloader支持从外部介质启动这需要在uboot阶段配置boot order且卡上的boot分区要放对位置。关于刷完先别急着装应用。GSI刷完之后先花时间把系统自带的功能全部过一遍打电话、发短信、联网、拍照、录音、GPS、蓝牙、亮度、指纹。这轮测试能过八成的机器基本就能当日常机用了。剩下两成的问题往往会在你装完一堆应用之后才暴露那时候定位成本就高多了。关于记录。搞机这个圈子信息更新很快同一个GSI版本在不同月份发布兼容性可能完全不同。我现在的做法是每刷一个包就在备忘录里记一行日期、包名、版本、能用的功能、不能用得功能、用到的补丁模块。积累几十条之后你就有了一个属于自己的兼容性数据库比任何论坛帖都更贴合你手上的设备。我个人在实际操作中的体会是GSI这套东西的价值不在于一个包刷所有机器这个宣传点而在于它把系统适配的问题从编译期黑盒变成了运行期可观测。你能用日志看到每一层发生了什么能通过属性、overlay、sepolicy补丁一个个把问题磨掉。这个过程本身比刷成功那一刻更有意思。