Gradle practice: Multi-Channel packaging solution for Android, gradleandroid

Gradle practice: Multi-Channel packaging solution for Android, gradleandroid

View Original: http://blog.csdn.net/u010818425/article/details/52319382
Gradle practice series:
Gradle basic knowledge points and common configurations
Gradle practice: coexistence of devices with different compilation types
Gradle practice: Release the aar package to the maven Repository
Gradle practice: executing SQL operations on hive Databases

This article will continue the style of previous blogs and start with the basic concepts, which helps us to understand the latter. If we forget the specific meaning of a concept in the subsequent code, you can review the concepts in the header.
This article first introduces in detail the implementation principle of the general batch packaging solution, then introduces the basic implementation principle of Meituan batch packaging, and references several implementation schemes for your reference.

1. Introduction to Basic Concepts 1. package

• Package name in AndroidManifest File

  <manifest xmlns:android="http://schemas.android.com/apk/res/android"    package="com.company.appname"    android:versionCode="1"    android:versionName="1.0" >

  The package name has two functions:
  1. The unique identifier of the application on the device and the unique identifier in the application market;
  Second, the package used to name your resource class (and the class name used to parse any related Activity), suchcom.company.appname.R

2. PlaceHolder

• In the AndroidManifest file${PlaceHolder}It indicates that PlaceHolder is a variable that can be assigned a value, such as the Channel in umeng statistics:

  <meta-data    android:name="UMENG_CHANNEL"    android:value="${UMENG_CHANNEL_VALUE}"></meta-data>

3. applicationId

• Corresponding to package in AndroidManifest

  android {    defaultConfig {        applicationId "com.company.appname"    }}

4. buildTypes

• Used to generate packages of different compilation types, such as debug and release packages

  android{    buildTypes {        debug {            ...        }        release {            ...        }    }}

  Debug and release are the two build types that gradle comes with by default. In the BuildConfig automatically generated by the project, the differences are as follows:

  // The BuildConfig feature information generated by release is public final class BuildConfig {public static final boolean DEBUG = false; public static final String BUILD_TYPE = "release ";} // BuildConfig feature information generated by the debug version public final class BuildConfig {public static final boolean DEBUG = true; public static final String BUILD_TYPE = "debug ";}

• Customize different build types, such

  android{    buildTypes {        debug {            ...        }        release {            ...        }        beta {            ...        }    }}

5. productFlavors

• Used to generate packages of different channels

  Android {productFlavors {xiaomi {} baidu {} wandoujia {} _ 360 {} // or "360" {} ", the number must start with an underscore or be enclosed in double quotation marks }}

  Run./gradlew assembleRelease, The release package of all channels will be printed;
  Run./gradlew assembleWandoujiaThe release and debug packages of the pea pod channel are displayed;
  Run./gradlew assembleWandoujiaReleaseThe release package of the pods will be generated.
  Therefore, you can combine buildType and productFlavor to generate different Build Variants, that is, different combinations of types and channels.

6. signingConfigs

• Signature configuration. The configuration of the release compilation type is as follows:

  Release {storeFile file (".. /yourapp. keystore ") // signature certificate file storePassword" your password "// signature certificate password keyAlias" your alias "// alias keyPassword" your password "// alias password}

  Of course, the signature information can be hidden by reading the configuration file (see the previous article) and the configuration file ignore, which is not described in this article.

7. META-INFFile

• Used to store some information about the signature, add an empty file in the META-INF directory, the application does not need to re-sign.

Ii. Multi-Channel packaging Configuration 1. General packaging Solution

// Generate the package time def releaseTime () {return new Date (). format ("yyyy-MM-dd", TimeZone. getTimeZone ("UTC")} android {compileSdkVersion 23 buildToolsVersion "23.0.3" defaultConfig {applicationId "com. company. appname "minSdkVersion 15 targetSdkVersion 23 versionCode 1 versionName" 1.0 "// The default channel is manifestPlaceholders = [UMENG_CHANNEL_VALUE:" official "]} lintOptions {checkReleaseBuilds false abortOnError fa Lse} // configure the compiled jdk version compileOptions {sourceCompatibility org. gradle. api. javaVersion. version_00007 targetCompatibility org. gradle. api. javaVersion. version_00007} // signature configuration signingConfigs {debug {// No debug config storeFile file ("$ {rootDir}/keystores/xqsg_debug.jks ") // debug certificate} release {storeFile file ("$ {rootDir}/keystores/xqsg. jks ") // release certificate storePassword" test "// signature certificate password keyAlias" test "// alias keyPas Sword "test" // alias password }}buildtypes {debug {buildConfigField ("boolean", "LOG_ON", "true ") // use the compile type to configure the log switch versionNameSuffix "-debug" // The package name suffix is "-debug" minifyEnabled false // whether to confuse zipAlignEnabled false // Zipalign to optimize shrinkResources false // remove useless resource file signingConfig signingConfigs. debug // use debug Certificate Signature} release {buildConfigField "boolean", "LOG_ON", "false" // Log minifyEnabled true // enable obfuscation zipAlig NEnabled true // enable Zipalign to optimize shrinkResources true // Remove useless resource files. This option takes effect only when obfuscation is enabled. proguardFiles getdefaproproguardfile('proguard-android.txt '), 'proguard-rules. pro 'signingconfig signingConfigs. release // use the release certificate signature // configure applicationVariants in multi-channel packaging. all {variant-> variant. outputs. each {output-> def outputFile = output. outputFile if (outputFile! = Null & outputFile.name.endsWith('.apk ') {// The output apkname is test_v1.0_2016-08-15_wandoujia.apk def fileName = "outputs" output. outputFile = new File (outputFile. parent, fileName) }}}// configure productFlavors {wandoujia {}_ 360 {} baidu {} xiaomi {}} productFlavors. all {flavor-> flavor. manifestPlaceholders = [UMENG_CHANNEL_VALUE: name] // dynamically modify the channel name in AndroidManifest }}

Note: The preceding log switch can be used to obtain the variable value in java code, for example:

if(BuildConfig.LOG_ON){    Log.d("test","xxx");    }

2. Meituan packaging Solution

Implementation principle: the apk file of the Android application installation package is a compressed file. You can change its suffix to zip to decompress it directly. Decompress the package and you will find that there is a META-INF directory under the root directory. If you add an empty file in the META-INF directory, the application does not need to be signed again. Therefore, you can add different Empty files to applications of different channels to uniquely identify a channel.
In this way, every time you type a channel package, you only need to copy an apk and add an empty file named by channel number in the META-INF.

• Meituan Android automation tour-channel package generation
• Meituan Android automation tour-channel package adaptation
• Implementation reference 1
• Implementation Reference 2

In-depth study of Android Studio series tutorial 6-Gradle multi-channel packaging Android product development (5)-> multi-channel packaging more convenient Android multi-channel packaging Android package series-multi-channel Fast Packaging

View Original: http://blog.csdn.net/u010818425/article/details/52319382