Application management method based on OpenHarmony system and electronic equipment

Abstract

The invention discloses an application management method based on an OpenHarmony system and electronic equipment. The method comprises the following steps: acquiring a historical package name list, wherein the historical package name list comprises application information historically installed by the electronic equipment; obtaining a to-be-installed application, and if the to-be-installed application does not have the purchaser signature, judging whether the to-be-installed application has a developer signature; if the to-be-installed application has the developer signature, judging whether first application information corresponding to the to-be-installed application exists in the historical package name list or not; and if the first application information exists, determining the to-be-installed application as a secure application. The application signature verification process can be simplified, and the application development efficiency is improved.

Description

Technical Field

[0001] The present invention relates to the technical field of data processing, and in particular to an application management method and electronic equipment based on an OpenHarmony system. Background Art

[0002] The main purchasers of financial terminals are banks, third-party payment service providers, and related Internet companies. When purchasing financial terminals, these purchasers require that the financial terminals can only download and install applications that belong to them. Therefore, purchasers need to centrally manage the applications installed on the financial terminals. In order to achieve centralized management of applications in financial terminals, an application digital signature solution is introduced during the application installation process, and each application update installation requires the purchaser to sign.

[0003] In the related art, when manufacturers develop business applications for financial terminals, they need to install different business applications on the financial terminals for testing. Due to the existence of application signature schemes, manufacturers need purchasers to sign every time they install or update applications on financial terminals, which makes the application installation process cumbersome, the application development efficiency is low, and the financial terminals cannot install other applications except the purchaser's applications. Summary of the invention

[0004] The technical problem to be solved by the present invention is to provide an application management method and electronic device based on the OpenHarmony system, which can simplify the application signature verification process and improve the application development efficiency.

[0005] In order to solve the above technical problems, a technical solution adopted by the present invention is: An application management method based on the OpenHarmony system, used for an electronic device using the OpenHarmony system, comprising: Acquire a historical package name list, wherein the historical package name list includes application information historically installed by the electronic device; Obtaining the application to be installed, and if the application to be installed does not have a purchaser signature, determining whether the application to be installed has a developer signature; If the application to be installed has a developer signature, determining whether there is first application information corresponding to the application to be installed in the historical package name list; If the first application information exists, the application to be installed is determined to be a safe application.

[0006] In order to solve the above technical problems, another technical solution adopted by the present invention is: An electronic device comprises a memory, a processor and a computer program stored in the memory and running on the processor, wherein the processor implements each step of the above-mentioned application management method based on the OpenHarmony system when executing the computer program.

[0007] The beneficial effects of the present invention are as follows: the historical package name list of the present application records the application information of the electronic device that has been historically installed. The present application obtains the historical package name list and obtains the application to be installed. When the application to be installed does not contain the signature of the purchaser, it determines whether the application to be installed has the signature of the developer; if the application to be installed has the signature of the developer, it determines whether there is the first application information corresponding to the application to be installed in the historical package name list; if there is the first application information, the application to be installed is determined to be a safe application. Therefore, when the method of the present application determines whether there is the first application information corresponding to the application to be installed in the historical package name list, it can directly determine that the application to be installed is a safe application through the developer signature, thereby realizing the installation of the application. For applications that have been historically installed, the present application does not need to verify the signature of the purchaser when performing a secondary installation, thereby simplifying the signature verification process when the application is installed for the second time. Therefore, the manufacturer does not need to repeatedly ask the purchaser for the application signature when developing application updates, thereby effectively improving the development efficiency of the application. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Figure 1 A flowchart of an application management method based on the OpenHarmony system provided in an embodiment of the present invention; Figure 2 A schematic diagram of a secondary installation of an application containing only a developer's signature provided by an embodiment of the present invention; Figure 3 A schematic diagram of first installation of an application including only a developer's signature provided by an embodiment of the present invention; Figure 4 A schematic diagram of a secondary installation of an application including only a purchaser's signature provided by an embodiment of the present invention; Figure 5 A schematic diagram of first installation of an application including only a purchaser's signature provided by an embodiment of the present invention; Figure 6 A schematic diagram of first installation of an application including a developer signature and a purchaser signature provided by an embodiment of the present invention; Figure 7 Another flow chart of the application management method based on the OpenHarmony system provided by an embodiment of the present invention; Figure 8 A schematic diagram of an application package of an application app1 to be installed provided in an embodiment of the present invention; Fig. 9A schematic diagram of an application package of an application app2 to be installed provided in an embodiment of the present invention; Fig.10 A schematic diagram of an application package of an application app3 to be installed provided in an embodiment of the present invention; Fig.11 A schematic diagram of an application package of an application app4 to be installed provided in an embodiment of the present invention; Fig.12 A schematic diagram of the structure of an electronic device provided by an embodiment of the present invention; Description of labels: 100. An electronic device; 101. A memory; 102. A processor. DETAILED DESCRIPTION

[0009] In order to make the technical problems, technical solutions and beneficial effects to be solved by the present application more clearly understood, the present application 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 application and are not used to limit the present application.

[0010] In the following description, specific details such as specific system structures, technologies, etc. are provided for the purpose of illustration rather than limitation, so as to provide a thorough understanding of the embodiments of the present application. However, it should be clear to those skilled in the art that the present application may also be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted to prevent unnecessary details from obstructing the description of the present application.

[0011] It should be understood that when used in the present specification and the appended claims, the term "comprising" indicates the presence of described features, wholes, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, wholes, steps, operations, elements, components and / or combinations thereof.

[0012] References to "one embodiment" or "some embodiments" etc. described in the specification of this application mean that one or more embodiments of the present application include specific features, structures or characteristics described in conjunction with the embodiment. Therefore, the statements "in one embodiment", "in some embodiments", "in some other embodiments", "in some other embodiments", etc. that appear in different places in this specification do not necessarily refer to the same embodiment, but mean "one or more but not all embodiments", unless otherwise specifically emphasized in other ways. The terms "including", "comprising", "having" and their variations all mean "including but not limited to", unless otherwise specifically emphasized in other ways.

[0013] The main purchasers of financial terminals are banks, third-party payment service providers, and related Internet companies. When purchasing financial terminals, these purchasers require that the financial terminals can only download and install applications that belong to them. Therefore, purchasers need to centrally manage the applications installed on the financial terminals. In order to achieve centralized management of applications in financial terminals, an application digital signature solution is introduced during the application installation process, and each application update installation requires the purchaser to sign.

[0014] In the related art, when manufacturers develop business applications for financial terminals, they need to install different business applications on the financial terminals for testing. Due to the existence of application signature schemes, manufacturers need purchasers to sign every time they install or update applications on financial terminals, which makes the application installation process cumbersome, the application development efficiency is low, and the financial terminals cannot install other applications except the purchaser's applications.

[0015] In the related technology, the manufacturer needs to pre-install the root public key certificate provided by the purchaser in the financial terminal. For the financial terminal, any application to be installed must be signed by the private key corresponding to the working public key certificate derived from the root public key certificate before obtaining installation permission. This means that whether it is the first installation or subsequent upgrades, the applications on the financial terminal must go through the signature verification process of the purchaser. However, when manufacturers develop business applications for financial terminals, they need to install different business applications on the financial terminals for testing. However, this application digital signature scheme also needs to be re-signed by the purchaser when the application only undergoes minor changes, such as version number updates. This frequent signature requirement greatly reduces the manufacturer's business development efficiency and also prolongs the cycle of application version updates and upgrades.

[0016] In order to solve the above problems, an embodiment of the present application provides an application management method based on the OpenHarmony system, which is used for electronic devices using the OpenHarmony system.

[0017] Please refer to Figure 1 The method includes steps S110 to S140.

[0018] Step S110: Acquire a historical package name list, where the historical package name list includes application information historically installed on the electronic device.

[0019] Step S120: Obtain the application to be installed. If the application to be installed does not have a purchaser signature, determine whether the application to be installed has a developer signature.

[0020] Step S130: If the application to be installed has a developer signature, determine whether there is first application information corresponding to the application to be installed in the historical package name list.

[0021] Step S140: If there is first application information, determine the application to be installed as a secure application.

[0022] In a specific scenario, such as Figure 2 shown, if the application to be installed is historical application 1 that has been successfully installed on the electronic device, where i is the set of all integers satisfying 2 < i < N in the figure, that is, the application information of the application to be installed is recorded in the historical package name list of the electronic device, then the installation process of this application to be installed belongs to a secondary installation. For a secondary-installed application, only the developer signature is included in the application package. As long as it is determined that there is first application information of the application to be installed in the historical package name list, it can be determined as a secure application.

[0023] As can be seen from the above embodiments, for an application that has been historically installed, when performing a secondary installation, there is no need to verify the purchaser signature, which simplifies the signature verification process when installing the secondary-installed application. Therefore, when a manufacturer develops an application update, there is no need to repeatedly sign the application to the purchaser, effectively improving the development efficiency of the application.

[0024] In an embodiment of the present application, the method further includes step S210.

[0025] Step S210: If there is no first application information, determine the application to be installed as a normal application. The permission level of a secure application is higher than that of a normal application.

[0026] In a specific scenario, such as Figure 3 shown, if the application to be installed is not historical application 1 to historical application N that have been successfully installed on the electronic device, where i is the set of all integers satisfying 2 < i < N in the figure, that is, the application information of the application to be installed is not recorded in the historical package name list of the electronic device, then the installation process of this application to be installed belongs to a first installation. For a first-installed application, only the developer signature is included in the application package. Since the purchaser signature is not included in this application, it is impossible to determine whether this application is a secure application allowed by the purchaser to be installed. Therefore, it is determined as a normal application. Among them, the permission level of a secure application includes that of a normal application, enabling a secure application to execute all functions of a normal application on the electronic device.

[0027] As can be seen from the above embodiments, if there is no first application information in the historical package name list, it indicates that the application to be installed has not been installed on the electronic device, and only the developer signature exists for the application to be installed. Then the application to be installed can be determined as a normal application and is not allowed to be installed on the device. In this way, applications that have not been processed with the purchaser signature are not allowed to be installed on the device, realizing centralized management of applications on the electronic device and avoiding installing applications other than the purchaser.

[0028] In an embodiment of the present application, the method further includes step S310-step S320.

[0029] Step S310: If the application to be installed has a purchaser signature, determine whether there is second application information corresponding to the application to be installed in the historical package name list.

[0030] Step S320: If there is second application information, determine the application to be installed as a safe application.

[0031] In a specific scenario, such as Figure 4 shown, if the application to be installed is the historical application 1 that has been successfully installed on the electronic device, where i is the set of all integers satisfying 2 < i < N, that is, the historical package name list of the electronic device records the application information of the application to be installed, then the installation process of the application to be installed this time belongs to a secondary installation. For a secondary installation application, the application package only contains a purchaser signature. As long as it is determined that there is second application information of the application to be installed in the historical package name list, it can be determined as a safe application.

[0032] As can be seen from the above embodiment, if there is second application information in the historical package name list, it means that the application to be installed has been installed on the electronic device. At this time, regardless of whether there is a developer signature for the application to be installed, it can be determined as a safe application for installation. In this way, for a secondary installation application, installation can be achieved without verifying the developer signature, effectively simplifying the signature verification steps and improving the installation efficiency of the application.

[0033] In an embodiment of the present application, the method further includes step S410-step S420.

[0034] Step S410: If there is no second application information, perform signature verification on the purchaser signature.

[0035] Step S420: If the purchaser signature verification passes, determine the application to be installed as a safe application.

[0036] In a specific scenario, such as Figure 5 shown, if the application to be installed is not the historical applications 1 to N that have been successfully installed on the electronic device, where i is the set of all integers satisfying 2 < i < N, that is, the historical package name list of the electronic device does not record the application information of the application to be installed, then the installation process of the application to be installed this time belongs to a first installation. For a first installation application, the application package only contains a purchaser signature. As long as the purchaser signature verification passes, it can be determined as a safe application.

[0037] As can be seen from the above embodiments, if the second application information does not exist in the historical package name list, it indicates that the application to be installed has never been installed on the electronic device. At this time, as long as the purchaser signature verification of the application to be installed passes, regardless of whether the developer signature exists for the application to be installed, it can be determined as a safe application for installation. In this way, for an application installed for the first time, as long as the purchaser signature is verified, verification can be achieved. While realizing the centralized management of applications on the electronic device (that is, avoiding the installation of other applications other than the purchaser), the signature verification steps are effectively simplified, and the application installation efficiency is improved.

[0038] In an embodiment of the present application, the method further includes steps S510 to S530.

[0039] Step S510: If the second application information does not exist, determine whether the application to be installed has a developer signature.

[0040] Step S520: If the application to be installed has a developer signature, perform signature verification on the purchaser signature and the developer signature respectively.

[0041] Step S530: If both the purchaser signature and the developer signature pass the verification, determine the application to be installed as a safe application, and update the historical package name list according to the purchaser signature and the developer signature.

[0042] In a specific scenario, as Figure 6 shown, if the application to be installed is not the historical application 1 to historical application N that has been successfully installed on the electronic device, where i in the figure is the set of all integers satisfying 2 < i < N, that is, the application information of the application to be installed is not recorded in the historical package name list of the electronic device, then the installation process of the application to be installed this time belongs to the first installation. For an application installed for the first time, the application package contains a developer signature and a purchaser signature. As long as both the developer signature and the purchaser signature pass the verification, it can be determined as a safe application, and the historical package name list is updated.

[0043] As can be seen from the above embodiments, if the application to be installed has both a purchaser signature and a developer signature, and both pass the verification, it can be determined as a safe application for installation, and the historical package name list is updated at the same time. In this way, for an application installed for the first time, relevant historical installation records can be retained, so as to facilitate the secondary installation of the application and avoid the problem that the purchaser signature is required even for minor modifications to the application, effectively improving the application development efficiency.

[0044] Based on the above five embodiments, it can be known that for an application installed for the first time, the application must contain the signature of the purchaser and pass the signature verification to be determined as a safe application; and the application must be signed by both the purchaser and the developer and both signatures must pass the verification before it can be updated to the historical package name list. For an application installed for the second time, as long as the application contains the signature of the purchaser or the developer and the signature verification passes, it can be determined as a safe application. In this way, if the manufacturer needs to perform business updates and tests on the application, then when the application is first installed on the electronic device, it also needs to request a signature from the purchaser while containing the developer's signature, so that the application information can be recorded in the historical package name list to ensure that the application does not need to request a signature from the purchaser when it is installed for the second time, effectively simplifying the signature verification process of the application during the second installation and improving the efficiency of application installation.

[0045] In one embodiment of the present application, the method further includes steps S610 to S620.

[0046] Step S610: If the application to be installed is a safe application, installation of the application to be installed is allowed.

[0047] Step S620: If the application to be installed is not a safe application, installation of the application to be installed is not allowed.

[0048] In one embodiment of the present application, Figure 7 As shown, the application management method based on the OpenHarmony system specifically includes: obtaining a historical package name list, and determining whether there is application information of the application to be installed in the historical package name list. If there is application information, it is determined that the application to be installed is a secondary installation. If there is no application information, it is determined that the application to be installed is a first installation. After determining that the application to be installed is a secondary installation, the developer signature or the purchaser signature of the application to be installed is obtained, and the signature is verified according to the application information in the historical package name list, and the application is allowed to be installed after the signature verification passes. After determining that the application to be installed is the first installation, it is detected whether there is a purchaser signature for the application to be installed. If there is no purchaser signature, the application is not allowed to be installed. If there is a purchaser signature, the purchaser signature is verified, and the application is allowed to be installed after the signature verification passes, and it is detected whether there is a developer signature for the application to be installed. If there is no developer signature, the historical package name list is not updated. If there is a developer signature, the developer signature is verified, and the historical package name list is updated after the signature verification passes.

[0049] In one embodiment of the present application, the application of the present application adds a purchaser signature on the basis of retaining the native developer signature, wherein the signer ID of the purchaser signature is a custom ID assigned to the purchaser by the manufacturer. For applications developed based on the OpenHarmony system, the purchaser's profile file (configuration file) can be added to the application package, the custom ID can be written in the profile file, and the purchaser's root certificate can be added to the application package, thereby obtaining an application package containing the purchaser's signature. At the same time, when the electronic device is produced, the custom ID signed by the purchaser and the purchaser's root certificate are pre-set in the TEE (Trusted Execution Environment) security area for storage. When the electronic device is started, the custom ID is a read-only variable that cannot be modified. In this way, the purchaser's signature is distinguished from the native developer's signature, thereby realizing the purchaser's signature verification process.

[0050] In one embodiment of the present application, the program and file to be signed (i.e., the application package to be signed), the profile file, and the application signature are packaged to form an application package to be installed. The profile file includes a signature certificate for developer signature and / or a signature certificate for purchaser signature, and the application signature includes an application signature certificate.

[0051] like Figure 8 As shown, in a specific scenario, the application package app1-signed.hap to be installed is generated by the program and files to be signed, the profile file containing the signing certificate for the developer signature, and the developer signature package, wherein the program and files are specifically named app1-unsigned.hap, the profile file can be specifically named app1-profile.p7b, and the developer signature is specifically a pkcs7 structure, that is, the application package app1-signed.hap to be installed is only signed by the developer, and the final application signature is reflected in the developer signature.

[0052] like Fig. 9 As shown, in a specific scenario, the application package app2-signed.hap to be installed is generated by packaging the program and files to be signed, the profile file containing the signature certificate for the purchaser's signature, and the purchaser's signature, wherein the program and files are specifically named app2-unsigned.hap, the profile file is specifically named app2-profile.p7b, and the purchaser's signature is specifically a pkcs7 structure, that is, the application package app2-signed.hap to be installed is only signed by the purchaser, and the final application signature is embodied as the purchaser's signature.

[0053] like Fig.10As shown, in a specific scenario, the application package app3-signed.hap to be installed is generated by the program and files to be signed, the profile1 file containing the signing certificate for the purchaser's signature, the profile2 file containing the signing certificate for the developer's signature, and the developer's signature. The program and files are specifically named app3-unsigned.hap, the profile1 file is specifically named app3-profile1.p7b, the profile2 file is specifically named app3-profile2.p7b, and the developer's signature is specifically a pkcs7 structure, that is, the application package app3-signed.hap to be installed is first signed by the purchaser and then signed by the developer, and the final application signature is reflected in the developer's signature.

[0054] like Fig.11 As shown, in a specific scenario, the application package app4-signed.hap to be installed is generated by the program and files to be signed, the profile1 file containing the signing certificate for the developer's signature, the profile2 file containing the signing certificate for the buyer's signature, and the buyer's signature. The program and files are specifically named app4-unsigned.hap, the profile1 file is specifically named app4-profile1.p7b, the profile4 file is specifically named app4-profile2.p7b, and the buyer's signature is specifically a pkcs7 structure, that is, the application package app4-signed.hap to be installed is first signed by the developer and then signed by the buyer, and the final application signature is reflected in the buyer's signature.

[0055] Based on the above embodiments, it can be known that the application signatures corresponding to the four different packaging forms of the applications to be installed are different. Based on the application management method of the present invention, if the above four application packages to be installed are all installed for the first time, then the application package to be installed app1-signed.hap will be determined as a common application and will not be allowed to be installed, and the application packages to be installed app2-signed.hap, app3-signed.hap and app4-signed.hap will be determined as safe applications and will be allowed to be installed. Among them, for the application package to be installed app3-signed.hap, the purchaser's signature has actually completed the application installation steps, but in order to ensure that it can be installed a second time, the developer's signature is required. That is, the application packages to be installed app3-signed.hap and app4-signed.hap can both update the historical package name list.

[0056] In one embodiment of the present application, the method for verifying the signature of the purchaser in step S410 or step S520 includes the following steps: first, obtain the preset purchaser root certificate from the TEE security zone, compare and verify the purchaser root certificate in the application to be installed with the preset purchaser root certificate to determine whether the two are consistent, thereby determining the legitimacy of the signature source. Then obtain the preset signer ID from the TEE security zone, compare and verify the signer ID read from the profile file of the application to be installed with the preset signer ID to determine whether the two are consistent. If they are consistent, it is determined that the purchaser signature verification has passed.

[0057] In addition, the root certificate signed by the developer is preset by the OpenHarmony system natively. The method for verifying the developer's signature in step S520 is consistent with the above-mentioned method for verifying the purchaser's signature, and will not be repeated here.

[0058] In one embodiment of the present application, the method of updating the historical package name list according to the purchaser signature and the developer signature in step S530 includes steps S710 to S730.

[0059] Step S710: extracting the developer public key and the developer certificate in the developer signature, and generating first application information according to the developer public key and the developer certificate.

[0060] Step S720: extracting the buyer's public key and the buyer's certificate from the buyer's signature, and generating second application information according to the buyer's public key and the buyer's certificate.

[0061] Step S730: Add the first application information and the second application information to the historical package name list according to the application package name of the application to be installed.

[0062] In step S730, the electronic device can add the first application information, the second application information and the application package name to the historical package name list through the HAP centralized manager. The HAP centralized manager is a basic unit for managing application installation and operation in the OpenHarmony system.

[0063] It can be seen from the above embodiments that for an application installed for the first time, if both the purchaser's signature and the developer's signature are verified, the first application information and the second application information are generated based on the purchaser's signature information and the developer's signature information, respectively, to ensure that the application can complete the installation verification with only one signature when it is installed for the second time, thereby simplifying the application signature verification process while achieving centralized management of applications.

[0064] In one embodiment of the present application, the method for determining whether there is first application information corresponding to the application to be installed in the historical package name list in step S130 includes steps S810 to S840.

[0065] Step S810: Check whether there is a historical application package name in the historical package name list that is the same as the name of the application to be installed.

[0066] Step S820: If the historical application package name exists, obtain the first application information of the historical application package name, and verify the developer signature according to the first application information.

[0067] Step S830: If the verification is successful, confirm that the first application information corresponding to the application to be installed exists in the historical package name list.

[0068] Step S840: If the verification fails, confirm that the first application information corresponding to the application to be installed does not exist in the historical package name list.

[0069] From the above embodiments, it can be known that by detecting the application name, it is possible to quickly determine whether the application to be installed has been installed on the electronic device. If the first application information exists in the historical package name list, the developer signature is verified based on the first application information, and the application can only be installed after the verification passes, thereby ensuring the security of the application package.

[0070] In one embodiment of the present application, the method of verifying the developer signature according to the first application information in step S820 includes steps S910 to S940.

[0071] Step S910: Obtain the historical developer public key in the first application information.

[0072] Step S920: extract the developer public key to be verified in the developer signature, and compare the historical developer public key with the developer public key to be verified.

[0073] Step S930: If the comparison is consistent, the verification is successful.

[0074] Step S940: If the comparison is inconsistent, the verification fails.

[0075] It can be seen from the above embodiments that verifying the developer's signature based on the public key information has high detection accuracy and high detection efficiency.

[0076] In one embodiment of the present application, the method for determining whether there is second application information corresponding to the application to be installed in the historical package name list in step S310 includes the following steps: detecting whether there is a historical application package name identical to the name of the application to be installed in the historical package name list; if there is a historical application package name, obtaining the second application information of the historical application package name, and obtaining the historical purchaser public key in the second application information, extracting the purchaser public key to be verified in the purchaser signature, and comparing the historical purchaser public key with the purchaser public key to be verified; if the comparison is consistent, confirming that the second application information corresponding to the application to be installed exists in the historical package name list; if the comparison is inconsistent, confirming that the second application information corresponding to the application to be installed does not exist in the historical package name list.

[0077] Please refer to Fig.12 Another embodiment of the present application provides an electronic device 100, including a memory 101, a processor 102, and a computer program stored in the memory 101 and running on the processor 102. When the processor 102 executes the computer program, each step of the application management method based on the OpenHarmony system of the above embodiment is implemented.

[0078] Among them, the application management method based on the OpenHarmony system has been disclosed in the above section and will not be repeated here.

[0079] In summary, the present invention provides an application management method and electronic device based on the OpenHarmony system. For applications installed for the first time, the application must contain the signature of the purchaser and pass the signature verification to be determined as a safe application, thereby realizing the installation management of the application program and ensuring that only applications authorized by the purchaser can be installed and downloaded in the terminal. At the same time, applications that have passed the signature verification of both the developer signature and the purchaser signature are determined as safe applications, and the application information of the application is recorded in the historical package name list of the electronic device, so that when the application is installed for the second time, it only needs to contain the signature of the purchaser or the developer signature and pass the signature verification to be determined as a safe application, thereby ensuring that the application does not need to request a signature from the purchaser when it is installed for the second time, effectively simplifying the signature verification process of the application during the second installation, and improving the efficiency of application installation.

[0080] The above descriptions are merely embodiments of the present invention and are not intended to limit the patent scope of the present invention. Any equivalent transformations made using the contents of the present invention's specification and drawings, or directly or indirectly applied in related technical fields, are also included in the patent protection scope of the present invention.

Claims

1. An application management method based on the OpenHarmony system, characterized in that: Electronic devices for use with the OpenHarmony system, including: Acquire a historical package name list, wherein the historical package name list includes application information historically installed by the electronic device; Obtaining the application to be installed, and if the application to be installed does not have a purchaser signature, determining whether the application to be installed has a developer signature; If the application to be installed has a developer signature, determining whether there is first application information corresponding to the application to be installed in the historical package name list; If the first application information exists, the application to be installed is determined to be a safe application.

2. The method according to claim 1, characterized in that Also includes: If the application to be installed has a purchaser signature, determining whether there is second application information corresponding to the application to be installed in the historical package name list; If the second application information exists, the application to be installed is determined to be a safe application.

3. The method according to claim 2, characterized in that Also includes: If the second application information does not exist, performing signature verification on the purchaser's signature; If the purchaser's signature verification is successful, the application to be installed is determined to be a safe application.

4. The method according to claim 2, characterized in that: Also includes: If the second application information does not exist, determining whether the application to be installed has a developer signature; If the application to be installed has a developer signature, then performing signature verification on the purchaser signature and the developer signature respectively; If both the purchaser's signature and the developer's signature are verified, the application to be installed is determined to be a safe application, and the historical package name list is updated according to the purchaser's signature and the developer's signature.

5. The method according to claim 1, characterized in that Also includes: If the first application information does not exist, determining the application to be installed as a common application; The permission level of the security application is higher than the permission level of the common application.

6. The method according to claim 4, characterized in that Updating the historical package name list according to the purchaser signature and the developer signature includes: Extracting a developer public key and a developer certificate from the developer signature, and generating first application information according to the developer public key and the developer certificate; Extracting the buyer's public key and the buyer's certificate from the buyer's signature, and generating second application information according to the buyer's public key and the buyer's certificate; The first application information and the second application information are added to the historical package name list according to the application package name of the application to be installed.

7. The method according to claim 1, characterized in that Determining whether there is first application information corresponding to the application to be installed in the historical package name list includes: Detect whether there is a historical application package name identical to the name of the application to be installed in the historical package name list; If the historical application package name exists, obtaining first application information of the historical application package name, and verifying the developer signature according to the first application information; If the verification succeeds, confirming that the first application information corresponding to the application to be installed exists in the historical package name list; If the verification fails, it is confirmed that the first application information corresponding to the application to be installed does not exist in the historical package name list.

8. The method according to claim 7, characterized in that Verifying the developer's signature according to the first application information includes: Obtaining the historical developer public key in the first application information; Extracting the developer public key to be verified from the developer signature, and comparing the historical developer public key with the developer public key to be verified; If the comparison is consistent, the verification is successful; If the comparison is inconsistent, the verification fails.

9. The method according to any one of claims 1 to 5, characterized in that: Also includes: If the application to be installed is a safe application, allowing the application to be installed to be installed; If the application to be installed is not a safe application, installation of the application to be installed is not allowed.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that: When the processor executes the computer program, each step of the application management method based on the OpenHarmony system according to any one of claims 1 to 9 is implemented.

Images