Common Android SDK Development Approaches and Their Implementation

Android SDK development can be approached in several ways, each with its own packaging format, integration steps, and use‑case scenarios. This article introduces five typical SDK development methods, focusing on the fourth and fifth approaches that involve pluginization and cross‑process communication.

1. Jar‑based SDK

The simplest form is a Jar SDK, built as a library module with a build.gradle configuration. After compilation, the resulting classes.jar is placed under /intermediates/aar_main_jar/ . Developers copy the JAR into the libs directory of their Android project and add a dependency in build.gradle :

dependencies {
    // ... other dependencies ...
    // Import JAR file
    implementation files('libs/yourlibrary.jar')
}

Typical Jar SDKs include logging libraries, JSON parsers, and network utilities such as OkHttp.

2. SO‑based SDK

SO libraries require native C/C++ code and often involve JNI and CMake (or the older android.mk ) for compilation. The compiled native libraries are located under /intermediates/stripped_native_libs/ for architectures like arm64-v8a, armeabi‑v7a, x86, x86_64 . To use them, copy the .so files into the project’s libs folder and configure the JNI source set:

sourceSets {
    main {
        jniLibs.srcDirs = ['libs']
    }
}

Common SO SDKs include Unity game engines, FFmpeg‑based audio‑video processing, QR‑code scanning, and live‑streaming libraries.

3. AAR‑based SDK

An AAR package extends the Jar approach by bundling resources, manifest entries, and optionally native libraries. It can contain UI components (e.g., payment SDKs with activities), required permissions, and even embedded SO files. Developers can publish AARs to a Maven repository or copy them directly into the project:

implementation 'com.scwang.smart:refresh-layout-kernel:2.0.0-alpha-1'
// or
implementation files(name: 'my-sdk', ext: 'aar')

4. Dex‑plugin SDK

This method leverages Android’s dynamic class loading to deliver a fully updatable SDK. It requires a solid understanding of plugin architecture and Dex manipulation. The example demonstrates a logging SDK split into a model library ( wx_sdk4 ) defining an IWXLog interface, a loader interface ( IXLogLoader ), and a runtime implementation that can download and load a Dex plugin on demand.

interface IWXLog {
    fun e(tag: String, message: String)
    fun i(tag: String, message: String)
    fun v(tag: String, message: String)
}

interface IXLogLoader {
    fun isDownloadSuccess(): Boolean
    fun load(context: Context)
    fun getWXLog(): IWXLog
}

object WXLogger {
    fun getIXLogLoader(context: Context): IXLogLoader {
        val localFile = DynamicManageUtils.getDxFile(context, "d_dex", getDlfn("IXLogLoade_dex", 1000))
        return if (localFile.exists())
            WXClassLoader(localFile.absolutePath, null, context.classLoader)
                .getInterface(IXLogLoader::class.java, "com.example.PluginImpl")
        else XLogLoaderImpl.instance
    }
}

Clients obtain the logger via WXLogger.getIXLogLoader(this).load(this) and then call SampleApplication.xLogLoader.getWXLog().e(...) .

5. Apk‑installation SDK

This approach packages the SDK as a separate APK without a launcher icon. It can contain resources, SO libraries, and AIDL interfaces for cross‑process communication, making it suitable for devices such as POS terminals, kiosks, or automotive systems. The APK runs as a foreground service to stay alive.

<service
    android:name="com.wx.sdk5.MyService"
    android:enabled="true"
    android:exported="true"
    android:foregroundServiceType="mediaPlayback">
    <intent-filter>
        <action android:name="com.wx.sdk5.aidl" />
    </intent-filter>
</service>

An AIDL interface defines the contract:

interface IMyAidlInterface {
    void basicTypes(int anInt, long aLong, boolean aBoolean,
                    float aFloat, double aDouble, String aString);
}

The service implementation logs received calls, and a client library ( SDK5Impl ) binds to the service, forwards method calls, and manages the connection lifecycle.

Summary

The article summarizes five common Android SDK development patterns. Jar, SO, and AAR are static and cannot be updated dynamically. Dex‑plugin SDKs enable full runtime updates but require plugin‑related expertise. Apk‑installation SDKs allow complete decoupling of code, resources, and native libraries, with the caveat that AIDL data transfer should stay within reasonable size limits.