Multi-application dynamic loading method suitable for openharmonyL0

Abstract

The invention provides a multi-application dynamic loading method suitable for openharmonyL0, and the method comprises the steps: compiling an App logic code of each App to generate an App.img runnable file, packaging the App.img runnable file, a Manifest.json description file and a js resource file to generate an App package, and storing the App package in a file system of an APP layer; when the system application module launcher loads the App.img runnable file into a memory to run and initialize the App.img runnable file, the App application interface module of the NAPI module is called, and the corresponding js resource file in the file system is loaded through the App application interface module. An App.img runnable file of an App logic code is dynamically loaded to a memory and dynamically registered to a system kernel, so that an openharmony system can support the function of dynamically loading different applications to run.

Description

Technical Field

[0001] The invention belongs to the technical field of application design, and in particular relates to a multi-application dynamic loading method suitable for openharmonyL0. Background Art

[0002] At present, in many fields such as the financial field, the previously commonly used open-rtos system has been converted to the openharmony system, such as cloud speakers, code scanning terminals, and simple terminal products with display screens. Among them, the openharmony system is an open source operating system. However, when converting to the openharmony system, due to hardware resource issues, only lightweight systems (openharmonyL0 systems) can be adapted. The current lightweight system adopts the method of compiling application code and system code into a bin file, which has the following problems: (1) If you only need to modify the logic of the application, you must compile the system at the same time, resulting in long compilation time, large compiled files, low development efficiency, and longer remote upgrades of application versions. The application version is difficult to maintain. (2) The application code and system code are mixed together, resulting in different applications needing to maintain the same set of system code, which has high maintenance costs. Summary of the invention

[0003] In view of the defects in the prior art, the present invention provides a multi-application dynamic loading method suitable for openharmonyL0, which can effectively solve the above problems.

[0004] In order to achieve the above object, the present invention adopts the following technical solution:

[0005] The present invention provides a multi-application dynamic loading method applicable to openharmonyL0, comprising the following steps:

[0006] Step 1: compile the App application logic code of each App application to generate an App.img executable file;

[0007] Step 2: Package the App.img executable file, Manifest.json description file, and js resource file to generate an App application package, and store it in the file system of the App application layer;

[0008] Step 3, the openharmony system layer includes: a system application module launcher, a logic method registration function open to the application layer, and a NAPI module; wherein the NAPI module configures an App application interface module;

[0009] Step 4, compile the system application module launcher, logic method registration function and NAPI module of the openharmony system layer to generate the sys.img executable file, and store it on the MCU built-in flash;

[0010] Step 5: When the device is running, first load the sys.img executable file from the flash to run the system application module launcher;

[0011] Step 6: When a certain App application needs to be loaded, load it in the following way:

[0012] Step 6.1, first, the system application module launcher finds the corresponding App application package in the file system;

[0013] Step 6.2, the system application module launcher verifies the integrity and legality of the found App application package. After the verification passes, execute step 6.3;

[0014] Step 6.3, the system application module launcher loads the App.img executable file in the App application package into the memory to run and initialize;

[0015] At the same time, when the App.img executable file is loaded into the memory to run and initialize, the App.img executable file calls the logic method registration function to dynamically register the App application logic code in the App.img executable file to the openharmony system layer;

[0016] Step 6.4, the system application module launcher calls the App application interface module of the NAPI module, and loads the corresponding js resource file in the file system through the App application interface module;

[0017] Therefore, the system application module launcher is used to load the App.img executable file and js resource file of the App application, thereby completing the dynamic loading of the App application.

[0018] Preferably, the Manifest.json description file is used to describe the version, package name, and display name of the App application package.

[0019] Preferably, the APP application layer has a UI interface, and the UI interface has App application buttons for various App applications;

[0020] When one of the App application buttons is clicked, it triggers the need to load the corresponding App application.

[0021] Preferably, in step 6.3, specifically: the system application module launcher loads the App.img executable file in the App application package into the memory ram to run and initialize, and initializes the stack and global variables of the app.

[0022] Preferably, when the App.img executable file is loaded into the memory to run and initialize, the startup method main function of the App.img executable file is jumped, and the logic method registration function is called in the main function to dynamically register the App application logic code in the App.img executable file to the openharmony system layer.

[0023] Preferably, in step 6.4, when the App application interface module loads the corresponding js resource file in the file system, it first determines whether the openharmony system layer has registered the App application logic code; if not, an error is reported.

[0024] Preferably, the App application interface module includes three interfaces: a synchronous call interface, an asynchronous call interface and a callback call interface.

[0025] The multi-application dynamic loading method applicable to openharmonyL0 provided by the present invention has the following advantages:

[0026] 1. Separate the App application logic code related to App users from the kernel of the system layer, so that the system kernel code is more unified and basically does not need to be modified or modified less;

[0027] 2. After the App application logic code is stripped off, the App.img executable file is generated, and it is packaged with the Manifest.json description file and the js resource file to generate the App application package, thereby realizing a strong association between the App application logic code and the js resource file, solving the problem of mismatch between the App application logic code and the js resource file in the prior art;

[0028] 3. The App.img executable file of the App application logic code is dynamically loaded into the memory and dynamically registered into the system kernel, so that the openharmony system can support the function of dynamically loading different applications. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] Figure 1 A schematic diagram of a flow chart of a multi-application dynamic loading method applicable to openharmonyL0 provided by the present invention;

[0030] Figure 2 This is the format diagram of the App application package in the prior art;

[0031] Figure 3 This is a diagram of the interaction between the App application package and the openharmony system layer in the prior art;

[0032] Figure 4 This is the format diagram of the App application package provided by the present invention;

[0033] Figure 5 A diagram of an interaction mode between the openharmony system layer and the App application package provided by the present invention;

[0034] Figure 6 Two App application package format diagrams provided by the present invention;

[0035] Figure 7 This is another diagram of the interaction mode between the openharmony system layer and the App application package provided by the present invention. DETAILED DESCRIPTION

[0036] In order to make the technical problems, technical solutions and beneficial effects solved by the present invention more clearly understood, the present invention is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not used to limit the present invention.

[0037] See also Figure 1 The present invention provides a multi-application dynamic loading method applicable to openharmonyL0, comprising the following steps:

[0038] Step 1: compile the App application logic code of each App application to generate an App.img executable file;

[0039] Step 2: Package the App.img executable file, Manifest.json description file, and js resource file to generate an App application package, and store it in the file system of the App application layer;

[0040] Among them, the Manifest.json description file is used to describe the version, package name and display name of the App application package.

[0041] The APP application layer has a UI interface, and the UI interface has App application buttons of various App applications; when one of the App application buttons is clicked, it triggers the need to load the corresponding App application.

[0042] Step 3, the openharmony system layer includes: a system application module launcher, a logic method registration function open to the application layer, and a NAPI module; wherein the NAPI module configures an App application interface module;

[0043] Step 4, compile the system application module launcher, logic method registration function and NAPI module of the openharmony system layer to generate the sys.img executable file, and store it on the MCU built-in flash;

[0044] Step 5: When the device is running, first load the sys.img executable file from the flash to run the system application module launcher;

[0045] Step 6: When a certain App application needs to be loaded, load it in the following way:

[0046] Step 6.1, first, the system application module launcher finds the corresponding App application package in the file system;

[0047] Step 6.2, the system application module launcher verifies the integrity and legality of the found App application package. After the verification passes, execute step 6.3;

[0048] Step 6.3, the system application module launcher loads the App.img executable file in the App application package into the memory to run and initialize, and initializes the stack and global variables of the app.

[0049] At the same time, when the App.img executable file is loaded into the memory to run and initialize, the App.img executable file calls the logic method registration function to dynamically register the App application logic code in the App.img executable file to the openharmony system layer;

[0050] The specific implementation method is:

[0051] When the App.img executable file is loaded into the memory for execution and initialization, the startup method main function of the App.img executable file is jumped to call the logic method registration function in the main function to dynamically register the App application logic code in the App.img executable file to the openharmony system layer.

[0052] Step 6.4, the system application module launcher calls the App application interface module of the NAPI module, and loads the corresponding js resource file in the file system through the App application interface module;

[0053] Specifically, the App application interface module includes three interfaces: synchronous call interface, asynchronous call interface and callback call interface.

[0054] When the App application interface module loads the corresponding js resource file in the file system, it first determines whether the openharmony system layer has registered the App application logic code; if not, an error is reported.

[0055] Therefore, the system application module launcher is used to load the App.img executable file and js resource file of the App application, thereby completing the dynamic loading of the App application.

[0056] To facilitate understanding of the present invention, a comparative example is introduced below:

[0057] In the prior art, the device software is divided into layers, from bottom to top: Boot layer and openharmony system layer;

[0058] The main functions of the Boot layer are: 1. Booting; 2. Booting or system updating; 3. Verifying the integrity and signature of system packages, etc.

[0059] The main functions of the openharmony system layer are: 1. The openharmony system runs and interacts with device hardware, application management, process management, etc.

[0060] The openharmony system layer includes the openharmony system, system application modules, such as launcher, and App application logic code. These codes are compiled together to generate a xxxx.img file.

[0061] The Boot and system-layer firmware packages are stored in the MCU's built-in flash. The Boot and system-layer firmware are loaded from the flash when the device is running.

[0062] App packages for the openharmony L0 system are stored in the file system and loaded by the openharmony system layer to display on the screen for user interaction. The format of the App package is as follows: Figure 2 :

[0063] Manifest.json description file: records the version, package name, display name and other information of the App package;

[0064] js resource file: resource file package for web UI development, similar to script files developed in js language.

[0065] Because the functions that js language can implement are limited, many logics need to be implemented in C language. Therefore, when it comes to the mutual calling method between JS and C, the NAPI method is adopted (the openharmony kernel already supports this method).

[0066] The existing App package and the openharmony system layer interact in the following ways: Figure 3 As shown:

[0067] App application logic code: Functions implemented in C / C++ language, such as bank check-in function, bank card consumption function, QR code scanning consumption function, etc., located in the openharmony system layer;

[0068] The js resource file is located in the APP application layer; App application layer: mainly the UI interface, such as displaying the sign-in button and the consumption button. When the user clicks the sign-in button, the App logic sign-in related functions will be called through the NAPI framework.

[0069] for Figure 3 The architecture shown must build all App application logic codes into the firmware of the OpenHarmony system layer so that the corresponding js resource files can be used normally. If you need to modify the App application logic code of an App application, you must recompile and generate a new OpenHarmony system layer firmware package.

[0070] The invention provides a multi-application dynamic loading method applicable to openharmonyL0, which has the following key improvements:

[0071] 1. The existing layers remain unchanged, which are still the boot layer and the openharmony system layer;

[0072] 2. Separate the App application logic code from the openharmony system layer, so that the openharmony system layer only contains the openharmony system and system application modules, such as launcher. These codes are compiled together to generate a xxxx.img file.

[0073] 3. Compile the stripped App application logic code to generate the App.img executable file, and package it together with the Manifest.json description file and js resource file to generate the App application package, and store it in the file system of the App application layer.

[0074] The improved App application package format of the present invention is as follows Figure 4 and Figure 6 As shown, the Manifest.json description file and the js resource file remain the same as before, and the App.img executable file is a file that can be loaded into memory and run.

[0075] The improved program runs as follows:

[0076] The Boot and system-layer firmware packages are still stored in the MCU's built-in flash. The Boot and system-layer firmware packages are loaded from the flash when the device is running.

[0077] The App package is stored in the file system. When the launcher runs the App, it must first load the app.img file corresponding to the App into the memory RAM for execution.

[0078] The improved application loading steps are summarized as follows:

[0079] 1. The user clicks on an App in the launcher, triggering the need to load the App;

[0080] 2. The system application module launcher finds the corresponding App application package in the file system;

[0081] 3. The system application module launcher verifies the integrity and legitimacy of the found App application package (verifies the signature). After the verification passes, the following steps are executed;

[0082] 4. After verification, load the App.img executable file in the App application package into the memory (RAM) to run and initialize;

[0083] 5. The system application module launcher calls the App application interface module of the NAPI module and loads the corresponding js resource file in the file system through the App application interface module.

[0084] The interaction process between the improved openharmony system layer and the App application package of the present invention is as follows: Figure 5 and Figure 7 As shown:

[0085] After the improvement, the openharmony system layer opens a function called the logic method registration function (registration hook method) for the application layer as follows:

[0086]

[0087] Void registerAppLogic(AppLogicFunc*logicFunc);

[0088] When the App.img executable file is loaded into the memory for execution and initialization, the startup method main function of the App.img executable file is jumped to call the logic method registration function in the main function to dynamically register the App application logic code in the App.img executable file to the openharmony system layer.

[0089] When the App application interface module loads the corresponding js resource file in the file system, it first determines whether the openharmony system layer has registered the App application logic code; if not, an error is reported.

[0090] The way to load js resource files is as follows:

[0091] The system application module launcher calls the App application interface module of the NAPI module and loads the corresponding js resource file in the file system through the App application interface module, such as:

[0092] int StartJsApp(const char*bundlename,const char*apppath)

[0093] {

[0094] sysLOG("start,%s\r\n",apppath);

[0095] Want want={nullptr};

[0096] ElementName element={nullptr};

[0097] SetElementBundleName(&element,bundlename);

[0098] SetWantElement(&want,element);

[0099] SetWantData(&want,apppath,strlen(apppath)+1);

[0100] int ret=StartAbility(&want);

[0101] sysLOG("startAbility:%d",ret);

[0102] ClearElement(&element);

[0103] ClearWant(&want);

[0104] return ret;

[0105] }

[0106] Enter the package name of the App application package and the absolute path where the js resource file is located;

[0107] The call of NAPI module is: add a module such as App application interface module in the openharmony kernel:

[0108]

[0109] After adding, you can call runLogic and getParam methods through launcherkit to load js resource files.

[0110] In the specific implementation, as an embodiment, the App application loading method is managed by the system application module launcher:

[0111] 1. Load the App.img executable file into the system RAM to run, initialize the app stack and global variables, etc.;

[0112] 2. Load js resource file and run the UI interface;

[0113] 3. The js resource file and the App.img executable file are called through NAPI to interact with the UI and logic code.

[0114] The system's NAPI module adds an App application interface module, which has three fixed interfaces: synchronous call interface, asynchronous call interface, and callback call interface. The parameters are uniformly formatted as json strings, and no conversion is done in the system kernel. The parameter content is customized by the js layer and the APP application layer.

[0115] When the App application exits and returns to the launcher or jumps to other App applications, the created thread is terminated, resources are released, and the launcher application interface is returned or other App applications are reloaded, thereby realizing dynamic loading of multiple applications suitable for openharmonyL0.

[0116] The multi-application dynamic loading method applicable to openharmonyL0 provided by the present invention has the following advantages:

[0117] 1. Separate the App application logic code related to App users from the kernel of the system layer, so that the system kernel code is more unified and basically does not need to be modified or modified less;

[0118] 2. After the App application logic code is stripped off, the App.img executable file is generated, and it is packaged with the Manifest.json description file and the js resource file to generate the App application package, thereby realizing a strong association between the App application logic code and the js resource file, solving the problem of mismatch between the App application logic code and the js resource file in the prior art;

[0119] 3. The App.img executable file of the App application logic code is dynamically loaded into the memory and dynamically registered into the system kernel, so that the openharmony system can support the function of dynamically loading different applications.

[0120] The above is only a preferred embodiment of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principle of the present invention. These improvements and modifications should also be considered as the scope of protection of the present invention.

Claims

1. A multi-application dynamic loading method suitable for openharmonyL0, characterized in that: The following steps are involved: Step 1: compile the App application logic code of each App application to generate an App.img executable file; Step 2: Package the App.img executable file, Manifest.json description file, and js resource file to generate an App application package, and store it in the file system of the App application layer; Step 3, the openharmony system layer includes: a system application module launcher, a logic method registration function open to the application layer, and a NAPI module; wherein the NAPI module configures an App application interface module; Step 4, compile the system application module launcher, logic method registration function and NAPI module of the openharmony system layer to generate the sys.img executable file, and store it on the MCU built-in flash; Step 5: When the device is running, first load the sys.img executable file from the flash to run the system application module launcher; Step 6: When a certain App application needs to be loaded, load it in the following way: Step 6.1, first, the system application module launcher finds the corresponding App application package in the file system; Step 6.2, the system application module launcher verifies the integrity and legality of the found App application package. After the verification passes, execute step 6.3; Step 6.3, the system application module launcher loads the App.img executable file in the App application package into the memory to run and initialize; At the same time, when the App.img executable file is loaded into the memory to run and initialize, the App.img executable file calls the logic method registration function to dynamically register the App application logic code in the App.img executable file to the openharmony system layer; Step 6.4, the system application module launcher calls the App application interface module of the NAPI module, and loads the corresponding js resource file in the file system through the App application interface module; Therefore, the system application module launcher is used to load the App.img executable file and js resource file of the App application, thereby completing the dynamic loading of the App application.

2. A multi-application dynamic loading method suitable for openharmonyL0 according to claim 1, characterized in that: Manifest.json description file, used to describe the version, package name, and display name of the App package.

3. A multi-application dynamic loading method suitable for openharmonyL0 according to claim 1, characterized in that: The APP application layer has a UI interface, and the UI interface has App application buttons for various App applications; When one of the App application buttons is clicked, it triggers the need to load the corresponding App application.

4. A multi-application dynamic loading method suitable for openharmonyL0 according to claim 1, characterized in that: In step 6.3, specifically: the system application module launcher loads the App.img executable file in the App application package into the memory ram to run and initialize, and initializes the stack and global variables of the app.

5. The multi-application dynamic loading method applicable to openharmonyL0 according to claim 1, characterized in that: When the App.img executable file is loaded into the memory for execution and initialization, the startup method main function of the App.img executable file is jumped to call the logic method registration function in the main function to dynamically register the App application logic code in the App.img executable file to the openharmony system layer.

6. A multi-application dynamic loading method suitable for openharmonyL0 according to claim 1, characterized in that: In step 6.4, when the App application interface module loads the corresponding js resource file in the file system, it first determines whether the openharmony system layer has registered the App application logic code; if not, an error is reported.

7. A multi-application dynamic loading method suitable for openharmonyL0 according to claim 1, characterized in that: The App application interface module includes three interfaces: a synchronous call interface, an asynchronous call interface and a callback call interface.

Images