Android Gradle Pluin Guide (iii)-dependencies, Android libraries, and multi-project configurations

Original address: http://tools.android.com/tech-docs/new-build-system/user-guide# Toc-dependencies-android-libraries-and-multi-project-setup

4. Dependencies,android Libraries and multi-project setup (dependencies, Android libraries and multi-project settings)

The Gradle project can depend on other components. These components can be external binary packages, or other gradle projects.

4.1 Dependencies on binary packages (binary package dependent)

4.1.1 Local Packages (native pack)

To configure a jar dependency for an external library, you need to add a dependency in the compile configuration.

    dependencies {        compile files (' Libs/foo.jar ')    }    Android {        ...    }

Note: This dependencies DSL tag is part of the standard Gradle API, so it does not belong to the Android tab.

This compile configuration will be used to compile the main application. Everything inside it will be added to the compiled classpath and will be packaged into the final apk.

Here are some additional configuration options that you might use to add dependencies:

* Compile:main Application (main module).

* Androidtestcompile:test Application (test module).

* Debugcompile:debug Build Type (Compilation of debug type).

* Releasecompile:release Build Type (compilation of release types).

Because there is no possibility to build a apk,apk with no build type associated with it, the default configuration is two or more than two compilation configurations: Compile and <buildtype>compile.

Creating a new build type will automatically create a new configuration based on its name.

This is useful for debug versions that need to use a custom library (to feedback the crash information that is instantiated, and so on) but are not required for release builds, or they depend on different versions of the same library.

4.2.2 Remotes artifacts (remote files)

Gradle supports pulling files from maven or Ivy repositories.

You must first add the warehouse to the list, and then you must declare the files for Maven or Ivy claims in the dependency.

    repositories {        mavencentral ()    }    dependencies {        compile ' com.google.guava:guava:11.0.2 '    }    Android {        ...    }

Note: Mavencentral () is a simple way to specify a warehouse URL. Gradle supports remote and local warehouses.

Note: Gradle will follow the transitive nature of the dependency relationship. This means that if a dependency itself relies on something else, these things will be pulled back together.

For more information on setting up dependencies, refer to the Gradle User Guide and the DSL documentation.

4.2 Multi Project Setup (multi-project Setup)

Gradle projects can also rely on other gradle projects by using multi-project configurations.

The implementation of a multi-project configuration is typically to include all items as subfolders under a root project path.

For example, given the following project structure:

    myproject/     + app/     + libraries/        + lib1/        + lib2/

We can define 3 items. Grand will map them according to the following names:

: App

: LIBRARIES:LIB1

: Libraries:lib2

Each project has its own Build.gradle file that declares how it is built.

Also, under the root directory, there is a setting.gradle file that declares all items.

The structure of these files is as follows:

    myproject/     | settings.gradle     + app/        | build.gradle     + libraries/        + lib1/           | Build.gradle        + lib2/           | build.gradle

The content of Setting.gradle is very simple:

    Include ': App ', ': Libraries:lib1 ', ': Libraries:lib2 '

This defines which folder is the real Gradle project.

Where: The app project may depend on these libraries, which are declared by the following dependency configuration:

    dependencies {        Compile project (': Libraries:lib1 ')    }

For more information on multi-project configurations, please refer to here.

4.3 Library projects (Gallery project)

In the multi-project configuration above,: LIBRARIES:LIB1 and: Libraries:lib2 may be a Java project, and the Android project will use their jar package output.

However, if you want to share code to access the Android API or use Android-style resources, then these libraries will not be the usual Java projects, but should be the Android Library project.

4.3.1 Creating a library project (creating a gallery Item)

A library project is very similar to a typical Android project, just a little bit different.

Although building library projects differs from building applications, they use different plugin. But internally these plugin share most of the same code, and they are all provided by the same com.android.tools.build.gradle.jar.

    Buildscript {        repositories {            mavencentral ()        }        dependencies {            classpath ' com.android.tools.build:gradle:0.5.6 '        }    '    Apply plugin: ' Android-library '    android {        Compilesdkversion    }

This creates a library project that uses API 15 to compile Sourceset, and the dependency configuration method is the same as the configuration method for the application project, and it also supports custom configuration.

4.3.2 Differences between a project and a library project (the difference between a normal project and a library item)

The main output of a library project is an. AAR package (which represents an archive file for Android). It combines compiled code (such as a jar package or a local. so file) and resources (Manifest,res,assets).

A library project can also be tested independently of the application to generate a test apk.

The identity task also applies to library items (assembledebug,assemblerelease), so it is no different from building a project on the command line.

The rest of the section, the Library project is the same as the application project. They all have build type and product flavor, and can also generate multiple AAR versions.

Remember that most of the configuration of build type does not apply to library items. However, you can change the contents of a library project by using a custom sourceset, depending on whether the library project is being used by another project or whether it is used for testing.

4.3.3 referencing a library (referencing a gallery project)

Referencing a library project is the same way you would refer to other projects:

    dependencies {        Compile project (': Libraries:lib1 ')        Compile project (': Libraries:lib2 ')    }

Note: If you are referencing multiple libraries, sorting will be very important. This is similar to the dependency ordering in the Project.Properties file in the old build system.

4.3.4 Library Publication (Gallery project release)

In general, a library will only publish its release variant version. This version will be used by all projects that reference it, regardless of what version they build themselves. This is due to the limitations of gradle, and we are working to eliminate this problem, so this is only a temporary limitation.

You can control which variant version to use as the release version:

    Android {        defaultpublishconfig "debug"    }

Note that the Release configuration name here refers to the full variant version name. Relesae,debug is only available when there are no other feature versions in the project. If you want to replace the default release version with another variant, you can:

    Android {        defaultpublishconfig "Flavor1debug"    }

It is also possible to publish all variant versions of a library project. We plan to allow this in general project-dependent projects (similar to the one described above), but it is not likely to be the case because of the gradle limitations (we are also trying to fix the problem).

Publishing all Variant versions is not enabled by default. This can be enabled by:

    Android {        Publishnondefault true    }

Understanding publishing Multiple Variant versions means that it is important to publish multiple ARR files instead of an arr file that contains all variant versions. Each ARR package contains a single variant version.

Publishing a Variant version means building an available arr file as an output file for the Gradle project. Whether you publish to a MAVEN repository or another project needs to create a dependency on this library project, you can use this file.

The Gradle has a default file concept. This is used when the following configuration is added:

    Compile project (': Libraries:lib2 ')

To create a dependency on another publishing file, 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 version that includes the build type and needs to be referenced as above.

Important: When non-default publishing is enabled, the MAVEN publishing plug-in will release other variant versions as expansion packs (categorized by classifier). This means that there is no real compatibility release to the MAVEN repository. You should also publish a single variant version to the Repository, or allow all configurations to be published to support cross-project dependencies.