preface

During Android development, some features are common or needed by multiple business parties.

In order to unify the functionality logic and avoid duplication of development, it is necessary to develop this functionality as an SDK.

background

Recently, I encountered similar requirements. After developing the SDK, I encountered some problems when integrating it into the project or providing it to others. Here I share them to avoid repeated problems for other developers who need to develop the SDK.

The content of the article is as follows:

  1. Comparison of integration modes
  2. Some holes in the AAR integration approach
  3. The difference between using Maven publish and maven to push the SDK to the Maven repository
  4. Tips
  5. conclusion

Comparison of integration modes

Once the SDK is developed, you need to provide an integration method that others can use. There are about three integration methods.

1. Provide the Module

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

Advantage: do not have what pit, want oneself to test only no problem, others can use directly commonly.

Disadvantages: If there is a follow-up update, you need to replace the whole amount to others. Also, if multiple modules are referenced in a project, the structure of the project adds a lot of code files. You can also accidentally change the SDK. Because the source code can be directly modified, there is no protection.

2. Provide AAR files

This integration involves compiling the SDK and providing AAR files to others.

Advantages: only one file, do not need to give specific source code.

Disadvantages: Pits in some cases, as discussed below. In addition, it is not convenient to update the SDK. Each update requires the user to replace the AAR file.

3. Push to repository (using MAVEN repository as an example) (recommended)

This integration means that the AAR file compiled by the SDK is pushed to the repository, which can then be referenced through implementation or API (compile for the old Gradle version).

Advantages: easy integration, similar to third-party library integration, convenient developers. And versioning.

Disadvantages: Maven Publish has a pit. See below for analysis.

The table is as follows:

Integrated way advantages disadvantages
Provide the Module There is no hole Maintenance trouble, no code protection
Provide AAR files There’s only one file There are pits, update trouble
Push to warehouse Easy integration, version management Maven Publish has a bug

Some holes in the AAR integration approach

Generally, SDK development is to encapsulate some functions for easy invocation, so it is relatively rare to introduce third-party libraries in Module. In this case, AAR integration is not a problem.

However, when your SDK introducing third-party libraries, such as libraries, such as Retorfit (not directly into the jar packages or aar package), at this time you use the aar integration, run to the corresponding Java code will prompt. Lang. NoClassDefFoundError error. This is the time when you

If you try to re-introduce the third-party libraries used by the SDK into your project, you will find that the application does not fail.

Therefore, we can draw the conclusion that:

An AAR cannot pass third-party dependencies

Don’t panic. There are more ways 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.

Consider that some OF the SDKS are intended for internal use, so use Maven as an example.

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

Maven Publish is actually an upgrade to Maven.

So Maven publish is generally preferred.

This project already uses Maven publish, so this project also uses Maven publish at the beginning.

The pit came.

Found the same error as AAR, dependency cannot be passed.

At this point, take a quick look at the POM file (the same directory as AAR) and see that there really are no dependencies. I looked it up on the Internet. Found discuss.gradle.org/t/using-the… Student: One question

Of course, there should be a corresponding way to deal with it, but due to the tight time requirement of the project, I did not want to spend too much time, so I did not find a solution for the moment.

If a friend knows, you can leave a message, the follow-up is free to study, there are solutions will be updated.

Therefore, the integration of Maven Publish is not discussed here.

In the end, maven’s push method was used to check the data.

So how do you use it?

  1. Add the following code to the build.gradle file of the Module remotely:
apply plugin: 'maven'// Specify maven uploadArchives {repositories {mavenDeployer {pom.groupid ="com.maven.demo"// Package name pom.artifactid ="login"// Create a custom version of the SDK"0.0.1"// Version number repository(url:"File://localhost/Users/ username/Library/Android/SDK/extras/Android/m2repository/") // Replace the username with your own machine name, local address}}}Copy the code

Run the uploadArchives task to report it.

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

Looking at the POM file, you can see that the dependencies are all there. 2. Use the remote repository to modify the preceding parameters.

apply plugin: 'maven'// Specify maven uploadArchives {repositories {mavenDeployer {pom.groupid ="com.maven.demo"// Package name pom.artifactid ="login"// Create a custom version of the SDK"0.0.1"// Version number repository(url:"Url") {
                authentication(userName: "Username", password: "Password")}}}}Copy the code

The url, user name, and password must be replaced separately.

If others need to use it, just add the following to Module:

implementation 'com. Maven. Demo: login: 0.01' 
Copy the code

So the composition of the warehouse is pom.groupid + pom.artifactid +pom.version

Tips:

  1. SDK development may encounter situations where the same version such as 0.0.1 often needs to be modified before it is released.

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

There are two ways to handle this.

First, update the version number, and make changes that depend on the new version.

Second, execute the following command to force a pull from a remote location, without caching.

./gradlew build --refresh-dependencies
Copy the code
  1. When using a remote repository, the normal username and password are not pushed directly to the code repository, but may be placed on the build machine.

You need to use an external file like local.properties to store it.

Properties (maven_user_name=username); / / maven_user_name=username

Received status code 401 from server: Unauthorized
Copy the code
  1. How to specify debug or Release using Maven form?

By adding in the Android block

android {
    defaultPublishConfig "release"
}
Copy the code

You can specify.

The AAR package can be seen by looking at build/ Outputs /aar of the Module.

You can view the local POM file by viewing the build/poms/pom-default. XML file of the Module.

  1. Some developers or if, in accordance with the above operation after Java. Lang. NoClassDefFoundError error, you can try the following:

Modify the

implementation 'com. Maven. Demo: login: 0.01' 
Copy the code

for

implementation 'com. Maven. Demo: login: 0.01' {
        transitive = true
}
Copy the code

conclusion

  1. Once the SDK is developed and distributed to others, it is best to put it in a remote repository (such as Maven)
  2. If there is an error that the third party library introduced by the SDK does not find, remember to check the repository to see if the POM file has corresponding dependencies

Pay attention to the public account communication together: