1. Introduction

This is the Unity Android IL2CPp perfect hotfix solution Demo (Git address) description.

Unlike existing hotfix solutions, it doesn’t introduce redundant languages (just UnityScript, c#…). There are no restrictions on Unity programming and coding. You can add any Compnents component to the GameObject in the presets and scenes, serialized and unserialized, and they can be reconfigured without additional markup. In short, all of Unity’s resources and scripts are replaceable under this solution.

The rest of this article will show you how to make and apply hotwatch files. In order to simplify the design of the Demo, the heat update files included in the Demo will be made in advance in a full update mode and typed into the Apk together. For specific projects, hot files should be put on the server, and CDN should be put on the official launch. It is OK to make incremental updates to create the same directory structure as in the paper.

2. Program Overview

When Unity exports the Android project (or Apk file) as IL2CPP, the code is compiled into Libil2CPP, and the associated resources, configuration, and serialization Data are exported to the Android Assets directory (Assets /bin/Data) in their respective formats. These two parts, libil2cpp and Assets, must match in the same package for Unity to work, otherwise Unity will crash at startup. This program is heat more these two parts.

The formal process of heating is shown below.

Process description:

• Step 1: Libbootstrap will check for Patch files before Unity’s logic is installed. If no Patch files have been applied after Apk is installed, no Patch files will be installed. If the heat is too high, there will be a Patch directory, go to the yes process. How to prepare the Patch directory will be described later.

• Step 2 Load the libil2CPp library of the architecture corresponding to the Patch directory (ARM /x86), and apply the updated files of assets directory.

• Step 3, start the Unity process, enter the first Unity scene, and execute the relevant Unity Script, usually C#, which we use as an example.

• Step 4 check whether there is a new patch on the server. This step is not demonstrated in demo and needs to be implemented by yourself.

• Step 5: Download the new patch. This step is not demonstrated in the demo, so you need to implement it yourself

• Step 6 Prepare the patch directory according to the rules. The detailed rules will be described later. In Demo, we just unpack the full update package. The full update package is packaged with the correct directory structure, so we don’t need to do anything else.

• Step 7 Call the libbootstrap interface to set the patch directory. Since libil2cpp has been loaded into the process, restart the APP to load the patch from the new patch directory. The example for setting the patch directory is shown in this Demo.

• Step 8, restart the APP. The Demo provides pure C# code.

• Step 9, there is no new Patch, then the game is normal.

See Chapter 3 for a more detailed description of the process and how to generate Patch files.

3. The Demo in detail

3.1. Demo Directory Structure

All project files are placed under the directory AndroidIl2cppPatchDemo. The following table describes the files and directories.

The project is managed with Git. The master branch is the parent package branch, version1 and version2 are the Regen1 and Regen2 branches. There will be some slight differences between branches. Diff can check the details. The packaging process and how to apply heat files are described in detail below.

3.2. Packaging process

All the packaging logic is in the file editor\ AndroidBuilder.cs. From the main menu of AndroidBuilder, you can see that there are 5 steps, which we call the process to distinguish it from the hot start process.

• Procedure 1: Export the Gradle Android project as IL2CPP. The Gradle Android project was chosen over the ADT Android project simply because Unity2018 no longer supports the ADT mode. The Demo does not rely on AndroidStudio, but the exported Android project directory structure is annotated in Gradle style, and the subsequent build steps are all calls to the original JDK/SDK. The Demo part of the code can be reused, but needs to be modified according to the requirements of the project.

• Procedure 2: The Android project needs to be modified because LibBootstrap needs to check to load the local patch before entering Unity’s frame loop. In most cases, you can reuse the code from this step. But if your project changes Unity Java’s inheritance, you need to check to see if this code is called. If not, the logic and resources in the subsequent Unity frame loop will use the corresponding file in Apk.

• Process 3: Generate heat heat file. As described in Chapter 2, Patch is divided into two parts, il2CPP library and assets/bin/Data directory. The specific code is provided, but it is important to observe the naming and relative path of each file. All files are compressed. For incremental packages, if the files before compression are unchanged, you do not need to create the corresponding compressed files. This part of the production of the compression part of the code can be reusable, the increment part needs to be realized by themselves, hot change files had better be added to the version management (SVN /git/…) In the.

• Procedure 4: Generate a packaged Windows script. The script only relies on JDK/SDK commands and can be reused. Once the script is generated, the Android project is no longer dependent on Unity and can replace the file at will and call the script again to generate a new Apk. Note that the package used so dynamic library, is the PKg_raw directory so file, please note when replacing. For the first time, the Keystore directory and the corresponding signature file will be generated in the Unity directory. You can replace this signature and change the signature password in the exported script.

• Procedure 5: Execute the script in procedure 4 to generate an Apk installation file that can be reused.

The menu “Running Step 1, 2, 4, 5 for the base version” is also provided under the main menu AndroidBuilder, which is used to build the base package version with one key. The base package does not need to make the patch file, so the process 3 is omitted. And menu “Runnnig Step 1-4 for Patch Versions”, this is for one-click build patch, because in demo, there is no need to export the Apk file.

A few more words about packing here. If you don’t use AssetBundle, Unity will export all scenes and dependencies to assets/bin/Data in their own format, which can also be improved. However, don’t do this, because small changes can affect multiple files and cause hot files to become too large. It is better to use the AssetBundle method to make a clear division of resources, packaged AssetBundle in another directory under assets. Note that the libil2cpp library and assets/bin/Data files match. Runtime can rewrite AssetBundleManager. OverrideBaseDownloadingURL load the latest AssetBundle.

3.3. Apply heat files at run time

Let’s review the flow chart from Chapter 2 to further illustrate the packaging process with the Demo code.

Packaging process 2 inserts three lines of Java code before Unity’s game logic.

+        System.loadLibrary("main");
+        System.loadLibrary("unity");
+        System.loadLibrary("bootstrap");
        mUnityPlayer = new UnityPlayer(this);
Copy the code

These three lines of code ensure that steps 1-2 in the figure above are executed before Step 3, which begins with the next line of mUnityPlayer code. All logic after step 3 is Unity Script (c#,…) from il2cpp library. . If there is any change in the logic of the hot update, it will be reflected after the hot update. If the bug in this part does not affect the next hot update, it can be fixed through the hot update. Otherwise, users should be instructed to clear local data and update the logic of the parent package to the latest. Therefore, in the application of the scheme, it is still necessary to ensure the stability of the hot part of the code and can not be changed at will.

As mentioned above, there is no logic related to Step 4 and Step 5 in Demo. For the preparation of Patch in Step 6, Demo simply decompress the full compressed package, and the relevant logic is in Script/ versionsettor. cs file. Before updating the directory, ensure that libil2cpp is decompressed and the file name is consistent with Demo. Files under assets_bin_Data do not need to be decompressed. Ensure that the directory structure is consistent with Demo. For incremental updates, the files in the Patch directory should be the modification files relative to the parent package. In continuous hot more, should guarantee the before step 7, the integrity of the local current Patch directory (can ensure the running App normal execution), the new Patch should be a new directory, through the form of a hard link from extraction need not change the current Patch directory file, ready to step 7, after the old Patch directory will be deleted after restart. The code for steps 7 and 8 is also in Script/ versionsettor.cs and looks like this

        //4. tell libboostrap.so to use the right patch after reboot
        string error = Bootstrap.use_data_dir(runtimePatchPath);
        if(! string.IsNullOrEmpty(error)) { messageBox.Show("use failed. path:" + zipLibil2cppPath + ", error:" + error, "ok", () => { messageBox.Close(); });
            yield break;
        }

        //5. reboot app
        yield return StartCoroutine(Restart());
Copy the code

4. Verify and Build

4.1. Verify

Install precompiled Apk files and switch between versions by clicking the button.

Apk link

4.2. The Build

Rely on

• Unity (I’m using Unity2017/Unity2018)
• The JDK. (I use JDK1.8)
• Android SDK.(I use Android SDK Platform 23 and Build Tools 26.0.2 (lower than 26.0.2, Unity2018 does not support), it is better to use these two versions, otherwise I have to download again)
• Android NDK r13b. (Unity il2cpp原来只支持这个版本，现在不知道放开没，反正这个版本没问题)
• Git

The Build guide

• 1. Set the JDK/SDK/NDK path in Unity (Edit->Preference->External Tools) and the package code will be read from Unity.
• 2. If your Android SDK build Tools version is not 26.0.2, you need to modify the code androidBuilder.cs, line 14.
• 3. If you are using an Android platform other than Android-23, modify the code androidBuilder.cs, line 15.
• 4. AndroidBuilder->Run Step 1, 2, 4, 5 for base version
• 5. Git checkout Version 1 or Version 2. Go to AndroidBuilder->Run Step 1-4 for Patch Version. The corresponding files in the PrebuildPatches directory will be updated.

5. Remaining work and suggestions

Packaging part

• Modify the Settings based on the actual project.
• Incremental versioning management of hot change files.

Runtime part

• Check for new versions and download hot update files.
• Prepare the Patch directory for continuous incremental updates.
• Manage resources with Asset Bundles.

In addition, try to automate the packing with one click, one at a time, unless you want to share the moon on packing night. In addition, the low-cost packaging process, we are willing to see the results on the real machine, conducive to the stability of the product. Demo actually provides a set of automation framework and scripts, understand thoroughly, as their own use, is also a blessing. If there is a better way, welcome to discuss.