Apk secondary packaging to modify package name and configuration

Apk secondary packaging to modify package name and configuration

Purpose of apk secondary packaging:
When there are multiple channels, each channel requires different package names, icons, AndroidManifest.xml configuration, channel information, configuration files, etc.

Option 1:
Package multiple times, and modify different configurations according to the channel before each package.
Disadvantages: Package takes too long, and any modification requires re-packaging, which is inefficient.

Option 2:
Package an apk, decompile the apk,
modify the package name, icon, AndroidManifest.xml configuration AndroidManifest.xml file and other
resources in the StreamingAssets folder in the Unity directory. The decompilation generated path can be found in the assets file, so different channels The configuration can also be placed in the StreamingAssets folder and replaced according to the channel after decompilation.
Recompile into apk
and re-sign the recompiled apk (it cannot be installed normally on Android devices or emulators without re-signing)

One: The decompilation tool apktool
download address: https://apktool.org/
There are jars for Windows, Linux, and Mac platforms respectively. Let’s take
Windows as an example. Open the URL and select Install to download according to your own environment. Configure and

download according to the above steps , configure the environment variables, open the CMD command and enter apktool, if the apktool version and other information can be output, the configuration is successful. Two :

Pack apk
(1) Generate keystore files, use Keytool tools, AndroidStudio, Unity, etc. .apk

Three: Decompilation
(1) Open the CMD command in the Test.apk directory, or open the CMD command cd to this directory and
enter the command: apktool d Test.apk
to generate a Test folder in the same level directory as Test.apk, and store it for decompilation The output of the file is as follows.

The generated directory

original\META-INFis as follows. The original signature information is stored in the folder, which
apktool.ymlis the file generated after decompilation.

(2) You can also add parameters to the command, as follows:
apktool d -o output_dir Test.apk
-o output_dir means to store the decompiled files in the output_dir directory.
For more parameters, check the documentation by yourself

Four: Modify the configuration
(1) Modify the package name:
(1.1) Open with a text editor. AndroidManifest.xmlSearch package and modify the package name package="com.abc.def"
(1.2) Open. apktool.ymlThe content is roughly as follows.

The search renameManifestPackagedefault value is null, and the assigned value is the new package name com.abc.def.
renameManifestPackage: com.abc.def

(2) AndroidManifest.xml Add tag
Open Add AndroidManifest.xmlin<application> </application>

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

Five: Recompile the Test folder into apk
(1) Enter the command: apktool b Test
the generated apk is stored in Test\dist\Test.apk
(2) You can also add parameters in the command as follows
apktool b -o output_dir\new.apk Test
-o output_dir\new.apkto store the compiled apk in the directory, and the recompiled apk is named new. The apk
recompiled at this time Test.apkis unsigned and cannot be installed normally on Androidthe device and simulator. It needs to be Test.apkre-signed.

Six: Re-sign the apk
(1) Signing tool:
Jarsigner: It is a general tool provided by JDK for signing jar packages. It is located at: It is a special tool JDK/bin/jarsigner.exe
Apksignerofficially provided by Google for signature and verification. It is located at Other signing tools, etc.android apkAndroid SDK/build-tools/SDK版本/apksigner.bat

(2) There are two labels for apk signatures
: V1 signature: (Jar Signature)
V2 signature: (Full APK Signature)
Android 7.0For the following versions, only the old signature scheme can be used. V1 scheme (JAR signing)
From Android 7.0the beginning, Google added a new signature scheme. V2 Scheme (APK Signature)
Note:
V2 signature has obvious advantages. apksignerThe tool uses both V1 and V2 signatures by default for compatibility. Android 7.0following version. JDK、SDKTools must be selected under the path used when generating apk to avoid failure due to tool version issues.
For this reason I choose to use apksigner for signing.

(3) Signature command:

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

apksigner Here is a simplified path. In actual application, it is necessary to apksigner change apksigner所在路径\apksignerthe position to six (1) and write the
sign apk signature. The file "unity"
--ks H:\APK\unity.keystoreused for signature is the alias of the keystore file and the password of the keystore alias file (123456) (generally and alias Use the same password to generate) apk that needs to be signedkeystore
--ks-key-alias unity
--ks-pass pass:123456keystore
H:\APK\Test\dist\Test.apk

If successful after executing the command, there will be two files Test.apk and Test.apk.idsig in the same directory as Test.apk.
Test.apk is already a signed file and can be installed and used normally.

Seven: Optimize zipalign
official documentation: https://developer.android.google.cn/studio/command-line/zipalign?hl=zh-cn
(1) zipalign is an ziparchive file alignment tool that helps ensure that archive files are All uncompressed files are aligned relative to the beginning of the file. In this way, you can access these files directly through mmap(2) without copying the data in RAM and reduce the memory usage of the application. To put it bluntly, it is an optimization of the apk running memory usage.

(2) Use zipalign for optimization before distributing the APK file to end users. This is done automatically if you build from Android Studio using the Android Gradle Plugin (AGP). In this case, you should still use zipalign to verify that the APK is aligned, but you don't need to align it. This document is primarily intended for maintainers of custom build systems

(3) Note:
(3.1) You must use it at a specific point in the build process zipalign. The timing depends on the app signing tool you use:

(3.2) If you are using apksigner, you must use it before signing the APK file zipalign. If you apksigner make further changes to the APK after using Signed APK, the signature will become invalid.

(3.3) If you are using jarsigner(not recommended) you must use after signing the APK filezipalign

(4) Usage
(4.1) If your APK contains shared libraries ( .sofiles), use -pto ensure that they are aligned with 4KiB page boundaries suitable for mmap(2). For other files whose alignment is determined by zipalign's required alignment parameter, Android Studio will align to 4 bytes on both 32-bit and 64-bit systems.

zipalignTools are in the SDK directorySDK\build-tools\版本号

(4.2) If you need to align infile.apk and save it as outfile.apk, please run the following command.
zipalign -p -f -v 4 infile.apk outfile.apk
If the output outfile.apk is successfully aligned, output at the end of the output command:Verification succesful

(4.3) To confirm the alignment of existing.apk, please use the following command.
If you are building with Android Studio or AGP, you should use this command to verify that the APK is aligned.
zipalign -c -v 4 existing.apk
If existing.apk is not aligned, output at the end of the output command: Verification FAILED
If existing.apk is aligned, output at the end of the output command:Verification succesful

Eight: Encountered errors
(1) After the re-signed apk is installed, the operation crashes. First, check whether there are any missing steps ( 1.1
) . Do not filter the information, but look at all the output, because some information may not be visible after filtering, because there are many logs, you need to check carefully) (1.3) Running crashes, you can see the following logs through Logcat
adbLogcat

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

Reason: I am using the Android emulator on Windows, which is x86_64environment. Because I only checked it when packaging the apk ARMv7、ARM64, the emulator uses libhoudini.sothis library to simulate the execution arm of the code. In some cases, there is no problem, but in some cases There will indeed be problems. The Test.apk I generated with Unity did not check x86 related, but it can run normally. When packaging, choose: x86(Chrome OS)、 x86-64(Chrome OS)
Repackage the apk and re-execute all the above processes.

(2) Recompiling and executing apktool bthe command to generate apk failed, and the error was reported as follows

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

(2.1) The reason is that AndroidManifest.xmlthe following tags are included in

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

Since apktool it is used internally aapt for packaging apk, if the content is aapt incompatible withapktool
apktool b --use-aapt2 Test