CN116049799B

CN116049799B - System authority management method, system and electronic equipment

Info

Publication number: CN116049799B
Application number: CN202210826802.2A
Authority: CN
Inventors: 李囡
Original assignee: Honor Device Co Ltd
Current assignee: Honor Device Co Ltd
Priority date: 2022-07-14
Filing date: 2022-07-14
Publication date: 2023-11-07
Anticipated expiration: 2042-07-14
Also published as: CN116049799A

Abstract

The application provides a system authority management method, a system and electronic equipment, relates to the technical field of terminals, and can grant specific application authorities to applications so as to avoid misuse of high-risk system authorities or utilization of application developers. The method comprises the following steps: the second equipment analyzes the upgrade system file to obtain a system authority configuration file, and adds the system authority configured in the system authority configuration file to an authorized list, wherein the system authority configuration file is used for configuring the system authority to be added, and the authorized list comprises the system authority which can be granted to a third party application; the second equipment acquires an application program package of a first application, wherein the application program package of the first application carries a permission certificate of the first application, and the permission certificate comprises system permissions applied by the first application; when the first application is installed, if the first system authority in the system authorities applied by the first application is contained in the authorized list, the second device grants the first system authority to the first application.

Description

System authority management method, system and electronic equipment

Technical Field

The present application relates to the field of terminal technologies, and in particular, to a system authority management method, a system and an electronic device.

Background

With the continuous development of software technology, various application layers are endless. An application may typically call an application programming interface (application programming interface, API) to perform certain functions (e.g., disable factory settings, call a camera, etc.). However, before an application is allowed to call the API, the operating system will first determine whether the application has the rights required to call the API.

Typically, a developer of an application may list in advance a list of rights required for the application in an installation package of the application. Upon installation of an application on a device, the device may verify and grant the rights requested by the application through a package manager service (package manager service, PMS). The rights granted by the operating system may include four types of normal (normal), dangerous (dangerous), signature (signature), and signature/system (signature or system), with the rights level increasing in sequence.

Currently, system applications are typically granted all signatures or signature/system type rights, while third party applications are typically granted ordinary or dangerous type rights. If the third party application requires the rights of the signature or signature/system type, the developer of the third party application may submit its application to be re-signed as a system application by the device manufacturer. But this would enable the third party application to have all types of system rights, which is not beneficial for the device manufacturer to monitor, and there is a risk of revealing the user's privacy.

Disclosure of Invention

The embodiment of the application provides a system authority management method, a system and electronic equipment, which can grant specific system authority to specific applications and avoid abuse of the system authority.

In order to achieve the above purpose, the embodiment of the present application adopts the following technical scheme:

in a first aspect, an embodiment of the present application provides a system rights management method, where the method includes: responding to the submitting operation of a user, the first equipment sends resource configuration data to the first server, wherein the resource configuration data comprises first resource configuration information, and the first resource configuration information comprises system permissions to be configured; the method comprises the steps that a first server generates a resource configuration package based on resource configuration data and sends the resource configuration package to a second server, wherein the resource configuration package comprises a system authority configuration file, and the system authority configuration file is used for configuring system authorities to be added; the second server generates an upgrade system file according to the resource configuration package and pushes a system update notification; responding to the operation of the user upgrading system, and sending an updating request to a second server by the second equipment; in response to receiving the update request, the second server sends an upgrade system file to the second device; the second equipment analyzes the upgrade system file to obtain a system authority configuration file, and adds the system authority configured in the system authority configuration file to an authorized list, wherein the authorized list comprises the system authority which can be granted to a third party application; the second equipment acquires an application program package of a first application, wherein the application program package of the first application carries a permission certificate of the first application, and the permission certificate comprises system permissions applied by the first application; when the first application is installed, if the first system authority in the system authorities applied by the first application is contained in the authorized list, the second device grants the first system authority to the first application.

It can be seen that the present application can automatically update an authorizable list on an electronic device (e.g., a second device) based on resource configuration data submitted by a user, such that the authorizable list includes system permissions applied by the user; in this way, the authority certificate of the first application also includes the system authority required by the user, so that the first application can be granted the system authority. That is, granting system rights needs to be included in both the rights certificate and the deletable list before it can be granted. This way, the application can be granted specific application rights, avoiding that high risk system rights are misused or exploited by the developer of the application.

In an implementation manner provided in the first aspect, the resource configuration data further includes second resource configuration information and a first file carrying a device list, where the second resource configuration information includes resources to be configured, and the device list includes device identifiers of a plurality of devices; the first server generating a resource configuration package based on the resource configuration data, comprising: generating a system authority configuration file according to the first resource configuration information, and generating a resource configuration file according to the second resource configuration information, wherein the resource configuration file is used for configuring resources to be configured; generating a resource configuration package based on the system authority configuration file, the resource configuration file and the first file.

In an implementation manner provided in the first aspect, the second device parses the upgrade system file to obtain a system permission configuration file, and adds the system permissions configured in the system permission configuration file to an authorized list, where the method includes: the second device analyzes the upgrade system file to obtain a system authority configuration file and a first file, and adds the system authority configured in the system authority configuration file to the authorized list when the device identifier of the second device is contained in the device list.

That is, only the devices (devices in the device list) can be updated so that only those devices can grant the first application the system authority applied by the first application in the present application.

In an implementation manner provided in the first aspect, the generating, by the second server, an upgrade system file according to the resource configuration package includes: the second server sends a first request to a third server; in response to receiving the first request, the third server sends the private key to the second server; the second server encrypts the system authority configuration file based on the private key; and generating an upgrade system file based on the encrypted system authority configuration file, the equipment list and the resource configuration file. The security of the system authority configuration file can be effectively ensured by encrypting the system authority configuration file through the private key.

In an implementation manner provided in the first aspect, the parsing, by the second device, of the upgrade system file to obtain a system permission configuration file includes: the second equipment analyzes the upgrade system file to obtain an encrypted system authority configuration file; and decrypting the encrypted system authority configuration file by using the public key to obtain the system authority configuration file.

In an embodiment provided in the first aspect, the method further includes: if the second system authority in the system authorities applied by the first application is not included in the authorized list, the second device does not grant the first system authority to the first application.

In a second aspect, the present application further provides a system rights management method, where the method includes: the first device displays a first interface, the first interface including a first button; in response to a user operation of the first button, the first device displays a second interface, the second interface including a first input box and the second button; in response to an input operation by a user, the first device displays a name of a target system authority input by the user in a first input box; responding to the operation of the user on the second button, the first device displays a third interface, and the third interface comprises a second input box, the third button and a fourth button; in response to a user operation of the third button, the first device displays a file selection frame, the file selection frame including an icon of at least one file; responding to the operation of selecting the first file by a user, and displaying the name of the first file in a second input box by the first device, wherein at least one file comprises the first file, and the first file comprises the identifiers of a plurality of devices to be configured; and responding to the operation of the user on the fourth button, the first equipment transmits the name of the target system authority input by the user and the first file to the first server, so that the third party application has the target system authorities of a plurality of equipment to be configured.

It can be understood that the application can configure the system authority by clicking the operation of the newly added customized resource button (the first button), and the user does not need to write codes according to the system authority, thereby simplifying the flow of configuring the system authority and saving the time of configuring the system authority by the user.

In an embodiment provided in the first aspect, the method further includes: responding to the operation of clicking the first input box by the user, and displaying a selection prompt box by the first device, wherein the selection prompt box is used for providing a plurality of configurable options of the system weight for the user; in response to a user operation of selecting a target system right from a plurality of configurable system rights, the first device displays a name of the target system right in a first input box. That is, the first device can also display all the granted system authorities for the user to select, so that the user can be prevented from inputting the system authorities by himself, the operation of the user is reduced, the first server is not required to check for many times, and the configuration efficiency is effectively improved.

In one implementation manner provided in the first aspect, the first interface further includes a fifth button, and the method further includes: responding to the operation of a user on a fifth button, the first device displays a fourth interface, the fourth interface comprises a first input box and a second button, and the first input box displays the name of the first system authority; in response to an add operation by a user, the first device displays a name of a first system right and a name of a second system right added by the user in a first input box; responding to the operation of the user on the second button, the first device displays a third interface, and the third interface comprises a second input box, the third button and a fourth button; responding to the operation of the third button by the user, and displaying a file selection frame by the first device; in response to a user selecting the first file, the first device displays a name of the first file in the second input box; and responding to the operation of the user on the fourth button, the first equipment sends the name of the first system authority, the name of the second system authority added by the user and the first file to the first server, so that the third party application has the first system authority and the second system authority of the plurality of equipment to be configured. That is, the present application can edit the existing resources, and add other configuration items on the existing resource configuration items, so that the present application is convenient for the user to edit for many times.

In an implementation manner provided in the first aspect, displaying, by the first device, the name of the target system permission input by the user in the first input box includes: the first equipment sends the name of the target system authority input by the user to a first server; when a preset system authority list which can be granted comprises a name of a target system authority, the first server sends first information to the first device, the preset system authority list which can be granted comprises the name of the system authority which can be granted to a third party application, and the first information is used for indicating that the target system authority can be configured; in response to receiving the first information, the first device displays a name of the target system authority input by the user in a first input box.

In an embodiment provided in the first aspect, the method further includes: the method comprises the steps that a first server sends second information to first equipment under the condition that a preset system authority list capable of being granted does not comprise a name of a target system authority, and the second information is used for indicating that the target system authority cannot be configured; in response to receiving the second information, the first device displays first hint information indicating that the system permissions cannot be configured. That is, the user can only apply for the system rights included in the system rights list.

In an embodiment provided in the first aspect, the method further includes: and responding to the operation that the user drags the first file to the area where the second input box is located, and displaying the name of the first file in the second input box by the first device.

In a third aspect, the present application further provides a system rights management system, where the system includes a first device, a second device, a first server, and a second server, where the first device is communicatively connected to the first server, and the second server is communicatively connected to the second device and the first server, respectively; the first device is used for responding to the submitting operation of the user and sending resource configuration data to the first server, wherein the resource configuration data comprises first resource configuration information, and the first resource configuration information comprises system permissions to be configured; the first server is used for generating a resource configuration package based on the resource configuration data and sending the resource configuration package to the second server, wherein the resource configuration package comprises a system authority configuration file, and the system authority configuration file is used for configuring system authorities to be added; the second server is used for generating an upgrade system file according to the resource configuration package and pushing a system update notification; the second device is used for responding to the operation of the user upgrading system and sending an updating request to the second server; the second server is further configured to send an upgrade system file to the second device in response to receiving the update request; the second device is further configured to parse the upgrade system file to obtain a system authority configuration file, and add the system authority configured in the system authority configuration file to an authorized list, where the authorized list includes system authorities that can be granted to a third party application; the second device is further configured to obtain an application package of the first application, where the application package of the first application carries a permission certificate of the first application, where the permission certificate includes a system permission applied by the first application; the second device is further configured to grant the first application with the first system permission if the first system permission in the system permissions applied by the first application is included in the licensable list when the first application is installed.

In a fourth aspect, the present application also provides an electronic device, including: one or more processors; a memory; and one or more computer programs, wherein the one or more computer programs are stored in the memory, the one or more computer programs comprising instructions; the instructions, when executed by the electronic device, cause the electronic device to: responding to the operation of the user upgrading system, and sending an updating request to a second server; receiving an upgrade system file sent by a second server, wherein the upgrade system file comprises a system authority configuration file, and the system authority configuration file is used for configuring system authorities to be added; analyzing the upgrade system file to obtain a system authority configuration file, and adding the system authority configured in the system authority configuration file to an authorized list, wherein the authorized list comprises the system authority which can be granted to a third party application; acquiring an application program package of a first application, wherein the application program package of the first application carries a permission certificate of the first application, and the permission certificate comprises system permissions applied by the first application; when the first application is installed, if the first system authority in the system authorities applied by the first application is contained in the delegation list, the first system authority is granted to the first application.

In a fifth aspect, the present application also provides a computer-readable storage medium comprising computer instructions; the computer instructions, when run on a server or terminal device, cause the server or terminal device to perform the method as in any of the first aspects.

It may be appreciated that the advantages achieved by the system rights management method according to the second aspect, the system rights management system according to the third aspect, the electronic device according to the fourth aspect, and the computer readable storage medium according to the fifth aspect may refer to the advantages as in the first aspect and any one of the possible designs thereof, and are not described herein.

Drawings

FIG. 1 is a prior art authorization flow chart;

FIG. 2 is a diagram of a system architecture according to an embodiment of the present application;

fig. 3 is a schematic structural diagram of an electronic device according to an embodiment of the present application;

FIG. 4 is a flowchart of applying system permissions provided in an embodiment of the present application;

FIG. 5 is an interface diagram in the process of configuring system permissions according to an embodiment of the present application;

FIG. 6 is an interface diagram in the process of configuring system permissions according to an embodiment of the present application;

FIG. 7 is an interface diagram in the process of configuring system permissions according to an embodiment of the present application;

FIG. 8 is an interface diagram in the process of configuring system permissions according to an embodiment of the present application;

FIG. 9 is an interface diagram in the process of configuring system permissions according to an embodiment of the present application;

FIG. 10A is an interface diagram of a system authority configuration process according to an embodiment of the present application;

FIG. 10B is an interface diagram of a system authority configuration process according to an embodiment of the present application;

FIG. 11A is an interface diagram of a system authority configuration process according to an embodiment of the present application;

FIG. 11B is an interface diagram of a system authority configuration process according to an embodiment of the present application;

FIG. 11C is an interface diagram of a system authority configuration process according to an embodiment of the present application;

FIG. 11D is an interface diagram in the process of configuring system permissions according to an embodiment of the present application;

FIG. 11E is an interface diagram in the process of configuring system permissions according to an embodiment of the present application;

FIG. 12 is a flowchart of a system rights management method according to an embodiment of the present application;

FIG. 13 is a flowchart of a system rights management method according to an embodiment of the present application;

fig. 14 is a schematic structural diagram of a chip system according to an embodiment of the present application.

Detailed Description

The technical solutions in the embodiments of the present application will be described below with reference to the accompanying drawings in the embodiments of the present application. Wherein, in the description of the application, unless otherwise indicated, "at least one" means one or more, and "a plurality" means two or more. In addition, in order to facilitate the clear description of the technical solution of the embodiments of the present application, in the embodiments of the present application, the words "first", "second", etc. are used to distinguish the same item or similar items having substantially the same function and effect. It will be appreciated by those of skill in the art that the words "first," "second," and the like do not limit the amount and order of execution, and that the words "first," "second," and the like do not necessarily differ.

For clarity and conciseness in the description of the embodiments below, a brief introduction to related concepts or technologies is first given:

the android operating system sets the permission level of application use, and different levels have different requirements. The permission set by the android operating system comprises the following types:

ordinary (normal): any application can apply for the ordinary type of rights and the user is not prompted when installing the application. Common types of rights include the use of a network, the use of bluetooth, etc.

Risk (danthrous): any application can apply for dangerous types of rights, but the user is prompted when the application is installed. APIs that can be invoked by the dangerous type of rights include, but are not limited to, accessing private data such as messages, pictures, emails, etc. of the device or directly accessing the device's underlying high risk rights.

Signature (signature): only applications with the same signature as the one defining the rights can apply for this type of rights.

Signature/system (signature or system): only applications or system applications that have the same signature as the rights holder are defined to have the type of rights. APIs that can be invoked by the signature or rights of the signature/system type include, but are not limited to, device restoration from factory settings, disabling communications, offloading other applications, and the like.

It should be noted that, for convenience of description, the system authority will be hereinafter referred to as a signature type authority and a signature/system type authority.

Currently, as shown in fig. 1, an application package (application package, APK) of a third party application includes a permission certificate and an android management file, where the permission certificate is used to indicate the permission granted to the third party application by the operating system, and the permission granted by the permission certificate is required to be declared in the android management file. When a third party application is installed on an electronic device (e.g., a cell phone, tablet, etc.), the PMS of the electronic device may verify whether the rights requested by the third party application can be granted. Wherein the PMS may verify whether the type of rights to be granted is within the deletable list. In order to ensure the privacy of the user and to facilitate the monitoring by the device manufacturer, the device manufacturer generally specifies that the third party application can only be granted ordinary rights and dangerous rights, and then only ordinary rights and dangerous rights are included in the licensable list. If the PMS determines that the right to be granted is of a signature type, the PMS does not have the right to grant the third party to apply the right; if the PMS determines that the rights to be granted are of a normal type or a dangerous type, the rights can be granted to a third party application and recorded in an application rights list. When a third party application requests to call an API, the API queries whether the third party application has the authority required for calling the API from an application authority list, and if the third party application has the authority required for calling the API, the API is called to execute a specific function; if the third party application does not have the rights required to call the API, the call fails.

Some domestic three-party cooperators expect to install self-developed mobile device management (mobile device manager, MDM) applications on the electronic devices, so as to realize management and control of the electronic devices, such as forbid restoration of factory settings, forbid communication, and the like. In the process of managing and controlling the MDM application, a scene that an Android (Android) native system interface needs to be called often exists, and the MDM application needs to acquire system permission first, otherwise, the calling of the native system interface fails, and related management and control operation cannot be performed.

In order for an MDM application (third party application) to acquire system permissions, the developer of the MDM application may submit its application to be re-signed as a system application by the device manufacturer. Alternatively, the device manufacturer may open a system signature that is added in the installation package by the developer of the MDM application to obtain the system rights. However, these methods can enable the MDM application to have all types of system rights, which is not beneficial to the equipment manufacturer to monitor, and there is a risk of revealing the privacy of the user.

The application provides a system authority management method which can update an authorized list of PMS on specific electronic equipment based on an authority configuration requirement submitted by a user and based on a first application, wherein the authority configuration requirement comprises system authority required by the first application. When a specific electronic device installs a first application, the first application is granted the required system rights. The application avoids the misuse or illegal use of the high-risk system authority by granting the specific system authority to the specific electronic equipment.

Fig. 2 is a schematic diagram of a system architecture according to an embodiment of the present application. The system may include a first device, a second device, a first server, a second server, a third server, a fourth server, and a fifth server. The first server can be respectively communicated with the first device and the second server, the second server can be respectively communicated with the first server, the third server and the second device, the fourth server can be communicated with the second device, and the fourth server comprises an APK of the third-party application. The fifth server may be in communication with the first device.

The first server is a cloud server of a manufacturer of the electronic device (hereinafter referred to as a device manufacturer) and can provide a service for applying system rights to a user, the second server is a continuous integration (configuration integration, CI) tool of the device manufacturer, and the third server is a signature center of the device manufacturer. The first device may receive an operation submitted by a user for a rights configuration requirement of the first application and upload the rights configuration requirement to the first server in response to the submitting operation. The first server may generate a rights configuration file after receiving the rights configuration requirements and send the rights configuration file to the second server. The second server may obtain the private key from the third server, encrypt the rights configuration file based on the private key, and generate an update package based on the encrypted rights configuration file and the data such as the device list. The second server may also push an update package to the second device, based on which the second device may update the delegated authority list.

The fifth server may be a certificate platform for the device manufacturer. The developer of the application can submit a system authority application for the first application through the first device, and the first device sends the system authority application to the fifth server after receiving the system authority application. After the fifth server receives the system authority application, the fifth server or a background staff of the fifth server can audit the authority applied by the first application, and after the audit is passed, the authority certificate can be sent to the first equipment.

The fourth server may be a management server of the application. After acquiring the permission certificate, the application developer may integrate the permission certificate into the APK and upload the APK to the fourth server. The second device may receive a request to install the application and send a request to the fourth server to obtain the APK in response to the request. And after receiving the APK sent by the fourth server, the second device installs the first application.

The first device and the second device related in the embodiment of the present application may be any electronic device having a communication function. For example, the device may be a mobile phone, a tablet computer, a personal computer (personal computer, PC), a desktop (desktop), a handheld computer, a notebook (laptop), an ultra-mobile personal computer (ultra-mobile personal computer, UMPC), a netbook, a personal digital assistant (personal digital assistant, PDA), an augmented reality (augmented reality, AR) \virtual reality (VR) device, or the like, and the embodiment of the present application is not limited to the specific form of the electronic device.

The following describes a schematic structure of an electronic device applied to the implementation of the present application, taking the electronic device as an example of a mobile phone. Referring to fig. 3, the electronic device 200 may include: processor 210, external memory interface 220, internal memory 221, universal serial bus (universal serial bus, USB) interface 230, charge management module 240, power management module 241, battery 242, antenna 1, antenna 2, mobile communication module 250, wireless communication module 260, audio module 270, speaker 270A, receiver 270B, microphone 270C, headset interface 270D, sensor module 280, keys 290, motor 291, indicator 292, camera 293, display 294, and subscriber identity module (subscriber identification module, SIM) card interface 295, among others.

The sensor module 280 may include pressure sensors, gyroscope sensors, barometric pressure sensors, magnetic sensors, acceleration sensors, distance sensors, proximity sensors, fingerprint sensors, temperature sensors, touch sensors, ambient light sensors, bone conduction sensors, and the like.

It is to be understood that the structure illustrated in this embodiment does not constitute a specific limitation on the electronic apparatus 200. In other embodiments, the electronic device 200 may include more or fewer components than shown, or certain components may be combined, or certain components may be split, or different arrangements of components. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

Processor 210 may include one or more processing units such as, for example: the processor 210 may include an application processor (application processor, AP), a modem processor, a graphics processor (graphics processing unit, GPU), an image signal processor (image signal processor, ISP), a controller, a memory, a video codec, a digital signal processor (digital signal processor, DSP), a baseband processor, and/or a neural network processor (neural-network processing unit, NPU), etc. Wherein the different processing units may be separate devices or may be integrated in one or more processors.

The controller may be a neural hub and command center of the electronic device 200. The controller can generate operation control signals according to the instruction operation codes and the time sequence signals to finish the control of instruction fetching and instruction execution.

A memory may also be provided in the processor 210 for storing instructions and data. In some embodiments, the memory in the processor 210 is a cache memory. The memory may hold instructions or data that the processor 210 has just used or recycled. If the processor 210 needs to reuse the instruction or data, it may be called directly from the memory. Repeated accesses are avoided and the latency of the processor 210 is reduced, thereby improving the efficiency of the system.

In some embodiments, processor 210 may include one or more interfaces. The interfaces may include an integrated circuit (inter-integrated circuit, I2C) interface, an integrated circuit built-in audio (inter-integrated circuit sound, I2S) interface, a pulse code modulation (pulse code modulation, PCM) interface, a universal asynchronous receiver transmitter (universal asynchronous receiver/transmitter, UART) interface, a mobile industry processor interface (mobile industry processor interface, MIPI), a general-purpose input/output (GPIO) interface, a subscriber identity module (subscriber identity module, SIM) interface, and/or a universal serial bus (universal serial bus, USB) interface, among others.

It should be understood that the connection relationship between the modules illustrated in this embodiment is only illustrative, and does not limit the structure of the electronic device 200. In other embodiments, the electronic device 200 may also employ different interfaces in the above embodiments, or a combination of interfaces.

The charge management module 240 is configured to receive a charge input from a charger. The charger can be a wireless charger or a wired charger. The charging management module 240 may also provide power to the electronic device through the power management module 241 while charging the battery 242.

The power management module 241 is used for connecting the battery 242, and the charge management module 240 and the processor 210. The power management module 241 receives input from the battery 242 and/or the charge management module 240 and provides power to the processor 210, the internal memory 221, the external memory, the display 294, the camera 293, the wireless communication module 260, and the like. In some embodiments, the power management module 241 and the charge management module 240 may also be provided in the same device.

The wireless communication function of the electronic device 200 can be implemented by the antenna 1, the antenna 2, the mobile communication module 250, the wireless communication module 260, a modem processor, a baseband processor, and the like. In some embodiments, antenna 1 and mobile communication module 250 of electronic device 200 are coupled, and antenna 2 and wireless communication module 260 are coupled, such that electronic device 200 may communicate with a network and other devices via wireless communication techniques.

The antennas 1 and 2 are used for transmitting and receiving electromagnetic wave signals. Each antenna in the electronic device 200 may be used to cover a single or multiple communication bands. Different antennas may also be multiplexed to improve the utilization of the antennas. For example: the antenna 1 may be multiplexed into a diversity antenna of a wireless local area network. In other embodiments, the antenna may be used in conjunction with a tuning switch.

The mobile communication module 250 may provide a solution for wireless communication including 2G/3G/4G/5G, etc., applied on the electronic device 200. The mobile communication module 250 may include at least one filter, switch, power amplifier, low noise amplifier (low noise amplifier, LNA), etc. The mobile communication module 250 may receive electromagnetic waves from the antenna 1, perform processes such as filtering, amplifying, and the like on the received electromagnetic waves, and transmit the processed electromagnetic waves to the modem processor for demodulation.

The mobile communication module 250 can amplify the signal modulated by the modem processor, and convert the signal into electromagnetic waves through the antenna 1 to radiate. In some embodiments, at least some of the functional modules of the mobile communication module 250 may be disposed in the processor 210. In some embodiments, at least some of the functional modules of the mobile communication module 250 may be provided in the same device as at least some of the modules of the processor 210.

The wireless communication module 260 may provide solutions for wireless communication including WLAN (e.g., (wireless fidelity, wi-Fi) network), bluetooth (BT), global navigation satellite system (global navigation satellite system, GNSS), frequency modulation (frequency modulation, FM), near field wireless communication technology (near field communication, NFC), infrared technology (IR), etc., as applied on the electronic device 200.

The wireless communication module 260 may be one or more devices that integrate at least one communication processing module. The wireless communication module 260 receives electromagnetic waves via the antenna 2, modulates the electromagnetic wave signals, filters the electromagnetic wave signals, and transmits the processed signals to the processor 210. The wireless communication module 260 may also receive a signal to be transmitted from the processor 210, frequency modulate it, amplify it, and convert it to electromagnetic waves for radiation via the antenna 2.

The electronic device 200 implements display functions through a GPU, a display screen 294, an application processor, and the like. The GPU is a microprocessor for image processing, and is connected to the display screen 294 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. Processor 210 may include one or more GPUs that execute program instructions to generate or change display information.

The display 294 is used to display images, videos, and the like. The display 294 includes a display panel.

The electronic device 200 may implement a photographing function through an ISP, a camera 293, a video codec, a GPU, a display 294, an application processor, and the like. The ISP is used to process the data fed back by the camera 293. The camera 293 is used to capture still images or video. In some embodiments, the electronic device 200 may include 1 or N cameras 293, N being a positive integer greater than 1.

The external memory interface 220 may be used to connect an external memory card, such as a Micro SD card, to enable expansion of the memory capabilities of the electronic device 200. The external memory card communicates with the processor 210 through an external memory interface 220 to implement data storage functions. For example, files such as music, video, etc. are stored in an external memory card.

Internal memory 221 may be used to store computer executable program code that includes instructions. The processor 210 executes various functional applications of the electronic device 200 and data processing by executing instructions stored in the internal memory 221. For example, in an embodiment of the present application, the processor 210 may include a memory program area and a memory data area by executing instructions stored in the internal memory 221.

The storage program area may store an application program (such as a sound playing function, an image playing function, etc.) required for at least one function of the operating system, etc. The storage data area may store data created during use of the electronic device 200 (e.g., audio data, phonebook, etc.), and so on. In addition, the internal memory 221 may include a high-speed random access memory, and may further include a nonvolatile memory such as at least one magnetic disk storage device, a flash memory device, a universal flash memory (universal flash storage, UFS), and the like.

The electronic device 200 may implement audio functions through an audio module 270, a speaker 270A, a receiver 270B, a microphone 270C, an ear-headphone interface 270D, an application processor, and the like. Such as music playing, recording, etc.

Keys 290 include a power on key, a volume key, etc. The keys 290 may be mechanical keys. Or may be a touch key. The motor 291 may generate a vibration alert. The motor 291 may be used for incoming call vibration alerting or for touch vibration feedback. The indicator 292 may be an indicator light, which may be used to indicate a state of charge, a change in power, a message indicating a missed call, a notification, etc. The SIM card interface 295 is for interfacing with a SIM card. The SIM card may be inserted into the SIM card interface 295 or removed from the SIM card interface 295 to enable contact and separation from the electronic device 200. The electronic device 200 may support 1 or N SIM card interfaces, N being a positive integer greater than 1. The SIM card interface 295 may support Nano SIM cards, micro SIM cards, and the like.

Based on the system architecture shown in fig. 2, the application provides a system authority management method. The system authority management method mainly comprises 3 steps of:

the first step: and obtaining a permission certificate comprising system permission, and integrating the permission certificate into the APK of the first application.

And a second step of: and configuring the system authority, and updating an authorized list of the PMS on the second device, wherein the authorized list comprises the system authority.

And a third step of: the first application is installed on the second device, and system rights are granted to the first application.

In the following, a process of applying system rights to a first application by a client will be described in detail with reference to the accompanying drawings by taking a first device as an example of a PC.

Fig. 4 illustrates a process of acquiring a rights certificate provided by an embodiment of the present application. As shown in fig. 4, first, a client can input a system authority (e.g., system authority 1, system authority 2, etc.) that needs to be applied through a first device. Illustratively, a client may log into a credential application platform (which may also be referred to as a fifth server, e.g., "https:// development player. In response to a user entering a name of a system right (e.g., android. Permission. Read_ PRIVILEGED _phone_state) at a right application page and submitting the operation, the first device generates a right application request based on the name of the system right. The permission application request carries the name of the system permission which the user needs to apply for.

The first device may send the rights application request to the fifth server. After receiving the permission application request, the fifth server can analyze the permission application request to obtain a permission list. The fifth server may then generate a rights certificate based on the approval result of the rights list, the rights certificate including the approved system rights. In an alternative embodiment, the list of rights may be approved by the fifth server. The fifth server maintains in advance a system rights whitelist including system rights that can be granted to the third party application. The fifth server can judge whether the system authority in the authority list belongs to the system authority white list, and if the system authority in the authority list belongs to the system authority white list, the approval is passed. For example, if the system right 1 belongs to the system right white list and the system right 2 does not belong to the system right white list, the system right 1 is approved, the system right 2 is not approved, and the right certificate includes the system right 1 and does not include the system right 2. Alternatively, the fifth server may be manually approved by a security engineer (abbreviated as "An Gong") through a background device. The installer may examine the qualification of the customer, whether the first application can apply for system rights, whether the applied system rights can be authorized, etc. After the approval of the security worker is completed, uploading an approval result to a fifth server through background equipment, and generating a permission certificate by the fifth server according to the approval result. The rights certificate may also be sent to the first device after the rights certificate is generated by the fifth server.

Upon receiving the rights certificate, the client may integrate the rights certificate into a first application (e.g., an MDM application of a bank) that generates an APK for the first application. The client can also upload the APK integrated with the permission certificate to a fourth server through the first equipment for downloading and installation by the user.

Fig. 4 is a diagram illustrating only an example of applying for system authority. In fact, the client can apply for the system permission and synchronously apply for the non-system permission. If the client applies for the system authority and the non-system authority at the same time, the authority certificate granted by the fifth server may also include the system authority and the non-system authority.

After the client grants the system authority to the first application, the system authority passed by the examination and approval needs to be configured. In the following, a process of configuring system rights applied by a client to a first application will be described with reference to the accompanying drawings by taking a first device as an example of a PC.

As shown in FIG. 5, the PC may display an interface 501 to a service website that may provide the device manufacturer with a website for customizing resources, such as the website "https:// hqiyegou. Com/", of a service mall. The interface 501 includes a My order icon 502. The customer may click on the "My order" icon 502 and the PC responds to this operation, as shown in FIG. 6, and the PC may display an interface 503 (which may also be referred to as a first interface). The interface 503 may include an option to manage an order, an option to query an order, a custom resource management option, an add custom resource button 504a, a list of enterprise custom resources, and the like. The enterprise customized resource list comprises names of customized resources, customized goods, installation modes, equipment purchasing modes, updating time, state and the like. Illustratively, the resource list includes a resource order with a single number "XTDZ2022050500" and the order is for a device "television" installed in a "manual installation" and the last update time is "2022-05-05 10:38:49" in a "draft". It should be noted that, the status of the resource order may include "draft", "to-be-checked", "checking passing" and "checking failing", where the order with the status of "draft" is an order that has not been submitted by the user, and the user may modify and edit the order through the edit button 504b (may also be referred to as a fifth button).

If the customer wishes to add a new custom resource, the new custom resource button 504a may be clicked. In response to a customer clicking on the add custom resources button 504a (which may also be referred to as a first button), the PC may display an interface 505 (which may also be referred to as a second interface) as shown in fig. 7. The interface 505 provides options for customizing various resources, including customizing the boot logo of the screen, customizing the boot animation, setting the volume (including maximum volume, minimum volume, default volume), applying system permissions 506, saving options, submitting resources 507 (which may also be referred to as a second button), and the like. This option 506 is used to provide access to apply for granting system rights. The interface 505 further includes a first input box 506a and an add button 506b corresponding to the option 506. If the client wishes to apply for granting system rights to the first application, a rights name may be entered in the first input box 506 a.

For example, as shown in FIG. 8, the client may enter a rights name, such as android. Permission. READ_ PRIVILEGED _PHONE_STATE, in a first input box 506 a. In response to a client entering a rights name, the PC sends the rights name to a first server (e.g., a server of a mall of a brand of electronic device). The first server maintains a deletable system rights list including names of system rights that may be granted to third party applications. If the authority name input by the client is not in the authority list of the granted system, the first server can send the first information to the PC. After receiving the first information, the PC may display a first prompt box 508 as shown in fig. 9. The first prompt box 508 includes a first prompt message 508a, a cancel button 508b, and a delete button 508c. The first hint information 508a is used to hint that the rights configured by the client cannot be granted, for example, "permission, read PRIVILEGED _phone_state is not permitted to apply". The first prompt message 508a may further include more content, such as a warning icon, or the first prompt box 508 may include less content, which may achieve the effect of reminding the user that the permission setting is unsuccessful, which is not limited herein. The PC deletes the authority name input by the client from the first input box 506a in response to the client clicking the delete button 508c. The PC may also continue to hold the rights name in the first input box 506a in response to the client clicking on the cancel button 508b, but this is not representative of the rights being granted, but by holding the original rights name for modification by the client.

If the authority name input by the client is in the authority list of the granted system, the first server can send the second information to the PC. After receiving the second information, the PC does not need to display the first prompt box 508, and displays the rights name input by the client in the first input box 506a, so as to indicate that the rights can be configured. Of course, the PC may also display a prompt message prompting the client that the authority may be configured, without specific limitation.

Optionally, the option 506 may also include instructions regarding applying for system rights to indicate that the customer is properly using the option 506. For example, requirements may be given for applying for system rights, such as "only for a management application of an integrated rights certificate, other application customization is not effective" and examples of system rights are given.

If the client needs to apply for multiple rights, the add button 506b may be clicked. In response to a customer clicking on the add button 506b, the PC may display a new input box 506a for customer input. After the client inputs the new authority name in the new input box 506a, the first server still checks the authority name, and the PC can complete configuration after the verification is successful, details are referred to above, and details are not repeated here.

It will be appreciated that in FIG. 8, the configuration of permissions is provided for the client in a manner that provides an input box 506a for the client to enter the permission name by himself. In an alternative embodiment, the PC may provide a more convenient way for the client to enter the rights name. As shown in fig. 10A, in response to an operation of the client click input box 506a, the PC may display a selection prompt box 509. The selection prompt 509 is used to provide the customer with a plurality of options for system rights that may be granted, e.g., the plurality of options for system rights that may be granted include: android. Permission_obb, android. Permission_ PRIVILEGED _phone_state, and the like. The client can select the system authority to be configured in the selection prompt 509 according to the requirement. The selection prompt 509 also includes a ok button 509a and a cancel button 509b. The PC takes the system authority selected by the client as the authority of the configuration required by the client in response to the operation of the client selecting the system authority in the selection prompt box 509 and clicking the ok button 509 a. Alternatively, the PC may also close the selection prompt box 509 in response to an operation of clicking the cancel button 509b by the user. Because the system rights provided in the selection prompt box 509 are all system rights that can be granted to the system rights list, the first server is not required to verify the system rights selected by the client, and after the client selects and clicks the ok button 509a, the PC completes configuration of the system rights.

By displaying all the granted system authorities for the client to select, the client can be prevented from inputting authority names by himself, client operation is reduced, meanwhile, the first server is not required to be checked for many times, and configuration efficiency is effectively improved.

Of course, other resources may be configured while the client configures the system permissions, such as configuring a boot animation, deploying whether the application may run in the background, may be uninstalled, and so on. In addition, the customer may also edit resource orders that have not yet been submitted (i.e., resource orders in the "draft" state). Illustratively, as shown in (a) of fig. 10B, the user may click on edit button 504B (which may also be referred to as a fifth button). In response to an operation of clicking the edit button 504B by the user, as shown in (B) in fig. 10B, the PC may display an interface 505 (may also be referred to as a fourth interface). The interface 505 shown in (B) of fig. 10B is similar to the interface 505 in fig. 7, except that the interface 505 in (B) of fig. 10B further includes a configuration item set by a client, for example, in the interface 505, the configuration item of "boot flag" has been set, the corresponding file is "123.Jpg", and the configuration item of "boot animation" is set, where the corresponding file is "donghua. Zip", and the system authority of "android. Permission. Read_ PRIVILEGED _state" is configured. The resource configuration on the interface 505 in fig. 10B is similar to the above-described manner, and will not be described again.

After the configuration is completed, the customer may click on the submit resource button 507, as shown in FIG. 11A. In response to a client clicking on the submit resource button 507, the PC may send resource configuration information to the first server. The resource configuration information includes configuration items submitted by clients and corresponding configuration parameters. Optionally, in response to a client clicking on the submit resource button 507, the PC may also display an interface 510 (which may also be referred to as a third interface) as shown in fig. 11B. The interface 510 includes a second prompt 510a, a second input box 510b, a browse button 510c (which may also be referred to as a third button), a cancel button 510d, and a ok button 510e (which may also be referred to as a fourth button). The second prompt 510a is used to prompt the client to submit a device list, which includes a product Serial Number (SN) of the device that needs to be configured with system permissions. For example, the second hint information 510a can be "please submit a list of devices". The PC may receive an operation that a user drags a first file (the first file is a file including a device list) to an area where the second input box 510b is located, and use the first file as a file to be uploaded. Still alternatively, the PC may display a text selection box 511 as shown in fig. 11C in response to an operation of clicking the browse button 510C by the client. The text selection box 511 includes a file presentation area 511a, an open button 511b, and a file name display box 511c. The file presentation area 511a is used to present optional files, including, for example, flat. Txt, file 1.Txt, file 2.Txt. In response to a user selecting a first file (e.g., file 1. Txt). As shown in fig. 11D, if the user wishes to upload file 1.Txt, the file 1.Txt may be selected and the open button 511b may be clicked. In response to an operation in which the user selects file 1.Txt and clicks the open button 511b, as shown in fig. 11E, the PC displays the name of the first file (i.e., file 1. Txt) in the second input box 510 b. Thus, the PC can take the first file as the file to be uploaded. After the PC determines that the first file is a file to be uploaded, the name of the first file may be displayed in the second input box 510 b. On this basis, in response to the user's operation of clicking the cancel button 510d, the PC clears the name of the first file from the second input box 510 b. In response to the user clicking the ok button 510e, the PC uploads the first file to the first server.

After the client submits the resource configuration information and the first file through the first device, the first server, the second server and the third server may automatically configure the system authority of the specific electronic device (the electronic device included in the device list, for example, the second electronic device) based on the resource configuration information and the first file. As shown in fig. 12, a flow chart for automatically configuring system permissions is shown. The process comprises the following steps:

and S1201, the first device sends the resource configuration information submitted by the user and the first file to the first server.

The resource configuration information includes configuration information of system authority and configuration information of other resources (such as a startup picture, whether an application program is started up and automatically operated, etc.). In addition, the process of submitting the resource configuration information and the first file to the first server by the first device is referred to as a process shown in fig. 6 to 11B, and will not be described herein.

S1202, the first server generates a resource configuration package based on the resource configuration information and the first file, wherein the resource configuration package comprises orgPermission.xml, the first file and the resource configuration file.

Wherein the resource configuration file includes an explanation of configuration of one or more configuration items other than the system rights. The orgPermission.xml is a system authority configuration file, and includes a description for configuring the system authority applied by the client. In an alternative embodiment, the content of the orgPermission. Xml file may include:

<？xml version＝"1.0"encoding＝"UTF-8"？>

<allow-permission name＝"android.permission.PACKAGE_USAGE_STATS"/>

<allow-permission name＝"android.permission.READ_PRIVILEGED_PHONE_STATE"/>

</permissions>

The "permission-permission name" specifies the name of the system permission to be configured, for example, "android. Permission_usage_state", "android. Permission_read_ PRIVILEGED _phone_state".

The first file includes a device list including SN numbers of electronic devices for which system permissions need to be configured.

S1203, the first server sends a resource allocation packet to the second server.

S1204, the second server sends a request to obtain the private key to the third server.

The third server is a signing center of the equipment manufacturer and is used for managing signatures and keys.

And S1205, the third server feeds back the private key to the second server.

S1206, the second server encrypts the orgPermission.xml based on the private key to obtain extendsystemPermissions.xml.

Specifically, the second server may perform RSA256 signature encryption on the content of the system permission configuration file (i.e. orgpermission. Xml) based on the obtained private key, so as to obtain an encrypted system permission configuration file (i.e. extendsystempermission. Xml).

S1207, the second server generates an upgrade image file based on the extendsystems permission.xml, the first file and the resource configuration file.

In the embodiment of the application, the second server can package the extendsystems permission.xml and the resource configuration file under the mdm/xml directory of the image file, and combine the first file to generate the upgrade image file.

S1208, the second server pushes a system update notification to the second device.

The second device may be an electronic device corresponding to the SN code carried by the first file, which is not specifically limited herein.

S1209, in response to the upgrade operation of the user, the second device transmits an update request to the second server.

S1210, the second server sends an upgrade image file to the second device.

S1211, the second device decrypts the extendsystems permission.

Specifically, the PMS of the second device may manage the public key, and after the second device installs the upgrade image file, the PMS may decrypt the extendsystems permission. In addition, the PMS needs to check whether the SN code of the second device is in the device list carried by the first file. If the SN code of the second device is contained in the device list, adding the system authority in the configuration file to the authorized list; if the SN code of the second device is not included in the list of devices, the system permissions in the configuration file cannot be added to the list of authorizable devices. This allows only client-specific electronic devices to add system rights in the deletable list.

In this manner, the authorizable list includes, in addition to the non-system permissions that may otherwise be granted to the third party application, system permissions in the system permissions profile that may be granted to the third party application by the PMS.

Optionally, the user may not submit the first file, and the upgrade image file may not include the first file, and after the PMS obtains the system permission configuration file, the name of the system permission in the system permission configuration file is added to the authorized list.

After the application (see the process shown in fig. 4) and configuration (see the process shown in fig. 5-12) of the system rights required for the first application are completed. If the first application is installed on the second device, in the installation process, the PMS of the second device may parse the permission certificate carried in the APK to obtain all permissions (including system permissions and non-system permissions) applied by the first application. The PMS may also verify all rights of the first application based on the licensable list. Specifically, if the authority applied by the first application is in the authorized list, the authority can be granted to the first application; if the authority of the first application is not in the authorized list, the authorization fails. The PMS may also record, while authorizing the first application, the rights possessed by the first application in the application rights list. The application permission list comprises an application program and permissions possessed by the application program.

It will be appreciated that the system rights applied by the first application are added to the licensable list of the second device by the process shown in fig. 5-12, after the system rights are included in the rights certificate of the first application by the process shown in fig. 4. Thus, during the process of installing the first application, the second device may grant the first application system permission because the system permission applied by the first application is included in the delegation list.

Optionally, the PMS may also verify whether the SN code of the second device is in the list of devices carried by the first file. If the SN code of the second device is included in the device list and the authority applied by the first application is in the deletable list, the authority may be granted to the first application; if the SN code of the second device is not included in the device list, or the authority of the first application is not in the delegation list, the delegation fails.

After the second device grants the system authority to the first application, if the first application sends a call request to the system interface corresponding to the system authority, the system interface can be successfully called to perform related management and control operation.

In summary, the system rights management method provided by the present application can update the authorized list of PMS on a specific electronic device based on the rights configuration requirement submitted by the user, where the rights configuration requirement includes the system rights required by the first application. When a specific electronic device installs a first application, if the authority certificate of the first application also includes a statement of system authority, the electronic device may grant the first application with the required system authority. I.e. by granting specific system rights to specific electronic devices, high risk of system rights being misused or exploited by the application developer is avoided.

The embodiment of the application also provides a system authority management method, as shown in fig. 13, which comprises the following steps:

s1301, the first device displays a first interface, the first interface including a first button.

Illustratively, the first interface may be interface 503 in FIG. 6, and the first button may be the newly added custom resource button 504a.

In response to the user' S operation of the first button, the first device displays a second interface including the first input box and the second button S1302.

Illustratively, the second interface may be the interface 505 shown in fig. 7, the first input box may be the first input box 506a, and the second button may be the submit resource button 507.

S1303, in response to the input operation of the user, the first device displays the name of the target system authority input by the user in the first input box.

For example, the user's input operation may be the user inputting the rights name in the first input box operation 506 a.

In an alternative embodiment, the input operation of the user may be, for example, an operation of inputting the rights name in the first input box in fig. 8; in other alternative embodiments, the user input operation may be an operation in which the user selects one system authority from a plurality of system authorities in fig. 10A.

In addition, in an alternative embodiment, in response to an input operation by the user, the first device transmits the name of the target system authority input by the user to the first server. In the case that a preset system authority list which can be granted comprises a name of a target system authority, the first server sends first information to the first device, the preset system authority list which can be granted comprises the name of the system authority which can be granted to the third party application, and the first information is used for indicating that the target system authority can be configured; in response to receiving the first information, the first device displays a name of the target system authority input by the user in a first input box.

Under the condition that a preset list of the system authority which can be granted does not comprise the name of the target system authority, the first server sends second information to the first equipment, wherein the second information is used for indicating that the target system authority cannot be configured; in response to receiving the second information, the first device displays first hint information indicating that the system permissions cannot be configured. For example, the first prompt message may be the message in the first prompt box 508 shown in fig. 9, including but not limited to text, icon, symbol, etc.

S1304, in response to the user operating the second button, the first device displays a third interface, the third interface including a second input box, the third button, and the fourth button.

Illustratively, the user operation of the second button may be the operation of the user clicking on the submit resource button 507 in fig. 11A. The third interface may be interface 510 shown in fig. 11B. The second input box may be the second input box 510b, the third button may be the browse button 510c, and the fourth button may be the ok button 510e.

S1305, in response to the user' S operation of the third button, the first device displays a file selection frame including an icon of at least one file.

Illustratively, the file selection box may be text selection box 511 in FIG. 11C.

S1306, in response to the operation of selecting the first file by the user, the first device displays the name of the first file in the second input box, wherein at least one file comprises the first file, and the first file comprises the identifiers of a plurality of devices to be configured.

The operation of selecting the first file by the user may be an operation of selecting the first file in the file selection box and determining the first file by the user. For example, an operation of selecting the file 1.Txt and clicking the open button 511b may be shown in fig. 11D.

And S1307, responding to the operation of the user on the fourth button, the first device sends the name of the target system authority input by the user and the first file to the first server, so that the third party application has the target system authorities of the plurality of devices to be configured.

The third party application having the target system permissions of the plurality of devices to be configured may be understood that the third party application installed on the devices to be configured obtains the target system permissions through the flowcharts shown in S1201-S1211.

Embodiments of the present application also provide a chip system including at least one processor 1401 and at least one interface circuit 1402, as shown in fig. 14. The processor 1401 and the interface circuit 1402 may be interconnected by wires. For example, interface circuit 1402 may be used to receive signals from other devices (e.g., a memory of an electronic apparatus). For another example, interface circuit 1402 may be used to send signals to other devices (e.g., processor 1401).

For example, the interface circuit 1402 may read instructions stored in a memory in the electronic device and send the instructions to the processor 1401. The instructions, when executed by the processor 1401, may cause an electronic device (e.g. first device, second device, first server, second server, etc. in fig. 2) to perform the steps in the above embodiments.

Of course, the system-on-chip may also include other discrete devices, which are not particularly limited in accordance with embodiments of the present application.

Embodiments of the present application also provide a computer-readable storage medium including computer instructions that, when executed on an electronic device (e.g., a first device, a second device, a first server, a second server, etc. in fig. 2), cause the electronic device to perform the functions or steps performed by the electronic device in the above-described method embodiments.

The embodiment of the application also provides a computer program product, which when run on an electronic device, causes the electronic device to execute the functions or steps executed by the electronic device in the above-mentioned method embodiment.

In the several embodiments provided by the present application, it should be understood that the disclosed apparatus and method may be implemented in other manners. For example, the apparatus embodiments described above are merely illustrative, e.g., the division of the modules or units is merely a logical functional division, and there may be additional divisions when actually implemented, e.g., multiple units or components may be combined or integrated into another apparatus, or some features may be omitted, or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other form.

The units described as separate parts may or may not be physically separate, and the parts displayed as units may be one physical unit or a plurality of physical units, may be located in one place, or may be distributed in a plurality of different places. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

In addition, each functional unit in the embodiments of the present application may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit. The integrated units may be implemented in hardware or in software functional units.

The integrated units, if implemented in the form of software functional units and sold or used as stand-alone products, may be stored in a readable storage medium. Based on such understanding, the technical solution of the embodiments of the present application may be essentially or a part contributing to the prior art or all or part of the technical solution may be embodied in the form of a software product stored in a storage medium, including several instructions for causing a device (may be a single-chip microcomputer, a chip or the like) or a processor (processor) to perform all or part of the steps of the method described in the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read Only Memory (ROM), a random access memory (random access memory, RAM), a magnetic disk, or an optical disk, or other various media capable of storing program codes.

The foregoing is merely illustrative of specific embodiments of the present application, but the scope of the present application is not limited thereto, and any changes or substitutions within the technical scope of the present application should be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. A system rights management method, the method comprising:

in response to a submitting operation of a user, the first device sends resource configuration data to a first server, wherein the resource configuration data comprises first resource configuration information, and the first resource configuration information comprises system permissions to be configured;

the first server generates a resource configuration package based on the resource configuration data and sends the resource configuration package to a second server, wherein the resource configuration package comprises a system permission configuration file, and the system permission configuration file is used for configuring the system permissions needing to be added;

the second server generates an upgrade system file according to the resource allocation packet and pushes a system update notification;

responding to the operation of a user upgrading system, and sending an updating request to the second server by the second equipment;

In response to receiving the update request, the second server sends the upgrade system file to the second device;

the second device analyzes the upgrade system file to obtain the system authority configuration file, and adds the system authority configured in the system authority configuration file to an authorized list, wherein the authorized list comprises the system authority which can be granted to a third party application;

the second device obtains an application program package of a first application, wherein the application program package of the first application carries an authority certificate of the first application, and the authority certificate comprises system authorities applied by the first application;

when the first application is installed, if a first system authority in the system authorities applied by the first application is contained in the authorized list, the second device grants the first system authority to the first application.

2. The method of claim 1, wherein the resource configuration data further comprises second resource configuration information and a first file carrying a list of devices, the second resource configuration information comprising resources that need to be configured, the list of devices comprising device identifications of a plurality of devices;

The first server generating a resource configuration package based on the resource configuration data, comprising:

generating the system authority configuration file according to the first resource configuration information, and generating a resource configuration file according to the second resource configuration information, wherein the resource configuration file is used for configuring the resources to be configured;

and generating the resource configuration package based on the system authority configuration file, the resource configuration file and the first file.

3. The method of claim 2, wherein the second device parses the system rights configuration file from the upgrade system file and adds the system rights configured in the system rights configuration file to an authorizable list, comprising:

the second device analyzes the upgrade system file to obtain the system authority configuration file and the first file, and adds the system authority configured in the system authority configuration file to the authorized list when the device identifier of the second device is contained in the device list.

4. A method according to claim 2 or 3, wherein the second server generating an upgrade system file from the resource configuration package, comprising:

The second server sends a first request to a third server;

in response to receiving the first request, the third server sends a private key to the second server;

the second server encrypts the system authority configuration file based on the private key;

and generating the upgrade system file based on the encrypted system authority configuration file, the equipment list and the resource configuration file.

5. The method of claim 4, wherein the second device parsing the upgrade system file to obtain the system permission configuration file comprises:

the second equipment analyzes the upgrade system file to obtain an encrypted system authority configuration file;

and decrypting the encrypted system authority configuration file by using the public key to obtain the system authority configuration file.

6. A method according to any one of claims 1-3, characterized in that the method further comprises: and if the second system authority in the system authorities applied by the first application is not included in the authorized list, the second device does not grant the first system authority to the first application.

7. A system rights management method, the method comprising:

the first device displays a first interface, the first interface including a first button;

responsive to a user operation of the first button, the first device displays a second interface, the second interface including a first input box and a second button;

responding to input operation of a user, and displaying a name of a target system authority input by the user in the first input box by the first device;

responding to the operation of the user on the second button, the first device displays a third interface, wherein the third interface comprises a second input box, a third button and a fourth button;

in response to a user operation of the third button, the first device displays a file selection box, the file selection box including an icon of at least one file;

in response to a user selecting a first file, the first device displays a name of the first file in the second input box, wherein the at least one file comprises the first file, and the first file comprises identifications of a plurality of devices to be configured;

responding to the operation of the user on the fourth button, the first device sends resource configuration data to a first server, wherein the resource configuration data comprises a name of a target system authority input by the user and the first file;

The first server generates a resource configuration package based on the resource configuration data and sends the resource configuration package to the second server, wherein the resource configuration package comprises a system permission configuration file, and the system permission configuration file is used for configuring system permissions to be added;

8. The method of claim 7, wherein the method further comprises:

responding to the operation of clicking the first input box by a user, and displaying a selection prompt box by the first device, wherein the selection prompt box is used for providing a plurality of configurable options of system weight for the user;

in response to a user operation of selecting a target system right from the plurality of configurable system rights, the first device displays a name of the target system right in the first input box.

9. The method of claim 7, wherein the first interface further comprises a fifth button, the method further comprising:

responding to the operation of a user on the fifth button, the first device displays a fourth interface, wherein the fourth interface comprises the first input box and the second button, and the first input box displays the name of the first system authority;

in response to an adding operation of a user, the first device displays a name of the first system authority and a name of a second system authority added by the user in the first input box;

the first device displays the file selection frame in response to the operation of the third button by the user;

in response to a user selecting an operation of the first file, the first device displays a name of the first file in the second input box;

and responding to the operation of the user on the fourth button, the first equipment sends the name of the first system authority, the name of the second system authority added by the user and the first file to a first server, so that a third party application has the first system authority and the second system authority of the plurality of equipment to be configured.

10. The method of any of claims 7-9, wherein the first device displaying the name of the target system permission entered by the user in the first input box comprises:

the first device sends the name of the target system authority input by the user to the first server;

when a preset system authority list which can be granted comprises the name of the target system authority, the first server sends first information to the first device, wherein the preset system authority list which can be granted comprises the name of the system authority which can be granted to a third party application, and the first information is used for indicating that the target system authority can be configured;

In response to receiving the first information, the first device displays a name of a target system right entered by a user in the first input box.

11. The method according to claim 10, wherein the method further comprises:

the first server sends second information to the first device under the condition that a preset system authority list which can be granted does not comprise the name of the target system authority, wherein the second information is used for indicating that the target system authority cannot be configured;

in response to receiving the second information, the first device displays first hint information, where the first hint information is used to indicate that the system authority cannot be configured.

12. The method according to any one of claims 7-9, characterized in that the method further comprises:

and responding to the operation that the user drags the first file to the area where the second input box is located, and displaying the name of the first file in the second input box by the first device.

13. The system rights management system is characterized by comprising first equipment, second equipment, a first server and a second server, wherein the first equipment is in communication connection with the first server, and the second server is in communication connection with the second equipment and the first server respectively;

The first device is used for responding to the submitting operation of a user and sending resource configuration data to the first server, wherein the resource configuration data comprises first resource configuration information, and the first resource configuration information comprises system permissions to be configured;

the first server is used for generating a resource configuration package based on the resource configuration data and sending the resource configuration package to the second server, wherein the resource configuration package comprises a system permission configuration file, and the system permission configuration file is used for configuring the system permissions needing to be added;

the second server is used for generating an upgrade system file according to the resource allocation packet and pushing a system update notification;

the second device is used for responding to the operation of the user upgrading system and sending an update request to the second server;

the second server is further configured to send the upgrade system file to the second device in response to receiving the update request;

the second device is further configured to parse the upgrade system file to obtain the system permission configuration file, and add the system permissions configured in the system permission configuration file to an authorized list, where the authorized list includes system permissions that can be granted to a third party application;

The second device is further configured to obtain an application package of a first application, where the application package of the first application carries a permission certificate of the first application, where the permission certificate includes a system permission applied by the first application;

the second device is further configured to grant the first application with a first system right of the system rights applied by the first application if the first system right is included in the deletable list when the first application is installed.

14. An electronic device, comprising:

one or more processors;

a memory;

and one or more computer programs, wherein the one or more computer programs are stored in the memory, the one or more computer programs comprising instructions; the instructions, when executed by the electronic device, cause the electronic device to:

receiving a system update notification pushed by a second server after generating an upgrade system file according to the resource configuration package; the resource configuration package is generated by a first server according to resource configuration data, the resource configuration data is sent to the first server by a first device, the resource configuration data comprises first resource configuration information, the first resource configuration information comprises system permission to be configured, the resource configuration package comprises a system permission configuration file, and the system permission configuration file is used for configuring the system permission to be added;

Responding to the operation of the user upgrading system, and sending an updating request to a second server;

receiving an upgrade system file sent by the second server;

analyzing the upgrade system file to obtain the system authority configuration file, and adding the system authority configured in the system authority configuration file to an authorized list, wherein the authorized list comprises the system authority which can be granted to a third party application;

acquiring an application program package of a first application, wherein the application program package of the first application carries an authority certificate of the first application, and the authority certificate comprises system authorities applied by the first application;

and when the first application is installed, if the first system authority in the system authorities applied by the first application is contained in the authorized list, granting the first system authority to the first application.

15. A computer-readable storage medium comprising computer instructions;

the computer instructions, when run on a server or terminal device, cause the server or terminal device to perform the method of any of claims 1-12.