Configure Gradle build and gradle build

Configure Gradle build and gradle build
Build basic configuration

Android Studio contains a top-level build file and a build file for each module. A build file is called build. gradle. It is a plain text file that uses Groovy syntax to configure the elements provided by the Android Gradle plug-in. In most cases, you only need to edit the module-level build file. For example, the build file of the app module of the BuildSystemExample project is as follows:

Apply plugin: 'com. android. application' Android { CompileSdkVersion 19 BuildToolsVersion "19.0.0" DefaultConfig { MinSdkVersion 8 TargetSdkVersion 19 VersionCode 1 VersionName "1.0" } BuildTypes { Release { MinifyEnabled true ProguardFiles getDefaultProguardFile('proguard-android.txt '), 'proguard-rules. Pro' } } } Dependencies { Compile project (": lib ") Compile 'com. android. support: appcompat-v7: 19.0.1' Compile fileTree (dir: 'libs', include: ['*. jar']) }

Apply plugin: 'com. android. application' is built using the Android Gradle plug-in. In this way, add a specific Android build task to the top-level build task, and use android {...} To specify specific Android build items.

Android {....} Configure all specific Android build items:

 

The compileSdkVersion item specifies the compilation target.

 

The buildToolsVersion item specifies the version of the build tool to use. Use the SDK manager to install multiple build tools.

 

Note: Always use a version that is later than or equal to the version of your compilation target SDK.

 

The defaultConfig element is dynamically configured in AndroidManifest. xml. The value in defaultConfig overwrites the value in the manifest file. The value of configuration in defaconfig config will be applied to all build variants unless the build Variant Configuration overwrites these values.

 

The buildType element controls how to build and package your applications. The default build system defines two build types: debug and release. The debug build type contains the debugging symbol and uses the debug key signature. The release build type is not signed by default. In this example, the build file is configured with the release version and the ProGuard is used.

 

The dependencies element is outside the android element and is behind the android element. This element declares the dependencies of this module. In the following sections, dependencies are included.

 

Note: When you change the build file in your project, Android Studio requires project synchronization to import and change the build configuration. Click "Sync Now" in the yellow notification bar to synchronize the changed content.

<! -- [If gte vml 1]> <v: shapetype id = "_ x1__t75" coordsize = "21600,21600" o: spt = "75" o: preferrelative = "t" path = "m @ 4 @ 5l @ 4 @ 11 @ 9 @ 11 @ 9 @ 5xe" filled = "f" stroked = "f"> <v: stroke joinstyle = "miter"/> <v: formulas> <v: f eqn = "if lineDrawn pixelLineWidth 0"/> <v: f eqn = "sum @ 0 1 0"/> <v: f eqn = "sum 0 0 @ 1"/> <v: f eqn = "prod @ 2 1 2"/> <v: f eqn = "prod @ 3 21600 pixelWidth"/> <v: f eqn = "prod @ 3 21600 pixelHeight"/> <v: f eqn = "Sum @ 0 0 1"/> <v: f eqn = "prod @ 6 1 2"/> <v: f eqn = "prod @ 7 21600 pixelWidth"/> <v: f eqn = "sum @ 8 21600 0"/> <v: f eqn = "prod @ 7 21600 pixelHeight"/> <v: f eqn = "sum @ 10 21600 0"/> </v: formulas> <v: path o: extrusionok = "f" gradientshapeok = "t" o: connecttype = "rect"/> <o: lock v: ext = "edit" aspectratio = "t"/> </v: shapetype> <v: shape id = "image _ x0020_1" o: spid = "_ x1__i1027" type = "# _ x1__t75" alt = "http://developer.an Droid.com/images/tools/as-gradlesync.png "style = 'width: 415.2pt; height: 70.2pt; visibility: visible; mso-wrap-style: square '> <v: imagedata src =" file: // C: \ Users \ SUNNYA ~ 1 \ AppData \ Local \ Temp \ msohtmlclip1 \ 01 \ clip_image001.png "o: title =" as-gradlesync "/> </v: shape> <! [Endif] --> <! -- [If! Vml] --> <! -- [Endif] -->

Figure 1. Synchronize projects in Android Studio.

 

Declare dependency

The application module in this example declares three dependencies:

... 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']) }

Each dependency is described below. The build system adds dependencies of all types "compile" to the compilation path, and finally puts them into the final package.

 

Module dependencies

The app module depends on the lib module. As described in "Open an Activity from a Library Module", MainActivity logs on to LibActivity1.

 

Compile project (": lib") declares dependency on the lib module. When you build the app module, the build system will collect the lib module.

 

Binary program dependency

The app and lib modules both use the ActionBarActivity class from the Android support library, and all these modules depend on it.

Compile 'com. android. support: appcompat-v7: 19.0.1 'Declares dependency on Android support library 19.0.1 by specifying Maven coordinates. The Android support library is available in the Android SDK repository package. If the SDK you have installed does not have this package, you can use the SDK management tool to download and install it.

 

By default, Android Studio uses Maven's central repository to configure projects. (This configuration is in the top-level build file of the project ).

 

Local Binary dependency

Some modules do not use any binary dependency of the local system. If you have a module that depends on the local binary, copy the JAR file to the <moduleName>/libs directory.

 

Compile fileTree (dir: 'libs', include :['*. jar ']) tells the build system to include the JAR file Dependencies under the app/libs Directory into the compilation path and ultimately in the final package.

 

For more Dependency information on Gradle, see Gradle's User Guide (Dependency Management Basics ).

 

Run ProGuard

The build system runs ProGuard to confuse your code during the build process. In BuildSystemExample, run ProGuard to modify the app module's build file for the release build:

... android {     ...     buildTypes {         release {             minifyEnabled true             proguardFiles getDefaultProguardFile('proguard-android.txt'),'proguard-rules.pro'         }     } } ...

GetDefaultProguardFile('proguard-android.txt ') obtains the default ProGuard settings from the installed Android SDK. You can customize ProGuard rules, Android Studio will add the module root proguard-rules.pro file to the module-specific rules.

 

Package ID: Application ID

In the Android build system, the applicationId attribute uniquely identifies an application package to be released. The Application ID is set in the android node of the build. gradle file.

apply plugin:'com.android.application'     android {         compileSdkVersion 19         buildToolsVersion "19.1"     defaultConfig {         applicationId "com.example.my.app"         minSdkVersion 15         targetSdkVersion 19         versionCode 1         versionName "1.0"     }

Note: applicationID can only be specified in the build. gradle file, and cannot be used in the AndroidManifest. xml file.

 

When using build variants, the build system allows you to specify a unique identifier for each product flavors and build types. The Application ID in build type is added to product flavors as the suffix.

productFlavors {         pro {             applicationId ="com.example.my.pkg.pro"         }         free {             applicationId ="com.example.my.pkg.free"         }     }     buildTypes {         debug {             applicationIdSuffix ".debug"         }     }     ....

The package name must still be specified in the manifest file. It is used in your source code to involve your R class and solve problems related to activity/service registration.

package="com.example.app">

Note: If you have multiple manifests (for example, a product flavor specified manifest and a build type manifest), the package name is optional among these manifests. If it is specified in these manifests, the registration must be consistent with the package name of manifest in the src/main directory.

 

For more information about the Build File and Build process, see Build System Overview.

 

Configure signature settings

Whether the debug and release versions of the app can be debugged on the security device is different from how to sign the app. The build system uses a default key to sign the debug version, and uses known certificates to avoid password prompts during the build process. The build system does not sign the release version unless you have clearly defined the signature configuration. If you do not have a release key, you can install the key described in "Signing your Applications.

 

Use build variants to work

This section describes how to build a system to help you create different versions for the same application in a project. It was useful when there was a demo and paid version, or you wanted to publish multiple APK for devices with different configurations on Google Play.

 

The build system uses product flavors to create different versions for your application. Each version may have different features and device requirements. The build system also applies build types to different builds and packages the configurations to each version. A combination of product flavor and build type forms a build variant. The build system generates different APK for each build variant.

 

Build variants

The project example contains two default build types (debug and release) and two product flavors (demo and full ).