Distributed Application Development, Debugging Method and Auxiliary Tool for HarmonyOS

Abstract

The present invention discloses a method and an auxiliary tool for distributed application development and debugging for HarmonyOS. The debugging tool includes: a distributed permission injection module for calculating the minimum permission set required for the execution project, injecting the minimum permission set into the config.json file of the project, and adding permission application code in the initialization callback function at the APP entry of the project; a distributed device management module for constructing a multi-terminal shared distributed device database; and a distributed exception parsing module for matching the running log file based on a regular script with each exception information key in the ErrorCode-exception information database as a keyword to generate a new log file. The present invention provides a readable and stable device information list for developers, automatically injects the minimum set of required permissions, constructs the association between ErrorCode and exception information, thereby ensuring the normal operation of the program while improving security and facilitating developers to quickly locate abnormal problems.

Description

Technical Field

[0001] The present invention relates to the field of HarmonyOS distributed application development, and proposes a method and an auxiliary tool for distributed application development and debugging for HarmonyOS. Background Art

[0002] HarmonyOS is a domestic distributed operating system for all scenarios. Its distributed capabilities are the decisive differences and core competitiveness compared with the Android system. It is reported that the installed capacity of HarmonyOS has exceeded 90 million, and the number of HarmonyOS application developers has reached 1.2 million. HarmonyOS has broad application prospects. HarmonyOS is built with distributed soft bus technology, providing good technical support for the systems developed by Huawei official and its distributed capabilities (such as Super Terminal, distributed screen mirroring, etc.).

[0003] However, the distributed capabilities of HarmonyOS have insufficient support for its application ecosystem. Only manufacturers closely cooperating with Huawei, such as JD.com and Youku, have launched distributed application demos. The reasons are as follows: First, the distributed capabilities of HarmonyOS bring a more complex permission system. In addition to independent distributed permissions, the permissions required for distributed capabilities are related to permissions such as network and data. Once a permission is missing, the program will enter an unexecutable state without error messages, and too many permissions will lead to device security risks. Second, in the native ability of HarmonyOS to scan distributed devices, each device is represented by a 24-bit hexadecimal number, and due to the changing network and signal conditions, the number and order of devices scanned each time are different, making it difficult to distinguish when there are multiple devices. Third, since the function calls of distributed capabilities need to delve into the HarmonyOS underlying system function library that is not oriented to application developers, in many cases, only ErrorCode can be reported for abnormal problems, and the abnormal information cannot be known.

[0004] As an important part of the operating system ecosystem, the application ecosystem should be emphasized. Therefore, there is an urgent need for an auxiliary tool for distributed application development for HarmonyOS to solve the above problems, reduce the development difficulty of HarmonyOS distributed applications, improve the experience of HarmonyOS application developers, enable more creative developers to join the HarmonyOS development team, and promote the development of the HarmonyOS application ecosystem. Summary of the Invention

[0005] To solve the problems existing in the above-mentioned background technology, in view of the characteristics of HarmonyOS, the present invention proposes a distributed application development, debugging method and auxiliary tool H-DADU (HarmonyOS-Distributed Application Development Utils) for HarmonyOS, so as to solve the problems of complex distributed application development mechanism, high learning cost, difficult Debugging, etc. of HarmonyOS, and enable distributed application developers to focus on the development of business logic.

[0006] The technical content of the present invention includes:

[0007] A distributed application development method for HarmonyOS, the steps of which include:

[0008] Configure the HarmonyOS application development environment and create a new project in DevEco;

[0009] Utilize the data files of distributed devices to construct a distributed device database shared by multiple terminals, so that the distributed application can uniformly identify all distributed devices;

[0010] Scan all the source codes of the project to match the HamronyOS functions with the built-in function-permission database, and obtain the minimum permission set required to normally execute the project;

[0011] Inject the minimum permission set into the config.json file of the project, and add permission application code in the initialization callback function at the APP entry of the project;

[0012] Develop the distributed application based on the config.json file and the initialization callback function.

[0013] Furthermore, the distributed device database is dynamically constructed through the following steps:

[0014] 1) Call the HarmonyOS function getDeviceList() to obtain the list of hexadecimal numbers of the current distributed devices;

[0015] 2) Match each hexadecimal number as a device key in the current distributed device database:

[0016] If the device key already exists in the current distributed device database, skip it;

[0017] If the device key does not exist in the current distributed device database, the device name in string format is used as the device value. By default, the device value is L + 1, and the device value and the device key are stored in the current distributed device database, where L is the length of the current distributed device database list.

[0018] Further, the method for statically constructing the distributed device database includes: constructing by loading the data file of the distributed device.

[0019] Further, the distributed device database is persisted in the form of a file to a storage device.

[0020] Further, the attributes of the function - permission database include: package name, function name, and permission name.

[0021] Further, the minimum permission set is obtained through the following steps:

[0022] 1) For each file P i , obtain the package name set B by regular matching of the import / include information i ;

[0023] 2) For each file P i , match the function name through the full - text regular matching method to obtain the function name set H i ;

[0024] 3) Retrieve according to the package name set B i and the function name set H i to obtain the permission name Q of this file P i ; i ;

[0025] 4) Integrate and deduplicate each permission name Q i to obtain the minimum permission set.

[0026] A distributed application debugging method for HarmonyOS, the steps of which include:

[0027] For the distributed application developed by the above method, export the running log file through DevEcoStudio;

[0028] Read the running log file into memory data;

[0029] Match the memory data based on the regular script with each exception information key in the ErrorCode - exception information database as the keyword;

[0030] Add the exception value in the form of a string after each match item to obtain a new log file;

[0031] Complete the debugging of the distributed application according to the new log file.

[0032] Further, construct the ErrorCode-exception information database through the following steps:

[0033] 1) Analyze the code repository of OpenHarmony's distributed capabilities and capture the characteristics of distributed-capability call exceptions;

[0034] 2) Establish the association between ErrorCode and the actual exception information;

[0035] 3) Use ErrorCode as the exception key and the exception information as the exception value to construct the ErrorCode-exception information database.

[0036] Further, the characteristics include: the ErrorCode list and annotations.

[0037] An auxiliary tool for distributed application development for HarmonyOS, including:

[0038] A distributed permission injection module, used to scan all source codes of the project to match the HarmonyOS functions with the built-in function-permission database, obtain the minimum permission set required for the normal execution of the project; inject the minimum permission set into the config.json file of the project, and add permission application code in the initialization callback function at the APP entry of the project;

[0039] A distributed device management module, used to utilize the data files of distributed devices to construct a multi-terminal shared distributed device database, so that the distributed application can uniformly identify all distributed devices;

[0040] A distributed exception parsing module, used to read the running log file into in-memory data; based on a regular script, match the in-memory data with each exception information key in the ErrorCode-exception information database, where the ErrorCode-exception information database is constructed based on the characteristics of distributed-capability call exceptions; add the exception value in the form of a string after each matching item to obtain a new log file.

[0041] Compared with the prior art, the present invention has the following advantages:

[0042] 1. By analyzing the function calls of the current project, automatically inject the minimum set of required permissions, ensuring the normal operation of the program while improving security, and developers do not have to worry about permission issues;

[0043] 2. By building a distributed device database, a readable and stable device information list is provided for developers. Meanwhile, the database supports persistence and multi-device synchronization.

[0044] 3. By analyzing the characteristics of abnormal calls of the distributed capabilities in the OpenHarmony source code, the association between ErrorCode and exception information is built, and the log file is optimized to facilitate developers to quickly locate problems. Description of the Drawings

[0045] Figure 1 It is a schematic diagram of an auxiliary tool for distributed application development for HarmonyOS.

[0046] Figure 2 It is a schematic diagram of the functions and usage methods of an auxiliary tool for distributed application development for HarmonyOS. Detailed Implementation Modes

[0047] The present invention will be further described below with reference to the drawings through embodiments, but the scope of the present invention is not limited in any way.

[0048] The auxiliary tool of the present invention has a principle as Figure 1 shown. It is developed in the form of a third-party component library. Its main function is to provide a set of function libraries and executable programs for distributed application development for HarmonyOS to solve complex problems in the development process. The function layer adopts a modular design and includes a distributed permission injection module, a distributed device management module, and a distributed exception parsing module. The modules are completely decoupled at the code level, facilitating the addition and modification of functions. It has good versatility and scalability.

[0049] 1. The distributed permission injection module provides the ability to scan and inject distributed permissions and provides corresponding executable programs. Developers only need to run the executable programs to complete the permission injection of the current project. This program has three functions:

[0050] 1.1 Permission scanning. By statically scanning all the source code of the current project, all the HarmonyOS functions used are matched with the built-in "function-permission" database to obtain the minimum set of permissions required for the normal execution of the current project.

[0051] The method for building the "function-permission" database is as follows:

[0052] The database belongs to a relational database, and the required attributes include "package name", "function name", and "permission name". Any HarmonyOS function can be uniquely determined by the package name and the function name, and the permission name represents the permissions required for the execution of the current function.

[0053] This database exists statically in the form of a file in the distributed permission injection module.

[0054] The usage method of the "function-permission" database is as follows:

[0055] The distributed permission injection module scans all source code files in the current project directory. For each file:

[0056] ① Obtain the package name set by regular expression matching of import / include information.

[0057] ② Match function names by full-text regular expression matching to obtain the function name set.

[0058] ③ Retrieve the corresponding permission names through the package name set and the function name set.

[0059] Integrate and deduplicate all permission names to obtain the minimum permission set required for the project.

[0060] 1.2 Permission injection. Add the "reqPermissons" field to the correct position of the config.json file of the project through regular expression matching, and inject the minimum permission set required in the form of a string into this field;

[0061] 1.3 Permission application. Add a permission application code block in the initialization callback function of the APP entry of the current project (by default, entry->src->main->java->com.example.myapplication->MyApplication->onInitialize()) using regular expression matching.

[0062] 2. The device detection function module provides a set of functions for managing distributed device information. Its specific working process is as follows:

[0063] 2.1 Distributed device database. The distributed device database, which is a key-value list representing distributed devices, uses hexadecimal numbers as keys and device names in string format as values.

[0064] 2.2 Automatic construction of the distributed device database. The distributed device database has two construction methods: dynamic construction and static construction.

[0065] For dynamic construction, when the program is running, call the HarmonyOS function getDeviceList() to obtain a list of hexadecimal numbers, and match each hexadecimal number as a key in the distributed device database:

[0066] ① If this key already exists in the database, skip this item.

[0067] ② If this key does not exist in the database, a new value "Device x" is constructed, where x = L + 1 and L is the length of the current database list. Finally, these key and value pairs are stored in the database.

[0068] Static construction: Build a distributed device database by loading a distributed device data file.

[0069] Dynamic construction and static construction can be combined with each other. For example, first obtain a database instance through static construction from a file, and then use the dynamic construction method to add newly recognized devices to the database.

[0070] 2.3 Manual modification of the distributed device database. The distributed device database supports developers to manually modify the value, that is, to customize the device name string.

[0071] 2.4 Persistence of the distributed device database. The distributed device database supports being persisted to the device storage device in the form of a file, regarded as a distributed device data file.

[0072] 2.5 Multi-device synchronization of the distributed device database. It supports sending distributed device data and files to other devices in the form of byte streams or files, realizing sharing the same device list at multiple ends, that is, device information synchronization.

[0073] 3. The exception information processing module provides a set of codes for parsing ErrorCode into exception information and provides corresponding executable files.

[0074] 3.1 Establish an "ErrorCode - Exception Information" database. It is built based on the analysis of the OpenHarmony system source code. By analyzing the distributed capability-related code repositories of OpenHarmony (such as distributedschedule_dms_fwk, communication_dsoftbus, etc.), capture the characteristics of distributed capability call exceptions. The characteristics include but are not limited to the ErrorCode list and comments, establish the association between ErrorCode and the actual exception information, and construct a database with ErrorCode as the key and exception information as the value.

[0075] 3.2 ErrorCode parsing based on log data. The exception information processing function module reads the log file into memory data, and based on a regular script, uses each key in the "ErrorCode - Exception Information" database as a keyword to match the log data. After each match, add the corresponding value in the form of a string, and after completion, save the new log data as a new log file.

[0076] The overall process of an auxiliary tool for distributed application development for HarmonyOS is as follows Figure 2 As shown, developers can freely select one or more of these modules for use. Here, only one implementation solution for distributed application control is exemplified: Develop distributed applications A1, A2, A3... A n , and install them on devices D1, D2, D3... D n respectively. Any A i can launch A j (i, j ∈ {1, 2, 3... n}).

[0077] In the case of using this auxiliary tool, the corresponding development process is as follows:

[0078] Preparation stage:

[0079] 1) Configure the HarmonyOS application development environment. This includes configuring DevEco Studio, configuring the HarmonyOS SDK, and configuring JDK.

[0080] 2) Create a blank project in DevEco and place this auxiliary tool in the root directory of the project.

[0081] Development stage:

[0082] 3) Develop the business logic of applications A1, A2, A3... A n . Due to the introduction of the device detection function module, developers can distinguish the corresponding devices by the device name; if the multi-device synchronization function of the distributed device database is used, the device list synchronization can be achieved, that is, the recognition of A1, A2, A3... A n for all distributed devices is unified; when using the persistent function of the distributed device database, corresponding files will be formed in the non-volatile storage medium of the device and statically constructed by loading the files, and the device list will not change with the restart or network conditions.

[0083] 4) Call the executable program of the distributed permission injection module to inject the permission list and permission application code into the config.json file and the APP initialization function based on the business logic of each APP.

[0084] Debugging stage:

[0085] 5) Install and run A1, A2, A3... A n on devices D1, D2, D3... D n, by exporting the running log file through DevEco Studio, dragging the log file onto the ErrorCode parser can perform the parsing. After the parsing is completed, a log copy txt file will be generated, which contains distributed exception information. Developers can locate and solve problems by reading the exception information.

[0086] In the case of not using this auxiliary tool, the corresponding development process is as follows:

[0087] Preparation stage:

[0088] 1) Configure the HarmonyOS application development environment. This includes configuring DevEco Studio, configuring the HarmonyOS SDK, and configuring JDK.

[0089] 2) Create a blank project in DevEco.

[0090] Development stage:

[0091] 3) Develop the business logic of applications A1, A2, A3... A n For any A i , A j (i≠j, i, j = {1, 2, 3... n}), the number and order of recognized devices are different; and for each run of any A i , the number and order of recognized devices may also be different; therefore, the only effective information representing the device is the hexadecimal code, and developers can only distinguish different devices by recording the hexadecimal code themselves.

[0092] 4) Developers record all the functions used by A1, A2, A3... A n by themselves, and retrieve the corresponding function descriptions in the API documentation on the official website of Huawei Developers. Only then can they query the permissions required by the current function. After completing all permission queries, declare the corresponding permissions one by one in config.json, and write the permission application code in the initialization function (or other appropriate location) of the APP.

[0093] Debugging stage:

[0094] 5) Install and debug A1, A2, A3... A n on D1, D2, D3... D n . By exporting the running log file through DevEcoStudio, developers need to analyze the log file by themselves. Any ErrorCode in the log is just a string of numbers and cannot provide effective information, so it can only be ignored, making it difficult to locate problems.

[0095] Based on the same inventive concept, another embodiment of the present invention provides an electronic device (such as a computer, a server, a smart phone, etc.), which includes a memory and a processor. The memory stores a computer program, and the computer program is configured to be executed by the processor. The computer program includes instructions for performing each step in the method of the present invention.

[0096] Based on the same inventive concept, another embodiment of the present invention provides a computer-readable storage medium (such as ROM / RAM, a disk, an optical disc). When the computer program stored in the computer-readable storage medium is executed by a computer, each step of the method of the present invention is implemented.

[0097] The present invention is developed in the form of a third-party component. The "module" mentioned in the text (for example, the device detection module) is essentially a collection of a series of codes. Only when the codes are compiled into an executable file can the functions of this component described in the description be brought into play.

[0098] The specific embodiments of the present invention disclosed above are intended to help understand the content of the present invention and implement it accordingly. Those of ordinary skill in the art can understand that various substitutions, changes, and modifications are possible without departing from the spirit and scope of the present invention. The present invention should not be limited to the content disclosed in the embodiments of this specification, and the protection scope of the present invention is subject to the scope defined by the claims.

Claims

1. A distributed application development method for HarmonyOS, the steps of which include: Configure the HarmonyOS application development environment and create a new project in DevEco; Utilize the data files of distributed devices to construct a distributed device database shared by multiple devices, so that the distributed application can uniformly identify all distributed devices; wherein, the distributed device database represents a key-value list of distributed devices, with hexadecimal numbers as keys and device names in string format as values; Scan all the source codes of the project to match HarmonyOS functions with the built-in function-permission database to obtain the minimum permission set required for the normal execution of the project; wherein, the function-permission database belongs to a relational database, and the attributes of the function-permission database include: package name, function name, and permission name. Any HarmonyOS function is determined by the package name and function name, and the permission name represents the permission required for the execution of the current function; Inject the minimum permission set into the config.json file of the project, and add permission application code in the initialization callback function at the APP entry of the project; Develop the distributed application based on the config.json file and the initialization callback function.

2. The method according to claim 1, characterized in that, Dynamically construct the distributed device database through the following steps: 1) Call the HarmonyOS function getDeviceList() to obtain a list of hexadecimal numbers of the current distributed devices; 2) Match each hexadecimal number as a device key in the current distributed device database: If the device key already exists in the current distributed device database, skip it; If the device key does not exist in the current distributed device database, use the device name in string format as the device value. By default, the device value is L + 1, and store the device value and the device key in the current distributed device database, where L is the length of the current distributed device database list.

3. The method according to claim 1, characterized in that, The method for statically constructing the distributed device database includes: constructing by loading the data files of distributed devices.

4. The method according to claim 1, wherein Persist the distributed device database in the form of a file to a storage device.

5. The method according to claim 1, wherein Obtain the minimum permission set through the following steps: 1) For each file P i , obtain the set of package names B by regular matching of import / include information i ; 2) For each file P i , match function names by full-text regular matching method to obtain the function name set H i ; 3) Retrieve according to the package name set B i and the function name set H i to obtain the permission name Q i of this file P i ; 4) For each permission name Q i Integrate and remove duplicates to obtain the minimum permission set.

6. A distributed application debugging method for HarmonyOS, the steps of which include: For the distributed application developed by any of the methods in claims 1-5 Export the running log file through DevEcoStudio; Read the running log file as in-memory data; Match the in-memory data based on regular scripts with each exception information key in the ErrorCode-exception information database as the keyword; Add the exception value in the form of a string after each matching item to obtain a new log file; Complete the debugging of the distributed application according to the new log file.

7. The method according to claim 6, characterized in that, Construct the ErrorCode-exception information database through the following steps: 1) Analyze the code repository of OpenHarmony's distributed capabilities and capture the characteristics of distributed capability call exceptions; 2) Establish the association between ErrorCode and actual exception information; 3) Use ErrorCode as the exception key and the exception information as the exception value to build an ErrorCode - exception information database.

8. The method according to claim 7, wherein The characteristics include: the ErrorCode list and comments.

9. An auxiliary tool for distributed application development for HarmonyOS, including: A distributed permission injection module, which is used to scan all the source codes of the project to match the HarmonyOS functions with the built-in function - permission database to obtain the minimum permission set required for the normal execution of the project; inject the minimum permission set into the config.json file of the project, and add permission application code in the initialization callback function of the APP entry of the project; wherein, the function - permission database belongs to a relational database, and the attributes of the function - permission database include: package name, function name, and permission name. Any HarmonyOS function is determined by the package name and the function name, and the permission name represents the permission required for the execution of the current function; A distributed device management module, which is used to utilize the data files of distributed devices to build a multi - terminal shared distributed device database to unify the identification of all distributed devices by distributed applications; wherein, the distributed device database represents a key - value list of distributed devices, with hexadecimal numbers as keys and device names in string format as values; A distributed exception parsing module, which is used to read the running log file as in - memory data; match the in - memory data based on the regular script with each exception information key in the ErrorCode - exception information database, where the ErrorCode - exception information database is built based on the characteristics of distributed capability call exceptions; add the exception value in the form of a string behind each matching item to obtain a new log file.

Images