Reference article:

What makes a good Android SDK

The actual production of the Android SDK development summary | end – developers headlines

Summary of Android SDK development in actual production

Android SDK development experience

Android SDK development and use

Android Studio(9): Reference jar and so file

Zero, basic concepts

What is the SDK?

The full name of SDK is Software Development Kit, which is a Software Development Kit. It is usually a specific Software package written to assist in the Development of a certain type of Software.

In a broad sense, SDK is a collection of development tools used to build applications for specific software packages, software frameworks, hardware platforms, operating systems, etc. In a narrow sense, SDK is a collection of new and independent tools developed and packaged based on system SDK that can complete specific functions and return relevant data.

The difference between App development and SDK development

App development is biased towards the user level, from UI display to business logic processing, processing user behavior in the whole process. However, SDK development tends to focus on functions, focusing on the development and implementation of functions, and the design and development of UI account for a small proportion.

Classification of the Android SDK

SDK can be divided into AAR, JAR and SO, and the relationship can be expressed as follows:

  1. The jar package

A Java Archive File is a platform-independent File format that combines many files into a compressed File. Based on the.zip format, jar files are used not only for compression and distribution, but also for deployment and encapsulation of libraries, components, and plug-ins. And can be used directly by tools such as compilers and JVMS. Jar files contain only class files and manifest files, not resource files such as images and all files in res. Directly into the liBS directory can be used.

  1. So library

In general, so is a library packaged with content from THE C or C++ language. To reference the so library, you need to copy and paste the so file into the “jniLibs” directory (if not, create it).

  1. Aar package

Android Archive is a binary Archive of Android library projects, containing collections of code, resources (images, layouts, etc.), so libraries, etc. When you unzip an AAR, you can see that the contents of each AAR may not be exactly the same, but will contain androidmanifest.xml, classes.jar, res, r.txt.

Build. Gradle configuration compile(name: ‘genius’, ext:’aar’)

How to choose?

If you are just developing or using a simple class library, use the generated.jar file.

If native is involved, or if performance needs to be improved, you can consider using the SO library.

If you need to develop or use a UI library that contains control layout files and resource files such as fonts, use an.aar file.

First, SDK development principles

There are two clear principles that govern the design of an SDK:

1, the principle of minimum availability, that is to use the least code, if not necessary to add entities;

2, the least dependence principle, that is, the minimum external dependence, if not necessary do not increase dependence.

  1. The basic principle of

One of the most important ground rules in SDK development is to be as stable as possible without affecting integrator functionality (e.g., no crashes, no performance issues, etc.).

  1. Design principles

2.1 Interface Ease of Use

  1. Control the number of interfaces
  2. Specification of interface naming

2.2 Coding Specifications

The best situation is that the integrator can see the code and know which VENDOR’s SDK it is. In other words, the unified coding specification of SDK forms the brand effect of our company and facilitates the use of integrators.

2.3 Cross-end Consistency

For the same SDK, try to keep the interface names and implementation logic of each end consistent.

2.4 Avoid relying on third-party libraries

  • Avoid conflicts caused by using the same tripartite library with the integrator and increase the integration difficulty of the integrator;
  • The tripartite library will be updated constantly. If a tripartite library is introduced, the SDK needs to be updated in time, which will add additional maintenance work;
  • Due to the introduction of tripartite libraries, troubleshooting is difficult when problems occur.

2.5 “Small” but “Sophisticated”

  • “Small” means that the SDK should be as small as possible. Avoid causing a large increase in the size of the App of the integrator, or it will cause the dissatisfaction of the integrator and even remove the SDK.
  • “Refinement” means focus on function. For example: our SDK is designed to be buried, and it would be inappropriate to provide a lot of common utility classes.

2.6 compatibility

In SDK development, the compatibility between the new version and the old version should be ensured. Common compatibility problems can be divided into two types:

  1. Compatibility of old and new interfaces: Expansibility should be considered in the design of functional interfaces.

  2. Compatibility with new functions: Some integrators use this function, so ensure that the function can be read properly. Some integrators do not use this feature, so make sure there are no exceptions.

  3. Complete SDK documentation

3.1 Access Guide

Complete user access guides are required for SDK integration and use, version update, and interface introduction. SDK access guide can be divided into:

  • The basic use
  • Use advanced
  • SDK API

A complete guidance document is still necessary because it can save a lot of integration costs and time. At the same time, the document needs to be properly planned and designed. Avoid too much content in one document that makes it difficult to read. For the usability section, it is best to have sample code to show.

3.2 Test Report

In the actual access process, many integrators need to provide related performance test instructions, which need to be prepared in advance. The test report can be output by r&d to facilitate subsequent support and reduce maintenance costs.

  1. Q&A

4.1 Don’t make imaginary needs

  • What if other customers don’t want to pass the configuration file and want to use the interface?
  • What if the user wants to delete the configured items in the configuration file?
  • What if the customer wants to restore the ignored configuration?

These imaginary requirements add a lot of extra work and delivery costs and have no real meaning. Therefore, it is important to avoid imaginary requirements in SDK development.

4.2 Too many Interfaces

There are often many initialization switch configuration interfaces in SDKS, which expose the set method for the user to set. This configuration item is usually configured once during initialization, so it is not necessary to provide the GET method to avoid too many interfaces. Too many interfaces increase the maintenance cost of the code, including the cost of late compatibility.

4.3 Cross-end Consistency

For SDK development, it is common to encounter the same requirement that needs to be realized synchronously on the Android, iOS and Web terminals, which requires the r&d and testing of the three terminals to communicate with each other to ensure the consistency of the logic of the three terminals. In this process, the most difficult to control is the consistency of the details. The problem of inconsistent details is usually caused by the fact that it is difficult to cover the test case and the r&d students have not communicated with each other about the detailed process.

Therefore, in order to avoid such problems, the implementation of the scheme for the details can allow the r&d students of the three ends to communicate with each other, strive to expose the inconsistent details during the r&d stage, and prevent the online inconsistent problems

Ii. Development methods

2.1 the new module

Create a new Module and reference it to the project

2.2 Compiling the AAR Package

Once the code is written, the build generates the RELEASE version of the AAR

Click the Build Variants bar in the lower left corner to change the Active Build Variant of the SDK module to Release

ReBuild project

The corresponding AAR package will be generated in the outputs folder of the corresponding Module directory

2.3 Other projects refer to AAR

Copy the AAR package above to the liBS folder of the corresponding module of other projects

And modify gradle configuration:

// same as dependencies
repositories {
    flatDir {
      dirs 'libs'}}Copy the code
/ / dependencies
implementation(name:'testsdk'.ext:'aar')
Copy the code

The AAR can be used under the corresponding Module when the project is in sync