Authority management method and device and storage medium

Abstract

The invention provides an authority management method and device and a storage medium. In the method, when it is determined that a first application currently applying for using a first permission is not a trusted application, a first pop-up window is displayed in a current interface, and a second control for guiding a user to remove the limitation on the first permission is provided in the first pop-up window, so that the user can use the first application to use the first permission by operating the second control; and directly releasing the second interface of the first permission. Therefore, the user can operate the third control in the second interface, and the limitation that the first application uses the first permission is relieved, so that the user can authorize the first permission, and the first application can use the first permission.

Description

Technical Field

[0001] This application relates to the field of terminal device technology, and in particular to a permission management method, device and storage medium. Background Technology

[0002] Enhanced Confirmation Mode (ECM) in Android 15 (Google's mobile operating system, codenamed Vanilla Ice Cream, also known as Google V version) is a security feature designed to restrict sideloading applications from obtaining sensitive permissions or accessing other applications, thereby improving user security and privacy.

[0003] However, in actual use, not all side-loaded applications pose security risks. Therefore, directly restricting side-loaded applications from obtaining sensitive permissions or applications that cannot meet the actual needs of users will result in a poor user experience. Summary of the Invention

[0004] To address the aforementioned technical issues, embodiments of this application provide a permission management method, device, and storage medium, aiming to reduce erroneous control scenarios under ECM and improve the convenience for users to remove control measures.

[0005] In a first aspect, embodiments of this application provide a permission control method. The method includes: displaying a first interface corresponding to a first application, the first interface including a first control, the first control being used to trigger the use of a first permission, the first permission being a permission restricted by enhanced confirmation mode; after receiving a first operation on the first control, determining whether the first application is a trusted application; if the first application is not a trusted application, displaying a first pop-up window, the first pop-up window including a second control; after receiving a second operation on the second control, displaying a second interface corresponding to the first application, the second interface including a third control; and after receiving a third operation on the third control, removing the restriction on the first permission by the first application and canceling the third control displayed on the second interface.

[0006] The permissions restricted by the Enhanced Confirmation Model (ECM) can also be described as ECM-restricted permissions. For an introduction to ECM-restricted permissions, please refer to the section on "Sensitive Permissions or Applications" in the Examples section; it will not be repeated here.

[0007] The first permission can be understood as any one of the permissions restricted by ECM.

[0008] In this context, the first control can be understood as the control that triggers the first application to request the first permission. In some implementations, it can also be an entry point, an option, etc.

[0009] The first application can be any application installed on the electronic device.

[0010] The first interface can be understood as the interface displayed when the first application is running in the foreground, including the interface that triggers the request to use the first control.

[0011] Taking information permission as the first permission as an example, the first interface is interface 20a, and the first control is control 20a-21.

[0012] The first pop-up can be understood as the pop-up corresponding to ECM, such as window 30a-3.

[0013] The second control can be understood as a control that guides the user to remove restrictions on information permissions, such as control 30a-31 displayed in window 30a-3.

[0014] The second interface can be understood as the application information interface corresponding to the first application. In this scenario, the second interface is, for example, interface 10b.

[0015] The third control can be understood as a control displayed on the application information interface corresponding to the first application, used to remove restrictions on information permissions, such as control 10b-1 displayed on interface 10b.

[0016] Therefore, if it is determined that the first application requesting the first permission is not a trusted application, a first pop-up window is displayed on the current interface. This pop-up window provides a second control within it to guide the user to remove the restriction on the first permission. By manipulating this second control, the user can directly access a second interface to remove the first permission. In this way, the user can manipulate a third control on the second interface to remove the restriction on the first application's use of the first permission, enabling the user to authorize the first permission and allowing the first application to use it.

[0017] In other words, the permission control method provided by the embodiments of this application can effectively improve the convenience for users to remove controlled permissions (ECM restricted permissions), thereby bringing a better user experience.

[0018] For specific implementation details of this aspect, please refer to the following embodiments. Figure 2 The description of the illustrated embodiment will not be repeated here.

[0019] According to the first aspect, the first pop-up also includes a fourth control; after displaying the first pop-up, the method further includes: after receiving a fourth operation on the fourth control, displaying a third interface, the third interface being the interface of a second application, the second application being used to provide a trusted first application; after receiving a fifth operation, downloading from the second application and installing the trusted first application.

[0020] The fourth control can be understood as a control that displays the "App Market" or "App Store", such as controls 30a-32.

[0021] Understandably, the so-called official "app market" or "app store" can be understood as an application pre-installed by the manufacturer of electronic devices for downloading apps. It can also be understood as an official or secure download path for trusted apps.

[0022] The third interface can be understood as the user's interaction with the fourth control, such as clicking on it and being redirected to the official "app market" or "app store" interface.

[0023] In some implementations, clicking the fourth control can redirect to the official "App Market" or "App Store" homepage by default, as shown in interface 10c.

[0024] In some other implementations, clicking the fourth control can directly redirect to the official "App Market" or "App Store" to download and install the first application, such as interface 20c.

[0025] Therefore, if it is determined that the first application requesting first access is not a trusted application, a first pop-up window is displayed on the current interface, and a fourth control is provided in the first pop-up window to guide the user to the official download path. This allows the user to directly access the safe and reliable official download path to obtain the trusted first application by operating the fourth control, thereby improving the convenience of the user in downloading and installing trusted applications.

[0026] Furthermore, understandably, ECM restricts permissions only for the untrusted first application. Therefore, after replacing the untrusted first application with a trusted one, the user can access the ECM-restricted permissions normally when using the first application subsequently.

[0027] For specific implementation details of this aspect, please refer to the operation descriptions in the following embodiments. Figure 2 After the controls 30a-32 shown in (1) are displayed, the interface becomes Figure 3 Interface 10c shown in (1), or Figure 3 The description of interface 20c shown in (2) will not be repeated here.

[0028] According to the first aspect, or any implementation of the first aspect above, when a first operation on the first control is received and it is determined that the first application is a trusted application, the method further includes: displaying a second pop-up window, the second pop-up window being used to allow the user to set the permission status of the first permission to an authorized status; wherein, in the authorized status, the first application is allowed to use the first permission.

[0029] For example, when the first permission is information permission, the second pop-up window is, for example, window 30a-4. When the user clicks control 30a-42 in window 30a-4, the first permission is set to an authorized state, and the first application can use the first permission.

[0030] Therefore, if it is determined that the first application requesting the first permission is a trusted application, by displaying a second pop-up window on the current interface, the user can conveniently operate the controls provided by the second pop-up window directly on the current interface to authorize the first permission.

[0031] For specific implementation details of this aspect, please refer to the following embodiments. Figure 4 The description of the illustrated embodiment will not be repeated here.

[0032] According to the first aspect, or any implementation of the first aspect above, before displaying the second pop-up window, the method further includes: determining whether the first permission has been set to an authorized state; if the first permission has not been set to an authorized state, performing the operation of displaying the second pop-up window.

[0033] Therefore, for the trusted primary application, once the primary application has been granted primary permissions, a second pop-up window will not repeatedly appear to ask the user for authorization, thus ensuring a better user experience.

[0034] According to the first aspect, or any implementation of the first aspect above, before receiving the first operation on the first control, the method further includes: receiving an operation to display a second interface, displaying the second interface, the second interface including a fifth control but excluding a third control; after receiving the fifth operation on the fifth control, displaying a fourth interface, the fourth interface including a sixth control, the sixth control being used to identify the first permission; after receiving the sixth operation on the sixth control, determining whether the first application is a trusted application; if the first application is not a trusted application, displaying the fifth interface, the fifth interface including a seventh control and an eighth control, the seventh control being grayed out and set to an unselectable state, and the eighth control being set to a selected state; wherein, when the eighth control is set to a selected state, the first application is prohibited from using the first permission; after receiving the seventh operation on the seventh control, displaying a first pop-up window.

[0035] In this scenario, the second interface can be understood as interface 20b. That is, the third control is not displayed on the second interface before the first application requests the first permission.

[0036] Among them, the fifth control is, for example, the control provided in interface 20b for viewing the permissions involved in the first application, such as control 20b-1.

[0037] The fourth interface can be understood as the permission interface that displays the permissions involved in the first application, such as interface 10g.

[0038] Understandably, the permissions displayed in Interface 10g include currently authorized permissions and unauthorized permissions (i.e., currently prohibited permissions).

[0039] For example, when the first permission is information permission, the sixth control is, for example, control 10g-1 in interface 10g.

[0040] The fifth interface is, for example, interface 10h.

[0041] The seventh control is, for example, control 10h-1 in interface 10h.

[0042] The eighth control is, for example, control 10h-2 in interface 10h.

[0043] For example, when the current interface is the fifth interface, the first pop-up window displayed is, for example, window 20h-2 displayed in interface 20h.

[0044] The unselectable state can be understood as a state that cannot be selected by the user. That is, after the user performs a user operation on the control in the unselectable state, the control retains its current style.

[0045] The selected state can be understood as the state in which the user has selected the item.

[0046] Therefore, in scenarios where a user triggers a request for first permissions using the first application and then checks the authorization status of the first application for the first permissions through other entry points, if it is determined that the first application is an untrusted application, the seventh control used to authorize the first permissions will be grayed out and set to an unselectable state. This can restrict the first application from using the first permissions and ensure the user's security and privacy.

[0047] Furthermore, after the user interacts with the grayed-out, unselectable seventh control, a first pop-up window is displayed on the current screen. This pop-up window provides a second control that guides the user to remove the restriction on the first permission. By interacting with the second control, the user can directly access a second interface to remove the first permission. In this way, the user can interact with a third control on the second interface to remove the restriction on the first application's use of the first permission, allowing the user to authorize the first permission and enabling the first application to use it.

[0048] For specific implementation details of this aspect, please refer to the following embodiments. Figures 5 to 7 The description of the illustrated embodiment will not be repeated here.

[0049] According to the first aspect, or any implementation of the first aspect above, before receiving the seventh operation on the seventh control, the method further includes: receiving the operation to return to the second interface; displaying the second interface, the second interface including the third control.

[0050] Among them, the received operation to return to the second interface is, for example, clicking on control 10h-3 in interface 10h.

[0051] Therefore, the third control is only displayed on the second interface after confirming that the first application is an untrusted application. The third control is not displayed before the detection of whether the first application is an untrusted application is triggered, thus avoiding interference with the user.

[0052] According to the first aspect, or any implementation of the first aspect above, after receiving the third operation on the third control, the method further includes: after receiving the eighth operation on the fifth control displayed in the second interface, displaying the fifth interface, the fifth interface including the seventh control and the eighth control, the seventh control being ungrayed and set to a selectable state, and the eighth control being set to a selected state; wherein, when the eighth control is set to a selected state, the first application is prohibited from using the first permission; after receiving the ninth operation on the seventh control, setting the seventh control to a selected state and setting the eighth control to a selectable state; wherein, when the seventh control is set to a selected state, the first application is allowed to use the first permission.

[0053] For example, in the scenario shown in this aspect, the fifth interface is, for example, interface 30h. Correspondingly, the seventh control is, for example, control 30h-1, and the eighth control is, for example, control 30h-2.

[0054] The "selectable" state can be understood as something that can be selected by the user, but is currently not selected. In other words, it is not currently selected, but can be selected by the user clicking on it.

[0055] The seventh control, set to the selected state, is, for example, control 40h-1. Correspondingly, the eighth control, set to the selectable state, is, for example, control 40h-2. In this scenario, the fifth interface is, for example, interface 40h.

[0056] In this scenario, the eighth control, which is set to the selected state, is, for example, control 30h-2, and correspondingly, the seventh control, which is set to the selectable state, is, for example, control 30h-1. The fifth interface in this scenario is, for example, interface 30h.

[0057] Determining whether a first application is a trusted application, based on the first aspect or any implementation of the first aspect above, includes: determining whether the first application possesses first authentication information, wherein the first authentication information is used to identify the first application as a trusted application; determining that the first application is a trusted application if the first application possesses the first authentication information; and determining that the first application is not a trusted application if the first application does not possess the first authentication information.

[0058] For specific implementation details of this aspect, please refer to the following embodiments. Figure 13 ,as well as Figure 17 The description of the embodiment shown in step S104 will not be repeated here.

[0059] According to the first aspect, or any implementation of the first aspect above, determining that the first application is not a trusted application when the first application does not possess the first authentication information includes: determining whether the first application is a trusted application based on the source information of the first application when the first application does not possess the first authentication information, wherein the source information is used to identify the application information of the application that provides the first application; and determining that the first application is not a trusted application when the application that provides the first application is not a trusted application.

[0060] For specific implementation details of this aspect, please refer to the following embodiments. Figure 13 ,as well as Figure 17 The description of the embodiment shown in step S104 will not be repeated here.

[0061] According to the first aspect, or any implementation of the first aspect above, the method further includes: determining that the first application is a trusted application if the application providing the first application is a trusted application.

[0062] For specific implementation details of this aspect, please refer to the following embodiments. Figure 14 ,as well as Figure 17 The description of the embodiment shown in step S105 will not be repeated here.

[0063] According to the first aspect, or any implementation of the first aspect above, when the application providing the first application is a trusted application, determining that the first application is a trusted application includes: when the application providing the first application is a trusted application, and the first authentication information possessed by the application providing the first application is at the first level, determining that the first application is a trusted application.

[0064] For specific implementation details of this aspect, please refer to the following embodiments. Figure 14 ,as well as Figure 17 The description of the embodiment shown in step S105 will not be repeated here.

[0065] According to the first aspect, or any implementation of the first aspect above, the method further includes: determining that the first application is not a trusted application if the application providing the first application is a trusted application and the first authentication information possessed by the application providing the first application is at the second level; wherein the first level and the second level are different levels.

[0066] For specific implementation details of this aspect, please refer to the following embodiments. Figure 14 ,as well as Figure 17 The description of the embodiment shown in step S105 will not be repeated here.

[0067] According to the first aspect, or any implementation of the first aspect above, the method further includes: when downloading and / or installing the first application, determining whether the package name information and signature information of the first application match the package name information and signature information pre-stored locally; if the package name information and signature information of the first application match the package name information and signature information pre-stored locally, determining that the first application is a trusted application; if the first application is a trusted application, upon receiving a first operation on the first control, or upon receiving a sixth operation on the sixth control, not performing the operation to determine whether the first application is a trusted application, but performing the operation after determining that the first application is a trusted application; if the first application is not a trusted application, upon receiving a first operation on the first control, or upon receiving a sixth operation on the sixth control, performing the operation to determine whether the first application is a trusted application, and performing the operation after determining that the first application is not a trusted application.

[0068] For specific implementation details of this aspect, please refer to the following embodiments. Figure 15 Figure 16 ,as well as Figure 17 The description of the embodiment shown in step S106 will not be repeated here.

[0069] According to the first aspect, or any implementation of the first aspect above, the locally pre-stored package name information and signature information include the pre-set package name information and signature information, as well as the package name information and signature information obtained from the server.

[0070] The package name information and signature information stored locally are, for example, the package name information and signature information recorded in the first trusted application whitelist as described in the following embodiments.

[0071] The package name information and signature information obtained from the server are, for example, the package name information and signature information recorded in the second trusted application whitelist as described in the following embodiments.

[0072] Understandably, the server can be a cloud server or a physical server.

[0073] According to the first aspect, or any of the implementation methods of the first aspect above, the pre-set package name information and signature information are modified through system upgrades.

[0074] In other words, users cannot modify the preset package name and signature information. This prevents accidental user actions from affecting the judgment of trusted applications.

[0075] Secondly, embodiments of this application provide an electronic device. The electronic device includes: a memory and a processor, the memory and the processor being coupled; the memory stores program instructions, which, when executed by the processor, cause the electronic device to perform the methods of the first aspect or any possible implementation thereof.

[0076] Thirdly, embodiments of this application provide a computer-readable medium for storing a computer program, the computer program including instructions for performing the method in the first aspect or any possible implementation of the first aspect.

[0077] Fourthly, embodiments of this application provide a computer program including instructions for performing the method in the first aspect or any possible implementation thereof.

[0078] Fifthly, embodiments of this application provide a chip including a processing circuit and transceiver pins. The transceiver pins and the processing circuit communicate with each other via an internal connection path. The processing circuit executes the method in the first aspect or any possible implementation of the first aspect to control the receiving pin to receive signals and to control the transmitting pin to transmit signals. Attached Figure Description

[0079] Figure 1 This is an illustrative diagram illustrating a scenario where an untrusted application uses ECM to restrict permissions.

[0080] Figure 2 This is an illustrative diagram illustrating yet another scenario where an untrusted application uses ECM to restrict permissions.

[0081] Figure 3 This is an illustrative diagram illustrating a scenario where an untrusted application uses ECM to restrict permissions.

[0082] Figure 4 This is an illustrative diagram illustrating a scenario where a trusted application uses ECM to restrict permissions.

[0083] Figures 5-8This is an illustrative diagram illustrating yet another scenario where an untrusted application uses ECM to restrict permissions.

[0084] Figure 9 This is an illustrative diagram illustrating yet another scenario where an untrusted application uses ECM to restrict permissions.

[0085] Figure 10 This is an illustrative diagram illustrating yet another scenario where an untrusted application uses ECM to restrict permissions.

[0086] Figure 11 This is a schematic diagram of the hardware structure of an electronic device as an example.

[0087] Figure 12 A schematic diagram illustrating the software structure of an electronic device as an example;

[0088] Figure 13 This is an illustrative diagram illustrating how to determine whether an application is a trusted application or an untrusted application.

[0089] Figure 14 This is an illustrative diagram illustrating another instance of determining whether an application is a trusted application or an untrusted application.

[0090] Figure 15 and Figure 16 This is an illustrative diagram illustrating another instance of determining whether an application is a trusted application or an untrusted application.

[0091] Figure 17 This is a schematic diagram illustrating the module interactions involved in an exemplary permission management method;

[0092] Figure 18 and Figure 19 This is an illustrative diagram illustrating a scenario where permission requests are kept continuous in a permission management method. Detailed Implementation

[0093] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0094] In this article, the term "and / or" is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can represent three situations: A exists alone, A and B exist simultaneously, and B exists alone.

[0095] The terms "first" and "second," etc., used in the specification and claims of this application are used to distinguish different objects, not to describe a specific order of objects. For example, "first interface" and "second interface," etc., are used to distinguish different interfaces, not to describe a specific order of interfaces.

[0096] In the description of the embodiments of this application, the words "exemplary," "for example," or "optionally" are used to indicate examples, illustrations, or explanations. Any embodiment or design that is described as "exemplary," "for example," or "optionally" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design options. Specifically, the use of the words "exemplary," "for example," or "optionally" is intended to present the relevant concepts in a specific manner.

[0097] In the description of the embodiments of this application, the names of various elements, such as controls, areas, options, and entry points, are for illustrative purposes only and are not intended to limit the embodiments of this application. That is, in actual use, they may also be described with other names.

[0098] In the description of the embodiments in this application, unless otherwise stated, "multiple" means two or more. For example, multiple processing units means two or more processing units; multiple systems means two or more systems.

[0099] In the description of the embodiments in this application, unless otherwise stated, only one user interface can be displayed at a time. For example, if interface 10a is displayed, interface 20a will not be displayed on the current screen. Conversely, if interface 20a is displayed, interface 10a will not be displayed on the current screen. However, the elements included in different interfaces can be the same.

[0100] In the description of the embodiments of this application, unless otherwise stated, the dashed lines appearing in the drawings are for illustration only. That is, they are not shown in actual use.

[0101] To facilitate understanding, the relevant terms involved in the embodiments of this application will be introduced below.

[0102] (1) Enhanced Confirmation Mode (ECM)

[0103] In this embodiment of the application, ECM is used to restrict the use of sensitive permissions or applications by applications installed via sideloading.

[0104] (2) Side load

[0105] In this application embodiment, sideloading refers to the act of installing an application onto a device without using an official app store (store) or without authorization. It typically involves downloading the application's installation package (APK file) and manually installing it.

[0106] (3) Dangerous permissions

[0107] In this embodiment, a dangerous permission refers to a permission that requires dynamic user authorization at runtime. If the user does not authorize it, the application cannot use the permission.

[0108] Dangerous permissions may include one or more of the following: Short Message Service (SMS) permissions (referred to as "information permissions" in this application embodiment), storage permissions, contact permissions, calendar permissions, camera permissions, location permissions, sensor permissions, microphone permissions, and phone permissions.

[0109] (4) Special access permissions

[0110] In the embodiments of this application, special access permissions refer to advanced permissions that allow an application to perform certain specific operations.

[0111] For example, in some embodiments of this application, special access permissions may include one or more of the following: all file access permissions, battery optimization, precise alarm clock permission, association with work and personal applications, do not disturb permission, display on top of other applications, media management application, modification of system settings, notification usage rights, picture-in-picture, paid SMS permission, no data usage restrictions, and usage-related access permissions.

[0112] (5) Default application

[0113] In this embodiment of the application, the default application refers to an application (APP, hereinafter referred to as "application") pre-installed by the manufacturer of the electronic device to ensure the normal operation of the basic functions of the electronic device. For example, one or more of the following: camera, call, photo album (gall), settings, and messages.

[0114] (6) Sensitive permissions or applications

[0115] In this application embodiment, the sensitive permissions restricted by ECM include information permissions in dangerous permissions, and access permissions such as display on top of other applications, notification access, and usage status access in special access permissions.

[0116] In this embodiment of the application, the applications restricted by ECM are, for example, the default phone application and the default messaging application among the default applications mentioned above.

[0117] For ease of description, the default phone application will be referred to as the phone application and the default messaging application will be referred to as the messaging application in this application embodiment.

[0118] Furthermore, for ease of description, the sensitive permissions and applications restricted by ECM in this application embodiment are described as ECM-restricted permissions, or permissions restricted by ECM.

[0119] Furthermore, it should be noted that the ECM restriction permissions listed in the embodiments of this application are merely illustrative. In practical applications, ECM restriction permissions may vary depending on the system version used by the electronic device.

[0120] For example, if the current system version of the electronic device is version 1, ECM restrictions may include information permissions, display on top of other applications, notification usage permissions, usage access permissions, phone applications, and messaging applications.

[0121] For example, if the current system version of the electronic device is version 2, ECM restrictions may include messaging permissions, phone permissions, display on top of other applications, notification usage permissions, usage access permissions, phone application and messaging application.

[0122] It should be understood that the above description is merely an example provided to better understand the technical solution of this embodiment, and is not intended as the sole limitation of this embodiment. In actual use, due to the influence of the system version used by the electronic device, ECM-restricted permissions may include any dangerous permission, and / or any special access permission, and / or any default application.

[0123] The following description, with reference to the accompanying diagram, uses a mobile phone as the electronic device, the current operating system being Android 15, and ECM-restricted permissions including messaging permissions, display on top of other applications, notification usage permissions, usage access permissions, the phone application, and the messaging application as examples to illustrate the use cases of ECM.

[0124] See Figure 1 This example illustrates a scenario where an untrusted application uses ECM to restrict permissions.

[0125] like Figure 1 In example (1), an interface 10a of an application, such as APP_1, is shown. The interface 10a includes one or more controls, such as control 10a-1 for sharing the image displayed in the interface 10a.

[0126] See also Figure 1 In example (1), when a user performs a user action on control 10a-1, such as clicking control 10a-1, the mobile phone responds to the user action, and the mobile phone's user interface can display as shown in the image. Figure 1 Interface 20a is shown in (2).

[0127] See Figure 1 In example (2), interface 20a may include display element 20a-1 and window 20a-2. Display element 20a-1 may include all elements in interface 10a, and window 20a-2 is located above display element 20a-1. That is, interface 20a can be understood as an interface that displays a sharing object selection window, such as window 20a-2, on interface 10a.

[0128] See also Figure 1 In (2), for example, window 20a-2 may include one or more sharing object selection controls, such as “Send to a friend” control, “Notes” control, “Send to Moments” control, “Save to cloud drive” control, “Message” control (hereinafter referred to as: control 20), “Save” control, “Save and send message” control, etc.

[0129] In a scenario where APP_1 is an untrusted application—that is, an application not downloaded from an official download path, such as an official app store—when the user clicks controls 20a-21, the phone, based on the ECM security feature, will restrict APP_1's access to the information permissions / applications corresponding to controls 20a-21. In this case, the phone's user interface may display as follows: Figure 1 Interface 30a is shown in (3).

[0130] See Figure 1 In (3), for example, interface 30a may include display element 30a-1 and window 30a-2. Display element 30a-1 may include all elements in interface 10a, and window 30a-2 is located above display element 30a-1. That is, interface 30a can be understood as an interface that displays the ECM restriction permission window, such as window 30a-2, on interface 10a.

[0131] See also Figure 1 In example (3), window 30a-2 displays a message indicating that the currently requested ECM restriction permission has been denied access, and a message indicating that the current application cannot function properly when the ECM restriction permission has been denied access.

[0132] See also Figure 1In example (3), window 30a-2 also displays controls 30a-21 and 30a-22. When the user clicks control 30a-21, the phone responds to the user's operation by closing window 30a-2, and the user interface displayed on the phone returns to interface 10a from interface 30a. When the user clicks control 30a-22, the phone responds to the user's operation by displaying a new window on the current interface, which displays text information on how to remove the restrictions on the currently requested information permissions / information applications, such as prompting the user to go to the settings application, find the application information interface of APP_1, and then remove the restrictions on the currently requested information permissions / information applications in the application information interface of APP_1.

[0133] Through the Figure 1 As can be seen from the scenario description, if the application requesting ECM restriction permissions is an untrusted application, the application will be denied the right to use the requested ECM restriction permissions, and an ECM restriction permission window will be displayed on the current interface, such as window 30a-2, informing the user of the reason why ECM restriction permissions cannot be used, thereby protecting the user's security and privacy.

[0134] However, in stock Android 15, the trust scope is determined based on the manufacturer's own app store (hereinafter referred to as: official app store). That is, apps downloaded and installed from the official app store are considered trusted apps, while apps downloaded and installed from unofficial app stores (or apps downloaded and installed via sideloading) are considered untrusted apps. Therefore, the trust scope is too limited. For some safe and reliable sideloaded apps that do not pose any security risks, directly restricting their access to ECM permissions obviously cannot meet the actual needs of users.

[0135] Furthermore, because there are many side-mounted applications that do not pose security risks, users have to check them one by one to remove restrictions. Due to the deep nesting of entry points, multiple human-computer interaction operations are required to find the corresponding application information interface and then remove the application's ECM restriction permissions. In other words, the operation of removing application restrictions (restrictions on applications requesting ECM restriction permissions) is too cumbersome and complicated, resulting in a poor user experience.

[0136] In view of this, this application provides a permission management method, which aims to expand the scope of trust, reduce the scenarios of erroneous control under ECM, improve the convenience for users to remove control and download and install trusted applications, and thus better apply to various usage scenarios, meet user needs, and improve user experience.

[0137] For details on the logic for determining whether an application requesting ECM restriction permissions is a trusted application, please see [link to relevant documentation]. Figures 13 to 17The description of the illustrated embodiments will not be repeated here. The following will first refer to... Figures 2 to 10 This paper describes the changes to the mobile phone interface in a scenario where an application requests ECM to restrict permissions, based on the permission management method provided in the embodiments of this application.

[0138] Scene 1:

[0139] Specifically, in the technical solution provided in this application embodiment, when the currently used application, such as APP_1, is not a trusted application, i.e., an application that needs to restrict the use of ECM restricted permissions, when the user clicks on the controls 20a-21 in the window 20a-2 displayed in the interface 20a corresponding to APP_1, the mobile phone responds to the user operation, and the mobile phone's user interface can display as follows: Figure 2 Interface 30a is shown in (1).

[0140] See Figure 2 In (1), exemplary, different from Figure 1 Interface 30 shown in (3) Figure 2 The interface 30a shown in Figure (1) includes display element 30a-1 and window 30a-3, but does not include window 30a-2. Display element 30a-1 can include all elements in interface 10a, and window 30a-3 is located above display element 30a-1. That is, in the technical solution provided in this application embodiment, in the scenario where an untrusted application requests ECM restriction permissions, the window that pops up on the current interface is window 30a-3, not window 30a-2.

[0141] See also Figure 2 In example (1), window 30a-3 displays a message indicating that the currently requested ECM restriction permissions have been denied.

[0142] For example, in some embodiments of this application, the displayed prompt information is, for example, Figure 2 The text in (1) states, "This is an unknown source application (untrusted application). Granting sensitive permissions may put your personal and financial information at risk. For security reasons, its use has been restricted."

[0143] For example, in some other embodiments of this application, the displayed prompt message may be, for example, "This is an external application. Granting this sensitive permission to the application may put your personal and financial information at risk."

[0144] It should be understood that the above description is merely an example provided to better understand the technical solution of this embodiment, and is not intended to be the sole limitation of this embodiment. In practical applications, prompt information can be preset according to actual needs. This application embodiment uses... Figure 2 The example shown in (1) will be used for illustration.

[0145] See also Figure 2 In example (1), windows 30a-3 also display a prompt message for the user to remove the restriction themselves, such as “You can go to Settings > App Management to remove the restriction.”

[0146] See also Figure 2 In (1), for example, window 30a-3 also displays controls 30a-31 for guiding the user to remove the restrictions on the ECM.

[0147] See also Figure 2 In example (1), after the user clicks on controls 30a-31, the mobile phone responds to the user's operation and can display something like this. Figure 2 Interface 10b is shown in (2). That is, it directly leads to the application information interface of APP_1.

[0148] See Figure 2 In example (2), when APP_1 is an untrusted application, the interface 10b will display a control 10b-1 for removing restrictions.

[0149] See also Figure 2 In example (2), when a user clicks control 10b-1, the mobile phone responds to the user's operation and can remove the restriction on ECM permissions.

[0150] Accordingly, after removing the restrictions on ECM permissions, the phone's user interface will be able to display as follows: Figure 2 The interface 20b shown in (3) is shown in the figure. The interface 20b does not include the control 10b-1, but other display elements can be the same as those in the interface 10b.

[0151] It should be noted that, in this embodiment of the application, the example is taken as the user clicking on control 10b-1 to remove all ECM restriction permissions with one click.

[0152] In other embodiments of this application, when a user clicks control 10b-1, the mobile phone responds to the user's operation by popping up a window on the current screen or displaying a new screen. For example, the pop-up window or the displayed screen can display all ECM restriction permissions, as well as controls for removing each ECM restriction permission. Thus, the user can, as needed, remove the ECM restriction permission corresponding to the control being operated on by operating the control corresponding to different ECM restriction permissions.

[0153] It should be understood that the above description is merely an example provided to better understand the technical solution of this embodiment, and is not intended to be the sole limitation of this embodiment. In practical applications, windows including controls for users to remove ECM restriction permissions and controls for one-click redirection to the official download path can both serve as the windows that pop up when an untrusted application requests ECM restriction permissions in this application embodiment, i.e., the windows 30a-3 mentioned above.

[0154] See also Figure 2 In example (1), windows 30a-3 also display a prompt message guiding the user to the official app store to install a security-certified app.

[0155] Furthermore, to enhance the ease of downloading and installing trusted applications, the "App Market" controls displayed in window 30a-3, such as the TextView control (control 30a-32 in interface 30a), are configured to redirect to the App Market application. Thus, when the user clicks control 30a-32, the phone responds to the user's action, launches the App Market, and displays the corresponding App Market interface, such as... Figure 3 Interface 10c shown in (1), or Figure 3 Interface 20c is shown in (2).

[0156] For example, in some embodiments of this application, when a user clicks controls 30a-32, the application information of APP_1, such as package name information, may not be obtained. In this scenario, the mobile phone responds to the user's behavior by launching the application market and displaying interface 10c.

[0157] For example, in a scenario where the phone responds to user action by clicking controls 30a-32, launching the app store and displaying interface 10c, the user can enter the application to be downloaded and installed, such as APP_1, in the search box 10c-1 of interface 10c. Accordingly, the phone searches for APP_1 based on the information in search box 10c-1, and displays interface 20c after finding APP_1.

[0158] Understandably, in the case of display interface 20c, the search box 20c-1 displays the information entered by the user, such as APP_1, and the area below the search box 20c-1 displays the searched applications and the installation control corresponding to each application. For example, the installation control 20c-2 corresponds to APP_1.

[0159] For example, if a user clicks to install control 20c-2, the phone responds to the user's action by downloading and installing the trusted APP_1 from the app store.

[0160] For example, in some other embodiments of this application, when the user clicks controls 30a-32, application information of APP_1, such as package name information, can be obtained. In this scenario, the mobile phone responds to the user's behavior by launching the application market and directly searching for APP_1 based on the package name information. Accordingly, if APP_1 exists in the application market, interface 20c is displayed, that is, the searched APP_1 is displayed (if not, APP_1 is not displayed in this interface, and a prompt message indicating that no relevant application was found can be displayed to the user). In this way, the user can directly operate the installation control 20c-2 corresponding to APP_1 in interface 20c to download and install the trusted APP_1 from the application market.

[0161] It should be understood that the above description is merely an example provided to better understand the technical solution of this embodiment, and is not intended to be the sole limitation of this embodiment. The specific implementation details regarding downloading and installing applications from the application market are not elaborated upon in this application embodiment.

[0162] See also Figure 2 In example (1), controls 30a-33 are also displayed in window 30a-3. When the user clicks on control 30a-33, the mobile phone responds to the user's operation by closing window 30a-33, and the mobile phone's user interface returns to interface 10a.

[0163] Therefore, if it is determined that the application requesting ECM restriction permissions is an untrusted application, by displaying window 30a-3 on the current interface and providing controls 30a-31 within window 30a-3 to guide the user in removing the ECM restriction permissions, the user can directly access interface 10b for removing ECM restriction permissions by manipulating control 30a-31. In this way, the user can manipulate control 10b-1 in interface 10b to remove the restriction on the untrusted application's use of ECM restriction permissions, enabling the user to authorize ECM restriction permissions and allowing the untrusted application to use them.

[0164] In other words, the permission control method provided by the embodiments of this application can effectively improve the convenience for users to remove controlled permissions (ECM restricted permissions), thereby bringing a better user experience.

[0165] Furthermore, when it is determined that the application requesting ECM restriction permissions is an untrusted application, by displaying window 30a-3 on the current interface and providing control 30a-32 in window 30a-3 to guide the user to the official download path, the user can directly access the safe and reliable official download path to obtain the trusted APP_1 by operating control 30a-32. That is, the permission control method provided by the embodiment of this application can also improve the convenience of users downloading and installing trusted applications.

[0166] Specifically, in the technical solution provided in this application embodiment, when the currently used application, such as APP_1, is a trusted application, i.e., an application that does not require restrictions on the use of ECM-restricted permissions, when the user clicks on the control 20a-21 within the window 20a-2 displayed in the interface 20a corresponding to APP_1, the mobile phone responds to the user's operation, and the user interface can display as follows: Figure 4 Interface 30a is shown in the figure.

[0167] See Figure 4 For example, unlike Figure 1 Interface 30 shown in (3) and Figure 2 Interface 30a shown in (1) Figure 4 The interface 30a shown includes display element 30a-1 and window 30a-4. Display element 30a-1 can include all elements in interface 10a, and window 30a-4 is located above display element 30a-1. That is, in the technical solution provided in this application embodiment, in the scenario where a trusted application requests ECM restriction permissions, the window that pops up on the current interface is window 30a-4, not window 30a-2 or window 30a-3.

[0168] It should be noted that, in this embodiment of the application, windows 30a-4 can be used to allow users to restrict permissions on the currently applied ECM, such as authorizing information selection / information application.

[0169] See also Figure 4 For example, in some embodiments of this application, windows 30a-4 may include asking the user whether to authorize the use of the ECM restricted permissions of the current application, such as information permissions / information application information, as well as controls 30a-41 and 30a-42.

[0170] For example, when a user clicks on controls 30a-41, the phone responds to the user's action by disabling APP_1 from using information permissions / information applications and closing windows 30a-4.

[0171] For example, when a user clicks on controls 30a-42, the phone responds to the user's action by authorizing APP_1 to use information permissions / information applications and closing windows 30a-4.

[0172] Therefore, if it is determined that the application requesting ECM restriction permissions is a trusted application, by displaying window 30a-4 on the current interface and providing controls 30a-41 and 30a-42 in window 30a-4, the user can complete the authorization of the requested permissions on the current interface, thereby enabling APP_1 to access the information application and share the image displayed on interface 10a to the information application.

[0173] It should be understood that the above description is merely an example provided to better understand the technical solution of this embodiment, and is not intended as the sole limitation of this embodiment. In practical applications, the controls provided in windows 30a-4 for authorizing permissions requested by the currently used application, such as APP_1, may include controls that indicate whether authorization is requested each time it is used and controls that allow permissions during use. That is, the aforementioned controls 30a-42 can be replaced by controls that indicate whether authorization is requested each time it is used and controls that allow permissions during use.

[0174] Therefore, in the process of using APP_1, when the user triggers the request for ECM restriction permissions through the control displayed in the interface provided by APP_1, the permission management method provided in this application embodiment improves the convenience for users to remove control and download and install trusted applications.

[0175] Scene 2:

[0176] Specifically, in the technical solution provided in this application embodiment, before using APP_1, the user can find the permission interface involved in APP_1 through the application settings, and then actively perform user operations on the control provided in the permission interface that identifies ECM restricted permissions, triggering the processing logic to determine whether APP_1 is a trusted application, and restricting ECM restricted permissions according to the processing result.

[0177] For example, in scenario 2, when a user launches the Settings app, such as by clicking the Settings app icon, the phone responds to the user's action by displaying the following on the phone's user interface: Figure 5 Interface 10d is shown in (1).

[0178] See Figure 5 In (1), for example, interface 10d may include one or more options / controls, such as application control 10d-1.

[0179] See also Figure 5 In example (1), after the user clicks control 10d-1, the mobile phone responds to the user's operation, and the mobile phone's user interface can display as shown in the image. Figure 5 Interface 10e is shown in (2).

[0180] See Figure 5 In (2), for example, interface 10e may include one or more options / controls, such as application management control 10e-1.

[0181] See also Figure 5 In (2), for example, after the user clicks control 10e-1, the mobile phone responds to the user's operation, and the mobile phone's user interface can display as follows: Figure 6Interface 10f is shown in (1).

[0182] See Figure 6 In the example (1), the interface 10f may include settings options for all applications installed on the phone (each application's settings options display the application icon, application name, current internal storage space occupied by the application, etc.) and a search box 10f-2 for searching applications installed on the phone.

[0183] For example, in some embodiments of this application, users can perform up and down swiping gestures on the interface 10f to find the target application.

[0184] For example, in some other embodiments of this application, users can also directly enter the application name of the target application in the search box 10f-2 to search for the target application.

[0185] Taking the user's target application as APP_1 as an example, after the user clicks on the settings option 10f-1 corresponding to APP_1, the phone responds to the user's operation, and the phone's user interface can display as follows: Figure 6 Interface 20b is shown in (2).

[0186] Understandably, since the user has not used APP_1 or requested ECM restriction permissions before clicking the settings option 10f-1, the phone's user interface will display interface 20b instead of interface 10b after the user clicks the settings option 10f-1, even if APP_1 is an untrusted application.

[0187] See Figure 6 In example (2), interface 20b includes one or more options / controls. This embodiment of the application takes the example of a user clicking control 20b-1 in interface 20b to view all permissions related to the functions and services provided by APP_1.

[0188] For example, after a user clicks control 20b-1, the mobile phone responds to the user's action, and the mobile phone's user interface can display as follows: Figure 7 The interface 10g is shown in (1).

[0189] See Figure 7 In (1), for example, the interface 10g may include one or more permissions. These permissions may be divided into permissions that have been granted by the user (such as the allowed permissions displayed in the interface 10g) and permissions that have not been granted by the user (such as the prohibited permissions displayed in the interface 10g).

[0190] It should be noted that ECM restriction permissions are disabled by default.

[0191] See also Figure 7 In example (1), when APP_1 is an untrusted application, when the user clicks on the ECM to restrict permissions, such as the permission control 10g-1 corresponding to the information permission, the phone responds to the user's operation, and the phone's user interface can display as follows: Figure 7 The interface 10h is shown in (2).

[0192] See Figure 7 In example (2), when APP_1 is an untrusted application, the control in interface 10h used to grant user authorization information permissions will be grayed out and set to an unselectable state, as shown in the style of control 10h-1 in interface 10h.

[0193] See Figure 7 In (2), for example, in some embodiments of this application, a prompt message such as “restricted settings” may also be displayed at control 10h-1 so that the user knows why the control is grayed out and cannot be selected.

[0194] Furthermore, understandably, since the user clicks on control 10h-1 which has a disabled permission, the controls in interface 10h that indicate the permission corresponding to control 10h-1 is set to disabled will be set to selected, as shown in the style of control 10h-2 in interface 10h.

[0195] See also Figure 7 In example (2), in the scenario where the mobile phone displays interface 10h, when the user clicks control 10h-1, the mobile phone responds to the user's operation, and the mobile phone's user interface can display as follows: Figure 7 The interface 20h is shown in (3).

[0196] See Figure 7 In example (3), interface 20h includes display element 20h-1 and window 20h-2. Display element 20h-1 may include all elements in interface 10h, and window 20h-2 is located above display element 20h-1. That is, it can be understood that window 20h-2 is displayed on interface 10h.

[0197] It should be noted that since display element 20h-1 (or interface 10h) is already the information permission interface for APP_1 found by the user in "Settings" > "Application Management", unlike window 30a-3, window 20h-2 does not include prompts for the user to remove restrictions themselves, such as "You can go to 'Settings' > 'Application Management' to remove the restrictions." It includes other content in window 30a-3, such as prompts indicating that the currently requested ECM restriction permissions have been denied, such as "This is an unknown source application (untrusted application). Granting sensitive permissions may put your personal and financial information at risk. For security reasons, its use has been restricted." It also includes controls 20h-21 to guide the user to remove the ECM restriction permissions, controls 20h-22 to redirect to the official app store, and controls 20h-23 to close window 20h-2.

[0198] The uses of controls 20h-21, 20h-22, and 20h-23 are the same as those of controls 30a-31, 30a-32, and 30a-33, respectively. For details regarding the use of controls 20h-21, 20h-22, and 20h-23, please refer to the descriptions of controls 30a-31, 30a-32, and 30a-33 in the above embodiments; they will not be repeated here.

[0199] Furthermore, it should be noted that after the user clicks control 10g-1, the phone has already triggered a process to determine whether APP_1 is a trusted application, and has determined that APP_1 is an untrusted application. Therefore, clicking the back control 10h-3 in interface 10h returns the phone's user interface to interface 10g. Clicking the back control 10g-2 in interface 10g then returns the phone to the application information interface corresponding to APP_1, which will change from interface 20b to interface 10b. This means that the application information interface corresponding to APP_1 will display control 10b-1, which is used to remove ECM restrictions. In this way, the user can manipulate control 10b-1 to remove ECM restrictions, thereby allowing the user to authorize APP_1 to use ECM-restricted permissions.

[0200] Regarding user operation control 10b-1, after removing the ECM restriction permission control, the method to authorize APP_1 to use the ECM restriction permission can be, for example, by clicking control 20b-1 again to enter interface 10g, and then clicking control 10g-1 again to enter... Figure 8 The interface 30h shown in (1) is used to authorize APP_1 to use ECM to restrict permissions.

[0201] See Figure 8In example (1), after the ECM restriction on permissions is lifted, the control in the information permission settings interface used for authorizing information permissions by users will be un-grayed and set to an selectable state, as shown in the style of control 30h-1 in interface 30h.

[0202] In addition, it should be noted that before the user performs a user operation on interface 30h, the controls whose permissions are set to prohibited according to the identification control 10h-1 remain selected, as shown in the style of control 30h-2 in interface 30h.

[0203] See also Figure 8 In example (1), after the user clicks control 30h-1, the mobile phone responds to the user's operation and authorizes APP_1 to use ECM to restrict permissions. That is, the control in the information permission settings interface used for user to authorize information permissions will be set to the selected state, and the control whose permission corresponding to control 10h-1 is set to the prohibited state will be set to the selectable state. At this time, the user interface displayed on the mobile phone will change from interface 30h to interface 40h. That is, control 30h-1 becomes control 40h-1, and control 30h-2 becomes control 40h-2. In this way, during the subsequent use of APP_1, when the user clicks control 20a-21 in interface 20a, the image displayed in interface 10a can be directly shared to the information application.

[0204] It should be understood that the above description is merely an example provided to better understand the technical solution of this embodiment, and is not intended as the only limitation on this embodiment.

[0205] Therefore, before using APP_1, users can find the permission interface involved in APP_1, such as interface 10g, through the settings application, and then actively operate on the control provided in interface 10g that identifies ECM restricted permissions, triggering the scenario of requesting ECM restricted permissions. Based on the permission management method provided in this application embodiment, the convenience of users to remove control and download and install trusted applications is improved.

[0206] Scene 3:

[0207] Specifically, in the technical solution provided in this application embodiment, before using APP_1, the user can find the permission management interface that manages all permissions on the phone through the settings application. Then, in the permission entry provided in the permission management interface, the user can find the control that identifies the ECM restricted permission and actively perform user operation on the control that identifies the ECM restricted permission, triggering the processing logic to determine whether APP_1 is a trusted application, and restricting the ECM restricted permission according to the processing result.

[0208] For example, in scenario 3, when a user launches the Settings app, such as by clicking the Settings app icon, the phone responds to the user's action by displaying the following on the phone's user interface: Figure 5 Interface 10d is shown in (1).

[0209] For example, after a user clicks control 10d-1, the mobile phone responds to the user's action, and the mobile phone's user interface can display as follows: Figure 9 Interface 10e is shown in (1). Understandably, Figure 5 The interface 10e shown in (2) is... Figure 9 The interface 10e shown in (1) is the same user interface, and includes the same display elements.

[0210] See Figure 9 In example (1), after a user clicks the permission management control 10e-2 in interface 10e, the mobile phone responds to the user's operation, and the mobile phone's user interface can display as follows: Figure 9 The interface 10i is shown in (2). Interface 10i may include permission entry 10i-1 and application entry 10i-2. After navigating to interface 10i from other interfaces, permission entry 10i-1 is selected by default, that is, the permission management interface is interface 10i by default.

[0211] See also Figure 9 In example (2), when permission entry 10i-1 is selected, interface 10i displays all permissions provided by the phone. Understandably, these permissions may include ordinary permissions (these permissions pose a low risk to user privacy or device operation, and the system will automatically grant them if the application requests them), dangerous permissions, ECM-restricted permissions, etc.

[0212] See also Figure 9 In (2), for example, after a user clicks on the ECM to restrict permissions, such as the control 10i-3 corresponding to information permissions, the mobile phone responds to the user's operation, and the mobile phone's user interface can display as follows: Figure 9 Interface 10j is shown in (3).

[0213] For example, information permissions may include permissions to read SMS / MMS messages, permissions to send SMS messages, permissions to receive SMS messages, and permissions to send MMS messages. Therefore, interface 10j can display these specific information permissions.

[0214] See Figure 9 In (3), for example, after the user clicks the control 10j-1 corresponding to the permission to read SMS / MMS, the mobile phone responds to the user's operation, and the mobile phone's user interface can display as follows: Figure 9 The interface 10k shown in (4) is shown in the middle.

[0215] See Figure 9 In (4), for example, all applications authorized to use the permission are displayed in the interface 10k, as well as applications not authorized to use the permission.

[0216] It should be noted that, in the technical solution provided in this application embodiment, when the user clicks control 10j-1, the mobile phone will determine which applications currently installed on the phone are restricted from using this permission based on the processing logic of the permission control method provided in this application. Thus, when displaying interface 10k, the corresponding controls for the applications with restricted permissions will be grayed out and set to an unselectable state. For example, if APP_1 is an untrusted application and its permission needs to be restricted, the controls corresponding to APP_1 in interface 10k, as well as the application icon and application name of APP_1, will be grayed out and set to an unselectable state, as shown in the style of control 10k-1.

[0217] See also Figure 9 In (4), for example, in some embodiments of this application, a prompt message such as "restricted settings" may also be displayed at APP_1 so that the user knows that APP_1 cannot apply for the permission and why control 10 is grayed out and cannot be selected.

[0218] See also Figure 9 In (4), for example, after the user clicks control 10k-1, the mobile phone responds to the user's operation, and the mobile phone's user interface can display as follows: Figure 9 The interface 20k shown in (5) is shown in the middle.

[0219] See Figure 9 In example (5), interface 20k includes display element 20k-1 and window 20k-2. Display element 20k-1k can include all elements in interface 10k, and window 20k-2 is located above display element 20k-1. That is, it can be understood that window 20k-2 is displayed on interface 10k.

[0220] See also Figure 9 In example (5), window 20k-2 includes the same content as window 20h-2. For details on the use of controls 20k-21, 20k-22, and 20k-23, please refer to the descriptions of controls 20h-21, 20h-22, and 20h-23 in the above embodiments, or the descriptions of controls 30a-31, 30a-32, and 30a-33. They will not be repeated here.

[0221] In addition, it should be noted that after displaying interface 10i, when the user exits interface 10i and enters the application information interface corresponding to APP_1 in the manner described in scenario 2, the application information interface is specifically interface 10b, which will display control 10b-1 for removing ECM restriction permissions.

[0222] For instructions on granting new ECM restrictions after removing them, please refer to [link to documentation / reference]. Figure 8 The description of the illustrated embodiment will not be repeated here.

[0223] Therefore, before using APP_1, users can find the permission management interface that manages all permissions on their phone through the settings application. Then, under the permission entry provided in the permission management interface, users can find the control marked with ECM restricted permissions and actively perform user operations on the control marked with ECM restricted permissions. This triggers the processing logic to determine whether APP_1 is a trusted application, and restricts the ECM restricted permissions according to the processing result.

[0224] Scene 4:

[0225] Specifically, in the technical solution provided in this application embodiment, before using APP_1, the user can find the permission management interface that manages all permissions on the phone through the settings application, and then find the control of APP_1 in the application displayed under the application entry provided in the permission management interface, and actively perform user operations on the control of APP_1 to trigger the scenario of requesting ECM restricted permissions. Based on the permission management method provided in this application embodiment, the convenience of users to remove control and download and install trusted applications is improved.

[0226] For example, in scenario 4, after a user enters interface 10i in the manner described in scenario 3, the user can click on application entry 10i-2 on interface 10i. In this case, the phone responds to the user's operation, and the phone's user interface can display as follows: Figure 10 The interface shown is 20i.

[0227] See Figure 10 For example, interface 20i includes some display elements in interface 10i, such as permission entry 20-i (or permission entry 10i-1) and application entry 20i-2 (or application entry 10i-2).

[0228] See also Figure 10 For example, when the application entry 20i-2 is selected, the interface 20i also includes settings options for all applications installed on the phone (each application's settings options display the application icon, application name, number of permissions currently granted to the application, etc.), and a search box 20i-4 for searching applications.

[0229] For example, in some embodiments of this application, users can perform up and down swiping gestures on the interface 20i to find the target application.

[0230] For example, in some other embodiments of this application, users can also directly enter the application name of the target application in search 20i-4 to search for the target application.

[0231] Taking the user's target application as APP_1 as an example, after the user clicks on the settings option 20i-3 corresponding to APP_1, the phone responds to the user's operation, and the phone's user interface can display as follows: Figure 7 The interface 10g is shown in (1).

[0232] Regarding the logic of how the phone responds to user actions and displays the user interface after entering interface 10g and using control 10g-1, please refer to [link to relevant documentation]. Figure 7 The description of the illustrated embodiment will not be repeated here.

[0233] Therefore, before using APP_1, users can find the permission management interface that manages all permissions on their phone through the settings application. Then, they can find the control of APP_1 in the application entry provided in the permission management interface and actively perform user operations on the control of APP_1 to trigger the scenario of requesting ECM restricted permissions. Based on the permission management method provided in this application embodiment, the convenience of users to remove control and download and install trusted applications is improved.

[0234] As can be seen from the description of the above four scenarios, the permission management method provided in this application embodiment can guide users to remove control and download and install trusted applications when they apply for ECM restriction permissions using an application, or guide users to remove control and download and install trusted applications when they view the usage of ECM restriction permissions of a certain application before using the application. In either case, users can directly access the interface for removing restrictions or downloading and installing trusted applications with one click, thereby improving the convenience for users to remove control and download and install trusted applications.

[0235] The following describes in detail, with reference to the accompanying drawings, the processing logic for determining whether an application is a trusted application in the permission management method provided in the embodiments of this application, and the interaction details of the functional modules involved in the above scenario based on the processing logic.

[0236] To better understand the technical solutions provided in the embodiments of this application, before describing the technical solutions in the embodiments of this application, the hardware and software structures of the electronic devices to which the embodiments of this application are applicable will first be described in conjunction with the accompanying drawings.

[0237] It should be noted that, in the embodiments of this application, the electronic device can be a mobile phone, tablet computer, wearable device, laptop computer, etc., and will not be listed here. This application does not limit the specific type of electronic device.

[0238] See Figure 11 The electronic device 100 may include: a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a sensor module 180, a button 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc.

[0239] It should be noted that the structures illustrated in the embodiments of the present invention do not constitute a specific limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0240] The processor 110 may include one or more processing units, such as an application processor (AP), a modem, a graphics processing unit (GPU), an image signal processor (ISP), a controller, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural network processing unit (NPU), etc., which will not be listed here and this application does not limit them.

[0241] The controller can generate operation control signals based on the instruction opcode and timing signals to control the fetching and execution of instructions.

[0242] Different processing units can be independent devices or integrated into one or more processors.

[0243] The processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. This memory can store instructions or data that the processor 110 has just used or that are used repeatedly. If the processor 110 needs to use the instruction or data again, it can directly retrieve it from the memory. This avoids repeated accesses, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0244] The wireless communication function of the electronic device 100 can be implemented through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor, and baseband processor.

[0245] Antennas 1 and 2 are used to transmit and receive electromagnetic wave signals. Each antenna in electronic device 100 can be used to cover one or more communication frequency bands. Different antennas can also be reused to improve antenna utilization. For example, antenna 1 can be reused as a diversity antenna for a wireless local area network. In some other embodiments, the antennas can be used in conjunction with a tuning switch.

[0246] The modem processor may include a modulator and a demodulator.

[0247] The mobile communication module 150 can provide wireless communication solutions for electronic devices 100, including 2-generation wireless telephone technology (2G), 3-generation mobile communication technology (3G), 4-generation mobile communication technology (4G), and 5-generation mobile communication technology (5G).

[0248] The wireless communication module 160 can provide solutions for wireless communication applications on the electronic device 100, including wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), infrared (IR) technology, etc.

[0249] In some embodiments, antenna 1 of electronic device 100 is coupled to mobile communication module 150, and antenna 2 is coupled to wireless communication module 160, enabling electronic device 100 to communicate with networks and other devices via wireless communication technology. For example, it can communicate with a server that manages a second trusted application whitelist to obtain an updated second trusted application whitelist from the server, in order to better determine whether an application requesting ECM restriction permissions is a trusted application.

[0250] The display screen 194 is used to display images, videos, etc. The display screen 194 includes a display panel. In some implementations, the electronic device 100 may include one or N display screens 194, where N is a positive integer greater than 1. The electronic device 100 can implement display functions through a GPU, the display screens 194, and an application processor. The GPU is a microprocessor for image processing, connected to the display screens 194 and the application processor. The GPU is used to perform mathematical and geometric calculations and for graphics rendering. The processor 110 may include one or more GPUs, which execute program instructions to generate or modify display information.

[0251] In this embodiment, the display screen 194 is used to display various user interfaces shown in the above embodiments. The display screen 194 can also be used to receive user operations performed on the display screen 194, such as click operations and up / down swipe gestures. The processor 110 is used to respond to the user operations detected by the electronic device 100, determine the location of various hot zones, and respond to the user operations performed on various hot zones to trigger the functions corresponding to the hot zones.

[0252] The external storage interface 120 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device 100. The external memory card communicates with the processor 110 through the external storage interface 120 to perform data storage functions. For example, music, video, and other files can be saved on the external memory card.

[0253] The internal memory 121 can be used to store computer executable program code, which includes instructions. The processor 110 executes various functional applications and data processing of the electronic device 100 by running the instructions stored in the internal memory 121. The internal memory 121 may include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function, etc. The data storage area may store data created during the use of the electronic device 100, etc. Furthermore, the internal memory 121 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc.

[0254] Specifically, in this embodiment of the application, the internal memory 121 can be used to store a first trusted application whitelist pre-set by the manufacturer, a second trusted application whitelist obtained from the server during the use of the electronic device 100, and a computer program that implements the permission management method provided in this embodiment of the application.

[0255] Accordingly, the processor 110 is used to execute the aforementioned computer program to implement the permission management method.

[0256] In addition, it should be noted that the sensor module 180 may include pressure sensors, gyroscope sensors, barometric pressure sensors, magnetic sensors, accelerometers, distance sensors, proximity sensors, fingerprint sensors, temperature sensors, touch sensors, ambient light sensors, bone conduction sensors, etc., which will not be listed here, and this application does not limit them.

[0257] Furthermore, it should be noted that an operating system runs on top of the aforementioned components. Examples include Apple's iOS operating system, Google's Android open-source operating system, and Microsoft's Windows operating system. These operating systems can employ layered architectures, event-driven architectures, microkernel architectures, microservice architectures, or cloud architectures.

[0258] For ease of explanation, this application uses a layered architecture Android system, specifically Android 15, to illustrate the software structure of the electronic device 100.

[0259] It should be noted that although this application uses the Android system as an example for illustration, its basic principles are equally applicable to electronic devices based on operating systems such as iOS or Windows. That is, the permission management method provided in this application is also applicable to electronic devices with other operating systems that have the same or similar problems.

[0260] See Figure 12 This is a software structure block diagram of the electronic device 100 according to an embodiment of this application.

[0261] like Figure 12 As shown, the layered architecture of electronic device 100 divides the software into several layers, each with a clear role and division of labor. Layers communicate with each other through software interfaces. In some implementations, the Android system is divided into four layers, from top to bottom: the application layer, the application framework layer, the Android runtime and system libraries, and the kernel layer.

[0262] The application layer can include a series of application packages. For example... Figure 12 As shown, the application package may include trusted applications, untrusted applications, settings, app stores, OUC and other applications, which will not be listed here, and this application does not impose any restrictions on them.

[0263] It should be noted that, in this embodiment, "trusted application" does not refer to a single application, but rather to a class of applications. That is, there can be multiple trusted applications; these trusted applications are authenticated, secure, and legitimate applications, and ECM-restricted permissions do not apply to this class of applications. In other words, trusted applications are not restricted from using ECM-restricted permissions; users can authorize or not authorize permissions as needed.

[0264] Correspondingly, untrusted applications do not refer to individual applications, but rather to a category of applications. That is, there can be multiple untrusted applications. These untrusted applications are typically installed via sideloading, are unauthenticated, pose security risks, or are illegal. ECM restriction permissions apply to this type of application. In other words, untrusted applications will be restricted from using ECM restricted permissions, and users cannot authorize them until the restriction is lifted.

[0265] OUC, or OTAUpdate Client, can interact with the server to provide operating system upgrade packages, whitelists of second trusted applications, etc.

[0266] App stores, also known as official app stores or official download paths, are used by users to download trusted applications.

[0267] The application framework layer provides application programming interfaces (APIs) and programming frameworks for applications within the application layer. In some implementations, these APIs and frameworks can be described as functions. For example... Figure 12As shown, the application framework layer may include a permission control module, a notification manager, a content provider, a view system, a resource manager, a window manager, etc.

[0268] Specifically, in this embodiment, the permission control module is used to confirm whether the application requesting ECM restriction permissions is a trusted application or an untrusted application, and returns the corresponding identifier to the application requesting ECM restriction permissions based on the confirmation result, so that the application can display the first pop-up or the second pop-up on the current interface according to the received identifier.

[0269] Furthermore, it should be noted that in some embodiments of this application, all functions implemented by the permission control module can be completed at the application framework layer or at other layers. For example, all functions can be completed at the application framework layer, or all functions can be completed at the application layer (i.e., the permission control module is located at the application layer), or all functions can be completed at the kernel layer (i.e., the permission control module is located at the kernel layer).

[0270] Furthermore, it should be noted that in some other embodiments of this application, some functions implemented by the permission control module can be completed at the application framework layer, while others are completed at other layers. For example, the function of notifying the OUC to obtain the second trusted application whitelist from the server is implemented at the application layer, while the function of determining whether an application is a trusted or untrusted application and returning the corresponding identifier to the application requesting ECM restricted permissions based on the confirmation result is completed at the application framework layer.

[0271] It should be understood that the above description is merely an example provided to better understand the technical solution of this embodiment, and is not intended as the only limitation on this embodiment.

[0272] Regarding the access control module, the specific methods for determining whether an application is a trusted or untrusted application are as follows:

[0273] Method 1: Determine if the application has a Mobile Device Management (MDM) certificate.

[0274] In essence, an MDM certificate is a data certificate used to manage mobile devices. These devices can include smartphones, tablets, and other mobile devices. MDM certificates enable remote management and monitoring of mobile devices, ensuring data security and device compliance. Based on this characteristic, electronic device manufacturers can grant third-party applications MDM certificates with signature-level capabilities, identifying the legitimacy of the application. Thus, when requesting ECM-restricted permissions, the electronic device can determine whether the application requesting ECM-restricted permissions is trusted or untrusted by checking whether it possesses an MDM certificate, and specifically, whether it is an MDM certificate provided by the manufacturer.

[0275] For example Figure 13 As shown, for application_1 without an MDM certificate provided by the manufacturer, the electronic device will consider application_1 as an untrusted application. For application_2 with an MDM certificate, and the MDM certificate is provided by the manufacturer, the electronic device will consider application_2 as a trusted application.

[0276] Furthermore, it is understood that the MDM certificate mentioned in the embodiments of this application is an MDM certificate provided by the manufacturer, which can be understood as the MDM certificate owned by the application being the same as the MDM certificate pre-installed in the electronic device.

[0277] Therefore, when determining whether an application is a trusted application, it is determined by whether the application has an MDM certificate provided by the manufacturer. As long as the application has an MDM certificate provided by the manufacturer, it is considered a trusted application. It is no longer limited to trusted applications that must be downloaded from the official app store, thereby increasing the trust scope of trusted applications. This allows more third-party applications without security risks or applications installed through sideloading to apply for ECM restriction permissions normally.

[0278] Method 2: If the application does not have an MDM certificate provided by the manufacturer, determine whether the application that provides the application (which can be called the child application) (which can be called the parent application) has an MDM certificate, and the level of the MDM certificate indicates that the child application downloaded from the parent application is a trusted application.

[0279] For example Figure 14 As shown, when both Application_3 and Application_4 are downloaded from unknown sources, i.e., not from the official app store, both Application_3 and Application_4 can be considered trusted applications if they both have MDM certificates provided by the manufacturer.

[0280] See also Figure 14 For example, in some embodiments of this application, the MDM certificate provided by the manufacturer and owned by application_3 is at level V1, while the MDM certificate provided by the manufacturer and owned by application_4 is at level V2. The level V1 MDM certificate indicates that the sub-application downloaded from application_3 is a trusted application. The level V2 MDM certificate indicates that the sub-application downloaded from application_4 is an untrusted application. Based on this, application_5 installed from application_3 can be considered a trusted application, and application_6 installed from application_4 can be considered an untrusted application.

[0281] In other words, if an application requesting ECM restricted permissions originates from a trusted application and that trusted application possesses a V1-level MDM certificate, then that application is also a trusted application. Conversely, if an application requesting ECM restricted permissions originates from a trusted application, but that trusted application possesses a V2-level MDM certificate, then that application is an untrusted application.

[0282] Therefore, for applications without an MDM certificate, by determining whether the application providing the application has an MDM certificate provided by the manufacturer, and whether the MDM certificate is of the specified version, such as V1, as long as the current application comes from an application with a V1-level MDM certificate, the application is considered a trusted application. This no longer restricts trusted applications to be downloaded from official app stores or to applications using MDM certificates, thereby further increasing the trust scope of trusted applications. This allows more third-party applications without security risks or applications installed via sideloading to normally apply for ECM restricted permissions.

[0283] Method 3:

[0284] It should be noted that method 3 can be used alone, or it can be used in conjunction with method 1, method 2 and method 4 described below.

[0285] In addition, it should be noted that method 3 is mainly used during the installation phase.

[0286] For example Figure 15 As shown, when installing application_7, the electronic device can verify whether the package name and signature of application_7 match the package name and signature obtained from the cloud server (which can be simply referred to as: the cloud).

[0287] Accordingly, if the package name and signature of the application_7 currently installed on the electronic device match the package name and signature obtained from the cloud (verification successful), it can be confirmed that application_7 is a trusted application.

[0288] Conversely, if the package name and signature of the application_7 currently installed on the electronic device do not match the package name and signature obtained from the cloud (verification fails), it can be confirmed that application_7 is an untrusted application.

[0289] It should be noted that in practical applications, the server can also be a physical server.

[0290] Furthermore, it should be noted that in this embodiment, the server can be understood as the server corresponding to the application market. Alternatively, it can be a server that manages the package names and signatures of trusted applications provided by the application market.

[0291] It should be understood that the above description is merely an example provided to better understand the technical solution of this embodiment, and is not intended as the only limitation on this embodiment.

[0292] See also Figure 15 For example, in some embodiments of this application, the verification operation performed during the installation phase may involve the electronic device sending a request to the cloud to obtain the package name and signature. Accordingly, the cloud responds to this request by sending a managed trusted package name and signature to the electronic device. After receiving the trusted package name and signature, the electronic device can verify whether the package name and signature of the application_7 to be installed match (or are identical to) any trusted package name and signature provided by the cloud, thereby determining the verification result. Specifically, if they match, the verification is considered successful; otherwise, the verification is considered to have failed.

[0293] See also Figure 15 For example, in some other embodiments of this application, the electronic device can periodically obtain trusted package names and signatures from the cloud, so that when installing application_7, the package name and signature of the installed application_7 can be directly matched with the locally managed trusted package names and signatures (obtained from the cloud).

[0294] See also Figure 15 For example, in some other embodiments of this application, the verification operation performed during the installation phase may involve the electronic device sending the package name and signature of application_7 to a cloud server for verification. This could involve verifying whether a package name and signature identical to those of application_7 exist on the cloud server.

[0295] Correspondingly, if the cloud server has a package name and signature that are identical to those of application_7, the cloud server will send a successful verification message to the electronic device. Otherwise, it will send a verification failure message.

[0296] It should be understood that the above description is merely an example provided to better understand the technical solution of this embodiment, and is not intended as the only limitation on this embodiment.

[0297] Furthermore, it should be noted that in this embodiment, the package name can be understood as an identifier for each application, used to distinguish each application. If two applications have the same package name, the system will consider them identical, resulting in them being unusable. Therefore, the system does not allow two applications with the same package name. In other words, the package name is used to identify the application.

[0298] Furthermore, it's important to note that a signature typically includes a public key and a private key. The public key is used to verify the application's legitimacy and security, while the private key is used to sign the application. In other words, the signature is used to determine the source of the application's installation package and whether it has been modified—it's used for verification.

[0299] Therefore, by using method 3, during the installation phase, it can be determined whether the currently installed application comes from the app store or has passed the app store's verification, thus determining whether the application is a trusted application or an untrusted application.

[0300] Method 4: Determine if the application requesting ECM restriction permissions is a whitelisted application.

[0301] It should be noted that method 4 can be used alone, or it can be used when methods 1, 2, and 3 cannot confirm that the application is trusted.

[0302] In addition, it should be noted that method 4 can be used at any stage of downloading, installing, or using the application.

[0303] Specifically, in this embodiment of the application, the implementation of method 4 requires the manufacturer of the electronic device to pre-configure a first trusted application whitelist in the operating system of the electronic device. The first trusted application whitelist pre-configures the package names and signatures of different trusted applications.

[0304] In other words, by determining whether the package name and signature of the application currently requesting ECM restriction permissions match any package name and the corresponding signature in the first trusted application whitelist, it can be determined whether the application is a trusted application.

[0305] Furthermore, it should be noted that since the first trusted application whitelist is pre-installed in the operating system, the package names and signatures recorded in the first trusted application whitelist will not change unless the operating system is upgraded. To further avoid false positives, in method 4, the electronic device can also obtain a second trusted application whitelist from a server, such as a cloud server. This second trusted application whitelist records the package names and signatures of different trusted applications.

[0306] In this way, if the package name and signature of the application currently requesting ECM restriction permissions do not match the package name and the corresponding signature in the first trusted application whitelist, it can be further determined whether it matches any package name and the corresponding signature in the second trusted application whitelist.

[0307] It should be noted that the trusted applications managed in the first and second trusted application whitelists are, for example, some special applications, such as accessibility applications, or applications for use by blind people.

[0308] Furthermore, the update logic for the second trusted application whitelist can be as follows: Figure 16 As shown.

[0309] See Figure 16For example, the parameter management center can write the configuration files of newly added trusted applications, such as package names and signatures, into the publishing rule group of the parameter publishing center using a package acquisition tool. Upon detecting a new configuration file being written, the publishing rule group can publish the newly written configuration file to the parameter management server.

[0310] It should be noted that the configuration file written to the parameter management server mentioned above can be regarded as an updated second trusted whitelist.

[0311] Furthermore, it should be noted that in some embodiments of this application, the parameter management server can be an OTA server implemented based on Over-the-Air (OTA) technology. This server is... Figure 15 The cloud server shown in the image.

[0312] The process of writing the updated second trusted whitelist can occur at any time, and is consistent with... Figure 16 The steps 1.1 to 1.5 are not sequential.

[0313] See also Figure 16 For example, in the scenario of usage method 4, after the electronic device starts up, the permission control module can register with the OUC to listen for the second trusted application whitelist, i.e., execute step 1.1. In this way, the OUC periodically triggers a packet search operation (step 1.2), and after searching for the updated second trusted application whitelist from the parameter management server, it will download the second trusted application whitelist from the path provided by the parameter management server to the local storage medium, such as the internal memory, i.e., execute steps 1.3 and 1.4.

[0314] Because the OUC and the access control module have registered a listener for obtaining the second trusted application whitelist, after downloading the second trusted application whitelist to the local storage medium, the OUC sends a download completion notification message, i.e., executes step 1.5. Thus, when subsequently needing to verify whether an application requesting ECM-restricted permissions is a trusted application using method 4, the access control module can read the package names and corresponding signatures from the first trusted application whitelist (pre-set by the manufacturer, requiring an operating system upgrade to modify) and the second trusted application whitelist (obtained from the server) from its internal storage, verify the application, and then determine whether the application is trusted or untrusted based on the verification result.

[0315] It should be understood that the above description is merely an example provided to better understand the technical solution of this embodiment, and is not intended as the only limitation on this embodiment.

[0316] Therefore, through method 4, side-loaded applications that do not have an MDM certificate, do not come from an MDM certificate with a V1 level, and do not come from an app store, but have no security risks, can normally apply for ECM restriction permissions.

[0317] Furthermore, it should be noted that methods 1, 2, 3, and 4 described above can be used individually or in combination. This application does not impose any restrictions on this.

[0318] See also Figure 12 For example, the Android Runtime includes core libraries and a virtual machine. The Android Runtime is responsible for the scheduling and management of the Android system.

[0319] The core library consists of two parts: one part is the functionalities that need to be called by the Java language, and the other part is the Android core library.

[0320] The application layer and application framework layer run in a virtual machine. The virtual machine executes the Java files of the application layer and application framework layer as binary files. The virtual machine is used to perform functions such as object lifecycle management, stack management, thread management, security and exception management, and garbage collection.

[0321] System libraries can include multiple functional modules. For example: surface manager, media libraries, 3D graphics processing libraries (e.g., OpenGL ES), 2D graphics engines (e.g., SGL), etc.

[0322] The Surface Manager is used to manage the display subsystem and provides the blending of 2D and 3D layers for multiple applications.

[0323] The media library supports playback and recording of various common audio and video formats, as well as still image files. It supports multiple audio and video encoding formats, such as MPEG4, H.264, MP3, AAC, AMR, JPG, and PNG.

[0324] The 3D graphics processing library is used to implement 3D graphics drawing, image rendering, compositing, and layer processing.

[0325] Understandably, the 2D graphics engine mentioned above is a 2D drawing engine.

[0326] The kernel layer is the layer between hardware and software, and includes various hardware drivers and hardware management. For example... Figure 12 As shown, the kernel layer can include display drivers, sensor drivers, camera drivers, audio drivers, etc.

[0327] This concludes the introduction to the software structure of electronic device 100. It is understandable that... Figure 12 The layers in the illustrated software structure and the components contained in each layer do not constitute a specific limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may include more or fewer layers than illustrated, and each layer may include more or fewer components; this application does not impose any limitations.

[0328] The following are Figure 11 The hardware structure shown and Figure 12 The electronic device with the software structure shown is a mobile phone, which serves as an example. Figures 13 to 16 The method for determining trusted applications is shown in the accompanying drawings. The permission management method provided in this application embodiment will be described in detail below.

[0329] See Figure 17 This illustration demonstrates the interaction logic of objects involved in implementing the permission management method provided in this application embodiment. For ease of explanation, this application embodiment uses the requested ECM restriction permission as information permission, and APP_1 as the application requesting information permission as an example.

[0330] Furthermore, it should be noted that in this embodiment, when installing APP_1, method 3 described in the above embodiment can be used to verify whether APP_1 is a trusted application. Correspondingly, if method 3 determines that APP_1 is an untrusted application, when a user operation using information permissions is received, methods 1, and / or 2, and / or 4 can be further used to verify whether APP_1 is a trusted application, thereby minimizing false positives. For ease of explanation, this embodiment uses the example of further verifying whether APP_1 is a trusted application using methods 1, 2, and 4 when a user operation using information permissions is received, after determining that APP_1 is an untrusted application using method 3.

[0331] See Figure 17 The permission management method provided in this application embodiment specifically includes:

[0332] S101, APP_1 receives user operation for using information permissions.

[0333] Optionally, in some embodiments of this application, the user operation received by APP_1 regarding usage information permissions is, for example, a user operation on controls 20a-21 received when the electronic device, such as a mobile phone, displays interface 20a. For the implementation method of triggering the mobile phone display interface 20a, please refer to the above-mentioned methods. Figure 1 Zhong (1) and Figure 1 The description of (2) will not be repeated here.

[0334] Optionally, in some other embodiments of this application, the user operation on the usage information permission received by APP_1 is, for example, a user operation on control 10g-1 received when the electronic device, such as a mobile phone displaying interface 10g. Regarding the implementation method for triggering the mobile phone display interface 10g, please refer to the above-mentioned methods for... Figure 5 , Figure 6 ,as well as Figure 7 The description of (1) will not be repeated here.

[0335] Optionally, in some other embodiments of this application, the user operation on the usage information permission received by APP_1 is, for example, a user operation on control 10j-1 received when the electronic device, such as a mobile phone, displays interface 10j. Regarding the implementation method for triggering the mobile phone display interface 10j, please refer to the above-mentioned methods for... Figure 5 , Figure 9 Middle (1) to Figure 9 The description of (3) will not be repeated here.

[0336] Optionally, in some other embodiments of this application, the user operation on the usage information permission received by APP_1 is, for example, a user operation on control 20i-3 received when the electronic device, such as a mobile phone, displays interface 20i. Regarding the implementation method for triggering the mobile phone display interface 20i, please refer to the above-mentioned methods for... Figure 5 , Figure 9 Middle (1) Figure 9 (2) Figure 10 The description of that part will not be repeated here.

[0337] It should be understood that the above description is merely an example provided to better understand the technical solution of this embodiment, and is not intended as the only limitation on this embodiment.

[0338] S102, APP_1 sends a permission request to the permission management module.

[0339] Specifically, when the requested ECM restriction permission is an information permission, the permission request sent by APP_1 to the permission management module is specifically an information permission request.

[0340] Furthermore, it should be noted that the permission request sent by APP_1 to the permission management module may carry one or more of the following: APP_1's package name and signature information, source information, and MDM certificate information. The specific parameters carried in the permission request sent by APP_1 to the permission management module can be determined based on the settings used to determine whether an application is a trusted application.

[0341] For example, in the scenario where the above method 1 is used by default, the specific parameter information carried in the permission request sent by APP_1 to the permission control module can be MDM certificate information.

[0342] For example, in the scenario where method 2 is used by default, the specific parameter information carried in the permission request sent by APP_1 to the permission control module can be source information.

[0343] For example, in the scenario where method 4 is used by default, the specific parameter information carried in the permission request sent by APP_1 to the permission control module can be the package name information and signature information of APP_1.

[0344] For example, in scenarios using the three methods mentioned above, the specific parameter information carried in the permission request sent by APP_1 to the permission control module may include APP_1's package name and signature information, source information, and MDM certificate information.

[0345] It should be noted that, for scenarios employing the above three methods, this application embodiment stipulates that method 1 is used first for judgment, followed by method 2, and finally method 4. The judgment logic for this scenario can be found in steps S103 to S106, and will not be elaborated here.

[0346] It should be understood that the above description is merely an example provided to better understand the technical solution of this embodiment, and is not intended to be the sole limitation of this embodiment. In practical applications, the processing order of different methods can also be adjusted as needed, and this application does not impose any restrictions on this.

[0347] In addition, it should be noted that the package name information mentioned in the embodiments of this application and the package name description are the same content.

[0348] Accordingly, the signature information and signature description are the same. The MDM certificate information and MDM certificate description are the same.

[0349] S103, the permission management module parses the permission request and obtains the parameter information of APP_1.

[0350] That is, the relevant parameter information of APP_1 is parsed from the permission request, such as one or more of the package name information, signature information, source information, and MDM certificate information of APP_1 mentioned in step S102.

[0351] For ease of explanation, this application embodiment uses the above three methods to determine whether an application is a trusted application as an example. That is, the relevant parameter information of APP_1, including the package name information, signature information, source information, and MDM certificate information of APP_1, is parsed from the permission request.

[0352] S104, if the parameter information of APP_1 includes MDM certificate information, the permission management module determines whether the MDM certificate information of APP_1 is the preset MDM certificate information.

[0353] For example, in scenarios employing the above three methods, this application embodiment stipulates that method 1 is used first for judgment, followed by method 2, and finally method 4. Based on this, the permission management module can first determine whether MDM certificate information has been parsed from the permission request.

[0354] Accordingly, once the MDM certificate information has been parsed, it can be determined whether APP_1 is a trusted application. That is, it is determined whether the parsed MDM certificate information is the default MDM certificate information (MDM certificate information provided by the manufacturer of the electronic device).

[0355] Accordingly, if the parsed MDM certificate information is determined to be the preset MDM certificate information, the access control module determines that APP_1 is a trusted application. In this case, the access control module can send a second identifier to APP_1 to identify that APP_1 is a trusted application, so that APP_1 can display a second pop-up window on the current interface based on the second identifier, i.e., execute step S108.

[0356] Conversely, if it is determined that the parsed MDM certificate information is not the preset MDM certificate information, the access control module can use method 2 to further determine whether APP_1 is a trusted application, that is, execute step S105.

[0357] For details on the specific implementation of using Method 1 to confirm whether APP_1 is a trusted application, please refer to the description of Method 1 in the above embodiments, which will not be repeated here.

[0358] S105, if the parameter information of APP_1 does not include MDM certificate information, or if the MDM certificate information of APP_1 is not the preset MDM certificate information, the permission management module determines whether APP_1 is an application from an unknown source based on the source information of APP_1.

[0359] That is, if the verification using method 1 fails (the MDM certificate information of APP_1 is not the pre-MDM certificate information), or if method 1 cannot be executed (the parameter information of APP_1 does not include MDM certificate information), the permission control module can use method 2 to determine whether APP_1 is a trusted application.

[0360] It should be noted that, in this embodiment of the application, the source information specifically refers to the application information of the provider of APP_1. This application information may include the provider's MDM certificate information and the level of the MDM certificate. Thus, based on the source information of APP_1, the judgment logic of method 2 described above can be used to confirm whether APP_1 is a trusted application.

[0361] Accordingly, if it is determined that APP_1 is not an application from an unknown source, i.e., an application obtained from a provider with V1-level MDM certificate information, the permission control module determines that APP_1 is a trusted application. In this case, the permission control module can send a second identifier to APP_1 to identify that APP_1 is a trusted application, so that APP_1 can display a second pop-up window on the current interface based on the second identifier, i.e., execute step S108.

[0362] Conversely, if it is determined that APP_1 is an application from an unknown source, that is, an application not obtained from a provider with V1-level MDM certificate information, the permission control module can use method 4 to further determine whether APP_1 is a trusted application, that is, execute step S106.

[0363] For details on the specific implementation of using method 2 to confirm whether APP_1 is a trusted application, please refer to the description of method 2 in the above embodiments, which will not be repeated here.

[0364] S106, If APP_1 is an application from an unknown source, the permission management module determines whether APP_1 is an application in the trusted application whitelist based on the package name information and signature information of APP_1.

[0365] Understandably, the trusted application whitelist mentioned in this application embodiment may include a first trusted application whitelist and a second trusted application whitelist. Therefore, the permission management module determines whether APP_1 is an application in the trusted application whitelist based on the package name and signature information of APP_1. Specifically, it verifies the package name and signature information of APP_1 against any package name in the first trusted application whitelist and the corresponding signature information. It also verifies the package name and signature information of APP_1 against any package name in the second trusted application whitelist and the corresponding signature information.

[0366] Accordingly, if the package name and signature information of APP_1 match any package name and its corresponding signature information in the first trusted application whitelist, or match any package name and its corresponding signature information in the second trusted application whitelist, the permission control module determines that APP_1 is a trusted application. In this case, the permission control module can send a second identifier to APP_1 to identify that APP_1 is a trusted application, so that APP_1 can display a second pop-up window on the current interface based on the second identifier, i.e., execute step S108.

[0367] Conversely, if the package name and signature information of APP_1 do not match the package name information and corresponding signature information in the first trusted application whitelist, and also do not match the package name information and corresponding signature information in the second trusted application whitelist, the permission control module determines that APP_1 is an untrusted application. In this case, the permission control module can send a first identifier to APP_1 to identify that APP_1 is an untrusted application, so that APP_1 can display a first pop-up window on the current interface based on the first identifier, i.e., execute step S107.

[0368] Furthermore, it should be noted that when the permission control module determines whether APP_1 is a trusted or untrusted application using the three methods described above and sends a corresponding identifier to APP_1, such as a first identifier or a second identifier, it can also record the first identifier or the second identifier. This way, when a request for ECM-restricted permissions, such as information permissions, is subsequently triggered again, the permission control module can directly determine whether APP_1 is a trusted or untrusted application based on the recorded identifier information.

[0369] S107, APP_1 displays the first pop-up window on the current interface based on the first identifier provided by the permission management module.

[0370] For example, if the interface receiving the user's information access permission is interface 20a, the first pop-up window displayed would be, for example, window 30a-3. That is, the current interface includes all elements of interface 10a. Displaying window 30a-3 as the current interface can be considered as... Figure 2 Interface 30a is shown in (1).

[0371] Regarding the operation of removing ECM restriction permissions after displaying window 30a-3, please refer to the above embodiment for the procedure. Figure 2 , Figure 3 , Figure 8 The description of that part will not be repeated here.

[0372] For example, if the interface receiving the user's operation on the information access permission is interface 10g, the current interface is, for example, interface 10h. That is, the first pop-up window is displayed on interface 10h, and in this scenario, the first pop-up window is, for example, window 20h-2. The current interface displaying window 20h-2 can be regarded as interface 20h.

[0373] Regarding the operation of removing ECM restriction permissions after the display window 20h-2, please refer to the above embodiment for the procedure. Figure 7 (3) Figure 2 (2) Figure 2 (3) Figure 3 , Figure 8 The description of that part will not be repeated here.

[0374] For example, if the interface receiving the user's operation on information access permissions is interface 10j, the current interface is, for example, interface 10k. That is, the first pop-up window is displayed on interface 10k, and in this scenario, the first pop-up window is, for example, window 20k-2. The current interface displaying window 20k-2 can be regarded as interface 20k.

[0375] Regarding the operation of removing ECM restriction permissions after displaying window 20k-2, please refer to the above embodiment for the procedure. Figure 9 (5) Figure 2 (2) Figure 2 (3) Figure 3 , Figure 8 The description of that part will not be repeated here.

[0376] For example, if the interface receiving the user's information access permission is interface 20i, the current interface is, for example, interface 10h. That is, the first pop-up window is displayed on interface 10h, and in this scenario, the first pop-up window is, for example, window 20h-2. The current interface displaying window 20h-2 can be regarded as interface 20h.

[0377] Regarding the operation of removing ECM restriction permissions after the display window 20h-2, please refer to the above embodiment for the procedure. Figure 7 (3) Figure 2 (2) Figure 2 (3) Figure 3 , Figure 8 The description of that part will not be repeated here.

[0378] It should be understood that the above description is merely an example provided to better understand the technical solution of this embodiment, and is not intended as the only limitation on this embodiment.

[0379] S108, APP_1 displays a second pop-up window on the current interface based on the second identifier provided by the permission management module.

[0380] It should be noted that, based on the second identifier provided by the permission management module, the second pop-up window displayed on the current interface by APP_1 specifically occurs when APP_1 triggers a request for ECM restricted permissions during its use. That is, the second window will only pop up when ECM restricted permissions are currently required. In this case, the interface receiving the user's operation on the usage information permission is typically interface 20a. Therefore, the displayed second pop-up window is, for example, window 30a-4. That is, the current interface includes all elements in interface 10a. The current interface displaying window 30a-4 can be considered as... Figure 4 Interface 30a.

[0381] Regarding the operation of user authorization information permissions after displaying window 30a-4, please refer to the above embodiments for the specific steps. Figure 4 and Figure 8 The description of that part will not be repeated here.

[0382] Therefore, the methods for confirming whether an application is a trusted application, based on methods 1, 2, and 4, expand the scope of trust and thus reduce erroneous control scenarios under ECM.

[0383] Furthermore, if the application is confirmed to be an untrusted application according to methods 1, 2, and 4, a first pop-up window is displayed on the current interface. This pop-up window provides controls (such as controls 30a-31, 20h-21, or 20k-21) to guide the user in removing ECM restriction permissions. By operating these controls, the user can directly access the application information interface for removing ECM restriction permissions (such as interface 10b). In this way, the user can operate the controls for removing ECM restriction permissions (such as control 10b-1) on this interface to remove the restriction on APP_1's use of ECM restriction permissions (such as information permissions), allowing the user to authorize ECM restriction permissions and enabling APP_1 to use them. This improves the convenience for users to remove restrictions.

[0384] In addition, the first pop-up window provides controls (such as controls 30a-32, 20h-22, or 20k-22) to guide users to the official download path. This allows users to directly access a safe and reliable official download path to obtain the trusted app_1 by interacting with the controls. In other words, it improves the convenience for users to download and install trusted applications.

[0385] Furthermore, it should be noted that the above explanation only illustrates a scenario where one permission is requested at a time. However, in practical applications, there are cases where multiple permissions are requested simultaneously, including both ECM-restricted and non-ECM-restricted permissions. For example, after clicking the "Save and Send Message" control in window 20a-2 (requesting storage and message permissions), because APP_1 is an untrusted application, based on the ECM security feature, an ECM restriction window will first pop up on the current screen, as shown in window 30a-2, informing the user why ECM restriction permissions cannot be used. However, after closing window 30a-2, in some embodiments of this application, a window for authorizing storage permissions will not pop up on the current screen. Additionally, after the user manually removes the restriction on message permissions, a window for authorizing message permissions will not pop up on the current screen. In other words, the continuity of permission requests is poor, resulting in a poor user experience.

[0386] In view of this, this application provides another permission management method, which aims to expand the scope of trust, reduce the scenario of erroneous control under ECM, improve the convenience for users to remove control and download and install trusted applications, and improve the continuity of permission requests, thereby better adapting to various usage scenarios, meeting user needs, and improving user experience.

[0387] See Figure 18 and Figure 19 This illustration shows a scenario diagram of ensuring the continuity of application permissions in a permission management method provided in an embodiment of this application.

[0388] like Figure 18 As shown, when an untrusted application APP_1 triggers an operation requesting multiple permissions, such as requesting information permissions (ECM restricted permissions) and storage permissions, the mobile phone responds to the user's operation by using method 1, and / or method 2, and / or method 3, and / or method 4 as described in the above embodiments to confirm whether APP_1 is a trusted application. For specific implementation details of this process, please refer to the above embodiments, which will not be repeated here.

[0389] See also Figure 18 For example, if APP_1 is confirmed to be an untrusted application using method 1, and / or method 2, and / or method 3, and / or method 4, a first pop-up window can be displayed on the current screen, specifically the first pop-up window corresponding to information permissions, such as window 30a-3.

[0390] See also Figure 18For example, when a user interacts with the controls in the first pop-up window to remove the restriction on information permissions and returns to the interface corresponding to APP_1, such as interface 10a, a second pop-up window for each requested permission can be displayed sequentially on the current interface, such as interface 10a. Specifically, when the user interacts with the second pop-up window corresponding to a permission, granting or denying the permission, and closes the second pop-up window corresponding to that permission, a second pop-up window for the remaining permissions to be granted will then appear on the current interface.

[0391] Furthermore, it should be noted that in some embodiments of this application, the pop-up order of the second pop-up windows can be determined according to the application order of each permission. For example, if it is necessary to apply for information permission first, after the restriction on information permission is lifted, the second pop-up window corresponding to the information permission will pop up on interface 10a first. After the user completes the authorization operation for the information permission or closes the second pop-up window, the second pop-up window corresponding to the storage permission will then pop up on the current interface.

[0392] For example, when the user clicks Figure 19 After the controls 30a-31 shown in (1) are activated, the mobile phone responds to the user's operation and can directly access the desired location with one click. Figure 19 The interface 10b is shown in (2). After the user clicks on the control 10b-1 in the interface 10b, the mobile phone responds to the user's operation and can remove the restriction on information permissions, and the mobile phone's interface will change. Figure 19 Interface 20b is shown in (3).

[0393] See also Figure 19 In example (3), after the user clicks the return control 20b-2 in interface 20b, the mobile phone responds to the user's operation and can return to interface 30a. In this case, since the restriction on information permissions has been lifted, a second pop-up for authorizing information permissions, such as window 30a-4, can be displayed on interface 30a. That is, after the user clicks the return control 20b-2 in interface 20b, the mobile phone responds to the user's operation, and the mobile phone's display interface displays... Figure 19 Interface 30a is shown in (4).

[0394] For example, after a user clicks on control 30a-41, or control 30a-42, or the area of ​​display element 30a-1 excluding window 30a-4, the mobile phone responds to the user's operation by closing window 30a-4 and displaying a second pop-up window corresponding to storage permissions on the current interface, such as interface 30a. Figure 19Window 30a-5 is shown in (5). Window 30a-5 functions similarly to window 30a-4, serving as a means for users to authorize permissions. Specifically, window 30a-5 is used to authorize storage permissions. The uses of controls 30a-51 and 30a-52 in window 30a-5 are the same as those of controls 30a-41 and 30a-42, respectively. For details regarding the use of controls 30a-51 and 30a-52, please refer to the description of controls 30a-41 and 30a-42 in the above embodiments; further details will not be repeated here.

[0395] Furthermore, it should be noted that in the scenario of displaying interface 10b, when the user clicks the back control 10b-2, the phone responds to the user's action and can return to interface 10a. In this case, since the restriction on information permissions has not been lifted, based on... Figure 18 The logic shown allows a second pop-up window for authorizing storage permissions to be displayed on the current interface, such as interface 30a, as window 30a-5. That is, after the user clicks the back control 10b-2 in interface 10b, the phone responds to the user's action, and the phone's display screen shows... Figure 19 Interface 30a is shown in (5).

[0396] Furthermore, it should be noted that if the user clicks control 30a-33 or an area of ​​display element 30a-1 excluding window 30a-3 without clicking control 30a-31, the phone will respond to the user's action by closing window 30a-3. On the current interface, such as interface 30a, a second pop-up window corresponding to storage permissions can be directly displayed. Figure 19 The window 30a-5 is shown in (5).

[0397] Therefore, the permission management method provided by the embodiments of this application can not only expand the scope of trust and reduce the scenarios of false control under ECM, but also improve the convenience for users to remove control and download and install trusted applications, and ensure the continuity of permission requests. Thus, it can be better applied to various usage scenarios, meet user needs, and improve user experience.

[0398] Furthermore, it is understood that, in order to achieve the aforementioned functions, the electronic device includes hardware and / or software modules corresponding to the execution of each function. Based on the algorithmic steps of the various examples described in conjunction with the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in a hardware-driven or software-driven manner depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application in conjunction with the embodiments, but such implementation should not be considered beyond the scope of this application.

[0399] Furthermore, it should be noted that in practical application scenarios, the permission management methods provided in the above embodiments, implemented by electronic devices, can also be executed by a chip system included in the electronic device. This chip system may include a processor. The chip system can be coupled to a memory, enabling it to call computer programs stored in the memory during runtime to implement the steps executed by the electronic device. The processor in this chip system can be an application processor or a non-application processor.

[0400] In addition, this application embodiment also provides a computer-readable storage medium storing computer instructions. When the computer instructions are executed on an electronic device, the electronic device performs the above-mentioned related method steps to implement the permission management method in the above embodiment.

[0401] In addition, this application also provides a computer program product that, when run on an electronic device, causes the electronic device to perform the aforementioned related steps to implement the permission management method in the above embodiments.

[0402] In addition, embodiments of this application also provide a chip (which may also be a component or module), the chip may include one or more processing circuits and one or more transceiver pins; wherein, the transceiver pins and the processing circuits communicate with each other through internal connection paths, and the processing circuits execute the above-mentioned related method steps to implement the permission management method in the above embodiments, so as to control the receiving pin to receive signals and control the transmitting pin to transmit signals.

[0403] Furthermore, as can be seen from the above description, the electronic devices, computer-readable storage media, computer program products, or chips provided in the embodiments of this application are all used to execute the corresponding methods provided above. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods provided above, and will not be repeated here.

[0404] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A method for managing access permissions, characterized in that, include: Displays a first interface corresponding to the first application. The first interface includes a first control. The first control is used to trigger the use of a first permission. The first permission is a permission that is restricted by the enhanced confirmation mode. After receiving the first operation on the first control, determine whether the first application is a trusted application; If the first application is not a trusted application, a first pop-up window is displayed, and the first pop-up window includes a second control. Upon receiving a second operation on the second control, a second interface corresponding to the first application is displayed, the second interface including a third control; Upon receiving a third operation on the third control, the first application's restriction on the first permission is lifted, and the third control displayed on the second interface is removed.

2. The method according to claim 1, characterized in that, The first pop-up window also includes a fourth control; After displaying the first pop-up window, the method further includes: Upon receiving a fourth operation on the fourth control, a third interface is displayed, which is the interface of the second application, which is used to provide the trusted first application. Upon receiving the fifth operation, download and install the trusted first application from the second application.

3. The method according to claim 1 or 2, characterized in that, Upon receiving the first operation on the first control and determining that the first application is a trusted application, the method further includes: A second pop-up window is displayed, which allows the user to set the permission status of the first permission to an authorized status; In the authorized state, the first application is allowed to use the first permission.

4. The method according to claim 3, characterized in that, Before displaying the second pop-up window, the method further includes: Determine whether the first permission has been set to the authorized state; If the first permission is not set to the authorized state, the operation of displaying the second pop-up window is performed.

5. The method according to any one of claims 1 to 4, characterized in that, Before receiving the first operation on the first control, the method further includes: Upon receiving an operation to display the second interface, the second interface is displayed, which includes a fifth control but does not include the third control. Upon receiving a fifth operation on the fifth control, a fourth interface is displayed, the fourth interface including a sixth control, the sixth control being used to identify the first permission; Upon receiving the sixth operation on the sixth control, determine whether the first application is a trusted application; If the first application is not a trusted application, a fifth interface is displayed. The fifth interface includes a seventh control and an eighth control. The seventh control is grayed out and set to an unselectable state, while the eighth control is set to a selected state. When the eighth control is set to the selected state, the first application is prohibited from using the first permission. Upon receiving the seventh operation on the seventh control, the first pop-up window is displayed.

6. The method according to claim 5, characterized in that, Before receiving the seventh operation on the seventh control, the method further includes: Received the operation to return to the second interface; The second interface is displayed, and the second interface includes the third control.

7. The method according to any one of claims 1 to 6, characterized in that, After receiving the third operation on the third control, the method further includes: Upon receiving an eighth operation on the fifth control displayed in the second interface, the fifth interface is displayed. The fifth interface includes the seventh control and the eighth control. The seventh control is ungrayed and set to a selectable state, and the eighth control is set to a selected state. When the eighth control is set to the selected state, the first application is prohibited from using the first permission. Upon receiving the ninth operation on the seventh control, the seventh control is set to the selected state, and the eighth control is set to the selectable state; wherein, when the seventh control is set to the selected state, the first application is allowed to use the first permission.

8. The method according to any one of claims 1 to 7, characterized in that, Determining whether the first application is a trusted application includes: Determine whether the first application possesses first authentication information, wherein the first authentication information is used to identify the first application as a trusted application; If the first application possesses the first authentication information, the first application is determined to be a trusted application; If the first application does not possess the first authentication information, it is determined that the first application is not a trusted application.

9. The method according to claim 8, characterized in that, Determining that the first application is not a trusted application when the first application does not possess the first authentication information includes: If the first application does not possess the first authentication information, the source information of the first application is used to determine whether the first application is a trusted application, wherein the source information is used to identify the application information of the application that provides the first application. If the application providing the first application is not a trusted application, then the first application is determined to be not a trusted application.

10. The method according to claim 9, characterized in that, The method further includes: If the application providing the first application is a trusted application, then the first application is determined to be a trusted application.

11. The method according to claim 10, characterized in that, The step of determining that the first application is a trusted application when the application providing the first application is a trusted application includes: If the application providing the first application is a trusted application, and the first authentication information possessed by the application providing the first application is at the first level, then the first application is determined to be a trusted application.

12. The method according to claim 11, characterized in that, The method further includes: If the application providing the first application is a trusted application, and the first authentication information possessed by the application providing the first application is at the second level, then the first application is determined to be not a trusted application. The first level and the second level are different levels.

13. The method according to any one of claims 1 to 12, characterized in that, The method further includes: When downloading and / or installing the first application, determine whether the package name information and signature information of the first application match the package name information and signature information pre-stored locally; If the package name and signature information of the first application match the package name and signature information stored locally, the first application is determined to be a trusted application. If the first application is a trusted application, when the first operation on the first control is received, or the sixth operation on the sixth control is received, the operation of determining whether the first application is a trusted application is not executed, and the operation after determining that the first application is a trusted application is executed. If the first application is not a trusted application, upon receiving the first operation on the first control or the sixth operation on the sixth control, the operation of determining whether the first application is a trusted application is executed, and the operation after determining that the first application is not a trusted application is executed.

14. The method according to claim 13, characterized in that, The locally stored package name and signature information includes pre-set package name and signature information, as well as package name and signature information obtained from the server.

15. The method according to claim 14, characterized in that, The pre-defined package name and signature information can be modified through system upgrades.

16. An electronic device, characterized in that, The electronic device includes: a memory and a processor, the memory and the processor being coupled; the memory stores program instructions, which, when executed by the processor, cause the electronic device to perform the access control method as described in any one of claims 1 to 15.

17. A computer-readable storage medium, characterized in that, The device includes a computer program that, when run on an electronic device, causes the electronic device to perform the access control method as described in any one of claims 1 to 15.

Images