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

This article introduces the relevant knowledge of "how to configure Android Gradle". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Gradle file in AndroidStudio

If we create a new Android project, AndroidStudio will default that we generate the following files, Project build file, Module build file, Project configuration file, obfuscation rule file, etc., so what are the functions of these files, and how can we configure them?

Settings.gradle

Include': app'

For a new project, there is only the above statement by default, which is used to indicate which modules Gradle should include when building the application. For most projects, there may be only one item in this file, but when we introduce other functional module, or business logic module, in our project, we need to add the corresponding module in the include statement.

Build.gradle

There are two build files, one for our Module and one for Project.

In Project, the following configuration is generated by default

/ / Top-level build file where you can add configuration options common to all sub-projects/modules. Buildscript {repositories {jcenter ()} dependencies {classpath 'com.android.tools.build:gradle:2.2.3' / / NOTE: Do not place your application dependencies here; they belong in the individual module build.gradle files}}

In the build file of Project, we can add some configurations common to the sub-module without having to configure them separately in each sub-module. Can rely on whether the warehouse is jcenter or other dependent repositories, etc. What is generated by default in module is some of the configuration options that are made when our module itself is built.

Gradle.properties

For the configuration file of gradle, you can define some constants for build.gradle to use, such as version number, as our business grows, the build file will become larger and the maintainability will become worse, when we want to modify some content, we need to find it one by one, but when we put some of the configuration constants in a separate file, the maintainability has been improved compared to before. We can add some information such as building the SDK version to this file.

COMPILE_SDK_VERSION = 23BUILD_TOOLS_VERSION = 23.0.1VERSION_CODE = 1

We can then refer to it in the build file. Reference method, directly through the variable name.

Configuration construction

Build type

Build types define some of the properties that Gradle uses when building and packaging your application, which are typically configured for different phases of the development lifecycle. For example, debug build types support debug options, signing APK; with debug keys, while publishing build types can compress, obfuscate APK, and use release keys to sign APK for distribution. You must define at least one build type to build the application-- Android Studio creates debug and release build types by default. To start applying custom packaging settings, learn how to configure the build type.

Default build method

DefaultConfig {applicationId "com.chenjensen.gradlelearn" minSdkVersion 14 targetSdkVersion 24 versionCode 1 versionName "1.0" testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"}

We can do things according to our own needs, such as obfuscation only for the released version, but not for the debug version, we can configure it in buildType.

BuildTypes {release {minifyEnabled false proguardFiles getDefaultProguardFile ('proguard-android.txt'),' proguard-rules.pro'} debug {}}

Product flavor

Product flavor represents different versions of applications that you can release to users, such as free and paid versions. You can customize the product flavor to use different codes and resources, while sharing and reusing parts common to all application versions. The product flavor is optional and you must create it manually. We can configure the settings we need in the productFlavors {} code block. The product flavor supports the same attributes as defaultConfig because defaultConfig actually belongs to the ProductFlavor class. This means that you can provide the basic configuration of all flavors in the defaultConfig {} code block, and each flavor can replace any default value, such as applicationId.

ApplicationId is used as the package name of our APK to distinguish between different packages. The package field in manifest is used to name the package name of the resource class. The generated R class file is located under this package. If the code in other packages needs to refer to resources, you can call it through this path.

For example

ProductFlavors {demo {applicationId "com.example.myapp.demo" versionName "1.0-demo"} full {applicationId "com.example.myapp.full" versionName "1.0-full"}}

Through the configuration of product flavor, we can release different application packages for different application markets, and we can refine the configuration to specific SDK versions for different application packages. The use of different application market distribution allows us to collect download rates according to different markets.

Dependency item

The build system manages project dependencies from your local file system as well as from remote stores. This eliminates the need to manually search, download binary packages for dependencies, and copy them into the project directory.

There are three ways to add dependencies in Android

/ / rely on our local module compile project (": mylibrary") / / remote binary dependency compile 'com.android.support:appcompat-v7:25.1.0' / / Local binary dependency mode We will detect the jar file compile fileTree (dir: 'libs', include: [' * .jar']) / javaTest dependency testCompile 'junit:junit:4.12' / / AndroidTest dependency androidTestCompile' com.android.support.test.espresso:espresso-core:2.2.2' in our local libs

When we add a dependency, the dependency also depends on other dependencies, and we want to remove one of the dependencies. The compile method can accept a closure parameter, which we can use to remove some of the dependencies.

AndroidTestCompile ('com.android.support.test.espresso:espresso-core:2.2.2', {exclude group:' com.android.support', module: 'support-annotations'})

Through compile configuration, Gradle adds the dependencies of this configuration to the classpath and the applied APK. In addition to the compile configuration, there is also apk,provided.

Apk

Specify the runtime-only dependencies that Gradle needs to package with the application's APK. You can use this configuration with JAR binary dependencies, not with other library module dependencies or AAR binary dependencies.

Provided

Specifies compile-time dependencies that Gradle does not package with the applied APK. If you do not need this dependency at run time, this will help reduce the size of the APK. You can use this configuration with JAR binary dependencies, not with other library module dependencies or AAR binary dependencies.

Sign

The build system can specify signing settings in the build configuration and automatically sign your APK during the build process. The build system signs the debug version with the default key and certificate of known credentials to avoid prompting for a password at build time. Unless the signing configuration is explicitly defined for this build, the build system does not sign the release version. If no key is issued, one can be generated as described in the signing application. Because debug certificates are created by build tools and are not safe in design, most application stores (including Google Play stores) do not accept the use of debug certificates to sign APK for release.

Signed application

Application upgrade: when the system installs an update of the application, it compares the certificate in the new version with the existing version. If the certificates match, the system allows updates. If you sign the new version with a different certificate, you must assign another package name to the application-in this case, the user installs the new version as an entirely new application.

Application modularity: Android allows multiple APK signed by the same certificate to run in the same process (if the application requests so) so that the system treats them as a single application. In this way, your application can be deployed in the module, and users can update each module independently.

When you create a signing configuration, Android Studio adds your signature information in plain text to the module's build.gradle file. If you are developing in a team or opening up your code, you should remove this sensitive information from the build file so that it is not easily accessible to others. To do this, create a separate properties file to store security information. Then get the configuration of the external file locally, and then keep our key configuration file when you release the code.

Create a file named keystore.properties in the root directory of the project.

StorePassword=myStorePasswordkeyPassword=mykeyPasswordkeyAlias=myKeyAliasstoreFile=myStoreFileLocation

In the build.gradle file of the module, add the code to load the keystore.properties file before the android {} block

Def keystorePropertiesFile = rootProject.file ("keystore.properties") / / Initialize a new Properties () object called keystoreProperties.def keystoreProperties = new Properties () / / Load your keystore.properties file into the keystoreProperties object.keystoreProperties.load (new FileInputStream (keystorePropertiesFile))

Use the syntax keystoreProperties ['attribute name'] to refer to attributes stored in keystoreProperties. Modify the signingConfigs block of the module build.gradle file to use this syntax to reference the signature information stored in keystoreProperties.

Android {signingConfigs {config {keyAlias keystoreProperties ['keyAlias'] keyPassword keystoreProperties [' keyPassword'] storeFile file (keystoreProperties ['storeFile']) storePassword keystoreProperties [' storePassword']}.}

ProGuard

The build system allows you to specify a different ProGuard rule file for each build variant. The build system can run ProGuard to compress and obfuscate classes during the build process. Code compression is provided through ProGuard, and ProGuard detects and removes unused classes, fields, methods, and properties in encapsulated applications, including unused items in its own code base (which makes it a useful tool to workaround 64k reference restrictions). ProGuard can also optimize bytecode, remove unused code instructions, and confuse other classes, fields, and methods with short names. Confused code can make it difficult for your APK to reverse engineer. For a more detailed introduction to ProGuard, you can refer to the previous article on project build.

Turn on code compression

MinifyEnabled true

Enable ProGuard rules

ProguardFiles getDefaultProguardFile ('proguard-android.txt')

'proguard-rules.pro'

The getDefaultProguardFile ('proguard-android.txt') method gets the default ProGuard settings from the Android SDK tools/proguard/ folder.

The proguard-rules.pro file is used to add custom ProGuard rules. By default, the file is located in the module root directory

After each execution of the ProGuard, the following file is generated

The internal structure of all class files in dump.txtAPK.

Mapping.txt provides conversion between original and confused class, method, and field names.

Seeds.txt

Lists classes and members that are not confused.

Usage.txt

Lists the code removed from APK.

These files are saved in / build/outputs/mapping/release/.

For some of these classes, we don't want to confuse them, we need to add a line of-keep code to the ProGuard configuration file. For example:

-this is the end of keep public class MyClass's "how to configure Android Gradle". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

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.