1. 为什么说Android14的logo分区是个“小麻烦”如果你正在做Android14的设备开发尤其是负责OTA升级这块那你很可能已经和logo分区打过照面了。这个分区听起来挺简单不就是开机时显示的那个厂商Logo画面吗但就是这个看似不起眼的分区在OTA升级时特别是Android14引入的一些新机制下很容易变成一个“坑”。我自己在项目里就踩过好几次明明系统升级包刷进去了重启后要么卡在开机第一屏要么直接报错回滚一查日志十有八九跟logo分区有关。这背后的原因其实不复杂。在Android的AB升级也叫A/B无缝升级体系里系统有两个完整的槽位slot A和slot B。OTA时新系统会被安装到非活动槽位验证成功后再切换启动。这就要求所有需要更新的分区在A和B槽位都必须存在且配置正确。而很多老项目的分区表里logo分区往往只有一个或者虽然分了logo_a和logo_b但OTA更新属性没打开。到了Android14系统对分区的管理和校验更严格了这种历史遗留问题就会在升级时集中爆发导致权限错误、找不到分区镜像或者刷写失败。所以今天我就结合自己的实战经验跟你详细聊聊怎么在Android14上把logo分区这个“小麻烦”给理顺了。整个过程主要围绕三件事改分区表、调编译脚本、加设备权限。我会把每一步的操作细节、背后的道理还有我踩过的那些坑都讲清楚保证你照着做就能搞定。2. 第一步动分区表这是所有改动的基础分区表就像是设备的“磁盘分区规划书”它定义了每个分区叫什么、有多大、在哪、有什么属性。我们要让logo分区支持OTA升级首先就得在这份“规划书”里把它标清楚。2.1 AB升级与Non-AB升级的差异处理这里首先要分清你的设备是AB升级还是Non-AB升级。现在新设备基本都用AB升级了因为它能实现无缝更新用户无感失败了也能回退体验好。但一些老项目或者对成本极其敏感的设备可能还在用Non-AB升级。对于AB升级的设备问题在于传统的分区表里只有一个logo分区。但在AB架构下实际运行时系统会根据当前启动的槽位去访问logo_a或logo_b。如果分区表里没有明确定义这两个分区OTA系统在尝试向logo_b写入新logo镜像时就会懵圈。所以我们的修改目标是把单一的logo分区拆分成logo_a和logo_b两个独立分区。你需要找到AB升级的分区表文件通常路径像这样vendor/mediatek/proprietary/tools/ptgen/MT6765/partition_table_emmc_ab.csv。用文本编辑器打开它找到logo分区那一行。这一行可能长这样logo, 0x0000000000c00000, 0x0000000002000000, raw我们的操作是删除原有的logo分区行。新增两行分别定义logo_a和logo_b分区。这里有个关键点除了名字不同它们的起始地址start、大小size和类型type应该和原来的logo分区保持一致或者根据你的实际需求调整。最重要的是找到表格里标识OTA更新属性的列可能叫OTA_Update或类似名字把这列的属性从NNo改成YYes。改完后的片段应该类似logo_a, 0x0000000000c00000, 0x0000000002000000, raw, Y logo_b, 0x0000000002c00000, 0x0000000002000000, raw, Y注意我假设了logo_b的起始地址紧接着logo_a之后具体地址需要你根据实际情况计算绝对不能重叠对于Non-AB升级的设备就简单多了。因为只有一个系统槽位分区表里本来就只有一个logo分区。你只需要找到这个分区行将其OTA_Update属性从N改为Y即可。文件可能是partition_table_emmc.csv。2.2 关键一步文件后缀名从.bin改为.img这是一个非常容易忽略但至关重要的细节在原始的编译输出里logo文件可能是logo.bin。但是Android的OTA打包工具如build/tools/releasetools中的脚本在制作OTA增量包或全量包时默认只会识别和打包后缀为.img的分区镜像文件。如果你不改后缀名即使分区表配置对了OTA包里面也可能根本没有包含logo镜像导致升级时无新logo可刷或者刷写逻辑出错。所以必须在分区表文件里将引用的文件名从logo.bin改为logo.img。在CSV文件里这通常体现在分区的名称或关联文件名字段上确保它指向的是.img文件。3. 第二步让编译系统生成正确的logo.img分区表告诉系统“要有这么个分区”接下来就得让编译系统真的生成对应名字的镜像文件。这需要修改编译配置文件。3.1 修改Android.mk和build_lk.mkLogo分区通常和LKLittle Kernel即Bootloader的一部分的编译打包过程绑定。我们需要修改几个Makefile文件将输出目标从.bin改为.img。首先找到vendor/mediatek/proprietary/bootable/bootloader/lk/Android.mk。在这个文件里搜索INSTALLED_LOGO_TARGET这个变量。你会发现它原本指向$(PRODUCT_OUT)/logo.bin。把它改成指向$(PRODUCT_OUT)/logo.img- INSTALLED_LOGO_TARGET : $(PRODUCT_OUT)/logo.bin INSTALLED_LOGO_TARGET : $(PRODUCT_OUT)/logo.img接着修改vendor/mediatek/proprietary/bootable/bootloader/lk/build_lk.mk。这个文件可能处理不同模式如正常模式、recovery模式的编译。找到类似INSTALLED_LOGO$(LK_MODE)_TARGET的变量定义同样进行修改-INSTALLED_LOGO$(LK_MODE)_TARGET : $(PRODUCT_OUT)/logo$(call to-lower,$(LK_MODE)).bin INSTALLED_LOGO$(LK_MODE)_TARGET : $(PRODUCT_OUT)/logo$(call to-lower,$(LK_MODE)).img同时在这个文件里往下找通常会有一个拷贝logo文件到输出目录的规则rule。找到$(INSTALLED_LOGO$(LK_MODE)_TARGET):开头的规则将其中的拷贝命令从logo.bin改为logo.img$(INSTALLED_LOGO$(LK_MODE)_TARGET): $(BUILT_LK$(LK_MODE)_TARGET) $(hide) mkdir -p $(dir $) - $(hide) cp -f $(dir $)logo.bin $ $(hide) cp -f $(dir $)logo.img $3.2 修改logo资源编译规则Logo图片本身是从一张张图片资源编译打包成二进制镜像的。我们需要修改这个生成过程的规则文件。找到vendor/mediatek/proprietary/bootable/bootloader/lk/dev/logo/rules.mk或类似路径的文件。在这个文件里找到定义最终输出镜像文件名的变量通常是LOGO_IMAGE把它从logo.bin改成logo.img- LOGO_IMAGE : $(BUILDDIR)/logo.bin LOGO_IMAGE : $(BUILDDIR)/logo.img3.3 更新镜像列表配置文件有些平台特别是MTK有一个镜像列表配置文件用于签名、加密等安全流程。这个文件会列出所有需要处理的bootloader相关镜像。你需要确保这个列表里引用的是新的.img文件。找到类似vendor/mediatek/proprietary/custom/mt6765/security/cert_config/img_list.txt的文件。在[single_bin]或相应的段落下找到logo.bin这一行将其改为logo.img[single_bin] -logo.binlogo logo.imglogo boot.imgboot recovery.imgrecovery ...完成以上所有编译文件的修改后记得进行一次完整的代码编译例如make -j24并检查out/target/product/你的设备名/目录下是否生成了logo.img、logo_a.img、logo_b.img取决于你的配置等文件。这是验证编译改动是否成功的最直接方法。4. 第三步解决OTA升级时的“Permission denied”错误好了分区表改了镜像也能正确生成了是不是就万事大吉了别急最经典的“坑”往往在这里等着你。当你信心满满地发起OTA升级时可能会在logcat或者update_engine的日志里看到这样的错误E update_engine: [ERROR:utils.cc(530)] Opening block device /dev/block/by-name/logo_b: Permission denied (13) E update_engine: [ERROR:partition_writer.cc(104)] Unable to open file /dev/block/by-name/logo_b: Permission denied (13)这个错误的意思是OTA更新引擎update_engine没有权限去读写logo_b这个块设备节点。在Android系统里/dev/block/by-name/下的符号链接指向的是实际的块设备比如/dev/block/mmcblk0pX对这些设备的访问权限是由ueventd进程在启动早期根据ueventd.rc文件设置的。4.1 修改ueventd.rc文件我们需要给logo分区的块设备节点加上合适的权限让update_engine通常以system或root用户/组身份运行能够读写。你需要找到你设备对应的ueventd.rc文件。对于MTK平台路径可能类似于device/mediatek/mt6765/ueventd.mt6765.emmc.rc。在这个文件里你需要添加几行规则。规则格式通常是/dev/block/by-name/logo_a root system 0660 block /dev/block/by-name/logo_b root system 0660 block或者更常见的做法是直接授权给system用户和组读写权限0660因为update_engine服务通常属于system组。有些平台可能要求更宽松的权限如0666但基于安全最小化原则建议先从0660开始试。这里有个非常重要的技巧你不能凭空写节点名字。你需要先确认你的内核实际创建了这些设备节点。一个简单的方法是在设备正常启动后通过adb shell进入执行ls -l /dev/block/by-name/查看是否存在logo_a和logo_b的符号链接。如果不存在说明你的分区表改动可能没有成功刷入设备或者内核的fstab/device tree没有正确配置。此时去改ueventd.rc是没用的。4.2 验证权限是否生效添加了ueventd规则后重新编译系统镜像并刷机。设备启动后再次通过adb shell检查权限adb shell ls -l /dev/block/by-name/logo_b你期望看到的输出应该是lrwxrwxrwx 1 root root ... /dev/block/by-name/logo_b - /dev/block/mmcblk0pXX然后检查目标块设备节点比如/dev/block/mmcblk0pXX的权限ls -l /dev/block/mmcblk0pXX输出中应该显示权限位包含rw-rw----即0660并且所有者和组是root和system。如果权限正确那么OTA升级时的“Permission denied”错误就应该解决了。5. 实战排查升级失败还有哪些可能即使完成了上述所有配置OTA升级仍然可能失败。我遇到过不少情况这里分享几个排查思路。镜像大小问题检查你新编译的logo.img文件大小是否超出了分区表中为logo_a/logo_b定义的大小。OTA更新引擎在写入前会做校验。如果镜像文件大于分区大小肯定会失败。用ls -l命令查看镜像大小并与分区表里的size字段通常是十六进制需要转换对比。分区表未生效你修改了vendor下的分区表CSV文件但这个文件是在什么时候被使用的它通常是在编译GPT分区表镜像如partition.img时被调用的。确保你执行了完整的编译并且最终刷入设备的partition.img包含了你的改动。有时需要清理中间文件make clean或删除out目录相关中间产物再重新编译。AB升级的槽位管理在AB系统下update_engine会严格管理哪个槽位是当前活动的current哪个是待更新的uncurrent。确保你的测试场景正确。例如设备从slot A启动OTA包应该被安装到slot B。你可以通过命令adb shell getprop ro.boot.slot_suffix来查看当前启动的槽位。签名与验证如果你的OTA包需要签名正式发布通常都需要请确保logo.img也被包含在需要签名的镜像列表中并且签名过程没有错误。查看编译日志确认logo.img是否被正确打包进OTA zip包中。可以解压OTA zip包查看IMAGES/目录下是否存在logo.img。内核命令行参数极少数情况下内核命令行的root或androidboot.bootdevice参数可能会影响块设备的识别路径。但这通常不是logo分区独有的问题。如果所有分区都无法更新才需要检查这里。调试OTA升级过程最宝贵的工具就是日志。多使用adb logcat -s update_engine来过滤查看更新引擎的详细日志它能告诉你每一步进行到了哪里失败的具体原因是什么。耐心分析日志能解决90%以上的问题。6. 一些更深入的思考与建议经过这么一番折腾logo分区总算能在OTA里顺利升级了。但回过头看我们可以总结出一些经验让以后的开发更顺畅。首先分区规划要前置。在项目启动、硬件选型EMMC大小确定后就应该制定详细的分区表方案。对于AB升级的设备从一开始就把所有需要独立更新的分区如boot、system、vendor、logo等规划好A/B双份。不要等到开发中后期再拆东墙补西墙容易留下隐患。其次统一镜像命名规范。强烈建议在项目内部统一所有通过编译系统生成的、最终要刷入设备非用户数据区的镜像文件都使用.img后缀。这包括bootloader、logo、dtbo、vbmeta等等。这样可以避免OTA打包工具因后缀名问题遗漏镜像。关于logo分区的内容。我们讨论的是分区配置但logo图片本身也值得注意。确保UI/视觉团队提供的logo图片尺寸、色深如RGB565、ARGB8888符合Bootloader的要求。一个错误格式的图片编译出来的镜像可能会导致开机黑屏或花屏。可以在修改配置后专门测试一下logo显示是否正常。最后自动化测试。对于OTA这种关乎用户体验的核心功能一定要建立自动化测试用例。可以搭建一个简单的测试环境模拟OTA升级流程生成OTA包、在设备上执行安装、验证升级后版本号、验证logo等分区内容是否更新。每次修改相关配置后都跑一遍能极大降低回归风险。做系统底层开发就是这样很多问题看似微小但牵一发而动全身。logo分区配置就是一个典型的例子它涉及分区表、编译系统、权限管理和OTA流程等多个模块。希望我这次踩坑和填坑的经历能帮你更顺利地完成Android14的OTA升级适配。