1. Overview of multi-channel packaging

Because there are many domestic application markets, different application markets may have different statistical requirements, so Android developers need to release an installation package for each application market, which leads to Android multi-channel packaging. Add different logos in the installation package to distinguish different channels and facilitate the statistics of various effects of APP in the market.

Therefore, every time a new version is released, the market will provide a list of channels, and Android RD will generate an equal number of channel packages based on these channels. With the increasing number of channels, in order to improve the efficiency of channel packaging, research on multi-channel packaging has been born.

This article mainly summarizes the relevant knowledge of multi-channel packaging and the new and old multi-channel packaging schemes of Meituan.

Second, channel package generation

Maven-style: The build process has to be executed for every package, which is inefficient.

Apktool: Re-sign each package, although no rebuild is required;

With the increasing number of channel packages, which can take several hours at a time, the above two methods are inefficient.

For details about these two packaging methods, see: Meituan Android Automation Tour – Generate channel package

META-INFAdding an empty file

This is a new multi-channel packaging method proposed by Meituan to improve packaging efficiency, which does not need to be rebuilt or re-signed.

introduce

By decompressing apk, a meta-INF directory exists in the root directory. Add empty files to this directory without re-signing the application. Therefore, a channel can be uniquely identified by adding different empty files for different channel applications.

Specific steps

  • Use Python code to add empty channel files to APK

  • Identify channels by reading empty channel file names in Java code

The code is detailed in the link to generate multi-channel packages for Meituan above.

Walle

Walle (WALL-E) : A new generation of channel packaging under the Android Signature V2 Scheme Signature

Wall · E adds customized channel information to the Apk Signature Block in Apk to generate channel packets, thus improving the generation efficiency of channel packets. It can be used as a stand-alone tool or deployed on the HTTP server to process the network upgrade requests of channel packet Apk in real time.

The principle is introduced

Android 7.0 (Nougat) introduces a new application Signature Scheme, APK Signature Scheme V2, which is a full file Signature Scheme. It provides faster application installation time, more protection against unauthorized changes to APK files, and by default, The Android Gradle 2.2.0 plugin uses APK Signature Scheme V2 and the traditional Signature Scheme to sign your application.

The Signing information for the new app Signing scheme is stored in the APK Signing Block, Contents of ZIP entries, ZIP Central Directory and ZIP End of Central Directory are protected. Any modification after the signature cannot escape the new application signature scheme.

The previous channel package generation Scheme, which added an empty file to the meta-INF directory, is no longer available in Signature Scheme v2 because the meta-INF is protected. Adding an empty file to the META-INF scenario affects all three of the above protected blocks.

The APK Signing Block described above is not protected by the Signing rules, so Walle writes channel information by playing around with this Block.

Specific steps

  • Writing channel information to the APK Signing Block generated by the new application Signing scheme and saving it in the APK

  • The signature verification of APK during the installation process ignores the added channel information, so that the installation can be normal

  • In the running stage of App, we can find the channel information added by ourselves through the information in the structure of ZIP End of Central Directory, central Directory and so on, so as to realize the function of obtaining channel information

In the end, you just copy an APK and add a channel to the APK for each channel package, which is very fast.

use

  • Gradle plug-in for quick integration

  • Command-line interface (CLI) to maximize customized requirements

For detailed steps on the two ways to use Walle, see: Android Uses Walle Multi-channel packaging

Third, channel package adaptation

The above multi-channel packaging method solves the problem of slow packaging, but as more and more channels become available, different channels have different requirements for applications.

For example, some channels require different app names, some require apps not to use third-party statistics tools, and some require apps not to automatically update.

The previous approach was to create a Git branch for each channel that needs to be adapted, switch to the appropriate branch at release time, and merge the code from the main branch. This approach is acceptable if there are fewer channels of adaptation, but becomes undesirable as the number of channels of adaptation increases.

Fortunately, Gradle Flavor can meet the needs of channel adaptation. You only need to configure Gradle to implement multi-channel adaptation.

Flavor

Let’s start with this code in the build.gradle file:

android {
    ....

    productFlavors {
        flavor1 {
            minSdkVersion 14
        }
    }
}
Copy the code

This example defines flavor: flavor1 and specifies the minSdkVersion of the application to be 14 (additional attributes can be configured, as described in the documentation). Gradle also associates the flavor with a sourceSet. The default location is SRC /

, which in this case is SRC /flavor1.

The next step is to configure the flavor in the build.gradle file and add the necessary code and resource files based on your specific requirements. For example, run the gradle assembleFlavor1 command to generate an adaptation package. You can generate different channel packages by adapting different flavors. However, this method requires repeated compilation and construction.

Concrete example

Use different package names

productFlavors {
    qq {
        applicationId "com.hello.group.qq"}}Copy the code

The code adds a flavor named QQ and specifies the package name of the application com.hello.group.qq. Run gradle Assembleqq to generate the QQ adaptation package.

Use different app names

Gradle builds applications using resources with the same name in flavor’s sourceSet. The solution is to add a string resource of the same name to flavor’s sourceSet to override the default resource.

First, add the following flavor to the build.gradle configuration file:

android {
    productFlavors {
        wandoujia { 
        }
    }
}
Copy the code

The previous configuration defaults the SRC/Wandoujia directory to the sourceSet of the Wandoujia flavor.

Next, create wandoujia directory within the SRC directory, and add the following application name string resources (SRC/wandoujia/res/values/appname. XML) :

<resources>
    <string name="app_name">wandoujia_app</string>
</resources>
Copy the code

The default application name string resources as follows (SRC/main/res/values/strings. The XML) :

<resources>
    <string name="app_name">origin_app</string>
</resources>
Copy the code

Finally, run the gradle assembleWandoujia command to generate an application named Wandoujia_app.

The strings. XML name is not used in the Wandoujia package because files are duplicated. By default, files in the main folder are not allowed in other adaptation directories with the same file name.

For more flavor adaptation examples, see: Meituan Android Automation Tour – Adaptation Channel Package

The above is the summary of the relevant knowledge about multi-channel packaging.

In order to implement the needs of more customized multi-channel packages, it is necessary to know more about Gradle.