zipalign 验证失败 resources.arsc BAD-1
Posted
技术标签:
【中文标题】zipalign 验证失败 resources.arsc BAD-1【英文标题】:zipalign verification failed resources.arsc BAD-1 【发布时间】:2016-10-29 01:52:14 【问题描述】:我尝试将我的应用上传到 gplay 但失败了,因为我的 apk 没有压缩对齐。我尝试 zipalign,但验证失败。真的不知道,有人请告诉我该怎么做。 提前致谢。
【问题讨论】:
这也将帮助你[看到这个](***.com/a/38055015/1978475) 不要包含文本图像 - 只需复制并粘贴文本即可! 【参考方案1】:我找到了一种更简单的方法 - 只需从命令行对齐.. TWICE!对齐两次后,我能够上传我的 apk。
删除旧文件并重命名第二个文件并再次对齐..
【讨论】:
它有效。需要这种变通方法有点令人沮丧。 什么?真的... 在 2.3.x 插件发布后,他们删除了禁用 zipalign 的选项,因此您不再可以从头开始手动操作。这造成了调试版本的问题 - 调用 zipalign 失败并显示上面的输出。奇怪的是,发布版本不受影响。你拯救了我的一天 - 我多年来一直在思考这个问题,最终如何解决。 这是一个很好的收获。你为我节省了很多时间。谢谢! 经过数小时的搜索,这是我唯一为我工作的东西。【参考方案2】:无需手动,这样做:
buildTypes
release
minifyEnabled true
proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
zipAlignEnabled true
//uncomment for automatically zip aligned by studio
build.gradle
set classpath 'com.android.tools.build:gradle:2.2.0-alpha3'
到
classpath 'com.android.tools.build:gradle:2.1.2'
看我的回答here
【讨论】:
【参考方案3】:以防其他人在使用 gradle 插件“3.6.0”及更高版本时遇到同样的问题,因为我花了几个小时试图找到它。
Gradle 插件 3.6.0 正在页面对齐和打包您的原生库未压缩 https://developer.android.com/studio/releases/gradle-plugin?hl=el#3-6-0
解决方法是通过添加禁用原生库的未压缩打包
android:extractNativeLibs="true"
到您的 AndroidManifest.xml 作为应用程序标签上的属性。
【讨论】:
也为我工作【参考方案4】:试试下面的建议
buildTypes
release
debug
debuggable false
或者在 Manifest 中设置属性 android:debuggable="false" 生成构建并运行 zipalign 工具验证成功。
【讨论】:
奇怪的是,这也有效 - 你知道为什么吗?【参考方案5】:当您尝试 zipalign 并签署调试 apk 时会出现此问题。
这不是一个好主意。
改为使用命令
./gradlew assembleRelease
生成发布未签名的apk。然后 zipalign 输出 apk。
或者使用@Nilesh Senta 给出的答案
【讨论】:
这应该是答案!【参考方案6】:聚会有点晚了,但最近在从命令行对齐未签名的 apk 时遇到了同样的问题。 zipalign 命令失败,因为我在 gradle 文件中有以下代码 -
buildTypes
debug
debuggable true
release
debuggable true
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
zipAlignEnabled true
Zipalign 失败,但并未指出发布版本不能标记为 debuggable
的事实。 Android Studio Build > Generate Signed Bundle / APK
在release版本标记为debuggable
时没有问题,所以在生成签名APK的过程中肯定是覆盖了部分gradle配置。
希望这对某人有所帮助。
【讨论】:
【参考方案7】:我读到您需要在签名之前对齐 APK;如果你先签名,然后对齐,它会破坏签名。那是虚假信息。先签名,然后 zipalign,然后上传。
【讨论】:
如果您在签名后对齐,您绝对可以破坏您的签名。仅仅因为它在您的一个实例中有效并不意味着它不能破坏签名。导致它崩溃的情况有点极端,但是如果您在安装应用程序时遇到随机签名不匹配,很可能是因为您在对齐之前进行了签名。以上是关于zipalign 验证失败 resources.arsc BAD-1的主要内容,如果未能解决你的问题,请参考以下文章
JenkinsCI:APK 上的 zipalign 失败:退出代码 1
zipalign 正在手动工作,但在 Jenkins 后期构建下失败
AzureDevOps Android Pipeline zipalign - 失败,退出代码为 1
Android ------ 360加固出现预签名失败align error