【Android(安卓)Studio】Gradle Plugin User Guide
16lz
2021-12-22
Gradle Plugin User Guide
Contents
IntroductionThis documentation is for the Gradle plugin version 0.9. Earlier versions may differ due to non-compatible we are introducing before 1.0.Goals of the new Build SystemThe goals of the new build system are:
Why Gradle?Gradle is an advanced build system as well as an advanced build toolkit allowing to create custom build logic through plugins.Here are some of its features that made us choose Gradle:
Requirements
Basic ProjectA Gradle project describes its build in a file called build.gradlelocated in the root folder of the project.Simple build filesThe most simple Java-only project has the following build.gradle:apply plugin: 'java' This applies the Java plugin, which is packaged with Gradle. The plugin provides everything to build and test Java applications. The most simple Android project has the following build.gradle: buildscript { repositories { mavenCentral() buildToolsVersion "19.0.0" } There are 3 main areas to this Android build file: buildscript { ... }configures the code driving the build. In this case, this declares that it uses the Maven Central repository, and that there is a classpath dependency on a Maven artifact. This artifact is the library that contains the Android plugin for Gradle in version 0.11.1 Note: This only affects the code running the build, not the project. The project itself needs to declare its own repositories and dependencies. This will be covered later. Then, the androidplugin is applied like the Java plugin earlier. Finally, android { ... }configures all the parameters for the android build. This is the entry point for the Android DSL. By default, only the compilation target, and the version of the build-tools are needed. This is done with the compileSdkVersionand buildtoolsVersion properties. The compilation target is the same as the targetproperty in the project.properties file of the old build system. This new property can either be assigned a int (the api level) or a string with the same value as the previous targetproperty. Important:You should only apply the androidplugin. Applying the javaplugin as well will result in a build error. Note:You will also need a local.propertiesfile to set the location of the SDK in the same way that the existing SDK requires, using the sdk.dirproperty. Alternatively, you can set an environment variable called ANDROID_HOME. There is no differences between the two methods, you can use the one you prefer. Project StructureThe basic build files above expect a default folder structure. Gradle follows the concept of convention over configuration, providing sensible default option values when possible.The basic project starts with two components called “source sets”. The main source code and the test code. These live respectively in:
For both the Java and Android plugin, the location of the Java source code and the Java resources:
Configuring the StructureWhen the default project structure isn’t adequate, it is possible to configure it. According to the Gradle documentation, r econfiguring thesourceSetsfor a Java project can be done with the following:sourceSets { main { java { srcDir 'src/java' } resources { srcDir 'src/resources' } } } Note: srcDirwill actually add the given folder to the existing list of source folders (this is not mentioned in the Gradle documentation but this is actually the behavior). To replace the default source folders, you will want to use srcDirsinstead, which takes an array of path. This also shows a different way of using the objects involved: sourceSets { main.java.srcDirs = ['src/java'] main.resources.srcDirs = ['src/resources'] } For more information, see the Gradle documentation on the Java plugin here . The Android plugin uses a similar syntaxes, but because it uses its own sourceSets, this is done within the androidobject. Here’s an example, using the old project structure for the main code and remapping theandroidTestsourceSetto the tests folder: android { resources.srcDirs = ['src'] renderscript.srcDirs = ['src'] res.srcDirs = ['res'] }
Note: because the old structure put all source files (java, aidl, renderscript, and java resources) in the same folder, we need to remap all those new components of the sourceSetto the same srcfolder. Note: setRoot()moves the whole sourceSet(and its sub folders) to a new folder. This moves src/ androidTest /*to tests/* This is Android specific and will not work on Java sourceSets. The ‘migrated’ sample shows this. Build TasksGeneral TasksApplying a plugin to the build file automatically creates a set of build tasks to run. Both the Java plugin and the Android plugin do this. The convention for tasks is the following:
This allows you to always call the same task(s) no matter what the type of project is, or what plugins are applied. For instance, applying the findbugsplugin will create a new task and make checkdepend on it, making it be called whenever the checktask is called. From the command line you can get the high level task running the following command: gradle tasks For a full list and seeing dependencies between the tasks run: gradle tasks --all Note: Gradle automatically monitor the declared inputs and outputs of a task. Running the build twice without change will make Gradle report all tasks asUP-TO-DATE, meaning no work was required. This allows tasks to properly depend on each other without requiring unneeded build operations. Java project tasksThe Java plugin creates mainly two tasks, that are dependencies of the main anchor tasks:
The tests are compiled withtestClasses, but it is rarely useful to call this as test depends on it (as well as classes ). In general, you will probably only ever call assembleor check, and ignore the other tasks. You can see the full set of tasks and their descriptions for the Java plugin here. Android tasksThe Android plugin use the same convention to stay compatible with other plugins, and adds an additional anchor task:
Note that builddoes not depend on deviceCheck, or connectedCheck. An Android project has at least two outputs: a debug APK and a release APK. Each of these has its own anchor task to facilitate building them separately:
Tip: Gradle support camel case shortcuts for task names on the command line. For instance: gradle aRis the same as typing gradle assembleReleaseas long as no other task match ‘aR’ The check anchor tasks have their own dependencies:
Basic Build CustomizationThe Android plugin provides a broad DSL to customize most things directly from the build system.Manifest entriesThrough the DSL it is possible to configure the following manifest entries:
android { compileSdkVersion 19 buildToolsVersion "19.0.0"
versionName "2.0" minSdkVersion 16 The defaultConfigelement inside the androidelement is where all this configuration is defined. Previous versions of the Android Plugin used packageName to configure the manifest 'packageName' attribute. Starting in 0.11.0, you should use applicationId in the build.gradle to configure the manifest 'packageName' entry. This was disambiguated to reduce confusion between the application's packageName (which is its ID) and java packages. The power of describing it in the build file is that it can be dynamic. For instance, one could be reading the version name from a file somewhere or using some custom logic: def computeVersionName() { ... } Note: Do not use function names that could conflict with existing getters in the given scope. For instance instance defaultConfig { ...} calling getVersionName() will automatically use the getter of defaultConfig.getVersionName() instead of the custom method. If a property is not set through the DSL, some default value will be used. Here’s a table of how this is processed.
The value of the 2nd column is important if you use custom logic in the build script that queries these properties. For instance, you could write: if (android.defaultConfig.testInstrumentationRunner == null) { // assign a better default... } If the value remains null, then it is replaced at build time by the actual default from column 3, but the DSL element does not contain this default value so you can't query against it. This is to prevent parsing the manifest of the application unless it’s really needed. Build TypesBy default, the Android plugin automatically sets up the project to build both a debug and a release version of the application. These differ mostly around the ability to debug the application on a secure (non dev) devices, and how the APK is signed.The debug version is signed with a key/certificate that is created automatically with a known name/password (to prevent required prompt during the build). The release is not signed during the build, this needs to happen after. This configuration is done through an object called a BuildType. By default, 2 instances are created, a debugand a releaseone. The Android plugin allows customizing those two instances as well as creating other Build Types. This is done with the buildTypesDSL container: android { buildTypes { debug { applicationId Suffix ".debug" } The above snippet achieves the following:
The possible properties and their default values are:
In addition to these properties, Build Typescan contribute to the build with code and resources. For each Build Type, a new matching sourceSetis created, with a default location of src/<buildtypename>/This means the Build Typenames cannot be mainor androidTest(this is enforced by the plugin), and that they have to be unique to each other. Like any other source sets, the location of the build type source set can be relocated: android { sourceSets.jnidebug.setRoot('foo/jnidebug') }Additionally, for each Build Type, a new assemble<BuildTypeName>task is created. The assembleDebugand assembleReleasetasks have already been mentioned, and this is where they come from. When the debugand release Build Typesare pre-created, their tasks are automatically created as well. The build.gradlesnippet above would then also generate an assembleJnidebugtask, and assemblewould be made to depend on it the same way it depends on the assembleDebugand assembleReleasetasks. Tip: remember that you can type gradle aJto run the assembleJnidebugtask. Possible use case:
Signing ConfigurationsSigning an application requires the following:
By default, there is a debugconfiguration that is setup to use a debug keystore, with a known password and a default key with a known password. The debug keystore is located in $HOME/.android/debug.keystore, and is created if not present. The debug Build Typeis set to use this debug SigningConfigautomatically. It is possible to create other configurations or customize the default built-in one. This is done through the signingConfigsDSL container: android { signingConfigs { debug { storeFile file("debug.keystore") }The above snippet changes the location of the debug keystore to be at the root of the project. This automatically impacts any Build Typesthat are set to using it, in this case the debug Build Type. It also creates a new Signing Configand a new Build Typethat uses the new configuration. Note: Only debug keystores located in the default location will be automatically created. Changing the location of the debug keystore will not create it on-demand. Creating a SigningConfigwith a different name that uses the default debug keystore location will create it automatically. In other words, it’s tied to the location of the keystore, not the name of the configuration. Note: Location of keystores are usually relative to the root of the project, but could be absolute paths, thought it is not recommended (except for the debug one since it is automatically created). Note: If you are checking these files into version control, you may not want the password in the file. The following Stack Overflow post shows ways to read the values from the console, or from environment variables. http://stackoverflow.com/questions/18328730/how-to-create-a-release-signed-apk-file-using-gradle We'll update this guide with more detailed information later. Running ProGuardProGuard is supported through the Gradle plugin for ProGuard version 4.10. The ProGuard plugin is applied automatically, and the tasks are created automatically if the Build Typeis configured to run ProGuard through the minifyEnabledproperty.android { buildTypes { release { minifyEnabled true proguardFile getDefaultProguardFile('proguard-android.txt') } } productFlavors { flavor1 { } flavor2 { proguardFile 'some-other-rules.txt' } } } Variants use all the rules files declared in their build type, and product flavors. There are 2 default rules files
Dependencies, Android Libraries and Multi-project setupGradle projects can have dependencies on other components. These components can be external binary packages, or other Gradle projects.Dependencies on binary packagesLocal packagesTo configure a dependency on an external library jar, you need to add a dependency on the compileconfiguration.dependencies { compile files('libs/foo.jar') } Note: the dependenciesDSL element is part of the standard Gradle API and does not belong inside the androidelement. The compileconfiguration is used to compile the main application. Everything in it is added to the compilation classpath andalso packaged in the final APK. There are other possible configurations to add dependencies to:
Creating a new Build Type automatically creates a new configuration based on its name. This can be useful if the debug version needs to use a custom library (to report crashes for instance), while the release doesn’t, or if they rely on different versions of the same library. Remote artifactsGradle supports pulling artifacts from Maven and Ivy repositories.First the repository must be added to the list, and then the dependency must be declared in a way that Maven or Ivy declare their artifacts. repositories { mavenCentral() } Note: mavenCentral()is a shortcut to specifying the URL of the repository. Gradle supports both remote and local repositories. Note: Gradle will follow all dependencies transitively. This means that if a dependency has dependencies of its own, those are pulled in as well. For more information about setting up dependencies, read the Gradle user guide here, and DSL documentation here. Multi project setupGradle projects can also depend on other gradle projects by using a multi-project setup.A multi-project setup usually works by having all the projects as sub folders of a given root project. For instance, given to following structure: MyProject/ + app/ + libraries/ + lib1/ + lib2/ We can identify 3 projects. Gradle will reference them with the following name: :app :libraries:lib1 :libraries:lib2 Each projects will have its own build.gradle declaring how it gets built. Additionally, there will be a file called settings.gradleat the root declaring the projects. This gives the following structure: MyProject/ | settings.gradle + app/ | build.gradle + libraries/ + lib1/ | build.gradle + lib2/ | build.gradle The content of settings.gradle is very simple: include ':app', ':libraries:lib1', ':libraries:lib2'This defines which folder is actually a Gradle project. The :appproject is likely to depend on the libraries, and this is done by declaring the following dependencies: dependencies { compile project(':libraries:lib1') } More general information about multi-project setup here. Library projectsIn the above multi-project setup, :libraries:lib1and :libraries:lib2can be Java projects, and the :app Android project will use theirjaroutput.However, if you want to share code that accesses Android APIs or uses Android-style resources, these libraries cannot be regular Java project, they have to be Android Library Projects. Creating a Library ProjectA Library project is very similar to a regular Android project with a few differences.Since building libraries is different than building applications, a different plugin is used. Internally both plugins share most of the same code and they are both provided by the same com.android.tools.build.gradlejar. buildscript { repositories { mavenCentral() } This creates a library project that uses API 15 to compile. SourceSets, and dependencies are handled the same as they are in an application project and can be customized the same way. Differences between a Project and a Library ProjectA Library project's main output is an .aarpackage (which stands for Android archive). It is a combination of compile code (as a jar file and/or native .so files) and resources (manifest, res, assets). A library project can also generate a test apk to test the library independently from an application.The same anchor tasks are used for this ( assembleDebug, assembleRelease) so there’s no difference in commands to build such a project. For the rest, libraries behave the same as application projects. They have build types and product flavors, and can potentially generate more than one version of the aar. Note that most of the configuration of the Build Type do not apply to library projects. However you can use the custom sourceSet to change the content of the library depending on whether it’s used by a project or being tested. Referencing a LibraryReferencing a library is done the same way any other project is referenced:dependencies { compile project(':libraries:lib1') compile project(':libraries:lib2') } Note: if you have more than one library, then the order will be important. This is similar to the old build system where the order of the dependencies in the project.properties file was important. Library PublicationBy default a library only publishes its releasevariant. This variant will be used by all projects referencing the library, no matter which variant they build themselves. This is a temporary limitation due to Gradle limitations that we are working towards removing.You can control which variant gets published with android { defaultPublishConfig "debug" } Note that this publishing configuration name references the full variant name. Releaseand debugare only applicable when there are no flavors. If you wanted to change the default published variant while using flavors, you would write: android { defaultPublishConfig "flavor1Debug" } It is also possible to publish all variants of a library. We are planning to allow this while using a normal project-to-project dependency (like shown above), but this is not possible right now due to limitations in Gradle (we are working toward fixing those as well). Publishing of all variants are not enabled by default. To enable them: android { publishNonDefault true } It is important to realize that publishing multiple variants means publishing multiple aar files, instead of a single aar containing multiple variants. Each aar packaging contains a single variant. Publishing an variant means making this aar available as an output artifact of the Gradle project. This can then be used either when publishing to a maven repository, or when another project creates a dependency on the library project. Gradle has a concept of default" artifact. This is the one that is used when writing: compile project(':libraries:lib2') To create a dependency on another published artifact, you need to specify which one to use: dependencies { flavor1Compile project(path: ':lib1', configuration: 'flavor1Release') flavor2Compile project(path: ':lib1', configuration: 'flavor2Release') } Important:Note that the published configuration is a full variant, including the build type, and needs to be referenced as such. Important: When enabling publishing of non default, the Maven publishing plugin will publish these additional variants as extra packages (with classifier). This means that this is not really compatible with publishing to a maven repository. You should either publish a single variant to a repository OR enable all config publishing for inter-project dependencies. TestingBuilding a test application is integrated into the application project. There is no need for a separate test project anymore.Basics and ConfigurationAs mentioned previously, next to the main sourceSetis the androidTest sourceSet, located by default in src/ androidTest /From this sourceSet is built a test apk that can be deployed to a device to test the application using the Android testing framework. This can contain unit tests, instrumentation tests, and later uiautomator tests. The sourceSet should not contain an AndroidManifest.xml as it is automatically generated. There are a few values that can be configured for the test app:
android { defaultConfig { testPackageName "com.test.foo" testInstrumentationRunner "android.test.InstrumentationTestRunner" testHandleProfiling true testFunctionalTest true } } The value of the targetPackageattribute of the instrumentationnode in the test application manifest is automatically filled with the package name of the tested app, even if it is customized through the defaultConfigand/or the Build Typeobjects. This is one of the reason the manifest is generated automatically. Additionally, the sourceSetcan be configured to have its own dependencies. By default, the application and its own dependencies are added to the test app classpath, but this can be extended with dependencies { androidTest Compile 'com.google.guava:guava:11.0.2' } The test app is built by the task assembleTest. It is not a dependency of the main assembletask, and is instead called automatically when the tests are set to run. Currently only one Build Typeis tested. By default it is the debug Build Type, but this can be reconfigured with: android { ... testBuildType "staging" } Running testsAs mentioned previously, checks requiring a connected device are launched with the anchor task called connectedCheck . This depends on the task androidTest and therefore will run it. This task does the following:
All test results are stored as XML files under build/androidTest-results(This is similar to regular jUnit results that are stored under build/test-results) This can be configured with android { ... The value of android.testOptions.resultsDiris evaluated with Project.file(String) Testing Android LibrariesTesting Android Library project is done exactly the same way as application projects.The only difference is that the whole library (and its dependencies) is automatically added as a Library dependency to the test app. The result is that the test APK includes not only its own code, but also the library itself and all its dependencies. The manifest of the Library is merged into the manifest of the test app (as is the case for any project referencing this Library). The androidTesttask is changed to only install (and uninstall) the test APK (since there are no other APK to install.) Everything else is identical. Test reportsWhen running unit tests, Gradle outputs an HTML report to easily look at the results.The Android plugins build on this and extends the HTML report to aggregate the results from all connected devices. Single projectsThe project is automatically generated upon running the tests. Its default location isbuild/reports/ androidTest s This is similar to the jUnit report location, which is build/reports/tests, or other reports usually located in build/reports/<plugin>/ The location can be customized with android { ...The report will aggregate tests that ran on different devices. Multi-projects reportsIn a multi project setup with application(s) and library(ies) projects, when running all tests at the same time, it might be useful to generate a single reports for all tests.To do this, a different plugin is available in the same artifact. It can be applied with: buildscript { repositories { mavenCentral() } This should be applied to the root project, ie in build.gradlenext to settings.gradle Then from the root folder, the following command line will run all the tests and aggregate the reports: gradle deviceCheck mergeAndroidReports --continue Note: the --continueoption ensure that all tests, from all sub-projects will be run even if one of them fails. Without it the first failing test will interrupt the run and not all projects may have their tests run. Lint supportAs of version 0.7.0, you can run lint for a specific variant, or for all variants, in which case it produces a report which describes which specific variants a given issue applies to.You can configure lint by adding a lintOptions section like following. You typically only specify a few of these; this section shows all the available options. android { lintOptions { // set to true to turn off analysis progress reporting by lint quiet true // if true, stop the gradle build if errors are found abortOnError false // if true, only report errors ignoreWarnings true // if true, emit full/absolute paths to files with errors (true by default) //absolutePaths true // if true, check all issues, including those that are off by default checkAllWarnings true // if true, treat all warnings as errors warningsAsErrors true // turn off checking the given issue id's disable 'TypographyFractions','TypographyQuotes' // turn on the given issue id's enable 'RtlHardcoded','RtlCompat', 'RtlEnabled' // check *only* the given issue id's check 'NewApi', 'InlinedApi' // if true, don't include source code lines in the error output noLines true // if true, show all locations for an error, do not truncate lists, etc. showAll true // Fallback lint configuration (default severities, etc.) lintConfig file("default-lint.xml") // if true, generate a text report of issues (false by default) textReport true // location to write the output; can be a file or 'stdout' textOutput 'stdout' // if true, generate an XML report for use by for example Jenkins xmlReport false // file to write report to (if not specified, defaults to lint-results.xml) xmlOutput file("lint-report.xml") // if true, generate an HTML report (with issue explanations, sourcecode, etc) htmlReport true // optional path to report (default will be lint-results.html in the builddir) htmlOutput file("lint-report.html") } Build VariantsOne goal of the new build system is to enable creating different versions of the same application.There are two main use cases:
Product flavorsA product flavor defines a customized version of the application build by the project. A single project can have different flavors which change the generated application.This new concept is designed to help when the differences are very minimum. If the answer to “Is this the same application?” is yes, then this is probably the way to go over Library Projects. Product flavors are declared using a productFlavorsDSL container: android { .... This creates two flavors, called flavor1and flavor2. Note: The name of the flavors cannot collide with existing Build Typenames, or with the androidTest sourceSet. Build Type + Product Flavor = Build VariantAs we have seen before, each Build Typegenerates a new APK.Product Flavorsdo the same:the output of the project becomes all possible combinations of Build Typesand, if applicable, Product Flavors. Each ( Build Type, Product Flavor) combination is called a Build Variant. For instance, with the default debugand release Build Types, the above example generates four Build Variants:
Product Flavor ConfigurationEach flavors is configured with a closure:android { ... Note that the android.productFlavors.*objects are of type ProductFlavorwhich is the same type as the android.defaultConfigobject. This means they share the same properties. defaultConfigprovides the base configuration for all flavors and each flavor can override any value. In the example above, the configurations end up being:
There are cases where a setting is settable on both the Build Typeand the Product Flavor. In this case, it’s is on a case by case basis. For instance, signingConfigis one of these properties. This enables either having all release packages share the same S igningConfig, by setting android.buildTypes.release.signingConfig, or have each release package use their own S igningConfigby setting each android.productFlavors.*.signingConfigobjects separately. Sourcesets and DependenciesSimilar to Build Types, Product Flavorsalso contribute code and resources through their own sourceSets.The above example creates four sourceSets:
The following rules are used when dealing with all the sourcesets used to build a single APK:
Finally, like Build Types, Product Flavorscan have their own dependencies. For instance, if the flavors are used to generate a ads-based app and a paid app, one of the flavors could have a dependency on an Ads SDK, while the other does not. dependencies { flavor1Compile "..." }In this particular case, the file src/flavor1/AndroidManifest.xmlwould probably need to include the internet permission. Additional sourcesets are also created for each variants:
Building and TasksWe previously saw that each Build Typecreates its own assemble<name>task, but that Build Variantsare a combination of Build Typeand Product Flavor.When Product Flavorsare used, more assemble-type tasks are created. These are:
#2 allows building all APKs for a given Build Type. For instance assembleDebugwill build both Flavor1Debugand Flavor2Debugvariants. #3 allows building all APKs for a given flavor. For instance assembleFlavor1will build both Flavor1Debugand Flavor1Releasevariants. The task assemblewill build all possible variants. TestingTesting multi-flavors project is very similar to simpler projects.The androidTestsourceset is used for common tests across all flavors, while each flavor can also have its own tests. As mentioned above, sourceSetsto test each flavor are created:
Similarly, those can have their own dependencies: dependencies { androidTest Flavor1Compile "..." } Running the tests can be done through the main deviceCheckanchor task, or the main androidTesttasks which acts as an anchor task when flavors are used. Each flavor has its own task to run tests: androidTest <VariantName>. For instance:
The location of the test results and reports is as follows, first for the per flavor version, and then for the aggregated one:
Multi-flavor variantsIn some case, one may want to create several versions of the same apps based on more than one criteria.For instance, multi-apk support in Google Play supports 4 different filters. Creating different APKs split on each filter requires being able to use more than one dimension of Product Flavors. Consider the example of a game that has a demo and a paid version and wants to use the ABI filter in the multi-apk support. With 3 ABIs and two versions of the application, 6 APKs needs to be generated (not counting the variants introduced by the different Build Types). However, the code of the paid version is the same for all three ABIs, so creating simply 6 flavors is not the way to go. Instead, there are two dimensions of flavors, and variants should automatically build all possible combinations. This feature is implemented using Flavor Dimensions. Flavors are assigned to a specific dimension android { ... The android.flavorDimensionsarray defines the possible dimensions, as well as the order. Each defined Product Flavoris assigned to a dimension. From the following dimensioned Product Flavors[freeapp, paidapp] and [x86, arm, mips] and the [debug, release] Build Types, the following build variants will be created:
Each variant is configured by several Product Flavorobjects:
The flavor dimension is defined with higher priority first. So in this case: abi > version > defaultConfig Multi-flavors projects also have additional sourcesets, similar to the variant sourcesets but without the build type:
Advanced Build CustomizationBuild optionsJava Compilation optionsandroid { compileOptions { sourceCompatibility = "1.6" targetCompatibility = "1.6" } }Default value is “1.6”. This affect all tasks compiling Java source code. aapt optionsandroid { aaptOptions { noCompress 'foo', 'bar' ignoreAssetsPattern "!.svn:!.git:!.ds_store:!*.scc:.*:<dir>_*:!CVS:!thumbs.db:!picasa.ini:!*~" } } This affects all tasks using aapt. dex optionsandroid { dexOptions { incremental false preDexLibraries = false jumboMode = false javaMaxHeapSize "2048M" } }This affects all tasks using dex. Manipulating tasksBasic Java projects have a finite set of tasks that all work together to create an output.The classestask is the one that compile the Java source code. It’s easy to access from build.gradleby simply using classesin a script. This is a shortcut for project.tasks.classes. In Android projects, this is a bit more complicated because there could be a large number of the same task and their name is generated based on the Build Typesand Product Flavors. In order to fix this, the androidobject has two properties:
Note that accessing any of these collections will trigger the creations of all the tasks. This means no (re)configuration should take place after accessing the collections. The DomainObjectCollectiongives access to all the objects directly, or through filters which can be convenient. android.applicationVariants.each { variant -> .... } All three variant classes share the following properties:
The ApplicationVariantclass adds the following:
The LibraryVariantclass adds the following:
The TestVariantclass adds the following:
API for Android specific task types.
The API for each task type is limited due to both how Gradle works and how the Android plugin sets them up. First, Gradle is meant to have the tasks be only configured for input/output location and possible optional flags. So here, the tasks only define (some of) the inputs/outputs. Second, the input for most of those tasks is non-trivial, often coming from mixing values from the sourceSets, the Build Types, and the Product Flavors. To keep build files simple to read and understand, the goal is to let developers modify the build by tweak these objects through the DSL, rather than diving deep in the inputs and options of the tasks and changing them. Also note, that except for the ZipAlign task type, all other types require setting up private data to make them work. This means it’s not possible to manually create new tasks of these types. This API is subject to change. In general the current API is around giving access to the outputs and inputs (when possible) of the tasks to add extra processing when required). Feedback is appreciated, especially around needs that may not have been foreseen. For Gradle tasks (DefaultTask, JavaCompile, Copy, Zip), refer to the Gradle documentation. BuildType and Product Flavor property referencecoming soon. For Gradle tasks (DefaultTask, JavaCompile, Copy, Zip), refer to the Gradle documentation.Using sourceCompatibility 1.7With Android KitKat (buildToolsVersion 19) you can use the diamond operator, multi-catch, strings in switches, try with resources, etc. To do this, add the following to your build file:android { compileSdkVersion 19 buildToolsVersion "19.0.0" defaultConfig { minSdkVersion 7 targetSdkVersion 19 } compileOptions { sourceCompatibility JavaVersion.VERSION_1_7 targetCompatibility JavaVersion.VERSION_1_7 } } Note that you can use minSdkVersion with a value earlier than 19, for all language features except try with resources. If you want to use try with resources, you will need to also use a minSdkVersion of 19. You also need to make sure that Gradle is using version 1.7 or later of the JDK. (And version 0.6.1 or later of the Android Gradle plugin.) |
更多相关文章
- 代码中设置drawableleft
- android 3.0 隐藏 系统标题栏
- Android开发中activity切换动画的实现
- Android(安卓)学习 笔记_05. 文件下载
- Android中直播视频技术探究之—摄像头Camera视频源数据采集解析
- 技术博客汇总
- android 2.3 wifi (一)
- AndRoid Notification的清空和修改
- Android中的Chronometer