Develop & Publish your own SDK in Android - Part 1(Know an AAR file)
Tags: android, sdk, gradle, aar
Published: 2019-01-27 13:59:34

---
title: Develop & Publish your own SDK in Android - Part 1(Know an AAR file)
published: true
description: First article of the series of developing and publishing your own Android library. This is about introduction of an AAR file.
cover_image: https://thepracticaldev.s3.amazonaws.com/i/a3fcuizve1znyo0s8lxw.png
tags: android, sdk, gradle, aar
---

_“Android is the kind of runaway smash hit that techies spend their careers dreaming about.” - Daniel Lyons_


A few days ago, we launched an Android library called [App Utility](https://github.com/mohitrajput987/android-utility), which has various utility APIs which are used in almost all Android projects i.e. validations, shared preferences etc. This library is in the initial development face and launched specially to write this tutorial.


In addition to JAR files, the Android also makes use of a binary distribution format called Android ARchive (AAR). The .aar bundle is nothing but the binary distribution of an Android Library Project.

An AAR is similar to a JAR file, but it can contain both resources and compiled byte-code. An AAR file can be included in the build process of an Android app similar to a JAR file.


As we all are familiar, in Android Studio, if you wish to include any library, for example, SmilePass Face SDK, you can do it by adding following lines to build.gradle file-

```gradle
dependencies {
implementation 'com.otb.utility:preference:0.0.1'
}
```

Have you ever wondered how does gradle pull library from the repository? Basically, we need to know that a gradle dependency string consists of three parts-

```gradle
dependencies {
implementation 'GROUP_ID:ARTIFACT_ID:VERSION'
}
```

In the above example, *GROUP_ID* is `com.otb.utility`, *ARTIFACT_ID* is `preference` and *VERSION* is `0.0.1`.

**GROUP_ID-** It defines the name of the library group. It is possible that multiple libraries which perform the job of the same context can belong to the same GROUP_ID. For example, the Android support library has the same GROUP_ID com.android.support for multiple support libraries. Here is the example-

```gradle
dependencies {
    implementation 'com.android.support:design:' + supportLibVersion
    implementation 'com.android.support:appcompat-v7:' + supportLibVersion
    implementation 'com.android.support:recyclerview-v7:' + supportLibVersion
    implementation 'com.android.support:support-v4:' + supportLibVersion
    implementation 'com.android.support:exifinterface:' + supportLibVersion;
}
```

When you add a gradle dependency to the build.gradle file and sync the project, Gradle will ask maven repository if corresponding AAR and other files exist.  For example, for the gradle dependency com.smilepass.mobilesdk:facesdk:1.0.0, you could find its library files from [here](http://jcenter.bintray.com/com/otb/utility/preference/0.0.1).
Then Android Studio downloads those files to our machine and compiles the project. Now you can access functionalities of this SDK in your project.

## Know an AAR File Format
AAR file is developed on top of a JAR file. It was invented because JAR file cannot contain Android specific files i.e. resources, manifest, assets, JNI etc. An AAR file contains all these things and it is a normal compressed file like JAR. It contains JAR file inside it with the classes.jar name. The structure of the AAR file is as follows-

```
- /AndroidManifest.xml (mandatory)
- /classes.jar (mandatory)
- /res/ (mandatory)
- /R.txt (mandatory)
- /assets/ (optional)
- /libs/*.jar (optional)
- /jni/<abi>/*.so (optional)
- /proguard.txt (optional)
- /lint.jar (optional)
```

## Develop & Publish Your Own Android Library
When you get a chance to develop your own SDK for the first time, few questions are likely to come in your mind-
What are the best practices to structure and develop an SDK?
How to obfuscate SDK, how is it different from normal application projects?
Where and how to publish SDK to create its Gradle dependency?
How to provide tutorials and sample apps to developers for the integration guide?

So that’s all? Are these questions enough to get started?
The answer is - NO.
You might not realize, but each question is the root of other sub-questions. When you dive in the ocean of these questions, you will feel many things coming towards you. To float your boat well, we have summarized these questions in this tutorial.

To get started with the development of your own Android library, read the [PART-2](https://dev.to/mohitrajput987/develop--publish-your-own-sdk-in-android---part-2getting-started-with-sdk-development-3159) of this article series.