Android Gradle plugin 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)

Configures a jar dependency for an external library. You need to add a dependency to 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 tag.

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 last apk at the same time.

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

* Compile:main Application (main module).

* Androidtestcompile:test Application (test module).

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

* Releasecompile:release Build Type (publication type compilation).

Since it is not possible to build a apk,apk that has no association, no matter what build type (build types), the default configuration is two or more than two compilation configurations: Compile and <buildtype>compile.

Creating a new build type will take its own initiative to create a new configuration based on its name.

This requires the use of a self-defined library for the debug version number (for feedback of the collapsed information instantiated) but no need to advertise the version number. Or they can be useful when 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 declarations in the dependencies.

    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 assuming that a dependency itself relies on something else, these things will be pulled back together.

Many other information about setting dependencies, please refer to the Gradle User Guide and the DSL documentation.

4.2 Multi Project Setup (multi-project Setup)

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

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

For example, given the following project structure:

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

We are able to define 3 items.

Grand will map them according to the following name:

: App

: LIBRARIES:LIB1

: Libraries:lib2

Each project has its own Build.gradle file to declare how it is built.

Also, under the root folder, another Setting.gradle file is used to declare 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 easy:

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

This defines which directory is the real Gradle project.

In: App projects may depend on these libraries, which are declared by the following dependency configuration:

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

Many other information about multi-project configurations is here.

4.3 Library projects (Gallery project)

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

But. Assuming you want to share code to access Android APIs or use Android-style resources, these libraries cannot be common Java projects, but should be Android library projects.

4.3.1 Creating a library project (creating a gallery Item)

A library project is similar to a typical Android project, with only a small difference.

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 application project configuration method, which also supports its own definition 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 is also able to generate a test apk to test independently of the application.

The identity task is the same for a library item (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 generate multiple AAR version numbers.

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 using your own defined Sourceset, depending on whether the library project is being used by another project or whether it is used to test.

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 important. This is similar to the dependency ordering in the Project.Properties file in the old build system.

4.3.4 Library Publication (Project announcement)

In general, a library only publishes its release variant (variant) version number.

This version number will be used by all projects referencing it, regardless of what version number they build themselves. This is because of 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 number as the release:

    Android {        defaultpublishconfig "debug"    }

Note that the publication configuration name here refers to the full variant version number name. Relesae,debug is only available when there are no other feature version numbers in the project. If you want to use a different variant version number instead of the default publication version number, you can:

    Android {        defaultpublishconfig "Flavor1debug"    }

It is also possible to advertise all variant version numbers of a library project. We plan to agree on a general project-dependent project (similar to the one described above), but it is unlikely that the gradle (and we are trying to fix it) are now.

By default, the advertise all variant version number is not enabled. Can be enabled by:

    Android {        Publishnondefault true    }

Understanding the publication of multiple variant version numbers means that it is important to advertise multiple ARR files instead of an arr file that includes all variant version numbers. Each arr package includes a single variant version number.

Publishing a Variant version number means building an available arr file as an output file for the Gradle project.

Whether it is published to a MAVEN repository, or if other projects need to create a dependency on this library project, this file can be used.

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

    Compile project (': Libraries:lib2 ')

To create a dependency on another advertised file, you need to specify which one to use in detail:

    dependencies {        Flavor1compile project (path: ': Lib1 ', configuration: ' Flavor1release ')        Flavor2compile Project (Path: ': Lib1 ', configuration: ' Flavor2release ')    }

Important: Note that the published configuration is a full variant version number. It contains the build type and needs to be referenced as above.

Important: When non-default advertisement is enabled, the Maven advertisement plugin will advertise the other variant version numbers as expansion packs (categorized by classifier). This means that no real compatibility is advertised to the MAVEN repository.

You should also publish a single variant version number into the Repository, or agree to publish all configurations to support cross-project dependencies.

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