AS对APK签名失败

文章讲述了在JDK11环境下,使用AndroidStudio(AS)生成签名文件时遇到HmacSHA256算法不可用的错误。作者发现该问题源于JDK版本,但因项目依赖限制无法调整。通过本地生成新的密钥文件解决了问题,同时提供了生成和签名Apk的关键命令。

问题背景

在jdk11的环境下,使用AS生成签名文件对App进行签名,但是再进行签名时报出 Algorithm HmacSHA256 not available 的异常。

报错日志

Execution failed for task ':app:packageRelease'.
> A failure occurred while executing com.android.build.gradle.tasks.PackageAndroidArtifact$IncrementalSplitterRunnable
   > com.android.ide.common.signing.KeytoolException: Failed to read key key0 from store "E:\...\analysis.jks": Integrity check failed: java.security.NoSuchAlgorithmException: Algorithm HmacPBESHA256 not available

解决过程

单纯从日志观察是无法从AS生成的签名密钥存储文件(analysis.jks)中获取签名密钥(key0),而出现这个问题的原因是 HmacSHA256 这个算法不可用。

所以根本的原因就是 HmacSHA256 这个算法的问题,那么为什么这个算法不可用呢?

在网上看到相关的资料时怀疑可能是JDK版本的问题(网上的解释是JDK11中 HmacSHA256 这个算法不存在),推荐将JDK版本进行回退到1.8版本或者升级到16版本。但是我这边项目由于依赖问题无法将JDK版本进行升级或者回退。当然我也将回退方法贴出来...

但是有一点很奇怪的事儿,我在JDK11的环境上对其他项目(存在签名密钥存储文件)进行编译出包是正常的。所以我怀疑出现这个问题可能是AS生成的签名密钥存储文件导致的。

所以我就本地生成了一个密钥存储文件,没想到问题就解决了...

说明:

  • 生成密钥文件的命令

keytool -genkeypair -alias key0 -keyalg RSA -keysize 2048 -validity 100000 -keystore analysis.jks

-genkeypair --- 产生密钥

-alias key0 --- 密钥的别名 key0

-keyalg RSA --- 使用RSA算法对签名文件进行加密

-keysize 2048 --- 密钥文件的大小为 2048

-validity 100000 --- 生成的签名文件的有效期为100000天

-keystore analysis.jks --- 生成签名文件的存放路径(自定义)

  • 对Apk进行签名

jarsigner -verbose -keystore analysis.jks -signjar app-debug-sign.apk app-debug.apk analysis.jks

-verbose --- 输出详细信息

-keystore analysis.jks ---签名过程中使用的签名文件(注意使用key的绝对路径)

-signjar app-debug-sign.apk app-debug.apk analysis.jks --- 正式签名,三个参数依次为签名后的apk,待签名的apk以及签名文件

<think>嗯,用户遇到了AOSP编译时SystemUI签名不匹配的问题,这确实是Android系统开发中常见的痛点。从用户描述看,ta应该是有一定AOSP编译经验的开发者,但可能对签名机制的理解还不够深入。 用户可能正在调试自定义SystemUI模块,签名问题导致无法正常刷机或运行。深层需求其实是想确保自定义修改能顺利生效,而不仅仅是解决签名错误。考虑到SystemUI是系统核心组件,签名验证特别严格,需要从多个维度排查。 参考AOSP构建系统的演进历史(引用[1]),现在Android.bp文件已取代Android.mk,所以解决方案要兼顾新旧两种构建系统。另外引用[2]提到的权限隔离机制也提醒我,签名问题可能涉及installd服务的权限配置。 最可能的三个故障点:一是PRODUCT_DEFAULT_DEV_CERTIFICATE指向的默认密钥被覆盖;二是模块Android.bp中force_module_build未开启;三是编译环境残留导致缓存签名冲突。需要引导用户像法医解剖现场那样层层排查。用户情绪可能比较焦虑,因为编译一次AOSP耗时很长。回复要给出可立即验证的快速方案(如clean编译),同时提供深度分析工具(如keytool检查证书)。最后补充的优化建议其实更重要,比如预置密钥到testkeys,能从根本上避免此类问题。特别要注意的是,SystemUI作为privileged应用,其LOCAL_CERTIFICATE必须是platform或shared,这点要在回复中强调。如果用户后续追问,还可以展开讲如何生成自定义platform密钥。</think>在AOSP编译过程中出现SystemUI签名不匹配问题,通常由以下原因及解决方案导致: --- ### **核心原因分析** 1. **签名密钥不一致** - SystemUI作为系统核心组件,需使用`platform`签名Android.bp中`certificate: "platform"`) - 若编译时使用的密钥与设备原有密钥不同,将触发签名验证失败 2. **残留编译产物冲突** - 增量编译时旧签名文件(如`out/target/product/.../system/priv-app/SystemUI/SystemUI.apk`)未被清除 3. **模块声明错误** - Android.bp中`certificate`字段缺失或值错误 - 模块未声明为特权应用(`privileged: true`) --- ### **解决方案步骤** #### 1. **强制使用平台签名** 在SystemUI的`Android.bp`中明确指定签名证书: ```python android_app { name: "SystemUI", certificate: "platform", // 关键声明 privileged: true, // 特权应用 srcs: ["..."], ... } ``` > 📌 若使用旧版Makefile,则在`Android.mk`中添加: > `LOCAL_CERTIFICATE := platform` #### 2. **清除编译缓存** 执行全量清理后再编译: ```bash make clean # 清除out目录 make -j8 SystemUI # 仅编译SystemUI模块 # 或完整编译 m -j8 ``` #### 3. **验证设备密钥** 检查设备内置密钥与编译密钥是否一致: ```bash # 查看设备中的platform密钥 adb pull /system/etc/security/otacerts.zip unzip -l otacerts.zip # 对比AOSP默认密钥 ls build/target/product/security/platform.* ``` > 🔑 **密钥位置**: > - 设备系统分区:`/system/etc/security/` > - AOSP源码:`build/target/product/security/` #### 4. **同步设备签名密钥** 若设备为自编译ROM,刷入**相同密钥编译**的全系统镜像: ```bash fastflashall -w # 清除数据并刷机 ``` 若为官方设备,需在AOSP中预置设备厂商的密钥(需厂商授权)。 #### 5. **临时禁用验证(仅调试)** 在`AndroidManifest.xml`中添加测试属性: ```xml <application android:debuggable="true" android:testOnly="true"> ``` > ⚠️ 此操作仅限开发调试,会降低安全性 --- ### **进阶调试方法** - **签名验证命令** ```bash jarsigner -verify -verbose SystemUI.apk | grep "CN=Android" ``` 输出应包含:`CN=Android` - **查看APK证书** ```bash keytool -printcert -jarfile SystemUI.apk ``` - **系统属性覆盖** 在`device.mk`中添加(不推荐生产环境): ```makefile PRODUCT_DEFAULT_DEV_CERTIFICATE := build/target/product/security/testkey ``` --- ### **根本解决建议** ```mermaid graph LR A[签名问题] --> B{设备类型} B -->|官方设备| C[预置厂商密钥] B -->|自编译设备| D[统一使用AOSP密钥] D --> E[编译前执行make clean] E --> F[确保Android.bp正确声明证书] F --> G[刷入完整系统镜像] ``` > 📚 参考AOSP构建机制:早期Android.mk已被Soong构建系统替代,签名策略通过Android.bp实现[^1]。若问题持续,需检查构建系统是否完整切换至Blueprint。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值