How to quickly and efficiently access the SDK-Implementation of packaging tools (dynamic integration of decompilation resources into channel packages) and sdk Decompilation

How to quickly and efficiently access the SDK-Implementation of packaging tools (dynamic integration of decompilation resources into channel packages) and sdk Decompilation

Original address: http://www.uustory.com /? P = 1472
The core idea of the complete u8sdk is to allow our SDK access costs to be controlled at 1 rather than N. What do you mean? That is, when I developed the first game, I took these sdks. When I developed the second and third games, This SDK can be reused as much as possible, instead of developing a game, you can access the sdk from various channels. All games can use the same SDK access framework to quickly complete SDK access. So how can we do this in U8SDK? Please refer to our general idea:

Game A, game B, and game C are three different games. For them, they only need to call the interfaces provided by the U8SDK abstraction layer to access all the sdks. This time is just an hour.

However, we know that sdks of various channels have different configurations such as APPID and APPKEY for different games. Therefore, we need to put the configuration information in the configuration file. During packaging, different games obtain channel packages for each SDK through packaging tools based on different configurations. So how are sdks like UC and dangle integrated? In fact, it is very simple. Every SDK access is to create a separate project, introduce the jar package of the SDK abstraction layer, and then implement the plug-in interface in the SDK abstraction layer. Then, the resources required by the SDK, classes. dex, libs, and other resources and code are stored in the SDK configuration directory corresponding to the packaging tool. For example, the uc sdk will be placed in the config/uc directory of the packaging tool, and the SDK resources and code will be connected. At the same time, we also need two configuration files. One is config. xml. We use it to configure the parameters of this channel. Such as APPID and APPKEY. At the same time, configure which directories need to be copied to which directories in the apk. In addition, you must configure activity, service, and permission in AndroidManifest. xml for SDK access. We put this information in SDK_Manifest.xml. Then, when packaging, combine the information of this file into AndroidManifest. xml of the parent package. Let's take a look at the packaging tool. You may wonder how the packaging tool outputs the game Mother package that is only connected to the abstraction layer as channel packages for each SDK. Here, let's take a look at the work of the packaging tool:

1. the input of the packaging tool is the apk package to be packaged, also called the parent package. Introduce the jar package of the sdk abstraction layer in the game and call the interface of the abstraction layer. Complete the access and compress it into an apk. 2. The packaging tool first uses apktool-d to decompile the parent package. Decompile to the temporary working directory corresponding to the channel. 3. Rename the package name. We know that the package in AndroidManifet. xml is the package name. To prevent conflicts caused by re-generating the R file, we set a suffix for each channel. For example, UC is suffixed with. uc. Dangle, suffix. dl, etc. If the channel SDK has clear requirements and uses the suffix they provide, use the suffix they provide. If not, set one by yourself. 4. Copy SDK resources. Copy the SDK resources corresponding to the channel from the corresponding SDK configuration directory to the temporary working directory after decompilation. 1) copy the assets Directory, libs directory, and res directory of the SDK. 2) copy the classes. dex is also decompiled into the smali format and copied to the decompiled temporary working directory. 3) the content in SDK_Manifest.xml is merged into the AndroidManifest in the game directory. in xml. 5. Generate the configurations required for the game. 1) For the config. APPID, APPKEY, and other information configured in xml are added to AndroidManifest as needed. in xml, we add it to AndroidManifest. meta-data in xml. For other parameters, we will generate a develop_config.properties file under the assets Directory. 2) For the plug-in information configured in config. xml in the SDK directory, We will generate a plugin_info.xml file under the assets Directory. In this way, the SDK abstraction layer will read this configuration to instantiate the corresponding plug-in. 6. regenerate the R file. Some channels need to support their screen views. Based on our flash screen solution (which will be specifically introduced later), we need to re-generate the R file to index our flash screen resource images and other information. 7. repackage and use apktool-B to re-package the merged resources and code. 8. Sign and optimize the package. Some channels require the signature files they provide. Therefore, we have also configured the signature files. You can configure different signature files based on different channels. 9. After the above steps, a channel package is generated. Through the above packaging process, we already know how a single channel package is generated. Then, as shown in the first image, our packaging tool uses the channel packages for different channel sdks at the same time. How do we implement it? See:

Each game has a global configuration with the channel to be packaged. In this way, the packaging tool first reads the configuration and then packages each channel according to the preceding packaging process. The channel package corresponding to each channel is generated in the output directory.

So far, I believe you have a comprehensive understanding of the packaging tools in U8SDK. However, this is not perfect. For example, we can remove parameters from the configuration and adopt an interface-based management method. In this way, you can use this tool for operation or planning. program developers no longer need to be responsible for packaging. The packaging efficiency and speed can also be continuously optimized. Delete unnecessary file operations and reduce unnecessary processes. The source code of the packaging tool is endless for three days and three nights. Therefore, we recommend that you familiarize yourself with the packaging tool based on the source code. Finally, you can master it and modify it as you like.
Author: Xiao Hei More articles welcome to the blog: http://www.uustory.com