android 源码集成jar包报Had 356 soft failure(s) verifying all classes

今天集成jar包发现编译不过。

Had 356 soft failure(s) verifying all classes, and was asked to abort in such situations. Please check the log.

从错误得知

ERROR: Dex2oat failed to compile a boot image. It is likely that the boot classpath is inconsistent. Rebuild with ART_BOOT_IMAGE_EXTRA_ARGS=--runtime-arg -verbose:verifier to see verification errors.

编译加上命令

make -j128 ART_BOOT_IMAGE_EXTRA_ARGS="--runtime-arg -verbose:verier" -j64

查看日志得:

 Soft verification failures in java.util.xxx.xx.xx.x(java.lang.String, java.lang.String, java.lang.String[])

'Unresolved Reference: xxx.xxx.xxx.xxx'

包里面引用了一些可能没用到的类。但是预编译过不了。因此。找包发布人员进行裁剪后重新发布。

<think>嗯,我现在遇到了一个问题,就是在MTK平台的Android 11设备上通过OTA升级到Android 13的时候,错说“Verifying update package E:comment is 1554 bytes; signature is 1536 bytes from end”。这到底是怎么回事呢?首先,我得理清楚这个错误信息的具体含义。错误提示中提到了comment的长度和signature的位置,看起来和升级的签名验证有关。 首先,我需要回忆一下Android OTA升级的流程。在升级过程中,设备会验证OTA的签名,确保它来自合法的来源并且没有被篡改。这个验证过程通常涉及到检查签名块的位置以及相关元数据,比如注释(comment)的长度。根据错误信息,comment是1554字节,而签名是从文件末尾开始的1536字节的位置。这两者的位置可能不匹配,导致验证失败。 接下来,我应该考虑可能的错误原因。首先想到的是签名块的结构问题。在Android的OTA中,签名块含签名本身以及一些元数据,比如注释。根据错误提示,注释的长度可能超过了签名块的预期范围,导致系统在计算签名位置时出现偏差。例如,如果签名块的结构要求注释长度加上其他元数据不能超过某个固定值,而这里的1554字节可能超过了,就会错。 另外,可能需要检查使用的签名工具和流程是否正确。在Android构建系统中,生成OTA时通常会使用sign_target_files_apks或类似的脚本来签名。如果这些脚本在生成签名块时没有正确处理注释的长度,或者在Android 13的版本中签名格式有变化,而旧版本(Android 11)的签名工具没有适应这种变化,就可能导致签名块的位置计算错误。 还有一个可能性是升级本身在生成过程中出现了问题。比如,构建过程中可能因为某些配置错误,导致注释部分被错误地添加了额外内容,或者签名步骤没有正确地将注释和签名块的位置对齐。这时候需要检查生成OTA的脚本或命令是否正确,特别是与签名相关的参数。 接下来,我需要查找是否有类似问题的解决方案。根据一些经验,这种错误通常和签名块中的注释长度不匹配有关。在Android的签名机制中,签名块的位置通常是从文件末尾算起的固定偏移量。如果注释长度过长,可能导致签名块的实际位置与预期不符,从而验证失败。 例如,假设签名块应该位于文件末尾的1536字节处,但由于注释占用了1554字节,系统在计算签名位置时可能发现注释长度超过了签名块所能容纳的范围,从而抛出错误。因此,解决这个问题可能需要调整注释的长度,或者在生成签名时正确设置相关参数,确保注释和签名的位置符合预期。 可能的解决步骤括: 1. 检查生成OTA时使用的签名工具和命令是否正确。确保使用的签名工具与目标Android版本(Android 13)兼容,可能需要更新构建环境中的工具或脚本。 2. 确认在签名过程中是否正确处理了注释。可能需要减少注释的长度,或者在生成签名时省略不必要的注释内容。例如,在签名命令中添加`--omit_comment`参数(如果支持)来避免含过长的注释。 3. 检查构建系统是否有针对Android 13的特定配置要求。例如,某些MTK平台可能需要在升级生成过程中使用特定的参数或补丁来处理签名块的结构变化。 4. 如果使用的是自定义的签名脚本或工具,需要审查其逻辑,确保在计算签名块位置时考虑了注释长度的影响,并正确地将签名放置在文件末尾的适当位置。 另外,查阅相关文档或社区讨论可能会有帮助。例如,Android开源项目(AOSP)的Issue Tracker或MTK的官方支持文档可能提到类似的问题和解决方法。此外,检查生成OTA时使用的build/make工具版本是否与Android 13兼容,可能需要升级到较新的版本以支持新的签名格式或结构。 如果上述方法无效,可能需要手动调整签名块的位置或注释长度。例如,通过解压OTA,修改注释内容,然后重新签名。不过这种方法需要对Android的签名机制有深入了解,并且操作不当可能导致完全无法使用,因此需谨慎处理。 总结来说,解决这个问题的关键在于确保OTA的签名块结构符合Android 13的要求,特别是注释长度和签名位置的正确匹配。需要检查构建和签名流程,必要时更新工具或调整参数,以生成符合目标系统验证要求的升级。</think>在MTK Android 11设备通过OTA升级到Android 13时,错`Verifying update package E:comment is 1554 bytes; signature is 1536 bytes from end`,是由于**升级签名块中注释(Comment)长度与签名位置不匹配**导致验证失败。以下是逐步解决方案: --- ### **1. 问题根源分析** - **签名块结构冲突**:Android系统要求签名块(Signature Block)的注释长度和签名位置必须符合固定规则。错误显示注释长度为`1554字节`,而签名应从文件末尾前`1536字节`开始,两者重叠导致验证失败。 - **Android 13签名格式变更**:Android 13可能调整了签名块格式,旧版签名工具生成的注释过长,无法兼容新规则。 --- ### **2. 解决方案** #### **方法一:更新构建工具链** - **升级签名工具**:确保使用与Android 13匹配的`sign_target_files_apks`脚本或`avbtool`(若使用AVB签名)。 ```bash # 更新AOSP代码库至Android 13版本 repo init -u https://android.googlesource.com/platform/manifest -b android-13.0.0_rXX repo sync ``` - **重新生成OTA**:使用更新后的工具重新构建完整升级。 #### **方法二:强制省略注释** - **在签名时添加`--omit_comment`参数**:跳过注释生成,避免长度冲突。 ```bash ./build/make/tools/releasetools/sign_target_files_apks \ --omit_comment \ -o -d <密钥路径> \ <未签名的target_files.zip> <已签名的target_files.zip> ``` - **重新生成OTA**: ```bash ./build/make/tools/releasetools/ota_from_target_files \ -k <密钥路径> \ <已签名的target_files.zip> ota_update.zip ``` #### **方法三:手动调整注释长度** - **解修改注释**(高风险,需谨慎): 1. 使用`java -jar apksigner.jar`或`signapk`解压签名块。 2. 编辑注释内容,缩短至不超过`1536字节`。 3. 重新签名并验证: ```bash java -jar apksigner.jar sign --key testkey.pk8 --cert testkey.x509.pem --in input.zip output.zip ``` #### **方法四:检查MTK平台补丁** - **同步MTK专属补丁**:部分MTK平台需额外补丁才能兼容新Android版本。 - 联系MTK支持获取针对Android 13的OTA生成补丁。 - 检查`vendor/mediatek`目录下是否有未合并的修复提交。 --- ### **3. 验证修复** - **本地签名验证**:使用`check_ota_package_signature`工具预验证: ```bash ./build/make/tools/releasetools/check_ota_package_signature ota_update.zip ``` - **刷入测试**:通过Recovery或fastboot临时刷入,观察是否通过`Verifying update package`阶段。 --- ### **4. 扩展注意事项** - **密钥一致性**:确保升级签名密钥与设备原有密钥一致(如userdebug/eng版本使用`testkey`,release版本用自定义密钥)。 - **分区大小检查**:若升级大小超出`/cache`或`/data`分区限制,可能触发其他错误,需通过`resize2fs`调整。 --- 通过上述步骤,可解决因注释长度与签名位置冲突导致的OTA验证失败问题。若仍无法解决,建议提供完整的构建日志及`update_engine_log`以进一步分析。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值