entation for more information about creating and setting a style.

What Is Android Library?

An Android library is structurally the same as an Android app module. It can include everything needed to build an app, including source code, resource files, and an Android manifest. However, instead of compiling into an APK that runs on a device, an Android library compiles into an Android Archive (AAR) file that you can use as a dependency for an Android app module.

Why And When To Use?

When you’re building multiple apps that use some of the same components, such as activities, services, or UI layouts.
When you’re building an app that exists in multiple APK variations, such as a free and paid version and you need the same core components in both.

How To Create?

Step 1 : Creating module.

:- Either to create a new library module in your project.

Click File > New > New Module > Android Library > Next >Finish

:- Or converting an existing app module to Library module.

Open the build.gradle file for the existing app module. At the top, you should see the following:

Java

apply plugin: 'com.android.application'

1

apply plugin: 'com.android.application'
Change the plugin assignment as shown here:

Java

apply plugin: 'com.android.library'

1

apply plugin: 'com.android.library'
Click Sync Project with Gradle Files.

:- Or import the library module to your project.

Click File > New > Import Module.
Enter the location of the library module directory then click Finish.

Step 2: Setup dependency & configuration

:- In your settings.gradle file add

include ‘:app’, ‘:my-library-module’

Where “app” is application module, and “my-library-module” is library module.

:- Open the app module’s build.gradle file and add a new line to the dependencies block as shown in the following

compile project(“:my-library-module”)

:- Click Sync Project with Gradle Files.

Now Any code and resources in the Android library (my-library-module) are accessible to your app module (app), and the library AAR file is bundled into your APK at build time.

Development considerations:-

As you develop your library modules and dependent apps, be aware of the following behaviors and limitations.

Once you have added references to library modules to your Android app module, you can set their relative priority. At build time, the libraries are merged with the app one at a time, starting from the lowest priority to the highest.

Resource merge conflicts- The build tools merge resources from a library module with those of a dependent app module. If a given resource ID is defined in both modules, the resource from the app is used.If conflicts occur between multiple AAR libraries, then the resource from the library listed first in the dependencies list (toward the top of the dependencies block) is used.To avoid resource conflicts for common resource IDs, consider using a prefix or other consistent naming scheme that is unique to the module (or is unique across all project modules).
A library module can include a JAR library- You can develop a library module that itself includes a JAR library; however, you need to manually edit the dependent app modules build path and add a path to the JAR file.
A library module can depend on an external JAR library- You can develop a library module that depends on an external library. (for example, the Maps external library). In this case, the dependent app must build against a target that includes the external library (for example, the Google APIs Add-On). Note also that both the library module and the dependent app must declare the external library in their manifest files, in an <uses- library> element.
Library modules cannot include raw assets- The tools do not support the use of raw asset files (saved in the assets/ directory) in a library module. Any asset resources used by an app must be stored in the assets/ directory of the app module itself.
The app modules minSdkVersion must be equal to or greater than the version defined by the library- A library is compiled as part of the dependent app module, so the APIs used in the library module must be compatible with the platform version that the app module supports.
Each library module creates its own R class- When you build the dependent app modules, library modules are compiled into an AAR file then added to the app module. Therefore, each library has its own R class, named according to the library’s package name. The R class generated from the main module and the library module is created in all the packages that are needed including the main module’s package and the libraries’ packages.
Note: By default, the app module uses the library’s release build, even when using the app modules debug build type. To use a different build type from the library, you must add dependencies to the dependencies block of the app’s build.gradle file and set publishNonDefault to true in the library’s build.gradle file. For example, the following code snippet in your app’s build.gradle file causes the app to use the libraries debug build type when the app module builds in debug mode and to use the library’s release build type when the app module builds in release mode:

Java

dependencies { debugCompile project(path: ':library', configuration: 'debug') releaseCompile project(path: ':library', configuration: 'release') }

1
2
3
4

dependencies {
debugCompile project(path: ':library', configuration: 'debug')
releaseCompile project(path: ':library', configuration: 'release')
}

You must also add the following line inside the android block of your library’s build.gradle file to expose your library’s non-release configurations to projects that use it:

Java

android { ... publishNonDefault true }

1
2
3
4

android {
...
publishNonDefault true
}

Note, however, that setting publishNonDefault can increase build times.