Official Android Technical Documentation translation-Gradle Plug-In User Guide (4)
Dependency, Android Library, and multi-project settings Gradle projects can be dependent on other components. These components can be external Binary packages or other Gradle projects.
To configure the dependency of an external library jar package, you must
CompileAdd a dependency in configuration.
Dependencies {compile files ('libs/foo. jar ')}
Android {...}
Note:
DependenciesDSL elements are part of the standard Gradle API and do not belong
AndroidElement.
The compile configuration is used to compile the main application. All the content will be added to the compilation class path,
AndPackage it into the final generated apk.
The following are other configurations that may be used when adding dependencies:
- Compile: Main Application
- AndroidTestCompile: tested application
- DebugCompile: debug Build Type
- ReleaseCompile: release Build Type. Because it is impossible to Build a project without any associationBuild TypeThe APK and apk are always configured with two or more configurations: compile and Compile.
When a new Build Type is created, a new configuration is automatically created based on its name.
This may be useful. For example, the debug version requires a user-defined Library (for example, reporting crash information), while the release version does not, or they depend on different versions of the same database.
Remote File Gradle supports pulling files from Maven and Ivy repositories.
First, the repository must be added to the list, and then the dependency must be declared using Maven Or Ivy declaration file.
Repositories {mavenCentral ()}
Dependencies {compile 'com. google. guava: 11.0.2 '}
Android {...}
Note: MavenCentral ()Is a shortcut to specify the URL of the maven central repository. Gradle supports remote and local warehouses.
Note: Gradle follows the transmission of all dependencies. This means that if a dependency has its own dependency, These dependencies will also be pulled.
For more information about setting dependencies, see the Gradle User Guide (here) and DSL documentation (here ).
You can set a multi-project Gradle project to depend on other Gradle projects by using multi-project settings.
A multi-project setting is usually implemented by making all projects as subfolders of a given root project.
For example, you can specify the following project structure:
MyProject/+ app/+ libraries/+ lib1/+ lib2/
We can identify three projects. Gradle will reference them using the following names:
: App: libraries: lib1: libraries: lib2
Each project has its own build. gradle file, which defines how to build it.
In addition, there will be Settings. gradleIs used to declare all projects.
The structure of these files is as follows:
MyProject/| settings. gradle + app/| build. gradle + libraries/+ lib1/| build. gradle + lib2/| build. gradle
The content of settings. gradle is simple:
Include ': app',': libraries: lib1', ': libraries: lib2'
It defines which folder is actually a Gradle project.
The : AppThe project may depend on libraries, which is configured by declaring the following dependency:
Dependencies {compile project (': libraries: lib1 ')}
For more information about setting multiple projects, see here.
Library Project in the above multi-purpose settings, : Libraries: lib1And: libraries: lib2 can be a Java project, while: the app Android project will use their JarPackage output.
However, if you want to share access to Android ?? Oid API or code that uses Android-style resources, these library projects cannot be common Java projects, but should be Android ?? Oid Library project.
Creating a Library project is very similar to a common Android project, but there are only some differences.
The build library project is different from the build application, so different plug-ins are used. These two plug-ins share most of the same Code and are provided by the same com. android. tools. build. gradle jar package.
Buildscript {repositories {mavenCentral ()}
Dependencies {classpath 'com. android. tools. build: gradle: 0.5.6 '}}
Apply plugin: 'android-library'
Android {compileSdkVersion 15}
In the above example, an API is created ?? 15. compiled library project. SourceSetsAnd dependencies are the same as their processing methods in application projects, and support the same way of customization.
Differences between a common project and a Library project mainly outputs . AarPackage (which represents the archive file of Android ). It combines compilation code (such as a jar file or a native. so file) and resources (manifest, res, assets ). A library project can also generate a test apk, Which is tested independently by applications.
The library project uses the same anchor task ( AssembleDebug, Assumerelease), So there is no difference in the command to build such a project.
For other content, the behavior of the Library Project and the application project is the same .. They all have build types and product flavors, and can generate multiple versions of aar. Note that most configurations of Build Type are not applicable to library projects. However, you can use custom sourceSet to change the content of a library project based on whether a library project is used or tested by other projects. Referencing a library project references a library project in the same way as referencing any other project:
Dependencies {compile project (': libraries: lib1') compile project (': libraries: lib2 ')}
Note: If you have multiple databases, sorting is very important. This is similar to the importance of the order of dependencies in the project. properties file in the old generation system.
By default, a library project only publishes its ReleaseVariant. This variant will be used by all projects that reference the library, regardless of the variant that those projects build. This is a temporary limitation due to the Gradle restriction. We are trying to solve this problem.
You can control which variant to publish
Android {defapublispublishconfig debug}
Note that the configuration name for this release references the complete variant name. ReleaseAnd Debug, Applicable only when flavor is not defined. If you want to change the default release variant when using flavors, you can write as follows:
Android {defapublispublishconfig flavor1Debug}
You can also publish all variants of a library project. We are planning to do this when the project-to-project dependency (as shown in the preceding example) is normal, however, due to the restrictions of Gradle, we are still trying to fix these problems. Publishing all variant is not enabled by default. To enable them, you can do this:
Android {publishNonDefault true}
Releasing multiple variants means releasing multiple aar files, rather than publishing an aar file containing multiple variants. It is very important to realize this. Each aar package contains a single variant. Release a variant, and realize that this available aar is used as the output file of the Gradle project. This file will be used when it is published to a maven repository or when another project is created to depend on this project.
Gradle has a default file concept. It is used in writing the following code:
Compile project (': libraries: lib2 ')
To create a dependency on another published file of a project, you must 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 complete variant, including the generation type, and must be referenced as above. Important: when non-default release is enabled, the Maven release plug-in releases these extra variant packages (classified by classifier. This means that it is not truly compatible with the release to a maven repository. You should only publish a single variant to a repository, or enable all release configurations for dependencies between projects.
