System static data updating method based on application installation package and electronic device

Abstract

The application discloses a system static data updating method based on an application installation package and an electronic device, wherein the method comprises the following steps: if there is a data updating service, generating a customized application installation package corresponding to the data updating service and a customized configuration file corresponding to the customized application installation package; when installing a to-be-installed application package, if the to-be-installed application package is the customized application installation package, obtaining a target customized configuration file corresponding to the to-be-installed application package, and executing the data updating service in the target customized configuration file. The application stores the business operation process of the data updating service by the mode of generating the customized application installation package corresponding to the data updating service and the customized configuration file corresponding to the customized application installation package, and does not need to update by the OTA mode, thereby improving the timeliness of updating.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a system static data update method and electronic device based on application installation packages. Background Technology

[0002] Currently, upgrades to the OpenHarmony terminal system can only be performed via OTA (Over-The-Air). However, the OTA upgrade cycle for each new version release is relatively long, and if certain scenarios require rapid firmware updates, the OTA method cannot meet timeliness requirements. Summary of the Invention

[0003] The technical problem to be solved by the present invention is to provide a method for updating static system data based on application installation packages, thereby improving the efficiency of data updates.

[0004] To solve the above-mentioned technical problems, the present invention adopts the following technical solution: A method for updating system static data based on application installation packages includes: If a data update service exists, a customized application installation package corresponding to the data update service and a customized configuration file corresponding to the customized application installation package will be generated. When installing an application package, if the application package is the customized application installation package, the target customized configuration file corresponding to the application package is obtained, and the data update service in the target customized configuration file is executed.

[0005] An electronic device includes a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor executes the computer program to implement the steps of the above-described method for updating static data of a system based on an application installation package.

[0006] The beneficial effects of this invention are as follows: When there is a data update service, the business operation process of the data update service is stored by generating a customized application installation package and a customized configuration file corresponding to the customized application installation package. During the installation process of the application package to be installed, if the application package to be installed is a customized application installation package, the target customized configuration file corresponding to the application package to be installed can be obtained, and the data update service corresponding to the configuration file can be executed. There is no need to update via OTA, but to update by installing the application installation package, which improves the timeliness of the update. Furthermore, during the installation process of the application installation package, the package management service (BMS) will authenticate the application installation package to ensure the security of the installation process. Attached Figure Description

[0007] Figure 1 A flowchart illustrating the steps of a system static data update method based on an application installation package, provided in an embodiment of the present invention; Figure 2 An implementation architecture diagram of a system static data update method based on an application installation package provided by an embodiment of the present invention; Figure 3 A flowchart illustrating the steps of a specific embodiment of a system static data update method based on an application installation package provided by this invention; Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0008] To make the technical problems, technical solutions, and beneficial effects to be solved by this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and are not intended to limit the scope of this application.

[0009] In related technologies, to ensure the security of financial terminals and facilitate transaction traceability, the scope of use of financial terminals is usually restricted to prevent unauthorized relocation. However, these technologies lack effective methods for restricting terminal location. This inability to effectively prevent unauthorized relocation can lead to discrepancies between the transaction location recorded by the terminal and the actual transaction location, resulting in fraudulent transactions.

[0010] In related technologies, upgrades to OpenHarmony (a distributed operating system for multiple smart terminals and all scenarios) terminal systems can only be achieved through OTA (Over-The-Air). However, the OTA upgrade cycle for each new version release is relatively long, making it unsuitable for scenarios requiring rapid firmware updates. For certain services (vendor services and business services) and customer resource files, such as customer root certificates, CRLs (Certificate Revocation Lists), TLS (Transport Layer Security), and CA (Certificate Authority) certificates, installing them on the terminal via HAP (HarmonyOS Ability Package) can meet the timeliness requirements for rapid updates. The BMS module sends specified broadcasts during HAP installation and uninstallation. Upon listening to these broadcasts, relevant modules can perform further processing, such as data updates and certificate injection.

[0011] However, the standard HAP installation mechanism completes installation, writing, and updating through a BMS (Bundle Management Service). The OpenHarmony standard only provides a basic application runtime environment without special functional extensions, which cannot meet the requirements. Specifically, the standard HAP functionality is limited; it cannot automatically launch the application / SA (System Ability, where / SA represents the system service directory) after installation, cannot write files to sensitive system partitions, and has coarse-grained resource access control, failing to meet special needs such as system service updates, configuration initialization, and hierarchical management of customer resources. Traditional firmware update methods are extremely inefficient, requiring a reboot into Recovery mode and only allowing for complete firmware flashing, not incremental updates of individual files; the process is complex, time-consuming, and does not support dynamic updates of personalized customer resources. Furthermore, traditional updates to customer resource files and sensitive configurations rely on OTA (Over-The-Air) updates, resulting in low update efficiency.

[0012] To address the aforementioned problems, this application provides a system static data update method and electronic device based on an application installation package. The following details the system static data update method based on an application installation package.

[0013] The system static data update method based on application installation packages in this application can be used in various electronic devices, especially electronic devices based on the OpenHarmony architecture. The electronic devices in this application can be financial devices, such as POS (Point of Sale) machines, cash registers, or devices with payment functions such as mobile phones and tablets.

[0014] The following details the system static data update method based on application installation packages in this invention, with reference to the appendix. Figure 1 This includes steps 110 to 140.

[0015] Step 110: If a data update service exists, generate a customized application installation package corresponding to the data update service and a customized configuration file corresponding to the customized application installation package. The data update service can include execution-type, copy-type, and resource-type services. Other types of customized application installation packages can also be developed as needed, with corresponding customized configuration files and BMS settings.

[0016] Step 120: When installing the application package to be installed, if the application package to be installed is the customized application installation package, then proceed to step 130; otherwise, proceed to step 140. For example, a process for determining whether the application package to be installed is a customized application installation package can be added to the BMS installation process.

[0017] Step 130: Obtain the target customized configuration file corresponding to the application package to be installed, and execute the data update service in the target customized configuration file. The target customized configuration file includes parameter identifiers and corresponding parameter values ​​for the data update service. The corresponding data update service can be executed according to the parameters. For example, the parameter values ​​of the parameter identifiers indicate whether a system restart is required after the application package to be installed is completed, the file storage location, and the package name of the service to be started after the application package to be installed is completed. The correspondence between parameter identifiers and specific execution processes can be pre-stored in the BMS.

[0018] Step 140: Perform the normal application installation process to complete the installation of the application package to be installed. That is, the installation of a normal application package to be installed will proceed normally, and the installation process of the modified customized application package will not affect the original installation process.

[0019] As described above, by using application installation packages to carry out data update services, the device does not need to be forcibly restarted and enter Recovery mode. Furthermore, it does not depend on a specific network environment and can be installed via storage media (such as USB, SD card), eliminating the need to wait for OTA upgrades. Moreover, the native mechanism for verifying application installation packages ensures the security of the installation process, thereby guaranteeing the security of the data update process. This improves efficiency while preventing the security of the data update process from being compromised.

[0020] In one embodiment of this application, generating the customized application installation package corresponding to the data update service in step 110 includes steps 111 to 112.

[0021] Step 111: Add a custom tag to the project configuration file of the regular application installation package. Adding a custom tag to the project configuration file will include the custom tag in the application installation package, allowing it to be read by the BMS during installation.

[0022] Step 112: Set the custom identifier in the custom tag to a first preset value, and add the file index value of the custom configuration file to the custom tag to obtain the customized application installation package. For ordinary installation packages that are not customized application installation packages, the custom identifier can be set to a second preset value, the custom tag can be left empty, or no custom tag can be set. If the BMS recognizes that there is no custom tag, the custom tag is empty, or the custom identifier in the custom tag is the second preset value, it can confirm that the application package to be installed is an ordinary installation package and execute the normal installation process.

[0023] As described above, by modifying the project configuration file of a regular application installation package, adding a custom tag, and setting the custom identifier to the first preset value to indicate that the application installation package is a custom application installation package, and adding the file index value of the custom configuration file corresponding to the custom application installation package, the corresponding custom configuration file can be read during the installation of the custom application installation package, and the business operation process can be completed according to the content written in the custom configuration file, thereby realizing the data update process through the installation of the application installation package.

[0024] In one embodiment of this application, step 120 includes step 121, and step 130 includes step 131.

[0025] Step 121: When installing the application package to be installed, obtain the target custom tag in the application package to be installed, and determine whether the target custom identifier in the target custom tag meets the first preset value. If so, proceed to step 131.

[0026] Step 131: Obtain the target custom configuration file based on the target file index value in the target custom tag.

[0027] As described above, because a custom tag was added to the project configuration file during the generation of the custom application installation package, and the custom identifier was set to the first preset value, if the custom identifier in the application package to be installed matches the first preset value during the installation process, it indicates that the application package to be installed is a custom application installation package. The corresponding target custom configuration file can be obtained according to the target file index value in its custom tag to execute the data update business, thereby completing the entire process from building the custom application installation package to installing the custom application installation package. This enables the execution of the data update business through the application installation package installation process, with minimal modification to the original process, requiring only the addition of a custom tag, and does not affect the normal application installation package installation process.

[0028] In one embodiment of this application, step 110, which generates the custom configuration file corresponding to the custom application installation package, includes step 113.

[0029] Step 113: Configure the type identifier and business operation process according to the type of data update service and generate a customized configuration file. Since different types of data update services correspond to different business operation processes, different parameter values ​​are required. For example, for execution-type data update services, the customized configuration file includes the package name of the service that needs to start automatically; for copy-type data update services, the customized configuration file includes the original filename and target filename of the copied file; for resource-type data update services, the customized configuration file includes the resource type of the resource to be stored, a list of resource filenames, and resource access rules.

[0030] As described above, by configuring a type identifier based on the type of data update service, and since different types of update services correspond to different operation processes, the BMS can read the type of update service corresponding to the application installation package during the application installation package installation process. This allows for the adoption of the corresponding processing method, enabling adaptation to different data update services. Furthermore, different processing flows can be configured in the BMS for different data update services. After reading the type identifier, the corresponding processing flow is triggered, thereby achieving dynamic expansion of the customized application installation package. The customized configuration file also includes business operation flows, allowing the BMS to execute corresponding operations based on these flows to complete the data update service, thus enabling the execution of the data update service through the installation of the customized application installation package.

[0031] In an alternative implementation, if step 210 is included after step 110, then the method further includes step 310.

[0032] Step 210: Sign the customized application installation package using the private key corresponding to the access permissions for the data update service. Because the data update service involves various operational processes, different data update services may require different access permissions. For example, if the customized application installation package is executable, it uses a vendor application signature (signed with the vendor's application private key). Generally, customers cannot use the rules of the customized application installation package to install executable customized application installation packages. Another example is a copy-type customized application installation package, where the private key can be determined based on its target path. If only access to the customer's own configured directory is needed, the customer's application signature can be used directly. Similarly, a vendor application signature with higher security requirements can be used. If access to the directory containing the vendor's firmware is required, the vendor's underlying signature is needed. Due to changes in the system firmware design, additional firmware signatures are required for copied files. Yet another example is a resource-type customized application installation package, which typically consists of resources configured by the customer themselves; therefore, a customer application signature is sufficient.

[0033] Step 310: When installing the application package to be installed, if the application package to be installed is the customized application installation package, then obtain the target customized configuration file corresponding to the application package to be installed, determine the target access permissions according to the business operation process in the target customized configuration file, obtain the certificate corresponding to the target access permissions, and verify the signature of the application package to be installed; if the signature verification is successful, then execute the business operation process in the target customized configuration file. The certificate is generated based on the public key corresponding to the private key in step 210, thus enabling signature verification based on the signature obtained from the private key to determine whether the customized application installation package has the corresponding permissions. If the signature verification result is unsuccessful, the customized application installation package will not be installed. This provides a new solution for system configuration through customized application installation packages while ensuring the security of system configuration.

[0034] As can be seen, step 310 corresponds to step 130, that is, after obtaining the target customized configuration file, the target access permission is first determined according to the business operation process in the target customized configuration file, and then the certificate corresponding to the target access permission is obtained to verify the signature of the application package to be installed. Only if the signature verification is successful will the business operation process in the target customized configuration file be executed. If the signature verification fails, the process will be terminated or a security warning will be issued.

[0035] As described above, during the construction of the customized application installation package, the corresponding private key is obtained based on the access permissions corresponding to the data update business to sign the customized application installation package. During the installation of the customized application installation package, the signature of the customized application installation package is verified by matching the corresponding certificate with the target access permissions read from the customized configuration file. Only after the verification is successful will the business operation process in the target customized configuration file be executed and the installation process of the customized application installation package continue. This avoids unauthorized third parties from using the customized application installation package to perform sensitive operations. Only authorized customized application installation packages will be installed and the corresponding operations in the customized configuration file will be executed, thus improving the overall security of the system.

[0036] In one alternative implementation, step 113 includes steps 1311 to 1314.

[0037] Step 1311: If the data update service type is execution type, then configure the type identifier as the execution type identifier.

[0038] Step 1312: In the business operation process, determine whether the system needs to be restarted after the customized application installation package is installed, and configure the corresponding restart flag.

[0039] Step 1313: Obtain the package name of the service that needs to be automatically started in the business operation process.

[0040] Step 1314: Generate a custom configuration file based on the execution identifier, restart identifier, and package name.

[0041] As described above, for execution-type data update services, the application itself and the required system services need to be started immediately after the application is installed. Therefore, in addition to configuring the type identifier and restart identifier, the package name of the service that needs to be started automatically is also configured. If the service that needs to be started automatically is an application service, such as the service corresponding to the installed custom application package, the package name of the custom application package can be written. If the service that needs to be started automatically is a system service, the package name corresponding to the system service can be written. This instructs the BMS to start the application service or system service corresponding to the package name according to the relevant identifier in the custom configuration file after installing the custom application package to complete the update process.

[0042] In one alternative implementation, step 113 includes steps 1321 to 1324.

[0043] Step 1321: If the data update service type is copy type, then configure the type identifier as copy type identifier.

[0044] Step 1322: In the business operation process, determine whether the system needs to be restarted after the customized application installation package is installed, and configure the corresponding restart flag.

[0045] Step 1323: Obtain the target path, original filename, and target filename of the file to be copied in the business operation process. It is evident that since the copied file can be directly placed in the customized application installation package, there is no need to write the original path of the copied file in the customized configuration file.

[0046] Step 1324: Generate a custom configuration file based on the copy identifier, restart identifier, target path, original file name, and target file name.

[0047] As described above, for copy-type data updates, the target path for the copied file is also configured, specifying the final storage path of the file, the original filename of the copied file, the destination filename (the filename after the target path), and instructing the BMS to complete the file copying process according to the configured parameters. If the copied file itself can be directly stored in the directory of the customized application installation package, then the original path of the copied file does not need to be written in the customized configuration file, reducing the amount of data written.

[0048] In one alternative implementation, step 113 includes steps 1331 to 1334.

[0049] Step 1331: If the data update service type is resource-based, then configure the type identifier as a resource-based identifier.

[0050] Step 1332: In the business operation process, determine whether the system needs to be restarted after the customized application installation package is installed, and configure the corresponding restart flag.

[0051] Step 1333: Obtain the resource type, resource file name list, and resource access rules for the resources to be stored in the business operation process. The resource files are directly placed in the customized application installation package. In the customized configuration file corresponding to a resource-type customized application installation package, only one resource access rule is included. All resource files in a single resource-type customized application installation package share the same set of resource types and resource access rules. This simplifies the complexity of subsequent BMS operations after the customized application installation package is installed, improves processing efficiency, and facilitates the management of customized application installation package versions.

[0052] Step 1334: Generate a customized configuration file based on the resource identifier, restart identifier, resource type, resource file name list, and resource access rules.

[0053] As described above, if the data update service is of the resource type, the resource type, resource file name list, and resource access rules are configured. The resource access rules limit the permissions that can access the resources. In the BMS, the resource files can be stored and the corresponding access rules can be configured according to the corresponding configuration to ensure the security of resource access.

[0054] In one optional implementation, the method further includes: the target path and the storage path of the resource to be stored are in a preset isolated directory.

[0055] As described above, the preset isolation directory, the target path in the custom configuration file corresponding to the copy-type identifier, and the storage path of the resource in the custom configuration file corresponding to the resource-type identifier are all set in the isolation directory. Therefore, the custom application installation package can only access the preset isolation directory and cannot access the system directory, which limits the scope of influence of the custom application installation package. In this way, even if the custom application installation package is maliciously exploited, it can only access the isolation directory and will not affect other directories on the device, especially the system directory, thus further improving system security.

[0056] See attached document Figure 2 This paper provides an implementation architecture diagram of a system static data update method based on an application installation package, as described in this application. It includes a custom HAP layer, an OpenHarmony system layer, and an isolated directory (Data_ext partition) layer.

[0057] The customized HAP layer includes resource-based HAPs, copy-based HAPs, execution-based HAPs, and other extensible types of HAPs, used to perform step 110 above. Execution-based HAPs are installed natively. After installation, the native method does not automatically start the installed HAP or SA (System Ability) program. However, in some scenarios, it is necessary to start the HAP or SA immediately after installation, such as when writing configuration files or items. In this case, by writing the package name of the HAP or SA program to be started in the customized configuration file, the HAP execution module in the BMS can be instructed to start the corresponding HAP or SA program according to the package name, thus completing the data update process. Copy-based HAPs correspond to system files that need to be copied to a specified subdirectory in the terminal isolation directory, and these files are loaded preferentially by the terminal's relevant system services. Resource-based HAPs correspond to resource files that need to be installed on the terminal. After installation, relevant modules need to be notified in real time to update resource data related to the resource files, and access control is required for resource files, allowing only authorized programs to access them, while prohibiting unauthorized applications from accessing them.

[0058] The OpenHarmony system layer includes a BMS, which comprises a custom HAP parsing and identification module, a signature verification module, and a custom HAP execution module. The custom HAP parsing and identification module parses the identifiers of custom HAPs and the corresponding custom configuration files, used to execute step 120 above. The signature verification module performs hierarchical and categorized signature verification of custom HAP packets and differentiates file storage and permissions based on the target path of copy-type HAPs or the access rules of resource-type HAPs, as used to execute step 310 above. The HAP execution module executes the operations required by the custom HAP based on the type of data update service corresponding to the custom HAP and the configuration fields in the custom configuration file, as used to execute step 130 above. The isolated directory layer includes a system service directory, a vendor firmware directory, and a customer directory.

[0059] The following describes the application embodiments of this application. This application can apply the above solution to the static data update process of the OpenHarmony system, including the following steps 410 to 440.

[0060] Step 410, Custom HAP (Custom Application Installation Package) Configuration and Creation, includes steps 411 to 413. This is equivalent to step 110 above.

[0061] Step 411: Use Deveco Studio (OpenHarmony's official development workbench) to generate an HAP project. Place the custom configuration file for the customized HAP in the project's resource path. For example, place the custom configuration file special_hap_config.json in the Profile directory path, and place the files in the rawfile path (the default resource directory). If it is a resource-type HAP, place the corresponding resource files; if it is a copy-type HAP, place the copy files.

[0062] Step 412: Add a custom tag "metadata" inside the "module" tag in the HAP project configuration file module.json5. Define a set of special HAP configuration information within the "metadata" tag, as shown in the example below. The "module" tag is the root node of the HAP project configuration file, defining the identity and capabilities of a HAP application, which is fundamental for the correct compilation, distribution, and operation of the application.

[0063] "metadata":[{ "name":"specialHapConfig", "value": "special hap config", "resource":"$profile:special_hap_config"}] In the example above, the `metadata` tag identifies the custom metadata of the HAP, and its value is an array type. The `name` sub-tag's value is set to a first preset value to identify the HAP as a custom application installation package. For example, setting the tag value to `specialHapConfig` identifies the application type as a custom HAP. The `value` sub-tag's value serves as descriptive information, which can be used to describe the purpose of the HAP, etc. The `resource` sub-tag's value is the index value of the custom configuration file of the custom HAP, used to retrieve the custom configuration file. For non-custom ordinary HAPs, the custom `metadata` tag can be omitted, or the `metadata` tag can be set with its `name` sub-tag set to empty. In this way, during the identification process, the BMS will determine that installation packages without a `metadata` tag or with a `metadata` tag but an empty `name` sub-tag are all ordinary application installation packages.

[0064] Step 413: Edit the custom configuration file: special_hap_config.json. This file is used to configure the type of custom HAP and the management commands triggered after installation. Different configuration parameter fields are defined according to different custom HAP types. Steps 4131 to 4133 are examples of the custom configuration files for the three custom HAP types (corresponding to three types of data update services) in this application, and their execution order is not important. If there are other types of data update services, the configuration parameter fields in the custom configuration file can also be limited according to the specific data update service's business operation process, all of which are within the scope of protection of this application.

[0065] Step 4131: For execution-type custom HAPs, the following is an example of the configuration parameter fields in the custom configuration file: {"type": "excute", / / Indicates that this custom HAP type is execution type execute;} "excute":{ "rebootSysFlag": false, / / rebootSysFlag indicates whether the system should be restarted after the custom HAP is installed. Here, a value of false means no restart is needed, while a value of true means a restart is required. "bundleName": "com.deep.test.demo", / / This represents the package name of the application service that needs to start automatically. Here, after the customized HAP installation is complete, the application with the package name com.deep.test.demo will start; Step 4132: For copy-type custom HAPs, the following is an example of the configuration parameter fields in the custom configuration file: {"type": "copy", / / Indicates that this custom HAP type is copy;} "copy": { "rebootSysFlag": false, / / Indicates whether to restart the system after the custom HAP is installed. The specific configuration method is the same as the execution-type custom HAP mentioned above; "dirPath": " / data_ext / component / etc / init / ", / / Identifies the target path. Here, the target path is / data_ext / component / etc / init / , so the BMS will copy the file to this target path; "files": [ {"srcName": "trs.cfg", "destName": "trs.cfg"}} / / files identifies the filename, including the subfield srcName which identifies the original filename and the subfield destName which identifies the target filename. Here, the original filename is trs.cfg, which is the filename of the file to be copied in the resource directory. The target filename is trs.cfg, which is the filename used by the file to be copied after it is saved to the target path.

[0066] Step 4133: For resource-based customized HAPs, the following is an example of the configuration parameter fields in the customized configuration file: {"type": "resource", / / Indicates that this custom HAP type is resource-based;} "resource":{ "rebootSysFlag":false, / / Indicates whether to restart the system after the custom HAP is installed; "restype":"common / ca / config / ..." / / Identifies the type of client resource file. For example, here, "common" indicates general client resources, "ca" indicates CA certificates, and "config" indicates configuration resources.

[0067] "files":"filenameList", / / Identifies a list of customer resource file names as an index, which can be used to retrieve the corresponding resource files in the resource-based customized HAP; "rule":"open / limited / private", / / Identifies the rules for installing and accessing resources. A value of "open" indicates an open resource that can be accessed by everyone; a value of "limited" indicates a restricted resource; a value of "private" indicates a private resource that can only be accessed by the customized HAP itself after installation.

[0068] "allowList":"appnamelist" / / This lists the application package names allowed when the access rule is "limited". If the access rule does not include "limited", it can be empty. Here, appnamelist simply lists all package names. Step 420: Divide the system into isolated directories. To manage the security of terminals with custom HAPs installed and prevent unauthorized applications from using custom HAPs to attack sensitive system partitions, a separate isolated directory, / data_ext / , can be created within the system to store the contents of copied custom HAPs. Within / data_ext / , separate system service directories, vendor firmware directories, and customer directories are defined to store corresponding resources or files. An example of directory division and usage is shown in Table 1 below, and configurations can be made according to actual needs. If the resources imported into the system via the special HAP belong to system services, they are placed in the system service directory. For example, if they are customer resources, they are placed in the customer directory. If they are system firmware-related files, they are placed in the vendor firmware directory. The vendor firmware directory can also have subdirectories. This directory planning is matched to the actual firmware update needs. For example, if you want to update the SE (Secure Element) firmware using this solution, a corresponding SE firmware path is planned. The path name in the table is used as an example: / data_ext / deep / firmware / se. The SE firmware update service is pre-configured to retrieve new files from a pre-defined path ( / data_ext / deep / firmware / se) and perform the corresponding verification and update process after receiving a file update from that path.

[0069] Table 1

[0070] Step 430: Sign the customized HAP. Steps 431 to 433 are examples of signing methods for execution-type, copy-type, and resource-type customized HAPs in this embodiment. If there are other types of customized HAPs, the signing method can also be configured according to requirements. Different signature designs are used for different types of customized HAPs, ensuring the security of customized HAPs while taking into account the convenience of the signing process.

[0071] Step 431: For execution-type customized HAPs, vendor application signing is used to control general customer applications. Only the vendor (the terminal manufacturer) can install execution-type customized HAPs; general customers cannot illegally install their own applications as execution-type customized HAPs by exploiting configuration rules. Because customized HAPs can automatically start and launch configured system services after installation, without restrictions, any third party can call system services, affecting system security, especially the security of payment devices.

[0072] Step 432: For copy-type custom HAPs, different signatures are used depending on the target path where the file needs to be copied and the type of the target path area. Referring to Table 1 above, in the isolated directory, the target path may belong to the system service directory, the vendor firmware directory, or the customer directory.

[0073] If the target path belongs to the system service directory and the service corresponding to the target path is a vendor service, then the corresponding vendor application signature is used; if the service corresponding to the target path is a customer service, then the corresponding customer application signature is used; if the target path belongs to the vendor firmware directory, then the vendor underlying signature is used, and the file to be copied must be signed with a firmware signature; if the target path belongs to the customer directory, then the customer application signature is used. Specifically, the customer application signature is held by the customer using a private key and is used for signing resource-type HAPs and copy-type customized HAPs whose target path is located in the customer directory ( / data_ext / customer); the vendor application signature is held by the terminal manufacturer using a private key and is used for execution-type customized HAPs and copy-type customized HAPs whose target path is located in the system service directory ( / data_ext / component) and whose corresponding service is a vendor service; its permissions are between those of the customer application signature and the vendor underlying signature; the vendor underlying signature is held by the terminal manufacturer with a higher-level key (such as a firmware key) and is exclusively used for copy-type customized HAPs whose target path is located in the vendor firmware directory ( / data_ext / deep / firmware), and the firmware file to be copied itself must also be attached with a firmware signature, which is then verified a second time by the firmware subsystem.

[0074] Step 433: For resource-based customized HAPs, customer application signatures are used because they do not involve system-level access.

[0075] Step 440, refer to Figure 3 The installation process and steps for the customized HAP are as follows, including steps 441 to 448, which are equivalent to steps 120 to 140 above.

[0076] Step 441: When installing the HAP file, BMS first determines the type of HAP according to steps 4411 to 4414 to determine whether the HAP is a custom HAP or a regular HAP.

[0077] Step 4411: Check if the application module.json5 project configuration file contains a metadata tag. If it does, proceed to step 4412. Otherwise, determine that the HAP is a normal HAP and proceed to step 4414.

[0078] Step 4412: Determine if the metadata tag is the first preset value; for example, if the first preset value is specialHapConfig, then check if the sub-tags name, value, and resource exist. If they exist, proceed to step 4413. If the metadata tag is not the first preset value, then determine that the HAP is a normal HAP and proceed to step 4414.

[0079] Step 4413: Parse the contents of the custom configuration file special_hap_config.json, and determine the type of custom HAP based on the type tag value.

[0080] Step 4414: Perform the normal HAP installation process.

[0081] Step 442: Based on the type of the customized HAP, the BMS verifies the customer application signature, vendor underlying signature, or vendor application signature of the customized HAP using a pre-installed verification certificate. If the verification passes, proceed to steps 443, 444, or 445, depending on the type of the customized HAP. If the verification fails, the customized HAP is not installed, and a security risk warning is displayed. The verification certificate is generated by a CA (Certificate Authority) using the public key corresponding to the private key used to sign the customized HAP. The specific certificate acquisition process is existing technology and will not be elaborated here.

[0082] If the customized HAP is of copy type, the target path in the customized configuration file is read further, and the customer application signature, vendor underlying signature, or vendor application signature verification is determined based on the target path.

[0083] Step 443: If the `type` in the parsed custom configuration file `special_hap_config.json` is an execution-type special HAP, then the service and application itself with the package name configured in the `special_hap_config.json` will be started immediately. For the application itself, it will start even if no corresponding package name is configured. This satisfies the scenario where the user application needs to automatically start itself and its dependent services after installation. After the BMS parses the package name configured in the custom configuration file, it searches for the program file based on the package name to start the corresponding application or system service.

[0084] Step 444: If the type in the parsed custom configuration file special_hap_config.json is copy type, then execute the following installation process, including steps 4441 to 4443.

[0085] Step 4441: BMS continues to parse the custom configuration file to obtain the target path (based on tags such as "copy", "dirPath", "files", "srcName" and "destName", determine which target path in the terminal the file is copied to).

[0086] Step 4442: The BMS determines whether the target path belongs to an isolated directory. If so, it determines whether the target path belongs to the vendor's firmware directory. If it belongs to the vendor's firmware directory, it further verifies the system firmware signature of the copied file. If the target path does not belong to the preset path, the installation terminates. If the target path belongs to the system service directory or customer directory in the isolated directory, proceed to step 4443; if the target path belongs to the vendor's firmware directory in the isolated directory and the signature verification passes, proceed to step 4443.

[0087] Step 4443: BMS copies the file to the isolated directory in the terminal.

[0088] If the type in the parsed custom configuration file special_hap_config.json is resource-type, then proceed with the installation process from step 4451 to 4454.

[0089] Step 4451: Read the restype field in the custom configuration file. This field identifies the type of customer resources. Determine whether the type matches the resource types supported by the terminal. If yes, continue to step 4452; otherwise, exit the process and prompt that the resource type is not supported.

[0090] Step 4452: Read the rule and allowlist fields to obtain the permission restrictions for the resource.

[0091] Step 4453: Parse the resource files to be imported, obtain the file type and file size, determine whether the file type belongs to the preset file type, and determine whether the file size meets the preset limit and the remaining size of data_ext / customer. If both are met, proceed to step 4454; otherwise, exit the process.

[0092] Step 4454: Store the resource file in the permission fields of rule and allowlist to grant the resource file the corresponding access permissions.

[0093] Step 450: BMS sends a broadcast notification to the target application or service. That is, after storing the resource file or copy file in a predetermined area, BMS does not use the resource file or copy file itself, but instead notifies the processing party that the resource file or copy file has been loaded to process it. Applications that need the copy file or resource file can then load it accordingly.

[0094] Step 460: After receiving the broadcast sent by the BMS, the target application or target service shall use the copied file or loaded resource file as needed.

[0095] Please refer to Figure 4The present invention also provides an electronic device 500, including a memory 501 and a processor 502, and a computer program stored on the memory 501 and running on the processor 502. When the processor 502 executes the computer program, it implements the various steps of the system static data update method based on the application installation package described above.

[0096] The beneficial effects of the electronic device of the present invention are the same as those of the method described above, and will not be repeated here.

[0097] As described above, this application provides a system static data update method and electronic device based on application installation packages. To address the low update efficiency of traditional firmware and client resources, it utilizes application installation packages (HAPs) as a carrier and proposes a configuration-driven, type-level HAP processing mechanism. First, by defining specific custom identifiers (metadata) and corresponding custom configuration files in the application configuration file, the system can identify the specific data update service type of the HAP, including execution, copy, and resource types. After identifying the specific type, differentiated process execution can be performed according to different types. For example, for execution types, the corresponding package name is configured in the custom configuration file to automatically launch the corresponding system service (Service) or application service (Ability) after the custom application installation package is installed, solving the problem of standard HAPs failing to start automatically after installation. For copy types, by setting a preset isolated directory / data_ext and using hierarchical access permission verification for the target path where copied files need to be stored, the permission and security issues of writing files to the system partition are resolved. For resource types, by configuring resource access rules (open / restricted / private), the fine-grained permission control of resource files is resolved.

[0098] The above are merely embodiments of the present invention and do not limit the patent scope of the present invention. Any equivalent modifications made based on the content of the present invention's specification and drawings, or direct or indirect applications in related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A method for updating static system data based on an application installation package, characterized in that, include: If a data update service exists, a customized application installation package corresponding to the data update service and a customized configuration file corresponding to the customized application installation package will be generated. When installing an application package, if the application package is the customized application installation package, the target customized configuration file corresponding to the application package is obtained, and the data update service in the target customized configuration file is executed.

2. The method according to claim 1, characterized in that, The customized application installation package corresponding to the data update service includes: Add custom tags to the project configuration file of a regular application installation package; Set the custom identifier in the custom tag to the first preset value, and add the file index value of the custom configuration file to the custom tag to obtain the custom application installation package.

3. The method according to claim 2, characterized in that, When installing the application package to be installed, if the application package to be installed is the customized application installation package, then obtaining the target customized configuration file corresponding to the application package to be installed includes: When installing the application package to be installed, the target custom tag in the application package to be installed is obtained, and it is determined whether the target custom identifier in the target custom tag conforms to the first preset value. If so, the target custom configuration file is obtained according to the target file index value in the target custom tag.

4. The method according to claim 1, characterized in that, The custom configuration file corresponding to the custom application installation package includes: Based on the data, update the service type configuration type identifier and service operation process, and generate a customized configuration file.

5. The method according to claim 1, characterized in that, After generating the customized application installation package corresponding to the data update service and the customized configuration file corresponding to the customized application installation package, the process further includes: Based on the access permissions corresponding to the data update service, the customized application installation package is signed using the private key corresponding to the access permissions; The method further includes: When installing the application package to be installed, if the application package to be installed is the customized application installation package, the target customized configuration file corresponding to the application package to be installed is obtained, the target access permission is determined according to the business operation process in the target customized configuration file, and the certificate corresponding to the target access permission is obtained to verify the signature of the application package to be installed. If the signature verification is successful, the business operation process described in the target customized configuration file will be executed.

6. The method according to claim 4, characterized in that, The step of updating the service type configuration type identifier and service operation process based on the data and generating a customized configuration file includes: If the data update service type is execution type, then configure the type identifier as the execution type identifier; In the business operation process, determine whether the system needs to be restarted after the customized application installation package is installed, and configure the corresponding restart flag. Obtain the package name of the application service that needs to be automatically started in the business operation process; A custom configuration file is generated based on the execution identifier, restart identifier, and package name.

7. The method according to claim 4, characterized in that, The step of updating the service type configuration type identifier and service operation process based on the data and generating a customized configuration file includes: If the data update service type is copy type, then configure the type identifier as the copy type identifier; In the business operation process, determine whether the system needs to be restarted after the customized application installation package is installed, and configure the corresponding restart flag. In the business operation process, obtain the target path, the original file name, and the target file name of the file to be copied. A custom configuration file is generated based on the copy identifier, restart identifier, target path, original filename, and target filename.

8. The method according to claim 4, characterized in that, The step of updating the service type configuration type identifier and service operation process based on the data and generating a customized configuration file includes: If the data update service type is resource-based, then the configuration type identifier is the resource-based identifier; In the business operation process, determine whether the system needs to be restarted after the customized application installation package is installed, and configure the corresponding restart flag. Obtain the resource type, resource file name list, and resource access rules of the resources to be stored in the business operation process; A custom configuration file is generated based on the resource identifier, restart identifier, resource type, resource file name list, and resource access rules.

9. The method according to any one of claims 7 or 8, characterized in that, The target path and the storage path of the resources to be stored are in a preset isolated directory.

10. An electronic device, characterized in that, The system includes a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor executes the computer program to implement a system static data update method based on an application installation package as described in any one of claims 1 to 9.

Images