Shulou(Shulou.com)06/02 Report--

What this article shares to you is about the daily development skills of Gradle, which the editor thinks is very practical, so I share it with you to learn. I hope you can get something after reading this article.

Gradle is the default build system in Android Studio. Gradle uses Groovy as the main scripting language. The build.gradle file in the build.gradle and APP Moudle of our app project is a Groovy class. Next, let me introduce the basic functions and advanced skills of Gradle.

Basic usage

Apply plugin: 'com.android.application' android {compileSdkVersion 26 buildToolsVersion "26.0.0" defaultConfig {applicationId "com.renny.gradletest" minSdkVersion 17 targetSdkVersion 26 versionCode 1 versionName "1.0" testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"} buildTypes {release {minifyEnabled false proguardFiles getDefaultProguardFile (' proguard-android.txt') 'proguard-rules.pro'} dependencies {compile fileTree (dir:' libs', include: ['* .jar']) androidTestCompile ('com.android.support.test.espresso:espresso-core:2.2.2', {exclude group:' com.android.support' Module: 'support-annotations'}) compile' com.android.support:appcompat-v7:26.+' compile 'com.android.support.constraint:constraint-layout:1.0.2' testCompile' junit:junit:4.12'}

The above code is the build.gradle in the default Module we created when studio just built the Android project, and the Gradle version is 2.3.3. And most of the functional configuration of Gradle is also implemented in a file.

Apply plugin:: is used to specify which plug-in is used. Common values in development are

'The com.android.application':Android APP plug-in (packaged with .apk files)

'The com.android.library':Android library plug-in (packaged with a .aar file)

'java': normal java plug-ins (packaged with .jar files)

Android {} is used to specify the relevant properties of the Android packaging plug-in, which contains the following nodes

CompileSdkVersion (apiLevel): sets the version of Android to use when compiling

BuildToolsVersion (buildToolsVersionName): sets the version of the build tool used at compile time

DefaultConfig: set some default properties, and the available properties are the sum of buildTypes and productFlavors. (not in the productFlavors default file, which will be described later)

BuildTypes: configure the build type, and you can type different types of packages. The common ones are debug and release. Of course, you can add N more.

ProductFlavors: configure different styles of APP, and let each type of APP have different styles on the basis of buildTypes, so the final number of APK that can be typed is buildTypes multiplied by productFlavors. The name of the built variable is productFlavors+buildTypes.

Dependencies: configuration dependency, which must be the most convenient place to switch from eclipse to studio. All kinds of external dependencies are done directly with one line of code, instead of relying on packages manually.

Where compile fileTree (dir: 'libs', include: [' * .jar']) means relying on all the jar files in the libs directory.

Advanced usage

Well, the basic configuration above is just a simple use of Gradle. In fact, we can play a lot of tricks with Gradle.

Manifest dynamic configuration

Many third-party SDK needs to configure some of your key information in AndroidManifest.xml. Take Youmian push as an example:

But the key is different for different test packages and official packages, so you can modify it like this:

Then add different information to each version of productFlavors, so that different packages you type will use different appkey.

ManifestPlaceholders = [UMENG_CHANNEL: "0", UMENG_APPKEY: "123456789"]

Not only the custom metadata can be configured dynamically, but also the tags such as android:icon,android:label can be modified, so that different packages have different icons, which is easy to distinguish.

Moudle dynamic dependency

In the modular app, we may need to rely on different components in the test package and the formal package. For example, the test environment requires debugging modules, but the formal environment does not. If the productFlavors is as follows, the debug module name is module-test.

ProductFlavors {ceshi {} publish {}}

Then you can rely on the test module in dependencies:

CeshiCompile project (': module-test')

BuildTypes is also applicable, and the two can be used together or separately:

DebugCompile project (': module-test') ceshidebugCompile project (': module-test')

Read variables in code

The above features are configured separately by gradle, but we often have different requirements that need to be reflected in the code for different build packages: log printing, Toast, and so on.

Although the BuildConfig.DEBUG field can be judged, we can use buildConfigField to pass custom values to the code, such as different construction packages require different api addresses at the beginning of Host, different https certificate paths, etc. The usage is as follows:

BuildConfigField 'type',' name','"vaule"'

For example:

DefaultConfig {buildConfigField 'String',' author','"renny"}

The above is added to defaultConfig, while adding to buildTypes or productFlavors will have different values in different build versions. If you configure a different applicationId, you can install different builds of applications on the same phone at the same time.

ProductFlavors {ceshi {applicationId "com.renny.test" buildConfigField "String", "API_TEST", "http://test.renny.com/android"} publish {applicationId" com.example.publish "buildConfigField" String "," API_PUBLISH "," http://publish.renny.com/android"}}

After the above introduction, you may find that the definitions of buildTypes and productFlavors are very similar, but the difference between them is that changing buildType will not change the code of the application. They just deal with different things. You can get more technical details through buildType (for example, build optimization,log level, etc.), but the content of app will not change. On the contrary, the content of app can be changed by using productFlavor configuration (ps: content can be understood as package). BuildType cannot change applicationId).

Gradle task

Gradle task is suitable for performing repetitive manual tasks that are both tedious and error-prone, such as batch modification, copying, and renaming files.

For example, the task of applicationVariants.all can set various properties for each build, such as modifying the apk name generated by each build:

ApplicationVariants.all {variant-> variant.outputs.each {output-> output.outputFile = new File (output.outputFile.parent, ("app-$ {variant.buildType.name}" + "-" + new Date (). Format ('yyyyMMdd') + ".apk") .toLowerCase ()}}

Gradle will by default match the build version of each productFlavors*buildTypes, which you can do if you want to skip several of them:

VariantFilter {variant-> if (variant.buildType.name.equals ('release')) {variant.setIgnore (! variant.getFlavors (). Get (1). Name.equals (' ceshi'));} if (variant.buildType.name.equals ('debug')) {variant.setIgnore (variant.getFlavors (). Get (1). Name.equals (' ceshi')) }} these are the daily development skills of Gradle, and the editor believes that there are some knowledge points that we may see or use in our daily work. I hope you can learn more from this article. For more details, please follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.