[Turn] gradle hits packages of different channels

Meituan Android Automation Tour - Adapting Channel Package
zhihu ·2014-09-01 16:06
Overview
Basically solved the problem of slow packaging.

However, as there are more and more channels, different channels have different requirements for applications. For example, some channels require the app of the Meituan client to be named Meituan, and some channels require the app to be named Meituan. For another example, some channels require applications not to use third-party statistical tools (such as flurry). In short, each package needs to adapt to these channels.

The previous practice was to create a Git branch for each channel that needs to be adapted, switch to the corresponding branch when the version is released, and merge the code of the main branch. This method is acceptable if there are few adaptation channels. If there are many branches, it will be a nightmare for developers. Fortunately, since the Gradle flavor, everything has become easier. This article assumes that the reader has used Gradle. If you don't understand it, it is recommended to read the relevant documentation first.

Flavor
first look at a piece of code in the build.gradle file:

android {
    ....

    productFlavors {
        flavor1 {
            minSdkVersion 14
        }
    }
}
The above example defines a flavor: flavor1, and specifies that the minSdkVersion of the application is 14 (of course, more properties can be configured, please refer to the relevant documents for details). At the same time, Gradle will also associate the corresponding sourceSet for the flavor. The default location is the src/<flavorName> directory, which corresponds to src/flavor1 in this example.

Next, all you have to do is configure flavors in the build.gradle file according to your specific needs, and add the necessary code and resource files. Take flavor1 as an example, run the gradle assembleFlavor1 command to generate the required adaptation package. The following mainly introduces some adaptation cases of the Meituan group buying Android client.

Case
Using different package names
Meituan previously had two versions of the Android client: mobile version (com.meituan.group) and hd version (com.meituan.group.hd). The two versions use different codes. At present, the code corresponding to the hd version is no longer maintained, and I hope to use the code of the mobile version directly. There are many ways to solve this problem, but using flavors is relatively simple, an example is as follows:

productFlavors {
    hd {
        applicationId "com.meituan.group.hd"
    }
}
The above code adds a flavor named hd and specifies The package name of the application is com.meituan.group.hd, and the hd adaptation package can be generated by running the gradle assembleHd command.

Controls whether to update automatically
The Meituan-buy Android client will check whether the client has an update by default when it is launched, and if there is an update, it will prompt the user to download it. However, some channels and app markets do not allow this default behavior, so you need to disable the automatic update function when adapting to these channels.

The solution is to provide a configuration field, and the value of this field is checked when the application starts to determine whether to enable the automatic update function. Using flavor can perfectly solve this kind of problem.

Gradle will generate a BuildConfig.java file for the flavor in the generateSources phase. The BuildConfig class provides some constant fields by default, such as the version name of the application (VERSION_NAME), the package name of the application (PACKAGE_NAME), and so on. Even more powerful, developers can also add custom fields. The following example assumes that the wandoujia marketplace disables automatic updates by default:

android {
    defaultConfig {
        buildConfigField "boolean", "AUTO_UPDATES", "true"
    }

    productFlavors {
        wandoujia {
            buildConfigField "boolean", "AUTO_UPDATES", "false"
        }       
    }

}
The above code will generate the AUTO_UPDATES boolean constant in the BuildConfig class, the default value is true, when using the wandoujia flavor, the value will be set to false. Next, you can use the AUTO_UPDATES constant in the code to determine whether to enable the automatic update function. Finally, run the gradle assembleWandoujia command to generate a channel package that does not enable the automatic upgrade function by default. Isn't it very simple.

Using a different application name
The most common type of adaptation is modifying the application's resources. For example, the app name of the Meituanbuy Android client is Meituan, but some channels need to change the app name to Meituanbuy; in addition, the client often cooperates with some application distribution markets, which needs to be added to the startup interface of the application. There are many similar forms of adaptation for logos on third-party markets.
When Gradle builds an application, it will preferentially use the resource of the same name in the dataSet to which the flavor belongs. Therefore, the solution is to add a string resource with the same name to the flavor's dataSet to override the default resource. The following is an example of an application called Meituan Group that adapts to the wandoujia channel.

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

android {
    productFlavors {
        wandoujia {
        }
    }
}
The above configuration will default the src/wandoujia directory to the dataSet of the wandoujia flavor.

Next, create the wandoujia directory in the src directory, and add the following application name string resource (src/wandoujia/res/values/appname.xml):

<resources>
    <string name="app_name">Meituan Group Purchase</string>
</resources>
The default application name string resource is as follows (src/main/res/values/strings.xml):

<resources>
    <string name ="app_name">Meituan</string>
</resources>
Finally, run the gradle assembleWandoujia command to generate an application named Meituan Group Purchase.

Using third-party SDKs
Some channels require clients to embed third-party SDKs to meet specific adaptation requirements. For example, the 360 ​​application market requires Meituan Group to use the SDK provided by them for the boutique application modules of the Android client. The difficulty of the problem is how to add the SDK only for a specific channel, and other channels do not introduce the SDK. Using flavor can solve this problem very well. The following is an example of introducing com.qihoo360.union.sdk:union:1.0 SDK for qihu360 flavor:

android {
    productFlavors {
        qihu360 {
        }
    }
}
...
dependencies {
    provided 'com. qihoo360.union.sdk:
    qihu360Compile 'com.qihoo360.union.sdk:union:1.0'
}
The above example adds a flavor named qihu360, and specifies that both compilation and runtime depend on com.qihoo360.union.sdk:union:1.0. Other channels only rely on the SDK at build time, and will not add it when packaging.

Next, you need to use reflection technology in the code to determine whether the SDK has been added to the application, so as to decide whether to display the boutique applications provided by the 360 ​​SDK. Part of the code is as follows:

class MyActivity extends Activity {
    private boolean useQihuSdk;

    @override
    public void onCreate(Bundle savedInstanceState) {
        try {
            Class.forName("com.qihoo360.union.sdk.UnionManager");
            useQihuSdk = true;
        } catch (ClassNotFoundException ignored) {

        }
    }
}
Finally, run the gradle assembleQihu360 command to generate the channel package containing the 360 ​​boutique application modules.

Summarize
Adaptation is a dirty job, especially when there are many adaptation channels. The above introduces several examples of using Gradle flavor for adaptation, which basically solves the complicated adaptation work.