Code open source design and implementation ideas

I. Background

Some customers have secondary development requirements for the project, and need to customize the function extension development of the existing APK.
In order to meet the needs of its secondary development, it is necessary to partially open the source code.
The principle for open source is mainly the principle of least known.
Mainly need to complete several goals:
1. Only open source relevant codes related to UI, and not open source other parts of the code.
2. For files that are not open sourced, document descriptions should be provided to explain related functions and related interfaces.
3. Finally, a source code file package that can be compiled and modified by the customer is formed and sent to the customer for use.

Second, design goals

1. Open source the project code to customers and provide a source code file.
2. The open source files only involve UI, not specific logic.
3. The source files that are open-sourced to customers must be compilable and run normally.
4. It is required to modify the code as little as possible in this open source process.

Three, detailed implementation plan and implementation ideas

Because the corresponding modular decoupling process has been done in the early stage of the project, this project is completed on the basis of the decoupling of the modular coupling relationship.
The basic solution is:
1. Open source the code that involves the UI lib and needs to be open sourced to the user for secondary development. This part of the code is retained according to the original file structure.
2. For the lib package not related to UI packaged into arr package and imported, keep the source code of this part, and obfuscate the logic code to avoid security problems at the code level.
3. Finally, a package of compliable and modifiable source code files that the user hides without revealing the part is formed and sent to the customer for use.

Basic ideas and steps

Current project block diagram:

Step 1: Determine the parts that need open source and those that don't (about 0.5 days)

Open source divides the components into two parts:
1. No need for open source parts:

1. The processing of the data logic of the basic components and the gate-lib part, as well as some underlying hardware control logic, has nothing to do with the UI, so there is no need to open source it.
2. Back-end interaction related lib: related to back-end interaction, this part is recommended to be reserved, exposure may have certain security problems, no need to open source.

2. Open source parts are required:

1. Registration-related lib: It involves the UI interface related to user registration. When the customer needs to modify some face acquisition logic, the user can modify it, and it needs to be open sourced to the customer.
2. Setting related modules lib: All scenarios involving apk system settings are easily involved in secondary development by customers, related to UI, and need to be open sourced to customers.
3. Collection-related lib: related to face collection. If users have scene requirements for face collection and need to use it, they need to open source to customers.
4. Platform UI-related lib: The main interface UI is related, and the key scenarios for customers to modify need to be open sourced to customers.
5. app-lib: where the overall entrance of the app is located and needs to be open sourced to customers.

In general, according to the principle of least knowledge, this open source will only open source the part related to UI and open source modified by customers to customers.The rest are selected as arr packages for import.

Step 2: Package the parts that do not need open source into arr packages

1. Use the gradlecompiler plugin that comes with Android Studio to generate aar files, and at the same time obfuscate the aar package to avoid code-level security issues.
2. Import the arr package into the app directory, and reference the related functions in the app directory.
3. Repeat this step continuously to complete all libs that need to be packaged into aar packages.

Step 3: Form a new code project file with the packaged arr package and the code that needs to be open sourced.

Combine the packaged aar file and the open source code file, delete the packaged aar file lib, and form a new, runnable code file project.

Step 4: Self-test whether the package can be compiled and run normally.

Compile the project and check if it is normal.
After the compilation is completed, run the APK to test whether the main process is normal, simulate the customer's secondary development scenario, and whether it can meet the customer's needs.

Step 5: Write the necessary interface documents and explanation documents.

The related interfaces of the open source part to the non-open source part need to be supplemented with an interface document. The secondary development of the open source part requires a secondary development document

Step 6: Combine code source files and related documents and send to customer