问题描述
Android9系统,当升级包大小超过2G的时候,升级失败。
原因分析
update_engine报错
04-27 11:09:50.511 2293 2293 E update_engine:[0427/110950.511596:ERROR:payload_metadata.cc(74)] Bad payload format -- invalid delta magic.
04-27 11:09:50.511 2293 2293 E update_engine:[0427/110950.511679:ERROR:download_action.cc(337)] Error ErrorCode::kDownloadInvalidMetadataMagicString (21) in DeltaPerformet's Write method when processing the received payload -- Terminating processing
通过日志可以看出update_engine报错错误码kDownloadInvalidMetadataMagicString(21),通过查阅update_engine源码得知,在update_engine中是因为解析出来的payload.bin前面的元数据不是’CrAU’(Android源码定义的就是CrAU)导致;
升级包偏移量
通过参考资料得知:
- .zip文件的文件格式中,会在生成一定的头部信息,然后内部的文件会按一定规则顺序排列在后面;
- 压缩包内容中,头部有30个字节是固定的,然后后面就到文件名(可变长度)、拓展区(可变长度),这些加起来就是头部内容的长度。
参考: Android A/B System OTA分析(六)如何获取 payload 的 offset 和 size_packageoffset size_洛奇看世界的博客-优快云博客
metadata数据中的偏移量与升级包实际的偏移量对不上,这个偏移量其实指的是压缩包内文件数据(payload.bin)在文件(升级包)中的偏移量。系统打包的时候会将这个偏移量解析出来写在metadata中,而update_engine会根据metadata文件中定义的这个偏移量提取payload.bin,并判断payload.bin的前4个字节是不是’CrAU’,如果提取出来的payload.bin的前4个字节与’CrAU’不匹配,则证明偏移量错误,导致提取的payload.bin文件不正确;
既然得知这原理,后面主要是看针对一个问题:
一个问题:为什么metadata中的偏移量和实际压缩包的偏移量对应不上? --> metadata的偏移量是如何生成的?
metadata的偏移量是如何生成?
从打包的python脚本ota_from_target_files.py入手,具体的排查过程不赘述。
最终排查到这个偏移量的计算有两处:其中一处是用于解析偏移量,一处是用来做重新计算校验的(因为解析之后经过了一些签名之类的处理,所以重新校验)。这里能校验过,是因为解析和校验用的接口和公式是一致的。
payload_offset = payload_info.header_offset + len(payload_info.FileHeader()) // 计算
offset = info.header

当Android9系统的升级包超过2G时,升级失败,原因是update_engine解析出的payload.bin偏移量错误。问题源于metadata中偏移量与实际压缩包偏移量不符,主要是由于文件大小判断导致的zip64格式计算差异。解决方案包括直接修正偏移量计算公式或移植AOSP官方修复代码。
最低0.47元/天 解锁文章
1787

被折叠的 条评论
为什么被折叠?



