Module guide
An Android SDK delivery should place the library, sample app, interface documentation and build records on one version baseline. The AAR describes the packaged library, the sample app shows integration, the documentation defines calling constraints and build records trace the artifact to its source.
What the AAR and sample app provide
AAR is an Android library archive that can contain code, resources, a manifest and configured native libraries. APK is an installable application artifact. State which dependencies are packaged and which the client project must supply. The Android library documentation explains the library/application distinction and dependency handling.
ABI means application binary interface and identifies native-code requirements for the target runtime. Check it together with the system version, external libraries, model files and resource paths.
Swipe the table horizontally to view all columns.
| Artifact | Contents and purpose | Conditions to confirm |
|---|---|---|
| AAR library | Public interfaces, resources and included native files | ABI, system version, dependencies and resource loading |
| Demo sample app | Initialization, input, callbacks and basic interaction | Permissions, threading, lifecycle and runtime |
| Interface documentation | Parameters, callbacks, errors, cancellation and release | Agreement between documentation and code |
| Build records | Source revision, toolchain, settings, steps and artifact hash | Traceability, reproduction conditions and maintenance |
A checklist for the delivery index
Organize the material by purpose. Agree actual directory names and source scope within the project.
Swipe the table horizontally to view all columns.
| Material | Contents to define |
|---|---|
| Library and version | AAR file, version identity and hash |
| Integration sample | Demo project, run steps and required permissions |
| Dependencies and resources | External dependencies, native ABI, models and resource placement |
| Interfaces and failures | Parameters, threads, error codes, cancellation and release |
| Build and tests | Toolchain, build steps, devices, cases and known limits |
| Licensing and release | Third-party terms, distribution scope and sample-app signing responsibility |
Initial-phase acceptance
Keep the device, Android version, ABI, code revision and calling method consistent throughout the checks. Check initialization, repeated calls, cancellation, error responses and release. For camera or audio functions, review buffer ownership and asynchronous lifetime. Define long-text boundaries only for SDK tasks that actually process speech or text.
For performance and continuous operation, specify load, duration and record method. Agree production signing, store submission and client-app release separately. Completing a library package does not complete application-release acceptance.
Existing SDK material and packaging inputs
The RK3588-S offline TTS SDK case, in Chinese and RK3588 vision SDK case, in Chinese provide references under different functions, devices and test conditions. Read their performance and scope separately. Provide code, ABI, interfaces, dependencies and delivery targets through the RK3588 Android adaptation service, in Chinese to define packaging, integration and checks.
Online
Phone
WeChat
Top