Android SDK Development - Release and Use Pitfalls

Preface

During the Android development process, some functions are common or required by multiple business parties.

In order to unify functional logic and avoid duplicate development, it is necessary to develop this function into an SDK.

background

It just so happened that I encountered a similar need recently. After developing the SDK, I encountered some pitfalls when integrating it into the project or providing it to others. I would like to share them here to avoid other developers who need to develop SDKs from repeating the same pitfalls.

The article is to explain the following:

1. Integration method comparison
2. Some pitfalls of AAR integration
3. The difference between using Maven publish and Maven to push the SDK to the Maven repository
4. Tips
5. Summarize

Integration method comparison

After the SDK is developed, it is necessary to provide an integration method so that others can use it.

There are roughly three integration methods.

1. Provide Module

This integration method makes the entire SDK source code available to others.

• Advantages: There are no pitfalls. As long as you test it yourself and there are no problems, others can generally use it directly.
• Disadvantages: If there are subsequent updates, the entire amount will need to be replaced by others.

Moreover, if multiple modules are referenced in the project at the same time, many code files will be added to the project structure.

It is also possible that the SDK has been changed accidentally.

Because the source code can be modified directly without any protection.

2. Provide AAR file

This integration method is to compile the SDK and provide the AAR file to others.

• Advantages: There is only one file and no specific source code is required.
• Disadvantages: There are pitfalls in some cases, which will be discussed below. In addition, it is inconvenient to update the SDK, and each update requires the user to replace the AAR file.

3. Push to the warehouse (here takes MAVEN warehouse as an example) (recommended)

This integration method pushes the AAR file compiled by the SDK to the warehouse, which can be referenced later through implementation or api (compile for old versions of Gradle).

• Advantages: Easy integration, similar to third-party library integration, convenient for developers. And version management.
• Disadvantages: Maven publish has a pitfall. See the analysis below.

The table comparison is as follows:

Integration method Advantages and Disadvantages Provide Module without pitfalls Maintenance is troublesome, no code protection Provide AAR file Only one file has pitfalls, update is troublesome Push to warehouse Convenient integration, version management Maven publish has pitfalls

Some pitfalls of AAR integration

Generally, SDK development encapsulates some functions for easy calling, so third-party libraries are rarely introduced into modules. In this case, there is no big problem with using AAR integration.

However, when you introduce a third-party library, such as Retorfit, into your SDK (not directly into a jar package or aar package), you use AAR integration and a java.lang.NoClassDefFoundError error will be displayed when running the corresponding code.

[[252825]]

The Module runs fine, but why does AAR report an error?

If you try to import the third-party library used by the SDK into the project again, you will find that the program does not report an error.

Therefore we can conclude that:

• AAR cannot transitively pass third-party dependencies

Don't panic, there are always more solutions than problems.

We can solve this problem by pushing the SDK to the repository.

There are many push repositories, such as the open source jcenter.

Here we consider that some SDKs are for internal use within the company, so we use Maven as an example to explain.

The difference between using Maven publish and Maven to push the SDK to the Maven repository

Maven publish is actually an upgrade of Maven.

Therefore, maven publish is generally preferred.

The project here has already used Maven publish, so we will also use Maven publish at the beginning.

As a result, the pit came.

It was found that the same error as AAR occurred and the dependency could not be transferred.

Here, I quickly took a look at the pom file (in the same directory as AAR) and found that there were really no dependencies.

I checked the information online.

• https://discuss.gradle.org/t/using-the-maven-publish-plugin-no-dependencies-in-pom-xml/7599

I have a question

[[252826]]

Of course there should be a corresponding way to deal with it, but due to the tight time requirements of the project and not wanting to spend too much time, I have not found a solution yet.

If anyone knows this, please leave a message. I will study it later and update the article if there is a solution.

Therefore, the integration method of Maven publish is not discussed here.

Finally, I consulted the information and used the Maven push method.

So how to use it?

1. Use the local repository first, make sure everything is ok, then use the remote one

Add the following code to the build.gradle file of the Module:

 apply plugin: 'maven' //Specify the use of Maven
 uploadArchives {
 repositories {
 mavenDeployer {
 pom.groupId = "com.maven.demo" //package name
 pom.artifactId = "login" //SDK function, just customize one
 pom.version = "0.0.1" //version number
 repository(url: "file://localhost/Users/用户名/Library/Android/sdk/extras/android/m2repository/" ) //Replace the username with your own machine name, local address
 }
 }
 }

Execute the uploadArchives task to report.

Then go to the directory specified by the above URL or open it through a browser to see the uploaded files.

Looking at the pom file, you can see that the dependencies are all above.

2. Use a remote repository and make slight modifications to the above.

 apply plugin: 'maven' //Specify the use of Maven
 uploadArchives {
 repositories {
 mavenDeployer {
 pom.groupId = "com.maven.demo" //package name
 pom.artifactId = "login" //SDK function, just customize one
 pom.version = "0.0.1" //version number
 repository(url: "URL" ) {
 authentication(userName: "username" , password : "password" )
 }
 }
 }
 }

Remember to replace the URL, username, and password respectively.

When others need to use it, they only need to add the following to the Module:

 implementation 'com.maven.demo.login.0.01'  

So the composition of the warehouse is pom.groupId+pom.artifactId+pom.version

Tips:

1. SDK development may encounter the situation where the same version, such as 0.0.1, often needs to be modified before release.

At this time, if you push the modified SDK to the remote, the local project may still use the old content.

There are two ways to deal with this situation.

• First, update the version number and modify the dependency on the new version.
• Second, execute the following command to force pulling from the remote without using the cache.

 ./gradlew build --refresh-dependencies  

2. When using a remote repository , the username and password are generally not pushed directly to the code repository, but may be placed on the build machine.

At this time, you need to use an external file similar to local.properties to store it.

At this time, there is a pitfall that needs to be reminded. When defining in local.properties, such as maven_user_name=username, remember not to add double quotes, otherwise authentication will fail and the following prompt will appear:

 Received status code 401 from server: Unauthorized

3. How to specify debug or release when using Maven?

By adding in the android block

 android {
 defaultPublishConfig "release"  
 }

Can be specified.

You can see the aar package by viewing the Module's build/outputs/aar.

You can see the local pom file by viewing the build/poms/pom-default.xml of the Module.

4. If some developers still get the java.lang.NoClassDefFoundError error after following the above steps , you can try the following:

Revise

 implementation 'com.maven.demo.login.0.01'   

for

 implementation 'com.maven.demo.login.0.01' {
 transitive = true  
 }

Summarize

• 1. After the SDK is developed, it is best to release it to other people for use in a remote repository (such as Maven). 2. If an error occurs that the third-party library introduced by the SDK is not found, remember to check the pom file in the repository to see if there is a corresponding dependency.