Apk 二次打包修改包名、配置_apk修改包名

Apk 二次打包修改包名、配置

apk 二次打包目的：
当有多个渠道，每个渠道需要的包名，图标，AndroidManifest.xml配置，渠道信息，配置文件等不同

方案一：
分多次打包，每次打包前根据渠道修改不同的配置
缺点：打包耗时太长，任何修改都要重新出包，效率低

方案二：
打包出来一个 apk，对apk 反编译
修改包名，图标，AndroidManifest.xml配置AndroidManifest.xml 文件 等
Unity目录下 StreamingAssets 文件夹的资源，反编译生成路径assets文件下可以找到，所以不同渠道的配置也可以放在 StreamingAssets 文件夹，反编译后根据渠道替换。
重新编译为 apk
对重新编译的apk重新签名(不重新签名是无法正常安装到Android 设备或模拟器上的)

一：反编译工具apktool
下载地址：https://apktool.org/
分别有 Windows、Linux、Mac 对应平台的 jar
下面以Windows 为例，打开网址，选择Install 根据自己的环境进行下载配置

按照如上步骤下载，配置环境变量即可，打开CMD 命令输入apktool，能输出apktool版本等信息说明配置成功

二：打包 apk
(1) 生成 keystore 文件，使用 Keytool 工具、AndroidStudio、Unity 等都可以生成
(4) 打包apk 生成 Test.apk

三：反编译
(1) 在 Test.apk 目录打开 CMD 命令，或者打开CMD命令cd 到这个目录
输入命令：apktool d Test.apk
在 Test.apk 同级目录生成一个 Test 的文件夹，存放反编译出来的文件，输出如下

生成目录如下

original\META-INF 文件夹中存放的是原本的签名信息
apktool.yml 是反编译后生成的文件

(2) 也可以在命令中添加参数，如下
apktool d -o output_dir Test.apk
-o output_dir 表示将反编译出来的文件，存放到 output_dir 目录
更多参数自行查看文档

四：修改配置
(1) 修改包名：
(1.1) 用文本编辑器打开 AndroidManifest.xml 搜索package 修改包名package="com.abc.def"
(1.2) 打开 apktool.yml 内容大概如下

搜索 renameManifestPackage默认值为 null，赋值为新包名 com.abc.def，
renameManifestPackage: com.abc.def

(2) AndroidManifest.xml 添加标签
打开AndroidManifest.xml 在 <application> </application> 中添加

<application>
    <meta-data android:name="CHANNEL" android:value="TapTap"/>
</application>
1
2
3

五：将Test 文件夹重新编译为 apk
(1) 输入命令：apktool b Test
生成的 apk 存放在 Test\dist\Test.apk
(2) 也可以在命令中添加参数如下
apktool b -o output_dir\new.apk Test
-o output_dir\new.apk 表示将编译出来的apk存放到目录 ，重新编译的 apk命名为 new.apk
此时重新编译的 Test.apk是无签名的，还无法正常安装到Android设备以及模拟器上需要对Test.apk 重新签名

六：重新给apk签名
(1) 签名工具：
Jarsigner：是JDK提供的针对jar包签名的通用工具,位于JDK/bin/jarsigner.exe
Apksigner：是Google官方提供的针对android apk签名及验证的专用工具,位于Android SDK/build-tools/SDK版本/apksigner.bat
其他签名工具等等

(2) apk 签名有两种标签
V1签名:(Jar Signature)
V2签名:(Full APK Signature)
Android 7.0以下版本, 只能用旧签名方案 V1 scheme (JAR signing)
从Android 7.0开始, 谷歌增加新签名方案 V2 Scheme (APK Signature)
注意:
V2签名优点明显, apksigner工具默认同时使用V1和V2签名,以兼容Android 7.0以下版本。工具都要选择生成apk时使用的 JDK、SDK 路径下的，避免因为工具版本问题导致失败。
鉴于此我选择使用 apksigner 进行签名。

(3) 签名命令：

apksigner sign --ks H:\APK\unity.keystore --ks-key-alias unity --ks-pass pass:123456 H:\APK\Test\dist\Test.apk
1

apksigner 此处是简化了路径，实际应用是需要将apksigner 改为 apksigner所在路径\apksigner 位置在 六(1) 处写了
sign 为 apk 签名
--ks H:\APK\unity.keystore 签名使用的 keystore 文件
--ks-key-alias unity “unity” 是 keystore 文件的别名
--ks-pass pass:123456 keystore 别名文件的密码(123456)(一般keystore和别名使用同样的密码生成即可)
H:\APK\Test\dist\Test.apk 需要签名的 apk

执行命令后如果成功则会在 Test.apk 同级目录则会有两个文件Test.apk 和 Test.apk.idsig
Test.apk 已经是签名后的文件了，可以正常安装使用了

七：优化 zipalign
官方文档：https://developer.android.google.cn/studio/command-line/zipalign?hl=zh-cn
(1) zipalign 是一种 zip归档文件对齐工具，有助于确保归档文件中的所有未压缩文件相对于文件开头对齐。这样一来，您便可直接通过 mmap(2) 访问这些文件，而无需在 RAM 中复制这些数据并减少了应用的内存用量，说白了就是对apk运行内存占用的优化

(2) 在将 APK 文件分发给最终用户之前，先使用 zipalign 进行优化。如果您通过使用 Android Gradle 插件 (AGP) 的 Android Studio 进行构建，系统会自动完成此操作。在这种情况下，您仍应使用 zipalign 来验证 APK 是否已对齐，但您无需对齐。本文档主要适用于自定义构建系统的维护者

(3) 注意：
(3.1) 您必须在构建流程的特定时间点使用 zipalign。该时间点取决于您使用的应用签名工具：

(3.2) 如果您使用的是 apksigner，则必须在为 APK 文件签名之前使用 zipalign。如果您在使用 apksigner 为 APK 签名之后对 APK 做出了进一步更改，签名便会失效。

(3.3) 如果您使用的是 jarsigner（不推荐），则必须在为 APK 文件签名之后使用 zipalign

(4) 用法
(4.1) 如果您的 APK 包含共享库（.so 文件），请使用 -p 来确保它们与适合 mmap(2) 的 4KiB 页面边界对齐。对于其他文件（其对齐方式由 zipalign 的必选对齐参数确定），Android Studio 将在 32 位和 64 位系统中对齐到 4 个字节。

zipalign 工具在SDK 目录 SDK\build-tools\版本号

(4.2) 如需对齐 infile.apk 并将其保存为 outfile.apk，请运行以下命令
zipalign -p -f -v 4 infile.apk outfile.apk
如果输出的 outfile.apk 对齐成功，在输出命令最后输出：Verification succesful

(4.3) 如需确认 existing.apk 的对齐情况，请使用以下命令。
如果您使用 Android Studio 或 AGP 进行构建，则应使用该命令来验证 APK 是否已对齐
zipalign -c -v 4 existing.apk
如果existing.apk 未对齐，在输出命令最后输出：Verification FAILED
如果existing.apk 已对其，在输出命令最后输出：Verification succesful

八：遇到的错误
(1) 重新签名的apk安装后运行闪退，首先检查操作步骤是否有遗漏的地方
(1.1) 有遗漏的则重新按照步骤再执行一遍
(1.2) 打开AndroidStudio 或者 使用 adb 查看 Logcat (不要过滤信息，要看全部输出，因为过滤后有些信息可能就看不到了，因为日志很多，需要细心查看)
(1.3) 运行闪退，可以通过 Logcat 看到如下日志

signal 11 (SIGSEGV), code 1 (SEGV_MAPERR)
#00 pc 00142325 /system/lib/libhoudini.so
1
2

原因：我使用的是Windows上的Android模拟器，是 x86_64 环境，因为我打包apk 的时候只勾选了ARMv7、ARM64，所以模拟器使用了libhoudini.so这个库来模拟执行arm 代码的，有的情况是没问题的，但是有些也确实会出问题，我用Unity生成的 Test.apk 没有勾选 x86 相关，但是是可以正常运行的。打包时选择： x86(Chrome OS)、 x86-64(Chrome OS)
重新打包apk，重新执行上边所有流程

(2) 重新编译执行 apktool b 命令生成 apk 失败，报错如下

AndroidManifest.xml:21: Tag <provider> missing required attribute name.
brut.androlib.exceptions.AndrolibException: brut.common.BrutException: could not exec (exit code = 1): [C:\Users\Administrator\AppData\Local\Temp\brut_util_Jar_18166975943944080932121909211781663143.tmp, p, --forced-package-id, 127, --min-sdk-version, 24, --target-sdk-version, 31, --version-code, 1, --version-name, 37.1.0, --no-version-vectors, -F, C:\Users\Administrator\AppData\Local\Temp\APKTOOL632521593023308607.tmp, -e, C:\Users\Administrator\AppData\Local\Temp\APKTOOL2355578712183391183.tmp, -0, arsc, -I, C:\Users\Administrator\AppData\Local\apktool\framework\1.apk, -S, H:\APK\CIAndroid_874\res, -M, H:\APK\CIAndroid_874\AndroidManifest.xml
1
2

(2.1) 原因是 AndroidManifest.xml 中包含下面标签导致的

<queries>       
     <provider android:authorities="com.facebook.katana.provider.PlatformProvider"/>
</queries>
1
2
3

由于 apktool 内部使用 aapt 来打包apk，如果内容与aapt 不兼容，那么apktool 将引发错误
解决办法：使用下面命令，指定使用 V2 签名 apktool b --use-aapt2 Test