Method for managing permissions of application program and electronic device

Abstract

The application provides an application permission management method and an electronic device, which can reduce the time for restarting the application and improve user experience.

Description

[0001] This application is a divisional application. The original application has the application number 202110064432.9 and the original application date is January 18, 2021. The entire contents of the original application are incorporated herein by reference. Technical Field

[0002] This application relates to computer technology, and more particularly to a method for managing application permissions and an electronic device. Background Technology

[0003] With the development of computer technology, more and more applications (APPs) are being developed and installed on electronic devices such as smartphones or tablets to improve the functionality and personalization of electronic devices and provide users with a richer user experience.

[0004] When an application needs to access certain data or resources on an electronic device, it can request permission from the device's system to access that data or resources. After the system or user grants this permission, the application can access that data or resources. Permissions requested by an application from the electronic device's system can include various access permissions, such as permission to read contacts, permission to read SMS messages, and permission to access the camera. To protect the security of the electronic device's system and user data, the electronic device's system can revoke granted permissions under certain circumstances. For example, when the electronic device's system receives an operation from a user to disable an application's camera access permission, in response to this operation, the electronic device's system revokes the application's camera access permission. Afterward, the application will be unable to access the electronic device's camera or obtain data obtained through the camera.

[0005] When an electronic device's system revokes permissions granted to an application, it needs to close (or kill) the application's process to reclaim those permissions. However, revoking permissions by closing the process results in no background processes running for that application. When the user reopens the application, the system reassigns a process to it—a cold start. A cold start causes the system to reload the application's startup process, and the electronic device displays the application's main interface. In other words, revoking permissions granted to an application will cause the application, even if the user didn't actively close it, to close, impacting the user experience. Summary of the Invention

[0006] This application provides a method for managing application permissions and an electronic device to reduce the time required to restart applications and improve the user experience.

[0007] In a first aspect, embodiments of this application provide a method for managing the permissions of an application. This method may include: obtaining a permission request instruction from the application, the permission request instruction being used to request permissions to be granted to the application; granting the requested permissions to the application in response to the permission request instruction; and revoking the permission of the application when an event is detected that triggers the permission revocation mechanism of the application, and reverting the application's state to the state of the application before the permission was requested or invoked.

[0008] This implementation can revert the application's state to the state it was in when the permission was requested or before the permission was invoked when revoking the application's permissions. This keeps the application running in the state it was in before the permission was requested or invoked, preventing the application process from being closed due to permission revocation. This reduces the application's restart time and improves the user experience.

[0009] In one possible design, the application's state includes one or more of the following: the application's interface state, background service state, storage state, or message receiving state.

[0010] This storage state can be the state of data in memory.

[0011] This implementation reverts one or more of the application's interface state, background service state, storage state, or message receiving state to the state the application was in when it requested or invoked permissions. This keeps the application in the running state it was in when it requested or invoked permissions, preventing the application process from being shut down due to permission revocation and thus reducing the application's restart time.

[0012] In one possible design, the event that triggers the permission revocation mechanism of the application includes the application switching from the foreground to the background, and the permissions of the application include one-time granted permissions; or, the event that triggers the permission revocation mechanism of the application includes the application switching from the foreground to the background and remaining in the background for a preset duration, and the permissions of the application include one-time granted permissions.

[0013] This implementation method, when the application's permissions are revoked due to the application switching from the foreground to the background, rolls back the application's state so that when the application switches from the background to the foreground, it is in the running state before the permission request or permission call, thus preventing the application process from being closed due to permission revocation and reducing the application's restart time.

[0014] In one possible design, the event that triggers the permission revocation mechanism for the application includes the application being in the background, the settings application being in the foreground, and the user being detected performing an operation to revoke the permission for the application in the settings application.

[0015] This implementation method, when the application's permissions are revoked due to the user's operation of canceling the application's permission in response to the settings application, rolls back the application's state so that when the application switches from the background to the foreground, it is in the running state before the permission request or permission call, thus preventing the application process from being closed due to permission revocation and reducing the application's restart time.

[0016] In one possible design, the event that triggers the permission revocation mechanism of the application includes the screen of the electronic device on which the application resides changing from on to off; or, the event that triggers the permission revocation mechanism of the application includes the screen of the electronic device on which the application resides becoming locked.

[0017] This implementation method, when the screen of an electronic device changes from on to off or locked, causing the application's permissions to be revoked, rolls back the application's state so that when the screen is turned on or unlocked again, the application is in the running state before the permission request or permission call, preventing the application process from being closed due to permission revocation and reducing the application's restart time.

[0018] In one possible design, the method may further include: recording the permission-process associated call stack information of the application, which represents the state of the application on the process node when the permission is requested or on any process node before the permission is invoked.

[0019] In one possible design, the permission-process associated call stack information includes the call stack information of the application when requesting the permission and permission type identification information. The call stack information when requesting the permission is used to indicate the state of the application on the process node where the permission is requested, and the permission type identification information is used to identify the permission. Alternatively, the permission-process associated call stack information includes the call stack information of the application on any one or more process nodes between requesting the permission and calling the permission, and permission type identification information. The call stack information of any one or more process nodes between requesting the permission and calling the permission is used to indicate the state of the application on any one or more process nodes between requesting the permission and calling the permission, and the permission type identification information is used to identify the permission.

[0020] In one possible design, the permission-process associated call stack information also includes application identification information, which is used to identify the application.

[0021] In one possible design, the method may further include: based on the permission type identifier information of the permission, obtaining the application state of the application when requesting the permission or before calling the permission in the permission-process associated call stack information.

[0022] In one possible design, granting the requested permissions to the application in response to the permission request instruction may include: displaying a pop-up window in response to the permission request instruction; detecting a first action performed by the user on the pop-up window, the first action indicating that the requested permissions should be granted to the application; and granting the requested permissions to the application in response to the first action.

[0023] In one possible design, granting the application the requested permissions may include granting the application the requested permissions only once.

[0024] This implementation can revert the application's state to the state it was in when the permission was requested or before it was invoked when revoking one-time permissions. This prevents the application process from being shut down due to permission revocation, thereby reducing the application's restart time and improving the user experience.

[0025] In one possible design, the permission could include normal permissions, signature permissions, or dangerous permissions.

[0026] In one possible design, the permission could include location permission, microphone permission, camera permission, or sensor permission.

[0027] Secondly, embodiments of this application provide an application permission management device, which has the function of implementing the first aspect or any possible design of the first aspect. The function can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above-described function, such as an acquisition unit or module, or a permission management unit or module.

[0028] Thirdly, embodiments of this application provide an electronic device that may include: one or more processors; one or more memories; wherein the one or more memories are used to store one or more programs; and the one or more processors are used to run the one or more programs to implement the method as described in the first aspect or any possible design of the first aspect.

[0029] Fourthly, embodiments of this application provide a computer-readable storage medium, characterized in that it includes a computer program, which, when executed on a computer, causes the computer to perform the method as described in the first aspect or any possible design of the first aspect.

[0030] Fifthly, embodiments of this application provide a chip, characterized in that it includes a processor and a memory, the memory being used to store a computer program, and the processor being used to call and run the computer program stored in the memory to perform the method as described in the first aspect or any possible design of the first aspect.

[0031] Sixthly, embodiments of this application provide a computer program product that, when run on a computer, causes the computer to perform the method described in the first aspect or any possible design of the first aspect.

[0032] The application permission management method and electronic device in this application embodiment record the application's permission-process associated call stack information. This permission-process associated call stack information may include call stack information and permission type identification information of the application when requesting permission or before requesting permission. The call stack information is used to indicate the state of the application on the process node where the permission request is located, or to indicate the state of the application on any one or more process nodes between the permission request and the permission request. Then, when the system revokes the application's permissions, the system can, based on this permission-process associated call stack information, roll back the application's process to the process node where the application was located when the permission was requested, thereby keeping the application in the running state at the time of permission request. This prevents the application process from being closed due to permission revocation, thus reducing the application's restart time and improving the user experience. Alternatively, by granting the application's requested one-time permissions to the application's process, and if the user does not actively close the application, the system will not actively close the application's process when switching between foreground and background. This avoids the application's process being closed due to the one-time permission revocation even if the user did not actively close the application, thereby reducing the application's restart time and improving the user experience. Attached Figure Description

[0033] Figure 1 This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of this application.

[0034] Figure 2 This is a schematic diagram of the software structure of an electronic device according to an embodiment of this application.

[0035] Figure 3A This is a schematic diagram illustrating one application scenario of an embodiment of this application.

[0036] Figure 3B This is a schematic diagram illustrating another application scenario of this application embodiment.

[0037] Figure 4 This is a flowchart illustrating an application permission granting method according to an embodiment of this application.

[0038] Figure 5 This is a flowchart illustrating another method for revoking permissions for an application according to an embodiment of this application.

[0039] Figure 6 This is a flowchart illustrating another application permission management method according to an embodiment of this application.

[0040] Figure 7 Examples of embodiments of this application Figure 3A A schematic diagram of the interface of the electronic device involved in the scenario shown.

[0041] Figure 8 Examples of embodiments of this application Figure 3A A schematic diagram of the interface of the electronic device involved in the scenario shown.

[0042] Figure 9 Examples of embodiments of this application Figure 3B A schematic diagram of the interface of the electronic device involved in the scenario shown.

[0043] Figure 10 This is a schematic diagram of the structure of an application permission management device according to an embodiment of this application.

[0044] Figure 11 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0045] The terms "first," "second," etc., used in the embodiments of this application are for descriptive purposes only and should not be construed as indicating or implying relative importance or order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion, such as including a series of steps or units. A method, system, product, or apparatus is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to these processes, methods, products, or apparatuses.

[0046] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0047] For revoking permissions for applications on electronic devices, simply closing the application's corresponding process will cause the application's process, even if the user hasn't actively closed it, to be shut down during permission revocation. The electronic device's system will then have no background processes running for that application, requiring a cold restart when the user reopens the application. Unlike revoking permissions by closing the application's corresponding process, the application permission management method provided in this application embodiment allows the application's process to continue running even after the system revokes one or more authorized permissions for an application that the user hasn't actively closed. This reduces application restart time and improves user experience. This application embodiment also provides an application permission management method that can grant one-time permissions requested by the application's process. Even if the user hasn't actively closed the application, the system won't actively close the application's process when switching between foreground and background processes, thus avoiding the application's process being shut down due to one-time permission revocation despite the user's lack of conscious effort. This further reduces application restart time and improves user experience.

[0048] For a detailed explanation of the application startup optimization provided by the permission management method of the application through the embodiments of this application, please refer to the explanation of the following embodiments.

[0049] First, some terms used in the embodiments of this application will be explained to facilitate understanding of the authentication application method of the embodiments of this application.

[0050] Applications: These include browsers or applications (APPs) that provide various functional services. Examples include lifestyle service applications, instant messaging applications, social networking applications, and audio / video playback applications.

[0051] Application identification information: Identification information used to identify an application. For example, the application's package name. One application can correspond to one application identification information.

[0052] Application permissions are the requests an application makes to access information on an electronic device. Once an application is granted the appropriate permissions, it can perform operations corresponding to those permissions on the electronic device. The permission mechanism is a crucial component of an electronic device's system, used to protect system security and user privacy.

[0053] Taking Android as an example, permissions can include, but are not limited to: normal permissions, signature permissions, or dangerous permissions. Normal permissions refer to data resources that an application needs to access, but do not involve user privacy or harm other applications. For example, setting an alarm clock is a normal permission. The system does not prompt the user when processing normal permissions, and the user cannot revoke these permissions. Signature permissions are permissions granted to applications by the system during installation. Using signature permissions, two applications with the same signature can securely share data. Dangerous permissions directly infringe on user privacy or affect the operation of other programs. For this type of permission, the system will prompt the user with a pop-up window, and the application must obtain the user's authorization before performing the corresponding action. For example, dangerous permissions may include access to dialer permissions, camera permissions, SMS reading permissions, or contact reading permissions, etc. In this application embodiment, permission type identifiers can be used to identify different permissions. For example, 0000 is used to identify dialing permission, 0001 is used to identify camera permission, and 0010 is used to identify geolocation permission.

[0054] The electronic device in this application embodiment is a device with a system (e.g., an operating system). The electronic device includes one or more applications. The electronic device in this application embodiment can be a mobile phone, tablet computer, computer with wireless transceiver capabilities, virtual reality (VR) terminal device, augmented reality (AR) terminal device, terminal device in industrial control, terminal device for assisted driving, terminal device for self-driving, terminal device in remote medical surgery, terminal device in a smart grid, terminal device in transportation safety, terminal device in a smart city, terminal device in a smart home, smartwatch, smart bracelet, smart glasses, and other sports accessories or wearable devices, etc. For example, a terminal device in a smart home can be a smart TV, smart speaker, or other smart home appliances.

[0055] The following describes the scenarios in which the embodiments of this application can be applied. Figure 1 This diagram illustrates a possible electronic device structure to which embodiments of this application can be applied. (See also...) Figure 1 As shown, the electronic device 100 includes components such as a communication unit 101, a processor 102, a memory 103, a display unit 104, an input unit 105, an audio circuit 106, a sensor 107, a camera 108, and a positioning module 109. The following description, in conjunction with... Figure 1 The various components of the electronic device 100 will be described in detail.

[0056] The communication unit 101 is used to enable data communication between the electronic device 100 and other electronic devices. Optionally, the communication unit 101 may include a wireless fidelity (WiFi) module 1011 and / or a Bluetooth module 1012.

[0057] Both Bluetooth and WiFi are short-range wireless transmission technologies. The electronic device 100 can connect to an access point (AP) via the WiFi module 1011, thereby enabling access to the data network and communication with other electronic devices or accessories (such as remote cameras) connected to the AP. The electronic device 100 can also directly establish connections with other electronic devices or accessories via the Bluetooth module 1012.

[0058] The communication unit 101 may also include radio frequency (RF) circuitry. For example, when the electronic device 100 is a smartphone, it can establish a wireless connection with a base station through the RF circuitry to make calls or access data networks via a mobile communication system.

[0059] The electronic device 100 may also include a communication interface for physical connection with other devices. This communication interface can be connected to the communication interface of other electronic devices via a cable, enabling data transmission between the electronic device 100 and other electronic devices.

[0060] The memory 103 can be used to store software programs and data. The processor 102 executes various functional applications and data processing of the electronic device 100 by running the software programs and data stored in the memory 103. For example, the software program can be a sports and health program, an audio and video playback program, etc.

[0061] The memory 103 may primarily include a program storage area and a data storage area. The program storage area may store the system, various applications, etc.; the data storage area may store user input or data created by the electronic device 100 during software program execution. Furthermore, the memory 103 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, or other volatile solid-state storage device. For example, in this embodiment, fitness and health programs, audio and video playback programs, etc., may be stored in the program storage area.

[0062] The input unit 105 can be used to receive character information and signals input by the user. Optionally, the input unit 105 may include a touch panel 1051 and other input devices (such as function keys). The touch panel 1051, also known as a touchscreen, can collect touch operations performed by the user on or near it, generate corresponding touch information, and send it to the processor 102 so that the processor 102 can execute the instructions corresponding to the touch information. The touch panel 1051 can be implemented using various types such as resistive, capacitive, infrared, and surface acoustic wave. For example, in this embodiment, the user can control the electronic device's application through the touch panel 1051 of the electronic device 100.

[0063] The display unit 104 is used to present the user interface and realize human-computer interaction. For example, the display unit 104 can display information input by the user or information provided to the user, as well as various menus, interfaces of various apps, browsers, etc. of the electronic device 100.

[0064] The display unit 104 may include a display panel 1041, which may be configured in the form of a liquid crystal display (LCD), an organic light-emitting diode (OLED), or the like.

[0065] It should be noted that the touch panel 1051 can cover the display panel 1041, although in Figure 1 In the present invention, the touch panel 1051 and the display panel 1041 are two separate components to realize the input and output functions of the electronic device 100. However, in the embodiments of this application, the touch panel 1051 and the display panel 1041 can be integrated (i.e., a touch screen) to realize the input and output functions of the electronic device 100.

[0066] The processor 102 is the control center of the electronic device 100. It connects various components through various interfaces and lines. By running or executing software programs and / or modules stored in the memory 103, and calling data stored in the memory 103, it performs various functions of the electronic device 100 and processes data, thereby realizing various services based on the electronic terminal device 100.

[0067] Optionally, the processor 102 may include one or more processing units. The processor 102 may integrate an application processor and a modem processor, wherein the application processor primarily handles system, user interface, and application programs, while the modem processor primarily handles wireless communication. It is understood that the modem processor may also not be integrated into the processor 102.

[0068] The audio circuit 106 (including a speaker 1061 and a microphone 1062) provides an audio interface between the user and the electronic device 100. The audio circuit 106 converts received audio data into electrical signals and transmits them to the speaker 1061, where the speaker 1061 converts them into sound signals for output. Conversely, the microphone 1062 collects sound signals and converts them into electrical signals, which are then received by the audio circuit 106 and converted back into audio data for further processing such as transmission or storage.

[0069] The electronic device 100 may also include one or more sensors 107, such as light sensors, motion sensors, ultrasonic sensors, and other sensors. For example, the electronic device 100 can determine the user-inputted control command based on the user motion data collected by the sensor 107, and then respond to the control command.

[0070] The electronic device 100 may also include a camera 108 to capture images. Of course, the electronic device 100 may also not include a camera 108. For example, the electronic device 100 may be a smartwatch or smart bracelet without a camera.

[0071] Optionally, the electronic device 100 may also include a positioning module 109, which can measure the user's geographical location data. The positioning module 109 may be a Global Positioning System (GPS) module or a BeiDou module, etc., and this embodiment of the application is not limited thereto.

[0072] Understandable. Figure 1 The structure of the terminal device shown does not constitute a limitation on the electronic device. The electronic device provided in the embodiments of this application may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0073] Furthermore, the system mounted on the electronic device 100 can be iOS®, Android®, Microsoft®, HarmonyOS, or other systems, and this application embodiment does not impose any restrictions on this.

[0074] Taking an electronic device 100 running the Android® system as an example, such as Figure 2 As shown, the electronic device 100 can be logically divided into a hardware layer 21, a system layer 41, and an application layer 31. The hardware layer 21 includes hardware resources such as the communication unit 101, processor 102, memory 103, display unit 104, input unit 105, audio circuit 106, sensor 107, camera 108, and positioning module 109, as described above. The application layer 31 includes one or more application programs, which can be any type of application such as social networking applications, e-commerce applications, or browsers. The system layer 41, acting as software middleware between the hardware layer 21 and the application layer 31, is a computer program that manages and controls hardware and software resources.

[0075] In one embodiment, system layer 41 provides various basic public components and services for applications in application layer 31, such as window management, location management, and permission management. For example, the permission management system in system layer 41 can manage the permissions of various applications in application layer 31 through the permission management method of the application in this embodiment, as explained in the following embodiments. It should be noted that the permission management system involved in this embodiment can be a logical functional module in the system layer, such as a permission management module. This permission management module can be understood as a capability interface provided by the operating system; for example, it can be a framework layer application programming interface (API).

[0076] The functions of each component of system layer 41 described above can be implemented by processor 102 executing the program stored in memory 103.

[0077] The aforementioned electronic device can execute the application permission management method of the embodiments of this application, which can reduce the time required to restart the application.

[0078] One example, Figure 3A A schematic diagram illustrating one scenario in which embodiments of this application can be applied. See also... Figure 3AAs shown, the application scenario includes an electronic device 31, on which applications 1 and 2 are hosted. For example, application 1 is an instant messaging application, and application 2 is a video application. The electronic device 31 also hosts a system 3, which can be any of the aforementioned systems, such as Android. The system 3 can manage the permissions of applications 1 and 2 using the application permission management method of this embodiment. For example, taking the system 3's management of application 1's permissions, application 1 is in the foreground of the system 3, and the user can use the related functional services provided by application 1, such as chat communication services. The system 3 grants application 1 the permission to access the camera in a single operation, meaning the system 3 allows application 1 to use the camera or access data obtained by the camera in one operation. The foreground of the system 3 is switched from application 1 to application 2; in other words, application 1 is in the background of the system 3. Since the camera access permission of application 1 is granted only once, the system 3 will revoke the camera access permission of application 1 when a preset condition is met. This preset condition could be that the duration of application 1 in the background exceeds a preset threshold, etc. In this embodiment, system 3 can revoke application 1's camera access permission using the application permission management method provided in the following embodiments. This allows the application process to be preserved while revoking the permission, thereby reducing the application's restart time. For example, it reduces the time it takes for system 3 to switch from application 2 to application 1 in the foreground, improving the efficiency of user access to applications 1 and 2.

[0079] Figure 3B A schematic diagram illustrating another scenario in which embodiments of this application can be applied. See also... Figure 3BAs shown, the application scenario includes an electronic device 31, which has an application 1 and a settings application 4. For example, application 1 is an instant messaging application. The electronic device 31 also has a system 3, which can be any of the aforementioned systems, such as Android. System 3 can manage the permissions of application 1 using the application permission management method of this embodiment. In one example, application 1 is in the foreground of system 3, and the user can use the related functional services provided by application 1, such as chat communication services. System 3 permanently grants application 1 the permission to access the camera, meaning system 3 always allows application 1 to use the camera or access the data acquired by the camera. The foreground of system 3 is switched from application 1 to settings application 4; in other words, application 1 is in the background of system 3, and settings application 4 is in the foreground. When the user performs an operation to cancel the camera access permission of application 1 on settings application 4, system 3, based on the user's operation, revoks the camera access permission of application 1. In this embodiment, system 3 can revoke the camera access permission of application 1 using the application permission management method provided in the following embodiments, so as to retain the application's process while revoking the permission, thereby reducing the application's restart time. For example, reducing the time it takes for the foreground of System 3 to switch from Settings app 4 to application 1 improves the efficiency of users accessing application 1.

[0080] It should be noted that System 3 in this document specifically refers to the permission management module used to execute the permission management method of the embodiments of this application. Taking the Android system as an example, this permission management module can be a framework layer API interface.

[0081] The following specific embodiments illustrate the application permission management method of this application.

[0082] Method 1: This application provides a permission management method for an application, which may include a permission granting method and a permission revokeing method. The permission granting method and permission revokeing method can be applied to the above-described... Figure 3A or Figure 3B The application scenarios shown are as follows. In other words, the permission granting and permission revokeing methods are applicable to permissions granted only once or permissions granted permanently.

[0083] Permission granting methods Figure 4 This is a flowchart of an application permission granting method according to an embodiment of this application, such as... Figure 4 As shown, this embodiment uses the example of granting a permission to application 1 by system 3 of electronic device 31 as an illustration. The method of this embodiment may include: Step 401: Application 1 sends a permission request instruction to System 3. This permission request instruction is used to request the grant of a permission.

[0084] This permission can be any of the above-mentioned permissions, such as dialing permission, camera permission, microphone permission, sensor permission (e.g., pedometer) permission, location permission, etc.

[0085] When application 1 is first launched after installation, application 1 requests permissions from system 3. Alternatively, during a previous launch of application 1, a permission was granted on the first launch, and application 1 requests permissions from system 3 upon this launch. Or, when application 1 detects the user's first action during its operation, application 1 requests permissions from system 3.

[0086] This permission request instruction may carry application identification information for application 1 and permission type identification information. The application identification information can be used to distinguish different applications; for a detailed explanation, please refer to the explanations of the aforementioned terms. The permission type identification information can be used to distinguish different permissions; for a detailed explanation, please refer to the explanations of the aforementioned terms.

[0087] The first operation could be an operation to activate a portion of the functionality of application 1, which requires permission granted by system 3. For example, if application 1 is an instant messaging application, the first operation could be a user's action on the camera button of application 1, which activates the camera function of application 1, and this camera function requires system 3 to grant application 1 permission to access the camera.

[0088] It should be noted that in step 401, system 3 can also record the permission-process associated call stack information of application 1. One possible implementation is that the permission-process associated call stack information can include the call stack information and permission type identifier information of application 1 when requesting permissions. Here, the call stack information of application 1 when requesting permissions refers to the call stack information of application 1 when requesting the permission corresponding to the aforementioned permission request instruction. This call stack information is used to represent the state of the application on the process node where the permission request is located, such as the interface state, background service state, storage state, message receiving state, etc. The storage state can be the state of data in memory. Another possible implementation is that the permission-process associated call stack information can include the call stack information and permission type identifier information of any one or more process nodes of application 1 between the permission request and the permission call. The process node where the permission request is located can be the process node when system 3 receives the aforementioned permission request instruction, and the process node where the permission call is located can be the process node when application 1 calls the permission corresponding to the aforementioned permission type identifier information. For example, taking the Android system as an example, the call stack information can include the state information of various components. Each component can include one or more of the following: Activity, Service, BroadcastReceiver, or ContentProvider.

[0089] Optionally, in some embodiments, the permission-process associated call stack information may also include a permission request flag. This permission request flag is used to identify whether application 1 is requesting the permission corresponding to the permission type identifier information on the corresponding process node.

[0090] For example, when application 1 is launched for the first time after installation, application 1 calls a permission request instruction to system 3. System 3 can record the permission-process associated call stack information of application 1 as follows: process node 3: permission type identifier is used to indicate geographical location request, activity status information is used to indicate that the window displays the main interface, and the activity status information corresponds to the permission request flag bit.

[0091] This is understandable; the permission-process associated call stack information can also include the call stack information of application 1 on other process nodes. This call stack information from other process nodes is used for process rollback of application 1. This call stack information from other process nodes is used to represent the state of the application on one or more process nodes, such as the interface state, background service state, message receiving state, etc.

[0092] For example, when the user's first action is detected during the operation of application 1, application 1 requests a permission from system 3. System 3 can record the permission-process associated call stack information of application 1 as follows: Process node 3: Permission type identifier indicates a geolocation request; Activity status information indicates that the window displays the functional interface after the jump (the first action triggered the interface switch); the Activity status information corresponds to the permission request flag. Before recording the call stack information of process node 3, system 3 can also record the call stack information of process node 1 and process node 2. For example, process node 1: Activity status information indicates that the window displays the main interface (the user triggered application 1 to start); Process node 2: Service status information indicates that service A has started.

[0093] In some embodiments, the permission-process associated call stack information corresponding to the above example can be in the form shown in Table 1 below.

[0094] Table 1. Illustration of Permission-Process Associated Call Stack Information

[0095] Step 402: System 3 displays a pop-up window. System 3 detects the second operation performed by the user on the pop-up window, which is used to instruct the granting of the permissions requested by application 1.

[0096] This pop-up window prompts the user whether to allow application 1 to access or use the information corresponding to the aforementioned permissions. For example, if the permission is to access geolocation, the pop-up window prompts the user whether to allow application 1 to use geolocation information. The pop-up window can also display multiple selection buttons, for example, three buttons: one for "Allow only this time," one for "Allow always," and one for "Deny." When the user clicks the "Allow only this time" or "Allow always" selection button, system 3 detects the user's second action on the pop-up window. When the user clicks the "Deny" selection button, system 3 detects the user's third action on the pop-up window. This third action indicates that the requested permission by application 1 is denied.

[0097] In step 403, system 3 responds to the second operation by granting the permissions requested by application 1.

[0098] In response to the second operation, system 3 grants the application 1 the requested permissions. After that, application 1 can perform operations on electronic device 31 corresponding to the permissions. For example, application 1 can use the geographic location information of electronic device 31.

[0099] In response to the third operation, system 3 refuses to grant the permission requested by application 1. Subsequently, application 1 is unable to perform the operation corresponding to the permission. For example, application 1 is unable to use the geographic location information of electronic device 31.

[0100] In this embodiment, when application 1 invokes a permission request command to system 3, system 3 records the permission-process associated call stack information of application 1. This permission-process associated call stack information may include the call stack information and permission type identification information of application 1 at the time of permission request. This call stack information is used to indicate the state of the application on the process node where the permission request is located. Alternatively, the permission-process associated call stack information may include the call stack information and permission type identification information of application 1 on any one or more process nodes between the permission request and the permission call. This call stack information is used to indicate the state of the application on any one or more process nodes between the permission request and the permission call. Subsequently, when system 3 revokes the permissions of application 1, system 3 can, based on this permission-process associated call stack information, roll back the process of application 1 to the process node where application 1 was located at the time of permission request or before the permission call. This keeps the application in the running state at the time of permission request or before the permission call, preventing the process of application 1 from being closed due to permission revocation. This reduces the application restart time and improves the user experience.

[0101] Permission revocation method Figure 5 This is a flowchart of a method for revoking permissions for an application according to an embodiment of this application, as shown below. Figure 5 As shown, this embodiment uses the example of system 3 of electronic device 31 revoking the permissions of application 1. The method of this embodiment may include: Step 501: When system 3 detects an event that triggers the permission revocation mechanism of application 1, system 3 determines the process rollback position based on the permission-process associated call stack information.

[0102] For a detailed explanation of the permission-process associated call stack information, please refer to the detailed explanation of step 401.

[0103] One possible implementation is that the event triggering the permission revocation mechanism of application 1 could be that application 1 switches from the foreground to the background, and the permissions granted to application 1 include one-time granted permissions. Alternatively, the event triggering the permission revocation mechanism of application 1 could be that application 1 switches from the foreground to the background and remains in the background for a preset duration (e.g., 60 seconds), and the permissions granted to application 1 include one-time granted permissions. When system 3 detects this event, system 3 determines the process rollback position based on the permission-process associated call stack information.

[0104] Another possible approach is that the event that triggers the permission revocation mechanism of application 1 can be the electronic device 31 changing from a screen on to a screen off, or becoming a locked screen. When system 3 detects this event, system 3 determines the process rollback position based on the permission-process associated call stack information.

[0105] For example, the permissions granted to application 1 include a one-time authorization permission. When system 3 detects any of the two possible implementation methods mentioned above, system 3 searches for the process node of the one-time authorization permission in the permission-process associated call stack information according to the permission type identification information of the one-time authorization permission, at the time of permission request or before permission call, and uses the location of the process node as the process rollback position.

[0106] For example, the permissions granted to application 1 include multiple one-time authorized permissions. When system 3 detects any of the two possible implementation methods mentioned above, system 3 searches for the process node of each one-time authorized permission in the permission-process associated call stack information according to the permission type identification information of each one-time authorized permission. The system 3 selects the location of the process node that first applied for the permission as the process rollback position.

[0107] Another possible approach is to trigger the permission revocation mechanism of application 1 by having application 1 in the background of system 3, settings application 4 in the foreground, and detecting that a user has performed an operation to revoke one or more permissions of application 1 on settings application 4. When system 3 detects this event, it determines the process rollback position based on the permission-process association call stack information.

[0108] When the system detects that a user has performed an operation to revoke a permission of application 1 in the settings application 4, the system 3 searches for the process node of the permission in the permission-process association call stack information based on the permission type identification information of the permission, and uses the location of the process node as the process rollback position.

[0109] When the system detects that the user has performed multiple permissions to the settings application 4, the system 3 searches for the process node of each permission in the permission-process association call stack information based on the permission type identification information of each permission. The system then selects the location of the process node that first requested the permission as the process rollback position.

[0110] Step 502: System 3 revoks the permissions of application 1.

[0111] System 3 can clean up the handle operations corresponding to the permissions of application 1. Taking the permission to access the camera as an example, System 3 can terminate the service or interface of application 1 that obtains camera data.

[0112] Step 503: System 3 rolls back the process state of application 1 to the state of the application corresponding to the process rollback position.

[0113] It should be noted that the execution order of steps 502 and 503 is not limited by the sequence number. In other words, step 503 can be executed first and then step 502, or steps 502 and 503 can be executed in parallel.

[0114] Since the permission-process associated call stack information includes the call stack information of application 1 when requesting permission or before requesting permission, permission type identification information, and permission request flag, and this call stack information is used to represent the state of the application on the process node where the permission request is located, system 3 can obtain the state of the application on the process node where the permission request is located based on the process rollback position, and roll back the process state of application 1 to the state of the application before the permission request or permission use, so that when application 1 switches from the background to the foreground, application 1 is in the state of the application before the permission request or permission use.

[0115] In this embodiment, when system 3 detects an event that triggers the permission revocation mechanism of application 1, system 3 determines the process rollback position based on the permission-process associated call stack information. System 3 then revokes the permissions of application 1 and rolls back the process state of application 1 to the state corresponding to the rollback position. This ensures that the application is in the running state before permission was requested or invoked, preventing application 1's process from being closed due to permission revocation. This reduces application restart time and improves user experience. Timely revocation of application permissions protects user privacy and data security.

[0116] Method Two: This application embodiment also provides another method for managing application permissions. Unlike Method One described above, the permission management method of this implementation can be applied to the above... Figure 3A The application scenario shown is as follows. In other words, the permission management method in Method 2 is suitable for permissions that are granted only once.

[0117] Figure 6 This is a flowchart of another application permission management method according to an embodiment of this application, such as... Figure 6 As shown, this embodiment uses a permission of the system 3 management application 1 of the electronic device 31 as an example for illustration. The method of this embodiment may include: Step 601: Application 1 sends a permission request instruction to System 3. This permission request instruction is used to request the grant of a permission.

[0118] This permission can be any of the above-mentioned permissions, such as dialing permission, camera permission, etc.

[0119] When application 1 is first launched after installation, application 1 requests permissions from system 3. Alternatively, during a previous launch of application 1, a permission was granted on the first launch, and application 1 requests permissions from system 3 upon this launch. Or, when application 1 detects the user's first action during its operation, application 1 requests permissions from system 3.

[0120] This permission request instruction may carry application identification information for application 1 and permission type identification information. The application identification information can be used to distinguish different applications; for a detailed explanation, please refer to the explanations of the aforementioned terms. The permission type identification information can be used to distinguish different permissions; for a detailed explanation, please refer to the explanations of the aforementioned terms.

[0121] The first operation could be an operation to activate a portion of the functionality of application 1, which requires permission granted by system 3. For example, if application 1 is an instant messaging application, the first operation could be a user's action on the camera button of application 1, which activates the camera function of application 1, and this camera function requires system 3 to grant application 1 permission to access the camera.

[0122] Step 602: System 3 displays a pop-up window. System 3 detects the user's fourth action on the pop-up window, which is used to instruct the user to grant the permissions requested by application 1 in one go.

[0123] This pop-up window prompts the user whether to allow application 1 to access or use the information corresponding to the aforementioned permissions. For example, if the permission is to access geolocation, the pop-up window prompts the user whether to allow application 1 to use geolocation information. The pop-up window can also display multiple selection buttons, for example, three buttons: one for "Allow only this time," one for "Allow all the time," and one for "Deny." When the user clicks the "Allow only this time" button, system 3 detects the user's fourth action on the pop-up window.

[0124] In step 603, in response to the fourth operation, system 3 grants the permissions requested by application 1 to the process of application 1.

[0125] System 3, in response to this fourth operation, grants the process of application 1 the permissions requested by application 1. In other words, the permissions requested by application 1 remain valid throughout the execution of the process. Application 1 can perform operations corresponding to the permissions on electronic device 31; for example, application 1 can use the geographical location information of electronic device 31.

[0126] For example, System 3 grants Permission 1 to the process of Application 1. When Application 1 is switched from the foreground to the background, or from the background to the foreground (i.e., the user does not actively close Application 1), the system will not actively close the process of Application 1 when switching between foreground and background. As long as the process of Application 1 is not closed, Permission 1 remains in effect.

[0127] In this embodiment, when application 1 requests permissions from system 3, system 3 displays a pop-up window. System 3 detects a fourth operation performed by the user on the pop-up window. This fourth operation instructs the system 3 to grant the requested permissions to application 1 in a one-time manner. In response to this fourth operation, system 3 grants the requested permissions to the process of application 1. Even if the user does not actively close application 1, the system will not actively close application 1's process when switching between foreground and background. Since application 1's process remains open, permission 1 remains valid. This avoids the situation where application 1's process is closed due to a one-time permission revocation, even if the user does not actively close application 1, thereby reducing application restart time and improving the user experience.

[0128] The following examples of specific application scenarios will be used to explain the permission management method of the application in this embodiment.

[0129] Figure 7 Examples of embodiments of this application Figure 3A The diagram illustrates the interface of the electronic device involved in the scenario. Application 1 in this embodiment is a camera application. This is intended as an example and not a limitation. Figure 7 As shown, the screen display system of the electronic device displays one possible interface content, which is the main interface 701 of the electronic device's application 1. This main interface 701 may display a function button, such as a camera button. It should be understood that the main interface 701 may also include other function buttons or graphical controls, and this embodiment of the application does not limit this.

[0130] User execution Figure 7As shown in Figure (a), clicking the camera button triggers a switch in the electronic device's interface to the camera function interface 702. The first operation in the above embodiment can be this click operation. This click operation is used to activate the camera function of application 1, which requires system 3 of the electronic device to grant application 1 permission to access the camera. Application 1 can request permission from system 3 via step 401, which requests permission to access the camera. System 3 can display a pop-up window via step 402. This pop-up window can be as follows: Figure 7 The pop-up window shown in Figure (b) prompts the user whether to allow application 1 to take a photo. The pop-up window can also display three selection buttons: one for "Allow only this time," one for "Allow all times," and one for "Deny."

[0131] User execution Figure 7 As shown in Figure (b), clicking the "Only Allowed Selection" button triggers a camera access permission granted to application 1 via step 403, and the electronic device's interface enters the camera function interface 703. The camera function interface 703 includes a preview area 7031 and a photo capture button 7032. It should be understood that the camera function interface 703 may also include other display content, which is not limited in this embodiment. Afterwards, the user switches application 1 from the foreground to the background, displaying the function interface 704 of application 2 in the foreground. The electronic device's system 3 can... Figure 5 The illustrated embodiment rolls back the process state of application 1 to the state of the application corresponding to the process rollback position, that is, rolls back to... Figure 7 The state is shown in Figure (b). Afterwards, the user operates the electronic device to switch application 1 from the background to the foreground, displaying the camera function interface 705 of application 1 in the foreground. This camera function interface 705 is identical to the camera function interface 702. Figure 4 and Figure 5 The permission management method of the illustrated embodiment can prevent the process of application 1 from being closed due to permission revocation, thereby reducing the time for application 1 to restart and improving the user experience. By promptly revoking the permissions of application 1, user privacy and data security can be protected.

[0132] Figure 8 Examples of embodiments of this application Figure 3A The diagram illustrates the interface of the electronic device involved in the scenario. Application 1 in this embodiment is a camera application. This is intended as an example and not a limitation. Figure 8As shown, the screen display system of the electronic device displays one possible interface content, which is the main interface 801 of the electronic device's application 1. This main interface 801 may display a function button, such as a camera button. It should be understood that the main interface 801 may also include other function buttons or graphical controls, and this embodiment of the application does not limit this.

[0133] User execution Figure 8 As shown in Figure (a), clicking the camera button triggers a switch in the electronic device's interface to the camera function interface 802. The first operation in the above embodiment can be this click operation. This click operation is used to activate the camera function of application 1, which requires system 3 of the electronic device to grant application 1 permission to access the camera. Application 1 can request permission from system 3 via step 601, which requests permission to access the camera. System 3 can display a pop-up window via step 602. This pop-up window can be as follows: Figure 8 The pop-up window shown in Figure (b) prompts the user whether to allow application 1 to take a photo. The pop-up window can also display three selection buttons: one for "Allow only this time," one for "Allow all times," and one for "Deny."

[0134] User execution Figure 8 As shown in Figure (b), clicking the "Only Allowed Selection" button triggers a camera access permission granted to the application 1 process via step 603, and the electronic device's interface enters the camera function interface 803. The camera function interface 803 includes a preview area 8031 ​​and a photo capture button 8032. It should be understood that the camera function interface 803 may also include more or less display content, which is not limited in this embodiment. Afterwards, the user switches the application 1 from the foreground to the background, displaying the application 2 function interface 804 in the foreground. Since the user does not actively close application 1, the system will not actively close the application 1 process during the foreground / background switch. As long as the application 1 process is not closed, the camera access permission remains valid. Afterwards, the user switches the application 1 from the background to the foreground, displaying the application 1 camera function interface 805 in the foreground, which is identical to the camera function interface 803. Figure 6 The permission management method of the illustrated embodiment can prevent the process of application 1 from being closed due to the one-time revocation of permissions of application 1 even if the user does not actively close application 1, thereby reducing the time for application to restart and improving the user experience.

[0135] Figure 9 Examples of embodiments of this application Figure 3B The diagram illustrates the interface of the electronic device involved in the scenario. Application 1 in this embodiment is a camera application. This is intended as an example and not a limitation. Figure 9 As shown, the screen display system of the electronic device displays one possible interface content, which is the main interface 901 of the electronic device's application 1. This main interface 901 may display a function button, such as a camera button. It should be understood that the main interface 901 may also include other function buttons or graphical controls, and this embodiment of the application does not limit this.

[0136] User execution Figure 9 As shown in Figure (a), clicking the camera button triggers a switch in the electronic device's interface to the camera function interface 902. The first operation in the above embodiment can be this click operation. This click operation is used to activate the camera function of application 1, which requires system 3 of the electronic device to grant application 1 permission to access the camera. Application 1 can request permission from system 3 via step 401, which requests permission to access the camera. System 3 can display a pop-up window via step 402. This pop-up window can be as follows: Figure 9 The pop-up window shown in Figure (b) prompts the user whether to allow application 1 to take a photo. The pop-up window can also display three selection buttons: one for "Allow only this time," one for "Allow all times," and one for "Deny."

[0137] User execution Figure 9 As shown in Figure (b), clicking the "Always Allow" selection button triggers a click. In response to this click, system 3 grants application 1 camera access permission through step 403 described above, and the electronic device's interface enters the camera function interface 903. The camera function interface 903 includes a preview area 9031 and a photo capture button 9032. It should be understood that the camera function interface 903 may also include other, more or less display content; this embodiment does not limit this. Subsequently, the user operates the electronic device to switch application 1 from the foreground to the background, displaying the permission settings interface 904 for application 4 in the foreground. The permission settings interface 904 includes an "Allow" button 9041 and a "Deny" button 9042 for application 1 to access the camera.

[0138] User execution Figure 9 In Figure (d), the click operation on the disable button 9042, in response to this click operation, system 3 reverts the process state of application 1 to the state of the application corresponding to the process reversion position through steps 501 to 503 described above. That is, it reverts to... Figure 9The state is shown in Figure (b). Afterwards, the user operates the electronic device to switch application 1 from the background to the foreground, displaying the camera function interface 905 of application 1 in the foreground. This camera function interface 905 is identical to the camera function interface 902. Figure 4 and Figure 5 The permission management method of the illustrated embodiment can prevent the process of application 1 from being closed due to permission revocation, thereby reducing the time for application 1 to restart and improving the user experience. By promptly revoking the permissions of application 1, user privacy and data security can be protected.

[0139] Figure 10 This is a schematic diagram illustrating the result of an application permission management device according to an embodiment of this application. Figure 10 As shown, the device can be applied to electronic devices (such as the electronic device 31 described above), and the device may include: an acquisition module 111 and a permission management module 112.

[0140] The acquisition module 111 is used to acquire the permission request instruction from the application, which is used to request permissions to be granted to the application. The permission management module 112 is used to grant the requested permissions to the application in response to the permission request instruction. The permission management module 112 is also used to revoke the permission of the application when an event that triggers the permission revocation mechanism of the application is detected, and the state of the application is rolled back to the state of the application when it requested the permission or before it invoked the permission.

[0141] In some embodiments, the state of the application includes one or more of the following: the application's interface state, background service state, storage state, or message receiving state.

[0142] In some embodiments, the event that triggers the permission revocation mechanism of the application includes the application switching from the foreground to the background, and the permissions of the application include one-time granted permissions; or, the event that triggers the permission revocation mechanism of the application includes the application switching from the foreground to the background and remaining in the background for a preset duration, and the permissions of the application include one-time granted permissions.

[0143] In some embodiments, the event that triggers the permission revocation mechanism for the application includes the application being in the background, the settings application being in the foreground, and the user being detected performing an operation to revoke the permission for the application on the settings application.

[0144] In some embodiments, the event that triggers the permission revocation mechanism for the application includes the screen of the electronic device on which the application resides changing from on to off; or, the event that triggers the permission revocation mechanism for the application includes the screen of the electronic device on which the application resides becoming locked.

[0145] In some embodiments, the permission management module 112 is further configured to: record permission-process associated call stack information of the application, the permission-process associated call stack information representing the state of the application on the process node when the application requests the permission or on any process node before the permission is invoked.

[0146] In some embodiments, the permission-process associated call stack information includes call stack information of the application when requesting the permission and permission type identification information. The call stack information when requesting the permission is used to indicate the state of the application on the process node where the permission is requested, and the permission type identification information is used to identify the permission. Alternatively, the permission-process associated call stack information includes call stack information of the application on any one or more process nodes between requesting the permission and calling the permission, and permission type identification information. The call stack information of any one or more process nodes between requesting the permission and calling the permission is used to indicate the state of the application on any one or more process nodes between requesting the permission and calling the permission, and the permission type identification information is used to identify the permission.

[0147] In some embodiments, the permission-process associated call stack information also includes application identification information, which is used to identify the application.

[0148] In some embodiments, the permission management module 112 is further configured to: obtain the state of the application when it applied for the permission or before it invoked the permission in the permission-process associated call stack information, based on the permission type identification information of the permission.

[0149] In some embodiments, the permission management module 112 is configured to: display a pop-up window in response to the permission request instruction; detect a first operation performed by the user on the pop-up window, the first operation being used to instruct the application to be granted the requested permission; and grant the requested permission to the application in response to the first operation.

[0150] In some embodiments, the permission management module 112 is used to grant the permissions requested by the application in one go.

[0151] In some embodiments, the permission includes normal permission, signature permission, or dangerous permission.

[0152] In some embodiments, the permission includes location permission, microphone permission, camera permission, or sensor permission.

[0153] Other embodiments of this application also provide an electronic device for performing the methods of the electronic devices in the above method embodiments. For example... Figure 11 As shown, the electronic device may include: a display screen 1101; one or more processors 1102; and one or more memories 1103. These devices can be connected via one or more communication buses 1105. The memory 1103 stores one or more computer programs 1104, and the one or more processors 1102 execute the one or more computer programs 1104. The one or more computer programs 1104 include instructions that can be used to execute various steps performed by the electronic device in the above method embodiment. The electronic device can be any of the above-described forms of electronic device, such as a smartphone, smartwatch, etc.

[0154] certainly, Figure 11 The electronic device shown may also include other components such as an audio module, and this application embodiment does not impose any limitations on this. When it includes other components, specifically... Figure 2 The electronic device shown.

[0155] The electronic device in this application embodiment can be used to perform the above-described... Figures 4 to 6 The technical principles and effects of the steps of the electronic device in any of the method embodiments shown can be found in the explanations and descriptions of the above method embodiments, and will not be repeated here.

[0156] Other embodiments of this application also provide a computer storage medium that may include computer instructions that, when executed on an electronic device, cause the electronic device to perform the various steps performed by the electronic device in the above method embodiments.

[0157] Other embodiments of this application also provide a computer program product that, when run on a computer, causes the computer to perform the various steps performed by the electronic device in the above method embodiments.

[0158] Through the above description of the embodiments, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0159] Through the above description of the embodiments, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0160] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling or direct coupling or communication connection may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0161] The units described as separate components may or may not be physically separate. A component shown as a unit can be one or more physical units; that is, it can be located in one place or distributed in multiple different locations. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0162] The processor mentioned in the above embodiments can be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method embodiments can be completed by the integrated logic circuitry in the processor's hardware or by instructions in software form. The processor can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. A general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this application can be directly implemented by a hardware encoding processor, or by a combination of hardware and software modules in the encoding processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.

[0163] The memory mentioned in the above embodiments may be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory.

[0164] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software 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, but such implementation should not be considered beyond the scope of this application.

[0165] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0166] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0167] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0168] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0169] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0170] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for managing application permissions, characterized in that, include: In response to a click on the camera button of a first application, a first interface is displayed; wherein the first interface includes a first control, the first control being used to indicate that the first application is allowed to access the camera only this time; Upon receiving a click operation on the first control, a second interface is displayed; wherein the second interface includes a preview area for the captured content and a photo capture button; Switch the first application from the foreground to the background; Displays the functional interface of the second application; Switch the first application from the background to the foreground and display the third interface of the first application, which includes the preview area of ​​the photo content and the photo capture button.

2. The method according to claim 1, characterized in that, The first interface includes a pop-up window, which includes the first control and a control for indicating that the first application should not access the camera.

3. The method according to claim 1 or 2, characterized in that, The step of receiving a click operation on the first control and displaying the second interface includes: Upon receiving a click on the first control, grant the first application permission to access the camera for this operation, and display the second interface.

4. The method according to claim 3, characterized in that, After the first application was switched to the background, the first application process was not closed, and the first application's permission to access the camera was valid.

5. The method according to any one of claims 1 to 4, characterized in that, The method further includes: In response to a click on the camera button of a third application, a fourth interface is displayed; wherein the fourth interface includes a second control, the second control being used to always allow the third application to access the camera; Upon receiving a click operation on the second control, a fifth interface is displayed; wherein, the fifth interface includes a preview area for the photographed content and a photo capture button; Switch the third application from the foreground to the background; The permission settings interface is displayed, and the permission settings interface includes a third control, which is used to prevent the third application from accessing the camera. After receiving a click operation on the third control, the third application is switched from the background to the foreground, and a sixth interface of the third application is displayed, which is the same as the fourth interface.

6. The method according to claim 5, characterized in that, Before displaying the sixth interface of the third application, the method further includes: In response to receiving a click operation on the third control, the process state of the third application is rolled back to the state of the third application when it requested access to the camera or before it accessed the camera.

7. The method according to any one of claims 1 to 6, characterized in that, include: Obtain a permission request instruction from an application, the permission request instruction being used to request permissions to be granted to the application; In response to the permission request instruction, grant the application the requested permissions; When an event is detected that triggers the permission revocation mechanism of the application, the permission of the application is revoked, and the state of the application is rolled back to the state of the application when it requested the permission or before it invoked the permission.

8. The method according to claim 7, characterized in that, The application's state includes one or more of the following: the application's interface state, background service state, storage state, or message receiving state.

9. The method according to claim 7 or 8, characterized in that, The event used to trigger the permission revocation mechanism of the application includes the application switching from the foreground to the background, and the permissions of the application include one-time authorized permissions; or, the event used to trigger the permission revocation mechanism of the application includes the application switching from the foreground to the background and remaining in the background for a preset duration, and the permissions of the application include one-time authorized permissions.

10. The method according to claim 7 or 8, characterized in that, The event used to trigger the permission revocation mechanism of the application includes the application being in the background, the settings application being in the foreground, and the user performing the operation of revoking the permission of the application on the settings application.

11. The method according to claim 7 or 8, characterized in that, The event that triggers the permission revocation mechanism of the application includes the screen of the electronic device on which the application is located changing from on to off; or, the event that triggers the permission revocation mechanism of the application includes the screen of the electronic device on which the application is located becoming locked.

12. The method according to any one of claims 7 to 11, characterized in that, The method further includes: Record the permission-process associated call stack information of the application. The permission-process associated call stack information indicates the state of the application on the process node when the application requests the permission or on any process node before the permission is invoked.

13. The method according to claim 12, characterized in that, The permission-process associated call stack information includes the call stack information of the application when requesting the permission and permission type identification information. The call stack information when requesting the permission is used to indicate the state of the application on the process node where the permission is requested, and the permission type identification information is used to identify the permission; or... The permission-process associated call stack information includes call stack information and permission type identification information of any one or more process nodes between the application requesting the permission and the invocation of the permission. The call stack information of any one or more process nodes between the application requesting the permission and the invocation of the permission is used to indicate the state of the application of any one or more process nodes between the application requesting the permission and the invocation of the permission. The permission type identification information is used to identify the permission.

14. The method according to claim 13, characterized in that, The permission-process associated call stack information also includes application identification information, which is used to identify the application.

15. The method according to claim 13 or 14, characterized in that, The method further includes: Based on the permission type identifier information of the permission, the state of the application when requesting the permission or before calling the permission is obtained from the permission-process associated call stack information.

16. The method according to any one of claims 7 to 15, characterized in that, The step of granting the application the requested permissions in response to the permission request instruction includes: In response to the permission request instruction, a pop-up window is displayed, and a first operation by the user on the pop-up window is detected. The first operation is used to instruct the application to be granted the requested permission. In response to the first operation, the requested permissions are granted to the application.

17. The method according to claim 16, characterized in that, Granting the application the requested permissions includes granting the application the requested permissions in a single instance.

18. The method according to any one of claims 7 to 17, characterized in that, The permissions include normal permissions, signature permissions, or dangerous permissions.

19. The method according to any one of claims 7 to 17, characterized in that, The permissions include location permissions, microphone permissions, camera permissions, or sensor permissions.

20. An electronic device, characterized in that, The electronic device includes: one or more processors; one or more memories; wherein the one or more memories are used to store one or more programs; and the one or more processors are used to run the one or more programs to implement the method as described in any one of claims 1 to 19.

21. A computer-readable storage medium, characterized in that, It includes a computer program that, when executed on a computer, causes the computer to perform the method as described in any one of claims 1 to 19.

22. A chip, characterized in that, It includes a processor and a memory, the memory being used to store a computer program, and the processor being used to invoke and run the computer program stored in the memory to perform the method as described in any one of claims 1 to 19.

Images