• Gradle Wrapper

      • The concept of DSL:
      • Gradle Wrapper concept
      • Wrapper configuration
      • gradle-wrapper.properties
      • Customize the Wrapper Task

    • The foundation of Gradle build scripts

      • Settings file
      • The Build file

    • Gradle plug-in

      • What plug-ins do

      • The plug-in application

        • Binary plug-in
        • Application script plug-in
        • Apply plug-ins published by a third party

    • Java Gradle plug-in

      • Configuring third-party Dependencies

      • Compile and testCompile (implementation and testImplementation)

        • API (compile) instruction
        • The implementation instruction
        • compileOnly
        • The difference between annotationProcessor and compileOnly

      • SourceSet source collection concept

    • Android Gradle plug-in

      • Brief introduction:
      • Android Gradle plugin
      • Buildscript {} configuration
      • Android Gradle task

    • Android Gradle Advanced customization

      • Use the shared library uses-library
      • Batch modify the generated APK file name
      • Example Hide signature file information
      • Dynamically configuring the AndroidManifest file (multi-channel packaging)
      • The method limit exceeded 65535
      • DEX Option Configuration

    • Android Gradle builds multiple projects

      • Android Project Differences
      • Android multi-project Settings
      • Library project references and configuration

    • AndroidGradle test

      • Lint support

Can have so one or two words, say to your heart, wish enough!

Gradle Wrapper

Gradle is an excellent build system tool. Its DSLS are implemented in Groovy and you can easily control these DSLS through your code to achieve your build goals. Gradle builds most of its functionality as plugins, so it is very flexible and you can customize your own plugins if the built-in plugins don’t meet your requirements.

The concept of DSL:

DSL(Domain Specific Language) is a Language that focuses on a Specific Domain in a timely manner. It is called Domain Specific, rather than a universal and comprehensive Language like Java. Gradle is a DSL. It’s a Groovy-based DSL for automated builds. Developers write Gradle scripts in accordance with the syntax defined by the Gradle DSL to automate the build.

Gradle Wrapper concept

The so-called “Wapper” is actually a layer of packaging for Gradle. It is convenient to unify gradle build versions in the development process of the team. In this way, everyone has used the same Gradle build version to avoid unnecessary problems caused by different Gradle versions. The Wrapper is a batch script in Windows and a shell script in Linux. When you start Gradle using the Wrapper, The Wrapper will check if Gradle is associated with a download, and if not it will download from the configured address (usually gradle’s official library) and run the build. This is very convenient for developers because instead of having to configure the environment, just execute the Wrapper command and it takes care of everything for you. This approach also makes it easier to do continuous integration (CI) on the server, since we no longer have to configure the Gradle environment on the server.

Wrapper configuration

– gradle-version specifies the gradle version to use. Gradle-distribution-url Specifies the URL to download gradle distribution

gradle-wrapper.properties

Gradle Wrapper is a gradle Wrapper configuration file generated by the Wrapper Task. The above configuration will be written to this file.

DistributionBase =GRADLE_USER_HOME. DistributionBase =GRADLE_USER_HOME DistributionPath =wrapper/dists # distributionBase, distributionBase, distributionBase, distributionBase ZipStoreBase =GRADLE_USER_HOME # same as distributionPath, ZipStorePath =wrapper/dists #Gradle directory distributionUrl=https\://services.gradle.org/distributions/gradle-4.4-all.zipCopy the code

The field we care about is distributionUrl, which determines which gradle version of your Gradle wrapper depends on. We usually change bin to all so that we can use the gradle source code during development.

Customize the Wrapper Task

Type the following script in the build.gradle file: Task is not a keyword, it is actually a function of the Project object.

task wrapper(type: Wrapper){gradleVersion =' 4.4' archiveBase ='GRADLE_USER_HOME' archivePath =' Wrapper /dists' distributionBase='GRADLE_USER_HOME' distributionPath='wrapper/dists' DistributionUrl = 'https\\://services.gradle.org/distributions/gradle-4.4-all.zip'}Copy the code

Gradle-version 4.4 wrapper is generated by default when executing gradle Wrapper instead of specifying -gradle-version 4.4.

The foundation of Gradle build scripts

Settings file

Gradle defines a setup file for initialization and configuration of the project tree. The default name of the Settings file is setting.gradle and it is placed in the root project directory.

Setup files are mostly used to configure sub-projects. In Gradle, multiple projects are represented by a project tree, similar to the concept of project and Module seen in AS.

A subproject is identified only when Gradle is configured in the setting file and is included in the build:

The Build file

Each Project has a Build file, which is the entry point to Build the Project, where you can configure the version, which plug-ins are required, which libraries to rely on, and so on. RootProject is no exception. It can obtain all ChildProjects, so in the Build file of Root Project, we can uniformly configure The Child Project, such as the plug-in of the application, the Maven central library dependent on, etc. For example, configure all Child Project repositories as JCenter, so that the jar packages we depend on can be downloaded from the JCenter central library:

allprojects {
    repositories {
        google()
        jcenter()
    }
}
Copy the code

In addition to AllProjects, there are subprojects, which are two methods that take a closure (a piece of code) as a parameter to traverse the Project. During the traversal process, our customized closure is called, so we can configure, print, output or modify the Project properties in the closure.

Gradle plug-in

What plug-ins do

  1. You can add tasks to your project to help with testing, compiling, packaging, etc.
  2. We can add dependency configurations to your project so that we can configure the dependencies that our project needs during the build process, such as third libraries, etc.
  3. You can add new extension properties, methods, etc. to existing object types in your project, so that you can use them to help you configure and optimize your build. For example, android{} configuration block is an extension of the Android Gradle plugin for the Project object.
  4. For example, if the Java plug-in is applied, the SRC /main/ Java directory will be used to store our source code, and the Java source file will be compiled in this directory.

This is the plug-in, we just need to follow its agreed way, using the tasks, methods, extensions provided by it, we can build our project.

The plug-in application

Binary plug-in

Binary plug-ins are plug-ins that implement the org.gradle.api.plugin interface. They can have a Plugin ID, for example:

The above statement applies the Java plugin to our project. ‘Java’ is the unique Plugin ID of the Java plugin. Gradle’s core plugins have an easy to remember short name, called plugin ID. Binary plugins are usually distributed in a JAR. For example, we can specify the plugin ID when we publish our own plugin. The plugin ID should be a fully qualified name, like the package name, to avoid duplication

Application script plug-in

To apply a script plug-in, you simply load the script in. Unlike a binary plug-in, it uses the from keyword and is followed by a script file, which can be local or web based (using an HTTP URL).

apply from:'version.gradle'
Copy the code

version.gradle

VersionName ='1.0.0' versionCode=1}Copy the code

Apply plug-ins published by a third party

Buildscript {} is used to configure the classpath, unlike the built-in plugins provided by Gradle. For example, our Android Gradle plug-in is a third-party plug-in released by Android. If you want to use it, you need to configure it first.

Jcenter buildscript {repositories {Google () ()} dependencies {classpath 'com. Android. View the build: gradle: 3.1.1' / / NOTE: Do not place your application dependencies here; they belong // in the individual module build.gradle files } }Copy the code

The buildScript {} block is a place to pre-prepare the project and initialize the associated configuration dependencies before building the project. Once the required dependencies are configured, the plug-in can be applied:

apply plugin: 'com.android.application'
Copy the code

Java Gradle plug-in

Configuring third-party Dependencies

In order to use third-party dependencies, you need to tell Gradle how to find the dependencies, that is, the configuration of the dependencies. In most cases, we need to find the jars we need from the repository. First, we need to tell Gradle what type of repository we want to use and where these repositories are

Maven {url "https://jitpack.io"} mavenCentral()} maven {url "https://jitpack.io"} mavenCentral()}Copy the code

Compile and testCompile (implementation and testImplementation)

For AS above 3.0 we use implementation and testImplementation, for AS below we deprecate compile and testCompile, we use the latest specification

dependencies { implementation fileTree(dir: 'libs', include: [' *. Jar ']) implementation 'com. Android. Support: appcompat - v7:27.1.1' implementation 'com. Android. Support. The constraint, the constraint - layout: 1.1.0' testImplementation junit: junit: '4.12' androidTestImplementation 'com. Android. Support. Test: runner: 1.0.2' androidTestImplementation 'com. Android. Support. Test. Espresso: espresso - core: 3.0.2'}Copy the code

Here’s the difference between dependency

API (compile) instruction

Exactly the same as the compile directive, dependencies can be passed, no difference, you change all compile to API, absolutely nothing wrong.

The implementation instruction

The special feature of this directive is that for dependencies compiled with the command, the project that has a dependency on the project will not be able to access any programs in the dependency compiled with the command, that is, the dependency will be hidden from the outside world. Simply put, dependencies using the Implementation directive are not passed. Dependencies should be set to implementation first, so if there’s no error, implementation, if there’s an error, API. Using implementation makes compiling a little bit faster. Using implementation makes compiling faster: for example, if I use implementation in a library that relies on the Gson library, and then my main project relies on the Library, then my main project can’t access the methods in the Gson library. This has the advantage of making the compilation faster. I switched to a version of the Gson library, but as long as the Library code stays the same, the main project code will not be recompiled.

compileOnly

Equivalent to provided, it only works at compile time, does not participate in packaging, and is not included in an APK file. Can be used to resolve duplicate import library conflicts

The difference between annotationProcessor and compileOnly

The annotationProcessor and compileOnly compile and not compileOnly into APK, so what’s the difference? AnnotationProcessor generates code at compile time, but compileOnly is not needed. CompileOnly is a duplicate library, so you can shave it off and keep only one library.

SourceSet source collection concept

SourceSet is an abstract concept used by Java plug-ins to describe and manage source code and its resources. SourceSet is a collection of Java source code files and resource files. With a source set, we can easily access the source directory. With a source set, we can group our source code for different businesses and applications, such as Main for major business products and Test for unit tests. The Java plug-in gives us a sourceSet attribute under Project and a sourceSets{} closure to access and configure the sourceSet. The sourceSet{} closure configures all the sourceSet objects. Here are the directories for the Java source and resource files that set the main sourceSet

sourceSets{
    main{
        java {
            java.srcDirs = ['src/main/java']
        }
        resources {
            java.srcDirs = ['src/main/resources']
        }
    }
}
Copy the code

Android Gradle plug-in

Brief introduction:

From Gradle’s point of view, Android is actually a third-party plugin for Gradle. From Android’s point of view, Android plug-ins are built based on Gradle.

Android Gradle plugin

  • APP plug-in id: com. Android. Application. The APP application engineering, can generate a working apk applications;
  • Library plugin ID: com.android.library. AAR package can be generated for other APP projects to use, just like our JAR, but it contains Android resources and other information is a special JAR package;
  • Test plug-in ID: com.android.test. Used for unit Test of APP project or Library project.

Buildscript {} configuration

This part can be written in the build.gradle script file of the root project so that all the sub-projects do not have to be configured repeatedly.

apply from:'version.gradle' buildscript { repositories { google() jcenter() } dependencies { classpath 'com. Android. Tools. Build: gradle: 3.1.1'}}Copy the code

AndroidGradle plugin can be applied to build. Gradle script under moudle

apply plugin: 'com.android.application' android { compileSdkVersion 27 defaultConfig { applicationId "Com. Gradle. Ytf. Gradleapplication" 15 targetSdkVersion 27 versionCode minSdkVersion 1 versionName "1.0" testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner" } buildTypes { release { minifyEnabled false proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro' } } }Copy the code
  • Android {} is a type of extension provided by android plugins that allows you to customize android Gradle projects.
  • CompileSdkVersion is the AndroidSDK version on which you compile, in this case API Level;
  • BuildToolsVersion is the version of the build tool used to build the Android project. Can see in the AndroidSDK directory, it is a kit, including appt, dex and other tools, we can through buildToolsVersion methods assignment, but can be by android. BuildToolsVersion his value this property, speaking, reading and writing.
  • DefaultConfig is the default configuration, which is a ProductFlavor. This allows us to generate multiple different APK packages depending on the situation, which means multi-channel packaging. If not configured separately, defaultConfig will be used for the ProductFlavor
  • MinSdkVersion 15 is the lowest supported API Level for Android
  • TargetSdkVersion 27 indicates which Android version we are developing on, in this case 27
  • VersionCode indicates the internal version number of our APP and is generally used to control APP upgrades.
  • VersionName “1.0” indicates the versionName of our APP, which users can see is our release version, in this case 1.0
  • ApplicationId is a property of ProductFlavor that specifies the package name to generate the APP. The default value is null and is read from the manifest file when building.
  • TestApplicationId: specifies the package name of the test APP. By default, it is applicationId+.test. General default is ok
  • TestInstrumentationRunner, used to configure the unit test is used when the Runner, the default is used. Android test. InstrumentationTestRunner, can be modified.
  • SigningConfig Configures default signature information and generates APP signatures.
  • ApplicationIdsuffix, the buildType attribute used to configure suffixes based on the default ApplicationID for building debug.apk
  • The debuggable is used to configure whether to generate an APK ready for debugging
  • JniDebuggable, similar to debuggable, is used to configure whether to generate an APK for debugging JNI (C/C++) code
  • MultiDexEnable Used to configure whether to enable the function of automatically splitting multiple dex when the number of methods exceeds 65535.
  • ShrinkResources enables you to automatically clear unused resources. The default value is false
  • Enable zipAlign optimization to improve system and application efficiency, write resources in APK faster, and reduce memory usage
   buildTypes {
        release {
            minifyEnabled false
            zipAlignEnabled true
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
    }
Copy the code

All of these configuration pairs use methods or properties from the ProductFlavor class. – buildTypes is a domain object, NamedDomainObjectContainer types, as well as SourceSet, punctuated with release and debug and so on, -minifyEnabled Whether to enable oblif for this build type -resconfigs’ zh ‘// Only zh resources are retained and other non-ZH resources are not packed into APK, is the resource qualifier -proGuardFiles. When oblif is enabled, The proGuard configuration file is used to configure how obfuscation is performed, such as the level of obfuscation, which classes and methods are not obfuscated, etc. The corresponding proguardFiles method in BuildType can accept a mutable argument. So we can configure multiple configuration files, for example

 proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
Copy the code

GetDefaultProguardFile is an Android extension method that gets the default ProGuard configuration file in your AndroidSDK directory. In the android-sdk/tools/proguard/ directory, the file name is timely and we passed the parameter name proguard-android.txt. Fully qualified writing: android getDefaultProguardFile, only need to pass a file name to this method, will return to the tool/proguard directory of the absolute path to the file, prototype method as follows:

public File getDefaultProguardFile(String name) { if (! ProguardFiles.KNOWN_FILE_NAMES.contains(name)) { extraModelInfo .getSyncIssueHandler() .reportError( EvalIssueReporter.Type.GENERIC, ProguardFiles.UNKNOWN_FILENAME_MESSAGE); } return ProguardFiles.getDefaultProguardFile(name, project); }Copy the code

Android Gradle task

Android plug-ins are Java-based plug-ins, so Android plug-ins basically contain all of the functionality of Java plug-ins, including integrated tasks such as Assemble, Check, Build, etc., with the following tasks added

  1. ConnectedCheck Runs check on all connected devices or emulators
  2. DeviceCheck connects to remote devices through apis to run Checks. It is used on CI (Continuous integration) servers.
  3. Lint runs Lint checking on all productFlavors.
  4. Tasks like Install and Uninstall can install or uninstall your APP directly on our connected devices.
  5. SigningReport can print the signature of the APP
  6. AndroidDependencies Print Android dependencies.

Android Gradle Advanced customization

Use the shared library uses-library

<? The XML version = "1.0" encoding = "utf-8"? > <manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.gradle.ytf.gradleapplication"> <application android:allowBackup="true" android:icon="@mipmap/ic_launcher" android:label="@string/app_name" android:roundIcon="@mipmap/ic_launcher_round" android:supportsRtl="true" android:theme="@style/AppTheme"> <uses-library android:name="com.google.android.maps" android:required="true"></uses-library> <activity android:name=".MainActivity"> <intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.LAUNCHER" /> </intent-filter> </activity> </application> </manifest>Copy the code

We declare that we need to use maps, and when we install the APK package, the system will help check if the mobile system has the required shared library according to our definition, since android: Required = “true” is set. If the mobile system does not, the application will not be installed. Add-ons libraries are optional libraries that can be used with older versions of the API. For example: Org.apache.http. legacy, this is an HTTPClient library. Starting with API23, the HTTPClient library is no longer included in the standard SDK. To use this library, org.apache.http.

Batch modify the generated APK file name

// applicationVariants.all { variant -> // if (variant.buildType.name == "release") { // variant.outputs.each { output -> // def appName = 'hibook' // def oldFile = output.outputFile // def buildName // def releaseApkName // // variant.productFlavors.each { product -> // buildName = product.name // } // // releaseApkName = appName + '-' + buildName + '-' + getDate() + '.apk' // output.outputFile = new File(oldFile.parent, ReleaseApkName) / / / / / / / /}}} above AS3.0 version of android. ApplicationVariants. All {variant - > the variant. The outputs. All {the if (varie.name.endswith ("Debug")) {// Debug package outputFileName = "$applicationId" _v ${defaultConfig. VersionName} _ ${getDate ()} _code ${defaultConfig. VersionCode} _debug. The apk "} else {/ / release package variant.outputs.each { output -> def appName = 'hibook' def oldFile = output.outputFile def buildName def releaseApkName  variant.productFlavors.each { product -> buildName = product.name } releaseApkName = appName + '-' + buildName + '-' + getDate() + '_release.apk' // output.outputFile = new File(oldFile.parent, releaseApkName) outputFileName =releaseApkName // outputFileName = "$applicationId _code _v ${defaultConfig. VersionName} ${defaultConfig. VersionCode} _ ${getDate ()}. _release apk "}}}}} / / get the static timestamp def getDate() { def date = new Date() def formattedDate = date.format('yyyy-MM-dd-HH_mm') return formattedDate }Copy the code

Example Hide signature file information

Put the signature file and key information on the server and read it when making the formal package.

SigningConfigs {def appStoreFile= system.getenv ("STORE_FILE")// Get the value of the environment variable named "STORE_FILE" def appStroePassword=System.getenv("STORE_PASSWORD") def appKeyAlias=System.getenv("KEY_ALIAS") def AppKeyPassword = system.getenv ("KEY_PASSWORD") // Use the dubug signature if(! appStoreFile||! appStroePassword||! appKeyAlias||! appKeyPassword){ appStoreFile="debug.keystore" appStroePassword="android" appKeyAlias="androiddebugkey" appKeyPassword="android" } release{ storeFile file(appStoreFile) storePassword appStroePassword keyAlias appKeyAlias keyPassword appKeyPassword } }Copy the code

Dynamically configuring the AndroidManifest file (multi-channel packaging)

<meta-data android:value="Channel ID" android:name="UMENG_CHANNEL"></meta-data>
Copy the code

You can dynamically modify the contents of the AndroidManifest file during the build process. For example, you can specify the Channel name Channel ID by using manifestPlaceholder, manifest placeholder, and manifestPlaceholder. ManifestPlaceholder is a property of ProductFlavor, which is a map type, so we can configure multiple placeholders at the same time

android{

 productFlavors{
        google{
            manifestPlaceholders.put("UMENG_CHANNEL","google")
        }
        baidu{
            manifestPlaceholders.put("UMENG_CHANNEL","baidu")
        }
    }
}
Copy the code

So, in this example, we define two channels, Google and Baidu, and configure their manifestplaceholder. Their key is the same, that is, our placeholder variable in the manifest file, When it is built, it will replace the manifest variable UMENG_CHANNEL with the manifestplaceholder value applied by the Manifestplaceholder:

  productFlavors {
        Baidu {
        }
        Server {
        }
        Xiaomi {
        }
        Huawei {
        }
        Vivo {
        }
        Oppo {
        }
        Tencent {
        }

    }

    productFlavors.all { flavor ->
        flavor.manifestPlaceholders = [UMENG_CHANNEL_VALUE: flavor.name]
    }
Copy the code

Or:

<meta-data android:name="UMENG_CHANNEL" android:value="${UMENG_CHANNEL_VALUE}"/>
Copy the code
productFlavors {
        Baidu {
        }
        Server {
        }
        Xiaomi {
        }
        Huawei {
        }
        Vivo {
        }
        Oppo {
        }
        Tencent {
        }

    }

    productFlavors.all { flavor ->
        flavor.manifestPlaceholders = [UMENG_CHANNEL_VALUE: flavor.name]
    }
Copy the code

The method limit exceeded 65535

For VMS running android5.0, there is only one DEX, and the name must be class.dex. Therefore, control must be done at the application entry. If there is no custom application, use MultiDexApplication directly. First add dependency: Implementation ‘com. Android. Support: multidex:’ build 1.0.1. Gradle

defaultConfig { applicationId "com.gradle.ytf.gradleapplication" minSdkVersion 15 targetSdkVersion 27 versionCode 1 VersionName "1.0" multiDexEnabled true / / enable multidex testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner" }Copy the code

Configure in the manifest file :(not required after 5.0)

android:name="android.support.multidex.MultiDexApplication"
Copy the code

If you have a custom Application and inherit it directly, you can change the inheritance to MultiDexApplication. If you inherit the custom Application from another third party, you cannot change the inheritance. Override the attachBaseContex () method

    @Override
    protected void attachBaseContext(Context base) {
        super.attachBaseContext(base);
        MultiDex.install(base);

    }
Copy the code

DEX Option Configuration

  1. Incremental property is used to configure whether to enable incremental mode for dx. The default value is false, which can improve the speed, but there are many restrictions.
android{
 dexOptions{
        incremental true     }
}
Copy the code
  1. JavaMaxHeapSize Specifies the maximum memory allocated to the dex command. It is used to solve the problem of insufficient memory when executing the DEX command. The premise is that your computer has sufficient memory, for example:javaMaxHeapSize '4g'
  2. The jumboMode is used to configure whether to enable the Jumbo mode. If a project is large and the number of functions exceeds 65535, the jumboMode must be forcibly enabled to enable the jumbo modejumboMode true
  3. PreDexLibraries Specifies whether to pre-execute the dex Libraries project. If this function is enabled, the build speed will be greatly improved, but the clean build speed will be affected. The default value is true.preDexLibraries false
  4. ThreadCount is an integer that sets the number of threads that Android Gradle uses to run dx commands.

Android Gradle builds multiple projects

Android Project Differences

Android projects are generally divided into library projects, application projects and test projects. The three plug-ins corresponding to Android Gradle are com.android.library, com.android.application and com.android.test. Library projects generally similar to Java library, more than some Android resource allocation, general class with common characteristics, resources can be abstracted as a library project, can be referenced by other projects, there is a kind of situation, engineering is complex, can according to the project of business into a library project, and then through an application project reference them, Put it all together, it’s a complex APP. Generally, there is only one application project, which can be packaged into APK. If you want to release apps with different features, but they are of the same kind, there will be multiple application projects, such as QQ standard version, chat version and other test projects, which are created to test the APP. Android is a framework method for testing Android projects based on Junit.

Android multi-project Settings

Gradle in setting.gradle

include ':app',':libraries libs1',':libraries libs2'
Copy the code

You can specify the configuration if there are too many paths

include ':libs1'
project(':libs1').projectDir = new File(rootDir,'chapter09/libs1')
Copy the code

Through the above method we can directly specify the project directory. This gives us a framework for multi-project configuration that can be simulated by adding and subtracting projects.

Library project references and configuration

Android library project reference is implemented in the same way as Gradle project reference. It is implemented in dependencies:

dependencies { compile project(':libraries libs1')}
Copy the code

This references the Lib library project using Gradle’s dependencies.

AndroidGradle test

Lint support

Android provides an optimization tool for code and resources, Lint, that can help us check which resources are not being used, which are using new apis, which resources are not internationalized, etc., and generate a report telling us what needs to be optimized.

  1. AbortOnError false Configures whether or not Lint exits a Gradle build if it finds an error
  2. Check ‘NewApi’ // check issue id is’ NewApi ‘property is a Set of two methods, different parameters, there are three ways to write
  3. LintOptions {abortOnError false // Used to configure whether Lint exits Gradle builds if it finds errors // Check 'NewApi'// Detect issue id 'NewApi' property is a Set of two methods, Def checkSet =new HashSet<String>() checkset.add ("NewApi") checkset.add ("InlinedApi") check=checkSet  check 'NewApi','InlinedApi' } } public void check(String id){ check.add(id) } public void check(String... ids){ for (String id:ids) { check(id) } }Copy the code

  1. CheckAllWarnings True checks all warning issues, including those closed by default. False does not check
  2. CheckReleaseBuilds True Whether Lint checks for known error issues in a release build. The default is true. Release builds are terminated if a ‘fatal’ level problem is found
  3. ExplainIssues true Specifies whether error reports detected by Lint should contain an explanation. This function is enabled by default, that is, there is an explanation in the report document
  4. NoLines True Defaults to true, meaning that the error output will not contain the line number of the source code
  5. Quiet True Setting the quiet mode to true means that progress and other information parsed by Lint will not be displayed
  6. ShowAll true // Indicates whether to display all output, such as location information, and not truncate messages that are too long.
  7. TextOutput (” E:/ytf file “) // Specifies the path to generate a text report, similar to xmlOutput, which generates an XML report
  8. TextReport true // Configures whether to generate text reports. The default is false, similar to xmlReport
  9. WarningsAsErrors false // whether to treat all warningsAsErrors.