Gradle Introduction
Gradle is an advanced build toolkit that makes it easy to manage dependent packages and define your own build logic. In the end how advanced, Android Studio official integration Gradle,google also specifically wrote the Android Plugin for Gradle, you feel it.
Basic Configuration
There is a top-level Build.gradle file in Android Studio, and each module has its own build.gradle. This file is a configuration file that uses groovy syntax and Android Plugin for gradle elements. Usually we just need to modify the module's build file. Here's a simple example.
apply plugin: ‘com.android.application‘android { compileSdkVersion 19 buildToolsVersion "19.0.0" defaultConfig { applicationId "com.example.my.app" minSdkVersion 8 targetSdkVersion 19 versionCode 1 versionName "1.0" } buildTypes { release { minifyEnabled true proguardFiles getDefaultProguardFile(‘proguard-android.txt‘), ‘proguard-rules.pro‘ } }}dependencies { // Module dependency compile project(":lib") // Remote binary dependency compile ‘com.android.support:appcompat-v7:19.0.1‘ // Local binary dependency compile fileTree(dir: ‘libs‘, include: [‘*.jar‘])}
The first sentence of apply plugin: ' com.android.application ' instructions in this build file using Android plugin for Gradle, with this sentence, The elements that target Android are meaningful. such as Android {...} This is the option to configure all of the Android project build.
- compilesdkversion: compile-time SDK version
- buildtoolsversion: version of the build tool
- Defaultconfig: dynamically in the build Configuration Androidmanifest.xml project, defaultconfig configuration can override the configuration in the manifest.
- buildtypes: Configure how you build and package your app, with debug and release two types by default. The debug type contains information when debugging and has the debug key signature. Release defaults to no signature. In this example, the release version uses Proguard.
- dependencies: on android {...} The dependency of this module is configured outside of this element.
Depend on
dependencies { // Module dependency compile project(":lib") // Remote binary dependency compile ‘com.android.support:appcompat-v7:19.0.1‘ // Local binary dependency compile fileTree(dir: ‘libs‘, include: [‘*.jar‘])}
- Module Dependency: Compile Project (": Lib"), indicating that this module relies on the Lib module, the system will include the Lib module in the compile time
- Remote binary dependencies: compile ' com.android.support:appcompat-v7:19.0.1 ', which defaults to downloading the appropriate dependencies from MAVEN central repository when there is no local dependency. From where to download can be configured in the top-level build file.
- * Local binary dependencies: **compile filetree (dir: ' Libs ', include: ['. Jar ']), copy the jar package to the/libs folder, compile Filetree (dir: ' Libs ', Include: [' *.jar ']) means that all jar packages under App/libs are included in the
Proguard
Proguard's role is to analyze and optimize your app at the byte level, making your app smaller and faster. It is worth mentioning that when you use certain open source projects, they will remind you to exclude some of the packages in Proguard, to prevent errors.
android { ... buildTypes { release { minifyEnabled true proguardFiles getDefaultProguardFile(‘proguard-android.txt‘), ‘proguard-rules.pro‘ } }}
getdefaultproguardfile (' Proguard-android.txt ') obtains the default Proguard configuration. Each module also has a module-level Proguard rule, in Proguard-rules.pro This file, of course you can also configure Proguard rules. For detailed configuration of Proguard, please refer to Proguard Manual
Application ID
The application ID is used to uniquely identify the app to be released. Set in Build.gradle.
defaultConfig { applicationId "com.example.my.app" minSdkVersion 15 targetSdkVersion 19 versionCode 1 versionName "1.0" }
The system allows you to set different IDs for different product types, such as the free and premium editions.
productFlavors { pro { applicationId = "com.example.my.pkg.pro" } free { applicationId = "com.example.my.pkg.free" } } buildTypes { debug { applicationIdSuffix ".debug" } }
Configuring signatures
The difference between the debug version and release version is whether Debug and apk can be signed on a secure device. In the debug version, the system provides a default key to sign and a known certificate to authorize the app, avoiding password prompts at build time. However, in release release, the system will not build this goal unless you provide a key voluntarily.
Release Signature Step
- Create a KeyStore. KeyStore is a binary file that contains a series of private keys that must be stored properly.
- Create a private key. A private key represents an app entity.
- Configuring in the Build file
android { ... defaultConfig { ... } signingConfigs { release { storeFile file("myreleasekey.keystore") storePassword "password" keyAlias "MyReleaseKey" keyPassword "password" } } buildTypes { release { ... signingConfig signingConfigs.release } }}
4. Launch Assemblerelease in Android Studio. app/build/apk/app-release.apk This file is the APK that contains your release key. Note: Passwords are not normally written directly in the build file, and the password information can be written in the environment variable
storePassword System.getenv("KSTOREPWD")keyPassword System.getenv("KEYPWD")
or enter it with the command line
storePassword System.console().readLine("\nKeystore password: ")keyPassword System.console().readLine("\nKey password: ")
Configuring Signatures in Android Studio
- In the menu bar, click Build > Generate signed APK.
- In the pop-up window, click Create New
- Fill in the relevant information
- Build Type Select Release
So far, you can go to the app market and launch your app ^_^
Build variable definition Productflavors
Sometimes you need to publish different versions of the same app, such as the free version, the paid version, and so on. Then you need to use the productflavors.
android { ... defaultConfig { ... } signingConfigs { ... } buildTypes { ... } productFlavors { demo { applicationId "com.buildsystemexample.app.demo" versionName "1.0-demo" } full { applicationId "com.buildsystemexample.app.full" versionName "1.0-full" } }}
The configuration in the productflavors will overwrite the configuration in the Defaultconfig, as configured above, the system will use a different ID for each different version.
Add a corresponding resource to each version
When you have different versions, there must be different versions, so you need to add different resources. In the demo version, for example, create the following directory under the SRC directory
Add the required activity,string.xml and other resources to the corresponding folder. The following four build variables can be seen in the build Variants window on the left side of the IDE
This way you need to choose the right version.
At last
See here, again open build.gradle This file is not feeling also not so complicated? Are you more in love with Android studio? If you have any questions welcome the message to discuss. If you like, don't forget to have a "top"? (^∀^)?
Reprint Please specify: Android development Chinese Station» about Gradle in Android Studio, all you need to know is here.
All you need to know about Gradle in Android Studio is here.