JP7348289B2 - How to manage application permissions and electronic devices - Google Patents

Description

This application relates to the field of terminal technology, and in particular to a method of managing application permissions and electronic devices.

Currently, when an application is installed on or used on a mobile phone, the user must previously grant one or more application permissions that the application is allowed to use. For example, application permissions may include reading contact information, obtaining location information, reading calendar information, enabling recording functionality, and activating a camera.

For example, if a user, upon installation of a browser application, grants the browser application an application permission to launch the camera, the mobile phone will indicate that launching the camera is a registered permission of the browser application. You may record this. Then, if that browser application detects that it is requesting to open the phone's camera, the phone will The camera may be opened for taking pictures in response to a browser application request. On the other hand, if an application abuses the application permission after registering it, it increases the resource overhead of the mobile phone and also increases the risk of user privacy leakage.

This application provides a method and electronic device for managing application permissions to allow applications to use different application permissions in different usage scenarios. This reduces the security risk of user privacy leakage and improves the user experience.

To achieve the above objective, the following technical solutions are used in this application.

According to a first aspect, the application provides a method for managing application permissions, wherein an electronic device displays a home screen, the home screen includes an icon of a first application, and a user selects the In response to a first operation of tapping, the electronic device may display a first interface, and upon displaying the first interface, the electronic device may cause the first application to in response to a second operation of the user on the first interface, the electronic device may display a second interface; The electronic device provides a method in which the electronic device may deny the first application to use the first application permission when displaying the second interface.

In other words, when running the first application, the electronic device uses the currently displayed Based on the interface, the first application may be allowed or denied to use application permissions, thereby reducing system resource consumption and security risks of user privacy leakage, as well as user It is possible to improve your experience.

In one possible implementation, the usage scenario indicated by the first interface is a first scenario and the usage scenario indicated by the second interface is a second scenario. The electronic device allows the first application to use the first application permission when the first application permission corresponds to the first scenario. including allowing a first application to use the first application permission. The electronic device may refuse the first application to use the first application permission when the first application permission does not correspond to the second scenario. includes denying the first application to use the first application permission.

In other words, when an application requests the use of an application permission from an electronic device, the electronic device may decide whether or not to grant the application permission based on the current specific usage scenario. good. If the application permission that an application requests and uses corresponds to the current usage scenario, it indicates that it is appropriate to use the application permission in accordance with the current usage scenario. In this case, the electronic device may allow the application to continue using the application permissions to avoid affecting the user's normal use of the various functions provided by the application. .

If the application permission requested by the application does not correspond to the current usage scenario, it indicates that it is inappropriate to use the application permission according to the current usage scenario. If an application is allowed to continue using an application grant, unnecessary system resources are consumed when the application uses the application grant, and the use of the application grant increases power consumption overhead. In addition, after an application is allowed to use an application permission that does not correspond to the current usage scenario, the application may further abuse that application permission to gain user privacy and protect the user's privacy. Increases the risk of privacy leaks. Therefore, in order to reduce the security risks of system resource consumption and user privacy leakage, as well as improve the user's experience, if the application permission that the application currently requests and uses does not correspond to the current usage scenario. Alternatively, the electronic device may refuse to allow the application to use the current application permission.

In one possible implementation, when the electronic device denies the first application to use the first application permission, the method includes: further comprising displaying a first notification within the user's browser, the first notification informing the user that a request to use the first application permission is now being denied by the first application. used to teach.

For example, the first notification may include the usage scenario corresponding to the second interface.

In one possible implementation, after the electronic device displays the first notification in the second interface, the method includes: The electronic device further includes displaying a settings interface for managing application permissions when detecting that the electronic device is present. A user may manually manage application permissions through a settings interface.

In one possible implementation, when displaying the second interface, the method detects that the first application is applying for use of the first application permission. the electronic device may display a dialog box within the second interface if the first application uses the first application permissions. a first button that does not allow the user to use the first application permission; the electronic device denying the first application to use the first application permission when detecting that a button is being selected; In other words, when the electronic device detects that there is a security risk in allowing the application to use the first application permission within the second interface, the electronic device The user may be prompted to manually elect to allow or deny the application to use the first application permission at this time.

In one possible implementation, the dialog box may further include prompt information. The prompt information is used to educate the user of the security risks of allowing the first application to use the first application permission, thereby causing the first application to: After being authorized to use the first application permission, the user becomes aware of the security risks.

In one possible implementation, the dialog box may further include a second button that allows the first application to use the first application permission, and the electronic device After displaying a dialog box within an interface of the method, the method includes: if the electronic device detects that the user has selected the second button; The method further includes the electronic device providing false data to the first application when using the first application permission. In other words, the user allows the first application to use the first application permission, but the user data that the first application ultimately obtains is not genuine user data, thereby causing the first application to use the first application permission. Preventing one application from abusing the first application permission to obtain user privacy.

In one possible implementation, the electronic device denies the first application to use the first application permission, wherein a permission service in the electronic device denies the first application permissions. and transmitting a permission deny response to the first application, thereby disabling the first application from using the first application permission.

Alternatively, the electronic device denies the first application to use the first application permission, wherein the electronic device denies the first application to use the first application permission. and providing the first application with the false data when the first application uses the first application permission. Thus, in case of unexpected termination etc. where it is not possible for the first application to operate normally after the electronic device has allowed the first application to use the first application permission, It may be avoided after the first application obtains an authorization denial response. In addition, it is possible for the electronic device to prevent the user's real data from being leaked by the first application by providing fake data to the first application.

For example, when the first application uses the first application permission, after the electronic device provides the first application with the false data, the method includes: further comprising displaying a second notification in a second interface, the second notification indicating that the user data obtained when the first application now uses the first application permission is Used to tell the user that the data is fake.

In one possible implementation, when the second interface is displayed, the electronic device denies the first application to use the first application permission, but the electronic device denies the first application permissions when the second interface is displayed. may use a second application permission, where the second application permission is different from the first application permission. In other words, in scenarios corresponding to the same interface, the electronic device may allow the first application to use multiple application permissions, and the electronic device may allow the first application to use other application permissions. You may refuse to do so.

In one possible implementation, when the first application is installed, the electronic device detects that the first application requests to register the first application permission; The electronic device may determine whether the first application permission corresponds to a type of first application. The electronic device allows the first application to register the first application permission if the first application permission corresponds to a type of the first application. In other words, when an application registers an application permission in an electronic device, the electronic device blocks multiple application permissions for the user that do not correspond to the application type of the application so that the application Those multiple application permissions may then be used to avoid security issues such as privacy leaks caused by capturing the user's privacy.

For example, the first application permission may include permission to obtain location information, permission to read/modify address book, permission to read/modify calendar, permission to use camera, permission to use microphone, and permission to use Bluetooth. It may also include permission or permission to use voice recognition functionality.

According to a second aspect, the application includes a touch screen including a touch-sensitive surface and a display, one or more processors, one or more memories, and one or more computer programs. Provide electronic devices. The processor is coupled to both the memory and the touch screen. One or more computer programs are stored in memory. When the electronic device starts up, the processor executes one or more computer programs stored in memory, thereby causing the electronic device to implement any one of the plurality of implementations of the first aspect. How to manage application permissions according to

According to a third aspect, the application provides a computer storage medium containing computer instructions. The computer instructions, when executed by the electronic device, enable the electronic device to perform a method for managing application permissions according to any one of a plurality of implementations of the first aspect. .

According to a fourth aspect, the application provides a computer program product. The computer program product, when executed by the electronic device, enables the electronic device to perform the method for managing application permissions according to any one of the plurality of implementations of the first aspect.

The electronic device of the second aspect provided above, the computer storage medium of the third aspect, and the computer program product of the fourth aspect are all configured to carry out the corresponding method provided above. It is possible to understand that it is composed of Therefore, for the beneficial effects that the electronic device, computer storage medium and computer program product are capable of achieving, reference should be made to the beneficial effects in the corresponding methods provided above. Details are not repeated herein.

FIG. 1 is a schematic configuration diagram of an electronic device according to one embodiment of this application. 1 is a schematic architectural diagram of an operating system in an electronic device according to one embodiment of this application; FIG. 1 is a schematic diagram of an application scenario of a method of managing application permissions according to an embodiment of this application; FIG. 1 is a schematic diagram of an application scenario of a method of managing application permissions according to an embodiment of this application; FIG. 2 is a schematic diagram of an application scenario of a method of managing application permissions according to an embodiment of this application; FIG. 2 is a schematic diagram of an application scenario of a method of managing application permissions according to an embodiment of this application; FIG. 2 is a schematic diagram of an application scenario of a method of managing application permissions according to an embodiment of this application; FIG. 3 is a schematic diagram of an application scenario of a method of managing application permissions according to an embodiment of this application; FIG. 4 is a schematic diagram of an application scenario of a method of managing application permissions according to an embodiment of this application; FIG. 4 is a schematic diagram of an application scenario of a method of managing application permissions according to an embodiment of this application; FIG. 4 is a schematic diagram of an application scenario of a method of managing application permissions according to an embodiment of this application; FIG. 5 is a schematic diagram of an application scenario of a method of managing application permissions according to an embodiment of this application; FIG. 5 is a schematic diagram of an application scenario of a method of managing application permissions according to an embodiment of this application; FIG. 5 is a schematic diagram of an application scenario of a method of managing application permissions according to an embodiment of this application; FIG. 6 is a schematic diagram of an application scenario of a method of managing application permissions according to an embodiment of this application; FIG. 7 is a schematic diagram of an application scenario of a method of managing application permissions according to an embodiment of this application; FIG. 7 is a schematic diagram of an application scenario of a method of managing application permissions according to an embodiment of this application; FIG. 8 is a schematic diagram of an application scenario of a method of managing application permissions according to an embodiment of this application; FIG. 9 is a schematic diagram of an application scenario of a method of managing application permissions according to an embodiment of this application; FIG. 10 is a schematic diagram of an application scenario of a method of managing application permissions according to an embodiment of this application; FIG. 11 is a schematic diagram of an application scenario of a method of managing application permissions according to an embodiment of this application; FIG. 11 is a schematic diagram of an application scenario of a method of managing application permissions according to an embodiment of this application; FIG. 12 is a schematic diagram of an application scenario of a method of managing application permissions according to an embodiment of this application; FIG. 13 is a schematic diagram of an application scenario of a method of managing application permissions according to an embodiment of this application; FIG. 14 is a schematic diagram of an application scenario of a method of managing application permissions according to an embodiment of this application; FIG. 14 is a schematic diagram of an application scenario of a method of managing application permissions according to an embodiment of this application; FIG. 15 is a schematic diagram of an application scenario of a method of managing application permissions according to an embodiment of this application; FIG. 15 is a schematic diagram of an application scenario of a method of managing application permissions according to an embodiment of this application; FIG. FIG. 2 is a schematic configuration diagram of an electronic device according to one embodiment of this application.

The following description describes in detail implementations of the embodiments with reference to the accompanying drawings.

Methods of managing application permissions provided by embodiments of this application apply to mobile phones, tablet computers, desktop computers, laptop computers, notebook computers, ultra-mobile personal computers (UMPC), It may be applied to electronic devices such as handheld computers, netbooks, personal digital assistants (PDAs), wearable electronic devices, or virtual reality devices. This is not limited to those embodiments of this application.

For example, FIG. 1 is a schematic configuration diagram of an electronic device 100.

The electronic device 100 includes a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, and a wireless Frequency module 150, communication module 160, audio module 170, speaker 170A, receiver 170B, microphone 170C, headset interface 170D, sensor module 180, key 190, motor 191, indicator 192, camera 193, display 194, and subscriber identification It may also include a subscriber identification module (SIM) card interface 195 and the like. The sensor module 180 includes a pressure sensor 180A, a gyroscope sensor 180B, a barometric pressure sensor 180C, a magnetic sensor 180D, an acceleration sensor 180E, a distance sensor 180F, an optical proximity sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, and an ambient light sensor. 180L, a bone conduction sensor 180M, and the like.

It can be understood that the example configuration in this embodiment of this application does not constitute a particular limitation to electronic device 100. In some other embodiments of this application, electronic device 100 may include more or fewer components than those shown in the figures, or may include some components. They may be combined, some components may be divided, or different layouts of components may exist. The components shown in the figures may be implemented by hardware, software, or a combination of software and hardware.

Processor 110 may include one or more processing units. For example, the processor 110 may include an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, a memory, a video codec, and a digital signal processor. It may include a processor (digital signal processor, DSP), baseband processor, and/or neural-network processing unit (NPU), and the like. The different processing units may be independent components or may be integrated into one or more processors.

The controller may be the nerve center and command center of the electronic device 100. The controller may generate operational control signals based on the instruction operational code and the time sequence signal to complete control of instruction fetching and instruction execution.

Memory may also be located within processor 110 and configured to store instructions and data. In some of the embodiments, the memory within processor 110 is a high speed cache memory. Memory may store instructions or data for use by processor 110 on an ongoing basis or periodically. When processor 110 needs to use the instructions or data again, processor 110 may recall the instructions or data directly from memory. This avoids repeated accesses and reduces processor 110 latency, improving system efficiency.

In some of the embodiments, processor 110 may include one or more interfaces. Interfaces include inter-integrated circuit (I2C) interface, inter-integrated circuit sound (I2S) interface, pulse code modulation (PCM) interface, and universal asynchronous receiver/transmitter. (universal asynchronous receiver/transmitter, UART) interface, mobile industry processor interface (MIPI), general-purpose input/output (GPIO) interface, subscriber identity module, It may also include a SIM (SIM) interface and/or a universal serial bus (USB) interface.

The I2C interface is a bidirectional synchronous serial bus and includes a serial data line (SDA) and a serial clock line (SCL). In some of the embodiments, processor 110 may include groups of I2C buses. Processor 110 may be individually coupled to touch sensor 180K, charger, flash, camera 193, etc. through multiple different I2C bus interfaces. For example, processor 110 may be coupled to touch sensor 180K through an I2C interface, whereby processor 110 communicates with touch sensor 180K through an I2C bus interface to implement touch functionality of electronic device 100. Good too.

The I2S interface may be configured to perform voice communications. In some of the embodiments, processor 110 may include groups of I2S buses. Processor 110 may be coupled to audio module 170 through an I2S bus to implement communications between processor 110 and audio module 170. In some of the embodiments, audio module 170 may implement the functionality of transmitting audio signals to communication module 160 through an I2S interface to answer calls by using a Bluetooth headset.

PCM interfaces may also be used for voice communications to sample, quantize, and encode analog signals. In some of the embodiments, audio module 170 may be coupled to communication module 160 through a PCM bus interface. In some of the embodiments, audio module 170 also implements the ability to transmit audio signals to communication module 160 through a PCM interface to answer calls by using a Bluetooth headset. good. Both the I2S and PCM interfaces may be configured to perform voice communications.

The UART interface is a universal serial data bus and is configured to perform asynchronous communication. The bus may be a bidirectional communication bus, converting data to be transmitted between serial and parallel communications. In some of the embodiments, a UART interface is typically configured to connect processor 110 and communication module 160. For example, processor 110 communicates with a Bluetooth module in communication module 160 through a UART interface to implement Bluetooth functionality. In some of the embodiments, audio module 170 may implement the functionality of transmitting audio signals to communication module 160 through a UART interface to play music by using a Bluetooth headset.

The MIPI interface may be configured to connect processor 110 to peripheral devices such as display 194 and camera 193. The MIPI interface includes a camera serial interface (CSI), a display serial interface (DSI), and the like. In some of the embodiments, processor 110 communicates with camera 193 through a CSI interface to implement the photography functionality of electronic device 100. Processor 110 communicates with display 194 through a DSI interface to implement display functionality of electronic device 100.

The GPIO interface may be configured by software. The GPIO interface may be configured as a control signal or a data signal. In some of the embodiments, the GPIO interface may be configured to connect the processor 110 and the camera 193, display 194, communication module 160, audio module 170, sensor module 180, etc. The GPIO interface may alternatively be configured as an I2C interface, an I2S interface, a UART interface, a MIPI interface, or the like.

The USB port 130 is an interface that complies with the USB standard specifications, and specifically may be a mini USB port, a micro USB port, a USB type C interface, or the like. USB port 130 may be configured to connect to a charger to charge electronic device 100, may be configured to transfer data between electronic device 100 and a peripheral device, or It may be configured to connect to a headset and play audio by using the headset. Alternatively, the interface may be configured to connect to other electronic devices, such as, for example, AR devices.

The interfacing relationship between the modules described in this embodiment of this application is one illustrative example only and does not constitute a limitation on the structure of electronic device 100. It is possible to understand. In some other embodiments of this application, the electronic device 100 may alternatively use a different interface connection scheme than that in the embodiments described above, or may use multiple interface connection schemes. A combination of connection methods may be used.

Charging management module 140 is configured to receive charging input from a charger. The charger may be a wireless charger or a wired charger. In some of the wired charging embodiments, charging management module 140 may receive charging input from a wired charger through USB port 130. In some of the wireless charging embodiments, charging management module 140 may receive wireless charging input by using a wireless charging coil of electronic device 100. Charge management module 140 charges battery 142 while providing power to the electronic device by using power management module 141.

Power management module 141 is configured to connect battery 142 and charge management module 140 to processor 110. Power management module 141 receives input from battery 142 and/or charge management module 140 and provides power to processor 110, internal memory 121, external memory, display 194, camera 193, communication module 160, and the like. Power management module 141 may further be configured to monitor parameters such as battery capacity, battery cycles, and battery health status (such as leakage or impedance). In some other embodiments, power management module 141 may alternatively be located within processor 110. In some other embodiments, power management module 141 and charging management module 140 may alternatively be located within the same device.

The wireless communication functionality of electronic device 100 may be implemented by antenna 1, antenna 2, radio frequency module 150, communication module 160, modem processor, baseband processor, etc.

Antenna 1 and antenna 2 are configured to transmit and receive electromagnetic signals. Each antenna within electronic device 100 may be configured to cover one or more communication frequency bands. Furthermore, multiple different antennas may be multiplexed to improve antenna utilization. For example, antenna 1 may be multiplexed as a diversity antenna in a wireless local area network. In some other embodiments, the antenna may be used in combination with a tuning switch.

The radio frequency module 150 can be applied to the electronic device 100 and provide a solution including wireless communication technologies such as 2G, 3G, 4G, and 5G. Radio frequency module 150 may include at least one filter, switch, power amplifier, low noise amplifier (LNA), and the like. The radio frequency module 150 may receive electromagnetic waves by using the antenna 1, perform processing such as filtering or amplification on the received electromagnetic waves, and forward the electromagnetic waves to a modem processor for demodulation. . The radio frequency module 150 may further amplify the signal modulated by the modem processor and convert it into electromagnetic waves for radiation by using the antenna 1. In some of the embodiments, at least some functional modules of radio frequency module 150 may be located within processor 110. In some of the embodiments, at least some functional modules in radio frequency module 150 may be located in the same device as at least some modules in processor 110.

A modem processor may include a modulator and a demodulator. The modulator is configured to modulate the low frequency baseband signal to be transmitted into a medium frequency signal or a high frequency signal. The demodulator is configured to demodulate the received electromagnetic wave signal into a low frequency baseband signal. The demodulator then sends the low frequency baseband signal obtained by demodulation to the baseband processor for processing. The low frequency baseband signal is processed by a baseband processor and then sent to an application processor. The application processor outputs audio signals by using audio devices (such as, but not limited to, speakers 170A and receiver 170B) or displays images or video by using display 194. In some of the embodiments, the modem processor may be a separate component. In some other embodiments, the modem processor may be independent from processor 110 and located within the same component as radio frequency module 150 or another functional module.

Communication module 160 may provide a wireless communication solution that supports wireless local area networks (e.g., wireless fidelity (Wi-Fi) networks). , WLAN), bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), or infrared , IR) technology, etc., and is applied to electronic devices 100. Communications module 160 may be one or more devices incorporating at least one communications processor module. The communication module 160 receives electromagnetic waves by using the antenna 2, performs frequency modulation and filtering processing on the electromagnetic wave signals, and transmits the processed signals to the processor 110. The communication module 160 further receives the signal to be transmitted from the processor 110, performs frequency modulation and amplification on the signal, and transmits the signal for radiation by using the antenna 2. may be converted into electromagnetic waves.

In some of the embodiments, antenna 1 of electronic device 100 is coupled to radio frequency module 150 and antenna 2 is coupled to communication module 160, whereby electronic device 100 uses wireless communication technology. By using it, it is possible to communicate with networks and other devices. Wireless communication technologies include global system for mobile communications (GSM), general packet radio service (GPRS), code division multiple access (CDMA), and wideband code. wideband code division multiple access (WCDMA), time-division code division multiple access (TD-SCDMA), long term evolution (LTE), BT, GNSS, WLAN, May include NFC, FM, and/or IR technology, etc. GNSS includes global positioning system (GPS), global navigation satellite system (GLONASS), Beidou navigation satellite system (BDS), and quasi-zenith satellite system ( quasi-zenith satellite systems (QZSS) and/or satellite based augmentation systems (SBAS).

Electronic device 100 implements display functionality by using a GPU, display 194, application processor, and the like. The GPU is a microprocessor for image processing and connects the display 194 to the application processor. The GPU is configured to perform mathematical and geometric calculations and render images. Processor 110 may include one or more GPUs that execute program instructions to generate or modify display information.

Display 194 is configured to display images, video, and the like. Display 194 includes a display panel. Display panels include liquid crystal displays (LCDs), organic light-emitting diodes (OLEDs), active-matrix organic light emitting diodes (AMOLEDs), and flexible light-emitting diodes (flex light emitting diodes). -emitting diodes (FLED), mini LEDs, micro LEDs, micro OLEDs, quantum dot light emitting diodes (QLED), etc. In some of the embodiments, electronic device 100 may include one or N displays 194, where N is a positive integer greater than one.

Electronic device 100 may implement photography functionality by using an ISP, camera 193, video codec, GPU, display 194, application processor, and the like.

The ISP is configured to process data fed back by camera 193. For example, when taking a picture, when you press the shutter, light is sent through the lens to the camera's photoreceptor. The optical signal is converted to an electrical signal, and the camera's photoreceptor sends the electrical signal to the ISP for processing, which converts the electrical signal into a visible image. The ISP may also perform algorithm optimization for image noise, brightness, and complexion. The ISP may further optimize parameters such as exposure and color temperature of the shooting scenario. In some of the embodiments, the ISP may be located within the camera 193.

Camera 193 is configured to capture still images or video. An optical image of the object is generated through the lens and projected onto the photoreceptor. The photoreceptor may be a charge coupled device (CCD) or a complementary metal-oxide-semiconductor (CMOS) phototransistor. The photoreceptor converts the optical signal into an electrical signal and then sends the electrical signal to the ISP, which converts the electrical signal into a digital image signal. The ISP outputs digital image signals to the DSP for processing. DSP converts digital image signals into standard image signals such as RGB format or YUV format. In some of the embodiments, electronic device 100 may include one or N cameras 193, where N is a positive integer greater than one.

The digital signal processor is configured to process digital signals and may process other digital signals in addition to digital image signals. For example, when electronic device 100 selects a frequency, the digital signal processor is configured to perform a Fourier transform, etc. on the frequency energy.

Video codecs are configured to compress or decompress digital video. Electronic device 100 may support one or more types of video codecs. In this way, the electronic device 100 is capable of playing or recording videos according to multiple encoding formats, such as, for example, moving picture experts group (MPEG)1, MPEG2, MPEG3, and MPEG4. be.

NPU is a neural-network (NN) computing processor, which refers to the structure of biological neural networks, for example by referring to the mode of communication between multiple neurons in the human brain. By doing so, it is possible to quickly process input information and further perform self-learning continuously. The NPU can implement applications such as intelligent cognition of the electronic device 100, such as image recognition, facial recognition, voice recognition, and text understanding, for example.

External memory interface 120 may be configured to connect to an external storage card, such as a micro SD card, to expand the storage capabilities of electronic device 100, for example. The external storage card communicates with processor 110 through external memory interface 120 to implement data storage functionality. For example, files such as music and videos are stored in external storage cards.

Internal memory 121 may be configured to store computer-executable program code. Executable program code includes instructions. Processor 110 executes instructions stored in internal memory 121 to perform various functional applications of electronic device 100 and process data. Internal memory 121 may include a program storage area and a data storage area. The program storage area may store applications, operating systems, etc. required by at least one function (eg, audio playback function or image playback function, etc.). The data storage area may store data generated in the process of using the electronic device 100 (eg, voice data, telephone directory, etc.). In addition, internal memory 121 may include high-speed random access memory, and may further include non-volatile memory, such as, for example, at least one magnetic disk storage device, a flash memory device, or universal flash storage (UFS). May include.

The electronic device 100 may implement audio functions, such as music playback and recording, by using an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, a headset interface 170D, an application processor, etc. good.

Audio module 170 is configured to convert digital audio information to an analog audio signal for output, and is configured to convert an analog audio input to a digital audio signal. Audio module 170 may be further configured to encode and decode audio signals. In some of the embodiments, audio module 170 may be located within processor 110 or some functional modules of audio module 170 may be located within processor 110. .

Speaker 170A is also referred to as a "horn" and is configured to convert audio electrical signals into audio signals. Electronic device 100 may be configured to listen to music or answer hands-free calls by using speaker 170A.

Receiver 170B is also referred to as an "earpiece" and is configured to convert audio electrical signals to audio signals. When electronic device 100 is configured to answer a call or listen to audio information, receiver 170B is placed near the human ear to hear audio.

Microphone 170C, also referred to as a "microphone" or "microphone," is configured to convert audio signals into electrical signals. When making a call or transmitting audio information, a voice may be emitted by moving a person's mouth close to microphone 170C, and an audio signal may be input to microphone 170C. At least one microphone 170C may be located within electronic device 100. In some other embodiments, two microphones 170C may be placed within the electronic device 100 to implement noise reduction functionality in addition to collecting audio signals. In some other embodiments, three, four, or more microphones 170C may alternatively be placed within the electronic device 100 to collect audio signals and reduce noise. good. The microphone may further identify the sound source, implement directional recording functionality, etc.

Headset interface 170D is configured to connect to a wired headset. The headset interface 170D may be a USB port 130, or a 3.5 mm open mobile terminal platform (OMTP) standard interface, or a cellular telecommunications industry association of the United States. USA, CTIA) standard interface may be used.

Pressure sensor 180A is configured to detect a pressure signal and is capable of converting the pressure signal into an electrical signal. In some of the embodiments, pressure sensor 180A may be located on display 194. For example, there are multiple types of pressure sensors 180A, such as resistive pressure sensors, inductive pressure sensors, and capacitive pressure sensors. A capacitive pressure sensor may include at least two parallel plates formed of electrically conductive material. When applying force to pressure sensor 180A, the capacitance between the plurality of electrodes changes. Electronic device 100 determines pressure intensity based on changes in capacitance. When a touch operation is performed on display 194, electronic device 100 detects the touch operation intensity by using pressure sensor 180A. Electronic device 100 may also calculate the touch position based on the detection signal of pressure sensor 180A. In some embodiments, touch operations performed at the same touch location but having different touch operation intensities may correspond to different operation instructions. For example, when performing a touch operation on an icon of an SMS application, the touch operation intensity is less than the first pressure threshold, the instruction for viewing the SMS message is executed. Instructions for creating an SMS message are executed when performing a touch operation on an icon of the SMS application with a touch operation intensity equal to or greater than a first pressure threshold.

Gyroscope sensor 180B may be configured to determine the motion posture of electronic device 100. In some of the embodiments, the angular velocity of electronic device 100 about three axes (i.e., axes x, y, and z) may be determined by using gyroscope sensor 180B. . Gyroscope sensor 180B may be configured to perform image stabilization during shooting. For example, when the shutter is pressed, the gyroscope sensor 180B detects the angle at which the electronic device 100 vibrates and calculates the distance that the lens module needs to compensate based on that angle, thereby performs camera shake compensation by canceling the vibrations of the electronic device 100 through a reversing operation. Gyroscope sensor 180B may also be used in navigation and motion sensing game scenarios.

Air pressure sensor 180C is configured to measure air pressure. In some of the embodiments, electronic device 100 calculates altitude by using barometric pressure values measured by barometric sensor 180C to assist in positioning and navigation.

Magnetic sensor 180D includes a Hall sensor. Electronic device 100 can detect opening and closing of the flip leather case by using magnetic sensor 180D. In some of the embodiments, when electronic device 100 is a clamshell phone, electronic device 100 can detect opening and closing of a flip cover by using magnetic sensor 180D. Furthermore, a function such as automatic unlocking of the flip cover is set based on the detected open/close state of the leather case or the detected open/close state of the flip cover.

The acceleration sensor 180E is capable of detecting acceleration values in various directions (usually three axes) of the electronic device 100, and detects the gravity value and direction of gravity when the electronic device 100 is stationary. Is possible. Acceleration sensor 180E may further be configured to identify the posture of the electronic device, and is applied in applications such as switching between horizontal and vertical modes or pedometers.

Distance sensor 180F is configured to measure distance. The electronic device 100 may measure distance using an infrared method or a laser method. In some of the embodiments, in a photography scenario, electronic device 100 may measure distance by using distance sensor 180F to achieve quick focusing.

Optical proximity sensor 180G may include, for example, an optical detector such as a photodiode and a light emitting diode (LED). The light emitting diode may be an infrared light emitting diode. Electronic device 100 emits infrared light by using light emitting diodes. Electronic device 100 uses photodiodes to detect infrared light reflected from nearby objects. When sufficient reflected light is detected, it can be determined that an object is present in the vicinity of the electronic device 100. When insufficient reflected light is detected, the electronic device 100 may determine that there is no object near the electronic device 100. By using the optical proximity sensor 180G, the electronic device 100 detects that the user holds the electronic device 100 close to the ear for a call and automatically turns the screen on for power saving. It is possible to turn it off. Optical proximity sensor 180G can also be used in leather case mode or pocket mode to automatically unlock or lock the screen.

Ambient light sensor 180L is configured to detect the brightness of ambient light. Electronic device 100 may adaptively adjust the brightness of display 194 based on the sensed ambient light brightness. Ambient light sensor 180L may also be configured to automatically adjust white balance during shooting. Ambient light sensor 180L may also cooperate with optical proximity sensor 180G to detect whether electronic device 100 is in a pocket and avoid accidental contact.

Fingerprint sensor 180H is configured to collect fingerprints. The electronic device 100 can use the collected fingerprint characteristics to implement fingerprint-based unlocking, application lock access, fingerprint-based photography, fingerprint-based call answering, and the like.

Temperature sensor 180J is configured to detect temperature. In some of the embodiments, electronic device 100 executes a temperature treatment policy based on the temperature detected by temperature sensor 180J. For example, when the temperature reported by temperature sensor 180J exceeds a threshold, electronic device 100 reduces the performance of a processor in the vicinity of temperature sensor 180J to reduce power consumption and implement thermal protection. . In some other embodiments, electronic device 100 heats battery 142 when the temperature is below another threshold to avoid abnormal shutdown of electronic device 100 due to low temperatures. In some other embodiments, electronic device 100 increases the output voltage of battery 142 when the temperature is below yet another threshold to avoid abnormal shutdown due to low temperatures.

Touch sensor 180K is also referred to as a "touch panel." Touch sensor 180K may be disposed on display 194, and touch sensor 180K and display 194 form a touch screen, also referred to as a "touch screen." Touch sensor 180K is configured to detect a touch operation performed at or near touch sensor 180K. The touch sensor can forward the detected touch operation to an application processor to determine the type of touch event. Visual output related to touch operations may be provided using display 194. In some other embodiments, touch sensor 180K may also be located on the surface of electronic device 100 at a different location than display 194.

Vibration signals can be acquired by the bone conduction sensor 180M. In some of the embodiments, the bone conduction sensor 180M is capable of acquiring vibrating bone vibration signals of the human vocal region. Bone conduction sensor 180M is also capable of contacting the human pulse and receiving blood pressure pulse signals. In some of the embodiments, bone conduction sensor 180M may alternatively be placed within a headset to form a bone conduction headset. The audio module 170 can implement an audio function by acquiring an audio signal through analysis based on the vibration signal of the vibrating bone of the voice part acquired by the bone conduction sensor 180M. The application processor may implement a heart rate detection function by analyzing heart rate information based on the blood pressure pulse signal acquired by the bone conduction sensor 180M.

Keys 190 include a power button, a volume button, and the like. Keys 190 may be mechanical keys or touch keys. Electronic device 100 is capable of receiving key inputs and generating key signal inputs related to user settings and functional control of electronic device 100.

Motor 191 is capable of generating vibration prompts. Motor 191 may be configured to generate incoming call vibration prompts and touch vibration feedback. For example, touch operations performed for different applications (eg, taking a photo and playing audio) may correspond to different vibration feedback effects. Motor 191 may also accommodate different vibration feedback effects for touch operations performed on different areas of display 194. Different usage scenarios (eg, time reminders, information reception, alarm clocks, and games) may also correspond to different vibration feedback effects. Touch vibration feedback effects may be further customized.

Indicator 192 may be an indicator light and may be configured to indicate charging status and power changes, or may be configured to indicate messages, missed calls, notifications, and the like.

SIM card interface 195 is configured to connect to a SIM card. A SIM card may be inserted into or removed from SIM card interface 195 to implement contact with or isolation from electronic device 100. Electronic device 100 may support one or N SIM card interfaces, where N is a positive integer greater than one. SIM card interface 195 may support nano SIM cards, micro SIM cards, SIM cards, and the like. Multiple cards may be inserted into the same SIM card interface 195 at the same time. The multiple cards may be of the same type or may be of different types. SIM card interface 195 may also be compatible with multiple different types of SIM cards. SIM card interface 195 may also be compatible with external storage cards. Electronic device 100 interacts with a network through a SIM card to implement functions such as calling and data communications. In some of the embodiments, electronic device 100 uses an eSIM, ie, an embedded SIM card. The eSIM card may be embedded within the electronic device 100 and cannot be separated from the electronic device 100.

The software system of electronic device 100 may use a layered architecture, an event-driven architecture, a microkernel architecture, a microservices architecture, or a cloud architecture. In one embodiment of this application, an Android system with a layered architecture is used as an example to describe the software structure of electronic device 100.

FIG. 2 is a block diagram of the software configuration of electronic device 100 according to one embodiment of this application.

In a layered architecture, software is divided into multiple tiers, with each tier having distinct roles and tasks. These layers communicate with each other through software interfaces. In some of the embodiments, the Android system is divided into four layers: an application layer, an application framework layer, an Android runtime and system libraries, and a kernel layer.

The application layer may include a series of application packages.

As shown in Figure 2, the application packages include "Camera", "Gallery", "Calendar", "Phone", "Maps", "Navigation", "Bluetooth", "Music", "Video", It may also include applications such as "Message" and "Message".

The application framework layer provides an application programming interface (API) and programming framework to applications in the application layer. The application framework layer includes some predefined functionality.

As shown in Figure 2, the application framework layer may include permission services. Permission services include, for example, permission to read calendar contents (READ_CALENDAR), permission to use a camera (CAMERA), permission to obtain location information (LOCATION), permission to read contacts (READ_CONTACTS), and permission to read call records (READ_CALL_LOG). ) may be used to manage application permissions for each application.

For example, the permission service may pre-register one or more application permissions for each application at the application layer. Using the WeChat application as one example. A WeChat application installation package typically records one or more application permissions required for the WeChat application to run. When the WeChat application is installed on the application layer, the WeChat application may register one or more application permissions with the permission service. In this case, as shown in Figure 3(a), the permission service displays to the user one or more application permissions for which the WeChat application should register and It is possible to ask the user whether or not to grant application permission. Upon detecting that the user taps the OK button 301, the permission service generates a permission access log for the WeChat application, and includes one or more application permissions that the user confirms in the permission access log. and complete the application authorization registration procedure. Then, when using each application permission in the execution process of the WeChat application, the WeChat application calls the permission service to check whether the application permission is recorded in the permission access log of the WeChat application. You can also inquire. If the application permission is recorded in the permission access log, it indicates that the application permission used this time has been granted, and the permission service implements the corresponding functionality for the WebChat application. may continue to use application permissions for

Alternatively, and as one example, use the WeChat application. When installing a WeChat application, one or more application permissions may be temporarily not registered with the permission service. When the WeChat application runs, for example, if the user uses the code scanning function of the WeChat application for the first time, as shown in Figure 3(b), the WeChat application will run the An application permit must be applied to the permit service. In this case, the permission service further determines whether to grant the WeChat application application permission to use the camera by using a dialog window 302, as shown in FIG. 3(b). You can also ask the user. If the permission service detects that the user taps the OK button 303, the permission service may add permission to use the camera to the permission access log of the WeChat application. In this way, the permission service may gradually register one or more application permissions that the user grants to the WeChat application in the process of executing the WeChat application. Thereafter, when the WeChat application requests permission to use the camera again from the permission service, the permission service may allow the WeChat application to use the camera based on the permission access log of the WeChat application.

In this embodiment of this application, after each application registers the corresponding application permission in the permission service, the permission service further allows the application to register the application permission with reference to the current specific usage scenario. It may be decided whether or not to allow the application to use the application permission at this time, i.e., it may be decided whether or not to allow the application to use the application permission at this time with reference to the current specific usage scenario. . For example, the WeChat application pre-registers application permission to use the camera with the permission service. When the WeChat application requests the permission service to use the camera, if it detects that the current display interface contains keywords such as "video call" and "hang up", the current WeChat application will This indicates that there is a possibility that the process is in progress. On the other hand, in the video call scenario, if the camera is not opened, the WeChat application is unable to complete the video call function. Therefore, the permission service may grant the WeChat application to use the application permission to use the camera (i.e., allow the WeChat application to use the application permission to use the camera). be. Correspondingly, when the WeChat application requests permission service to use the camera, if it detects that the current display interface includes controls such as login or password, the current WeChat application Indicates that a scenario may be in progress. In contrast, whether the camera is open or not usually does not affect whether it is possible to successfully log in to the WeChat application. Therefore, the authorization service may deny the WebChat application to use the application permission to use the camera.

In other words, when an application applies to the authorization service to use an application permission, the authorization service refers to the current specific usage scenario to decide whether to grant the application permission or not. good. If the application permission that an application applies for and uses corresponds to the current usage scenario, it indicates that it is appropriate to use the application permission in accordance with the current usage scenario. In this case, the permission service may allow the application to continue using the application permissions so as not to impact the user's normal use of the various features provided by the application.

When the application permission requested by an application does not correspond to the current usage scenario, it indicates that it is inappropriate to use the application permission in accordance with the current usage scenario. Consumes unnecessary system resources and increases power consumption overhead when an application uses an application grant if the application is allowed to continue using the application grant. In addition, after an application is allowed to use an application permission that does not correspond to the current usage scenario, the application may further abuse the application permission to obtain user privacy, resulting in user privacy leakage. increase the risk of Therefore, if the application permission that an application requests and uses this time does not correspond to the current usage scenario, we may refuse to allow the application to use the application permission this time, reducing the consumption of system resources. and reduce security risks due to leakage of user privacy, and may improve the user experience.

Of course, the application framework layer may further include a drawing service, window manager, content provider, telephony manager, resource manager, notification manager, etc.

The window manager is configured to manage window programs. The window manager obtains the size of the display, determines whether a status bar is present, performs screen locks, takes screenshots, etc. Content providers are configured to store and retrieve data and enable applications to access the data. The data may include videos, images, audio, phone calls, browsing history and bookmarks, phone books, etc. that are created and received. The telephone manager is configured to provide communication functions for the electronic device 100, such as, for example, managing call status (including answering, rejecting, etc.). The resource manager provides various resources to applications, such as localized strings, icons, images, layout files, and video files. The notification manager allows applications to display notification information in the status bar and may be configured to communicate notification messages. The notification manager may disappear automatically after a short pause without requiring user interaction. For example, the notification manager is configured to provide download completion notifications, message notifications, and the like. The notification manager may alternatively manage notifications that appear on the system's top-level status bar in the form of graphs or scrollbar text, such as notifications of application programs running in the background or notifications that appear on the screen in the form of a dialog window. There may be. For example, text information may be prompted in the status bar, an alert may sound, the electronic device may vibrate, or an indicator light may flash.

The Android runtime includes a kernel library and a virtual machine. The Android runtime is responsible for scheduling and managing the Android system.

The kernel library contains two parts: the functional functions that need to be called in the Java language and the Android kernel library.

The application layer and application framework layer run in virtual machines. The virtual machine executes the application layer and application framework layer Java files as binary files. Virtual machines are configured to perform functions such as object lifecycle management, stack management, thread management, security and exception management, and garbage collection.

The system library includes multiple functional modules, such as surface managers, media libraries, 3D graphics processing libraries (such as OpenGL ES), and 2D graphics processing libraries (such as SGL). It may also include an engine.

The surface manager is configured to manage the display subsystem and provide fusion of 2D and 3D image layers for multiple applications.

The media library supports playback and recording of multiple commonly used audio and video formats, still image files, etc. The media library may support multiple audio and video encoding formats such as MPEG4, H.264, MP3, AAC, AMR, JPG, and PNG.

The 3D graphics processing library is configured to implement 3D graphics rendering, image rendering, compositing, layer processing, and the like.

A 2D graphics engine is a drawing engine for 2D drawing.

The kernel layer is a layer between hardware and software. The kernel layer includes at least a display driver, a camera driver, an audio driver, a sensor driver, and the like. This is not limiting in this embodiment of this application.

The following description describes how to manage application permissions provided by embodiments of this application by using one example in which the electronic device is a mobile phone and with reference to the accompanying drawings. Explain in detail.

For example, a user installs a weather APP on a mobile phone. As shown in FIG. 4(a), the developer prerecords multiple application permissions that the weather APP needs to register in the installation package of the weather APP. For example, the application permissions that a weather app needs to register include permission 1 to obtain location information, permission 2 to use microphone, permission 3 to read calendar, and permission 4 to use camera. When the weather APP is installed, the weather APP may request the permission service to register permissions 1 through 4 for the weather APP. In this case, the authorization service may identify, based on the application type of the weather APP, whether the application permission that the weather APP requests to register includes an application permission that does not correspond to the application type of the weather APP. good.

For example, as shown in Table 1, a set of application permissions corresponding to different types of applications may be pre-stored in the mobile phone. Using the social applications in Table 1 as one example, the application permissions that correspond to social applications are typically the applications that social applications are required to use when they provide different functionality to users. social applications typically do not maliciously/ additionally gain user privacy when using permissions and those application permissions. In this case, when the weather APP requests to register permissions 1 to 4, the mobile phone checks whether all of permissions 1 to 4 belong to the set of application permissions corresponding to the weather type. You may also inquire. Of course, the mobile phone may inquire of the server whether Permission 1 to Permission 4 include inappropriate application permissions. This is not limiting in this embodiment of this application.

For example, if permission 1 to permission 3 all belong to the set of application permissions corresponding to the weather type, but permission 4 does not belong to the set of application permissions corresponding to the weather type, the permission is granted when the weather APP is executed. Indicates that there is no need to use 4. In this case, the permit service may automatically deny the registration of permit 4 for the weather APP. For example, as shown in FIG. 4(b), the mobile phone may prompt the user to grant weather APP permissions 1 through 3 in the dialog box 401, and the mobile phone has already set the default to deny permission 4 registration. Therefore, the mobile phone does not need to prompt the user to grant permission 4 in dialog box 401. Subsequently, when the mobile phone detects that the user taps the OK button 402 in the dialog box 401, the mobile phone specifies that the weather APP uses permissions 1 to 3 in the permission access log of the weather APP. You may allow it. In this way, when an application registers an application permission in the mobile phone, the mobile phone automatically blocks application permissions that have a relatively high security risk for the user, so that the application can then By using application permissions with high security risks, it is possible to prevent user privacy from being captured and avoid security issues such as privacy leaks.

Alternatively, as shown in Figure 4(c), when the mobile phone identifies that permission 4 for which the weather APP requests registration is an inappropriate application permission, the mobile phone: Furthermore, permission 4 may be displayed in dialog box 403. Meanwhile, the mobile phone informs the user in a dialog box 403 that the security risk of granting permission 4 is relatively high, and recommends the user not to grant permission 4 to the weather APP. In this case, the user may manually choose whether to grant permission 4 to the weather APP based on the prompt in dialog box 403. This is not limiting in this embodiment of this application.

Alternatively, when a new application is installed or executed on a mobile phone, the mobile phone automatically includes permission services for that application based on the correspondence shown in Table 1. One or more corresponding application permissions may be registered. In this way, when using a new application, the user is unaware of the process of granting application permissions to the application. In addition, the application permissions granted to the application are determined by the mobile phone and are often relatively legitimate application permissions that match the application type, so unauthorized application permissions can be exploited to protect users. It is possible to reduce the risk of gaining privacy.

In some of the embodiments, when an application registers one or more application permissions in a mobile phone's permission service and then uses each application permission, the application registers one or more application permissions in the permission service. must be called to determine that the currently used application permission is the registered application permission.

For example, as shown in Figure 5, the map application has four permission services, such as permission to obtain location information, permission to use a microphone, permission to use a camera, and permission to use Bluetooth. Register one application permission. In this case, when the map application uses any application permission, the map application needs to apply to the permission service to allow the map application to use the application permission at this time. For example, if a map application needs to use a camera to obtain image information that the camera obtains while the map application is running, the map application may need to use the camera to allow the application to use the camera at this time. It is possible to request the authorization service to grant authorization. Furthermore, the permission service may inquire whether the map application has registered permission to use the camera in the map application's permission access log. If the mapping application has registered an application permission to use the camera, the permission service further determines whether to allow the mapping application to use the camera at this time based on the current usage scenario. It's okay.

For example, a scenario identification model may be pre-configured in the mobile phone, and the scenario identification model may be used to identify the current application usage scenario. For example, when a map application requests the permission service to grant the application permission to use the camera this time, the permission service calls the screenshot service to take a screenshot of the currently displayed interface. You may. Further, the authorization service may input the obtained screenshot into a scenario identification model, which identifies the current usage scenario based on screenshot information such as text or controls in the screenshot. identify

Alternatively, the mobile phone may further extract keywords in the current display interface by using OCR (optical character recognition) technology. Furthermore, the authorization service may input the extracted keywords into a scenario identification model, which identifies the current usage scenario based on the keywords.

Alternatively, the mobile phone may further obtain the layout capabilities of the current display interface, for example by using a service such as a view, such as a layout tree. Additionally, the authorization service may input the extracted layout features into a scenario identification model, which identifies the current usage scenario based on the layout features. Of course, the mobile phone may further request the server to identify the particular usage scenario of the current application. The manner in which specific usage scenarios are identified is not limited in this embodiment of this application.

Further, as one example, use a map application. As shown in Figure 6(a), if an icon or keyword such as account or login password appears in the current display interface, the mobile phone indicates that the map application is currently in the login scenario. It may be determined that As shown in Figure 6(b), if icons or keywords such as map, navigation, route, etc. appear in the current display interface, the mobile phone indicates that the map application is currently in the positioning scenario. You may decide that you are in the middle of it. As shown in Figure 6(c), if the display elements of the map application do not appear in the current display interface, the mobile phone is in the middle of a background scenario in which the map application is currently running. You may decide that.

Alternatively, use the WeChat application as one example. As shown in Figure 7(a), when the mobile phone detects that an icon or keyword, such as an account or login password, is displayed in the current display interface, the mobile phone , you may mark the display interface as a login scenario. As shown in Figure 7(b), when the mobile phone detects that an icon or control, such as a chat bubble, appears in the current display interface, the mobile phone You may mark the display interface as . As shown in Figure 7(c), if the mobile phone detects that a control is displayed in the current display interface, such as a playback progress bar or a playback button, or the mobile phone , if it detects that the consumed data traffic is greater than a certain threshold, the mobile phone may mark the display interface as a playback scenario.

Further, as one example, use a map application. After the mobile phone determines the current usage scenario of the map application, the mobile phone refers to the usage scenario and determines whether to grant the application permission to use the camera this time to the map application. good. As shown in Figure 8, when the mobile phone detects that the map application is in the middle of a positioning scenario, the mobile phone determines that the application permission that matches the positioning scenario does not allow the application permission to use the camera. You may decide whether to include it or not. Indicates that there is a relatively low security risk for a mapping application to perform an operation by using a camera if the application permissions that match the positioning scenario include an application permission to use a camera, and the permission The service may grant the map application application permission to use the camera. Correspondingly, if the application permissions that match the positioning scenario do not include application permissions to use the camera, the security risk for the mapping application to perform operations by using the camera is relatively low. It shows that it is high. In this case, the authorization service may refuse to grant the map application application permission to use the camera.

For example, as shown in Table 2, the correspondence between each application permission and usage scenario whitelist may be preset in the mobile phone.

Each application permission corresponds to one or more usage scenarios in which the application permission is permitted to be used. For example, scenarios that are allowed to use the application permission to use a camera include filming/video recording scenarios, riding scenarios, shopping/scanning code scenarios, social communication scenarios, and certificate processing scenarios. For example, the WeChat application is run by a mobile phone. When running the WeChat application, if it detects that the WeChat application has applied to the permission service to use the camera according to the scenarios in the usage scenario whitelist, such as shooting/video recording scenarios, etc. The permission service may grant the WeChat application's permission request to use the camera at this time. If the WeChat application detects that the WeChat application has applied to the permission service to use the camera in a scenario that is not included in the usage scenario whitelist, such as chat, the permission service may deny the request for permission to use the camera at this time.

For example, if a mobile phone identifies that the usage scenario in which a mapping application requires the use of a camera is a positioning scenario, the mobile phone can determine by using Table 2 that a positioning scenario uses a camera. It may be determined that there is no usage scenario in the whitelist that corresponds to the application's permission to do so. This indicates that the operation of using the camera along with the positioning scenario has a relatively high security risk for the user. Therefore, the mobile phone may refuse to grant the map application permission to use the camera at this time. In this case, as shown in Figure 8, the mobile phone displays a notification 701, and the mobile phone notifies that the map application has rejected the permission application to use the camera this time. The user may be notified in 701.

For example, when the permission service in the mobile phone denies granting the map application permission to use the camera, it may send back a permission denial response, PERMISSION_DENIED, to the map application. After receiving a permission denied response, the map application will continue to call the camera service to open the camera and retrieve the image information, which is impossible because the application consumes system resources. avoids the problem of abusing application permissions to obtain application permissions or user privacy;

It should be noted that the above division of usage scenarios in this embodiment of this application is only one example for illustration. This is not limiting in this embodiment of this application.

Additionally, in some of the embodiments of this application, "usage scenario" may be used as a concept to explain the technical solutions provided by this application. Upon detecting detection items used to indicate a usage scenario, such as text, icons, controls, or operations, the mobile phone allows the application to use application permissions based on those detection items. It may be determined whether the application should be accepted or rejected. In this case, the mobile phone does not actually need to perform the step of determining the usage scenario. For example, a correspondence between a corresponding icon (or control) whitelist and multiple different application permissions may be set up in the mobile phone. If the mobile phone detects that a map or route icon is displayed on the current display interface, this detection means that the mobile phone is currently in the middle of a positioning scenario. . In this situation, if the authorization service receives a request for the mapping application to use the camera, the authorization service will, based on the correspondence above, grant the authorization application for the mapping application to use the camera this time. You may refuse directly.

Additionally, if the mobile phone detects that the user has tapped the displayed notification 701, the mobile phone jumps to the permission management interface 801 of the map application, as shown in Figure 9(a). You may. In the permission management interface 801, a user may manually enable or disable corresponding application permissions for a map application. Additionally, for enabled application permissions, the mobile phone may further configure functionality to modify the specific usage scenario of the application permission. For example, if the mobile phone detects that the user has tapped the settings button 802 for using camera application permissions in the permission management interface 801, as shown in FIG. 9(b). , the mobile phone may display certain usage scenarios in which the map application uses the camera's application permissions. The user may manually add usage scenarios in which the mapping application is allowed to use the camera, or disable the currently allowed usage scenarios in which the mapping application is allowed to use the camera. It's okay. This is not limiting in this embodiment of this application.

In some other embodiments, if the mobile phone determines that the current positioning scenario is not in the usage scenario whitelist corresponding to application permission to use the camera, As shown in FIG. It's okay. Additionally, the mobile phone may ask the user in prompt box 901 whether the map application is allowed to use the camera at this time. If it detects that the user has tapped the "deny" button 902, the permission service in the mobile phone denies granting the map application permission to use the camera. If the phone detects that the user has tapped the "Allow" button 903, the phone indicates that the user is aware of the security risks of using the camera in line with the current usage scenario. and the user still allows the map application to use the camera according to the current usage scenario. In this case, the mobile phone may grant the map application application permission to use the camera. For example, the permission service may send back a permission grant response, PERMISSION_GRANTED, to the map application. After receiving the authorization response, the map application may continue to call the camera service to open the camera to capture image information.

In addition to configuring a correspondence between each application permission and a usage scenario whitelist in the mobile phone, there is also a mapping between each application permission and usage scenario blacklist in the mobile phone. It should be noted that a correspondence relationship may be established. In this case, if the mobile phone detects that the map application has applied to the permission service for application permission to use the camera, the mobile phone detects that the current usage scenario is It may be determined whether the usage scenario corresponding to the application permission for is present in the blacklist. If the current usage scenario is in the usage scenario blacklist that corresponds to the application's permission to use the camera, then the map application's use of the camera according to the current usage scenario is indicates that the operation involves a high security risk. Therefore, the mobile phone may refuse to grant the map application application permission to use the camera.

Alternatively, if the mobile phone detects that the mapping application has applied to the permission service for application permission to use the camera, the mobile phone may also The server may be requested to determine whether it is suitable to capture image information by using a camera along the line. This is not limiting in this embodiment of this application. For example, as shown in FIG. 11, the mobile phone may report the map application's authorized access log to the server. Additionally, when running the map application, the mobile phone may periodically take screenshots of the display interface and report the resulting screenshots to the server. Based on the screenshots sent by the mobile phone, the server may identify the usage scenarios to which the different screenshots belong by using relevant algorithms of machine learning. Alternatively, the usage scenario for each screenshot may be marked by a staff member by using manual marking methods. Further, with reference to the map application's permission access log, the server establishes a correspondence (e.g., in Table 2) between the plurality of different application permissions in the permission access log and the usage scenario whitelist; Then, the correspondence relationship may be distributed to the mobile phone. In this way, when a map application in a mobile phone requests a permission service to use an application permission, the permission service uses a specific usage scenario that the scenario identification module identifies and a corresponding response that the server delivers. Based on the relationship, determine whether the application permission requested by the mapping application is appropriate according to the current usage scenario, and further permit or deny the mapping application to use the application permission. Good too.

In the above embodiments, for purposes of illustration, one example is used in which a map application requests the use of an application permission to use a camera in a positioning scenario. When the map application requests to use any application permission along with other usage scenarios, the permission service in the mobile phone determines whether the map application uses the application permission this time according to the method described above. It is possible to understand that it may be allowed/denied.

Correspondingly, when other applications apply to use the application permission along multiple different usage scenarios, the mobile phone also allows the application to use the application permission according to the method described above. You can allow/deny it.

Using the reading application as one example, when the mobile phone runs the reading application, the mobile phone periodically identifies the current usage scenario and updates the most recent identified usage scenario. May be stored. When the authorization service receives a request to obtain location information from a reading application, the authorization service determines that the most recently identified usage scenario is the reading scenario, as shown in Figure 12. You may get that. Furthermore, the authorization service may inquire whether the usage scenario whitelist corresponding to the application authorization to obtain location information includes the reading scenarios in Table 2. If the usage scenario whitelist corresponding to the application permission for acquiring location information does not include a reading scenario, the operation of acquiring the user's location information according to the reading scenario is an operation that poses a high security risk for the user. Show that there is. Accordingly, the authorization service may deny granting the reading application application permission to obtain location information.

For example, when the authorization service denies granting the reader application permission to obtain location information, the authorization service may send back a permission grant response, PERMISSION_GRANTED, to the reader application. In addition, the authorization service may send instruction information to the positioning service instructing the positioning service to provide the reading application with false location information this time. In this manner, after receiving the authorization response, the reading application may continue to send location requests to the positioning service requesting the positioning service to report the user's current location information. Because the positioning service has received the instruction information sent by the authorization service, after receiving the location request sent by the reading application, the positioning service instead of reporting the user's current actual location information to the reading application. , may report false location information to the reading application. For example, a positioning service may randomly generate longitude and latitude location information and report the location information to a reading application. As another example, the positioning service may obtain the latitude and longitude information of any location that the mobile phone presets (e.g., North and South Pole, etc.), and then send the reading application the obtained latitude and longitude information. Information may be reported.

Thus, although the reading application obtains application permission to use the location service in the reading scenario, the location information that the reading application ultimately obtains from the positioning service is not the user's actual location information. This prevents the reading application from randomly acquiring the user's location information along with inappropriate usage scenarios.

In some of the embodiments, if some applications apply to the permission service to use application permissions and do not obtain a permission grant response that the permission service returns, Applications may encounter exceptions that affect user usage, such as unexpected termination, stopping, or crashing. Those applications may be referred to as specific types of applications in subsequent embodiments. In this case, if the authorization service determines that the application permission that the reader application is currently requesting does not correspond to the current usage scenario, the authorization service further determines that the reader application You may also acquire whether it is an application. If the reading application is a particular type of application, the authorization service may instruct the associated service to provide corresponding false data to the reading application according to the method described above.

False data is when an application requests user data (e.g., location information, contact information, or image information) from a service (e.g., location service, contact service, or telephone service) by an authorized service. means that the corresponding service provides the application with virtual data that does not match the actual user data. For example, fake data may include fake location information, fake international mobile equipment identity (IMEI), fake serial number (SN), fake contact information, or fake photo. It is. In this way, it is possible to prevent the user's real data from being leaked by certain types of above-mentioned applications, and the normal execution process of certain types of above-mentioned applications is not affected.

For example, in a read scenario, if the reader application detects that it is requesting the authorization service to obtain location information, the authorization service may now provide the reader application with false location information. The positioning service may be automatically instructed. In this case, as shown in Figure 13(a), the mobile phone may display a notification 1001 indicating that the location information provided to the reading application this time is the user's actual location. The user may be informed that this is not location information.

In addition, the mobile phone may further set a modification button 1002 in the notification 1001. When the mobile phone detects that the user has selected button 1002, the mobile phone performs application permission management to obtain location information, as shown in Figure 13(b). You may jump to interface 1003. At the management interface 1003, the user may manually modify the particular manner in which location information is reported to the reading application. For example, an option 1004 is set in the management interface 1003 that prohibits reporting location information to reading applications. If the reading application is a certain type of above-mentioned application, the mobile phone may further inform the user that the reading application may not work properly after selecting option 1004. In other examples, the options 1005 to report false location information to the reader application and the option 1006 to report real location information to the reader application may be further configured within the management interface 1003. If the usage scenario whitelist corresponding to the application permission to obtain location information does not include a read scenario, the mobile phone will further prompt the user to select option 1006 and prevent user privacy leakage security. May increase risk.

Alternatively, if the mobile phone detects in the reading scenario that the reading application is requesting the authorization service to obtain location information, the mobile phone The phone may ask the user in prompt box 1007 whether to allow the reading application to obtain location information. Because the reading application belongs to a specific type of above-mentioned application, unexpected termination, stopping, or crashing of the reading application when it detects that the user taps the "Reject" button 1008, etc. In order to avoid this phenomenon, the authorization service in the mobile phone can instruct the positioning service to provide false location information to the reading application according to the above method, so that the user's real location can be recognized by the reading application. It is possible to prevent information from leaking.

In some of the embodiments, the application list may be pre-configured in the mobile phone, and all of the applications in the application list belong to a particular type of said application. Additionally, using the above reading application as one example. If the mobile phone detects that the application permissions used by the reading application request do not correspond to the current usage scenario, then the mobile phone detects that the reading application uses the specific application permissions mentioned above according to the application list above. It may be determined whether the type of application.

Alternatively, when some applications apply to the permission service to use a particular type of application permission, and the permission service does not get a permission grant response back, the application may, for example, Exceptions may be encountered that affect user usage, such as unexpected terminations, stops, or crashes. In this case, specific types of application permissions may also be set within the above application list that affect the user's usage. For example, the application list includes application A, and the specific types of application permissions corresponding to application A include application permission 1 and application permission 2. In this case, we will further use the reading application described above as one example. When the mobile phone detects that the application permission that the reading application requests to use does not correspond to the current usage scenario, the mobile phone detects that the above application list contains the reading application and the reading application If the mobile phone discovers that the particular type of application permission corresponding to includes the application permission that the reading application now requests to use, the mobile phone responds to the reading application according to the method described above. Associated services may be instructed to provide false data.

In addition, the mobile phone may also update applications or application permissions recorded in the application list. For example, if the mobile phone detects a phenomenon such as unexpected termination, stalling, or crash of application B after the authorization service denies the permission application of application B to use application 3, the mobile phone , may add application B to the above application list and record in the application list that the particular type of application permission corresponding to application B includes application 3. Of course, the mobile phone may alternatively request the server to create or update the application list. This is not limiting in this embodiment of this application.

In the method of managing application permissions provided by this embodiment of this application, the mobile phone controls the application to obtain corresponding application permissions in multiple different usage scenarios by using usage scenarios as granularity. may prevent applications from abusing application permissions to gain user privacy after registering application permissions. This reduces the security risk of leaking user privacy and improves the user experience.

In some of the embodiments, the application may be able to control the application permissions that the application is required to use based on more granular usage scenarios. The process of registering application permissions with the permission service may be omitted. In other words, when an application is installed or executed, one or more application permissions that need to be used later do not need to be pre-registered in the permission service. Correspondingly, each time an application needs to use an application permission, the permission service may allow or deny the application to use the application permission based on the current usage scenario. .

For example, the mobile phone may detect the current usage scenario in real time and set variables within the mobile phone to store the most recently detected specific usage scenario. Using the WeChat application as one example. There is no need to grant application permissions to the WeChat application when the WeChat application is installed. As shown in Figure 15, after detecting that the current scenario is the WeChat application login scenario, the mobile phone can save the current usage scenario as the WeChat login scenario by the above variables. It is possible. Additionally, if the authorization service receives an authorization application sent by the WeChat application as well as requesting to use the camera, the authorization service determines that the usage scenario whitelist corresponding to the application authorization to use the camera is Table 2 may be queried to see if the WeChat login scenario is included. Indicates that using the camera in a WeChat login scenario may compromise user privacy if the usage scenario whitelist corresponding to the application permission to use the camera does not include the WeChat login scenario. . Accordingly, the authorization service may refuse to grant the web chat application application permission to use the camera. In this case, the mobile phone further displays a dialog box 1101 to inform the user that the permission application to use the camera this time has been denied by WeChat, as shown in Figure 15. It's okay.

As shown in FIG. 16(a), after successfully logging into the WeChat application, the mobile phone can display the display interface 1201 of the WeChat application, and the display interface 1201 is a two-dimensional code includes a code scanning button 1202 used to scan the code. If the mobile phone detects that the user is tapping the code scanning button 1202, the mobile phone displays a code scanning interface 1203 in the WeChat application, as shown in Figure 16(b). You may. In this case, on the one hand, the mobile phone is able to detect that the current usage scenario has been updated to a code scanning scenario. On the other hand, the code scanning function of the WeChat application requires the use of a camera to obtain two-dimensional code information, so the WeChat application uses the camera for permission services in the mobile phone. may request that the WeChat application be granted application permissions. In this case, referring to the current code scanning scenario, from the correspondence shown in Table 2, it is determined that the use of the camera in the code scanning scenario by the WeChat application is an appropriate authorized application. You may. Accordingly, the permission service may automatically send back a permission grant response, PERMISSION_GRANTED, to the WeChat application. After receiving the granting response, the WeChat application may continue to call the camera service to open the camera to capture image information. In this way, the mobile phone automatically allows applications to use relevant application permissions in appropriate scenarios with relatively low security risks, without the user's perception, thereby protecting user privacy. It is possible to improve the user experience while reducing the risk of leakage.

In some other embodiments, as shown in FIG. 16(b), after the WeChat application determines that it is an appropriate authorized application to use the camera at this time in the code scanning scenario: The mobile phone further displays a dialog box 1204 on the code scanning interface 1203, in which the user is informed that the WeChat application is to use the camera function in the code scanning scenario, and the WeChat application is to use the camera function. The user may be asked whether or not to allow the feature to be used. If it detects that the user selects the "Allow this time" button 1205, that means that the user allows the WeChat application to use the camera permission only in code scanning scenarios. shows. Accordingly, the authorization service may allow the WeChat application to use the camera in response to the user's selection. Thereafter, if the mobile phone detects again in the code scanning scenario that the WeChat application is applying to use the camera, the mobile phone will continue to display the dialog box 1204 to indicate that the WeChat application is requesting to use the camera. The user may be prompted to allow use of the camera.

Alternatively, when displaying the dialog box 1204, the mobile phone may also set an "Allow every time" button 1205. Since the scenario whitelist for using the camera includes code scanning scenarios, it indicates that allowing an application to use the camera in code scanning scenarios typically does not compromise user privacy. Therefore, the mobile phone may recommend that the user select the "Allow every time" button 1205, specifically, even if the WeChat application does not allow the use of the camera every time in code scanning scenarios. good. In this case, if it detects that the user has selected the "Allow every time" button 1205, the user will be asked to grant application permission to the WeChat application to use the camera every time in a code scanning scenario. Show that. Additionally, the authorization service may authorize the WeChat application to use the camera in response to the user's selection. In addition, if the mobile phone subsequently detects in a code scanning scenario that the WeChat application has applied to use the camera, the mobile phone will automatically grant the application permission to the WeChat application to use the camera. and dialog box 1204 may no longer be displayed.

Alternatively, when displaying the dialog box 1204, the mobile phone may also set a "deny to allow" button 1206. If the mobile phone detects that the "Deny to Allow" button 1206 is tapped, the mobile phone tells the user that it is impossible to complete the code scanning function. Good too. If the user further refuses to use the WeChat application camera in a code scanning scenario, the mobile phone may refuse to allow the WeChat application to use the camera.

In some other embodiments, and as one example, WeChat application is used. When the mobile phone allows/denies the WeChat application to use the application permission, the mobile phone also prompts the user by specific usage scenarios in which the WeChat application is allowed to use the application permission. good. For example, when detecting for the first time in a WeChat login scenario that the WeChat application requests the authorization service to grant application permission to use the camera, as shown in Figure 17(a), , the mobile phone may display a dialog box 1301. In dialog box 1301, the mobile phone identifies one or more usage scenarios in which the WeChat application is allowed to use the camera permission, i.e., in the usage scenario whitelist corresponding to the application permission to use the camera. may present usage scenarios to the user. If it detects that the user has tapped the OK button 1302, it indicates that the user has authorized the WeChat application to use the camera in the usage scenario shown in the dialog box 1301. However, the current WeChat login scenario indicates that none of the above usage scenarios exist. Therefore, the mobile phone may refuse to grant the WeChat application application permission to use the camera. When the mobile phone detects that the user has tapped the permission management button 1303, the mobile phone taps the application permission management interface to use the camera, as shown in Figure 17(b). You can also jump to 1304. At the management interface 1304, the user may manually add specific usage scenarios in which the application is allowed to use the camera, or add currently allowed usage scenarios in which the application is allowed to use the camera. You may disable the usage scenarios that are currently being used. This is not limiting in this embodiment of this application.

As shown in FIG. 18, one embodiment of this application discloses an electronic device that includes a touch screen 1801. Touch screen 1801 includes a touch-sensitive surface 1806, a display 1807, one or more processors 1802, memory 1803, one or more application programs (not shown), and one or more computer programs 1804. The components described above may be connected via one or more communication buses 1805. One or more computer programs 1804 are stored in memory 1803 and configured to be executed by one or more processors 1802. One or more computer programs 1804 include instructions that may be used to perform the steps of the embodiments described above.

For example, processor 1802 may specifically be processor 110 shown in FIG. 1, and memory 1803 may specifically be internal memory 121 or external memory 120 shown in FIG. The display 1807 may specifically be the display 194 shown in FIG. 1, and the touch sensitive surface 1806 may specifically be the sensor module 180 shown in FIG. The touch sensor 180K may be used.

Those skilled in the art will clearly understand that the above description of multiple implementations only uses the above division into multiple functional modules as one example for convenience and concise explanation. make it possible to In practical applications, it is possible to allocate the above functions to different functional modules for implementation based on requirements. In other words, the internal configuration of the device is divided into different functional modules to implement all or some of the functionality described above. For detailed operating processes of the above systems, devices and units, reference should be made to the corresponding processes in the above method embodiments, and the details will not be described repeatedly herein.

The functional units in the embodiments of this application may be integrated into one processing unit, or each of the units may be physically present alone, or two One or more units may be integrated into one unit. The integrated unit may be implemented in hardware or in the form of a software functional unit.

When the integrated unit is implemented in the form of a software functional unit and sold or used as a separate product, the integrated unit may be stored in a computer-readable storage medium. . Based on such an understanding, the technical solutions of those embodiments of this application may essentially or partially contribute to the prior art or all or part of the technical solutions. may be implemented in the form of a software product. The computer software product is stored in a storage medium and includes a number of instructions that perform all of the steps of the methods described in those embodiments of this application. or instruct a computing device or processor (which may be a personal computer, server, or network device) to execute a portion. The storage medium includes any medium capable of storing program code, such as flash memory, removable hard disk, read-only memory, random access memory, magnetic disk, or compact disk.

The above descriptions are only specific implementations of the embodiments of this application, but are not intended to limit the protection scope of the embodiments of this application. Any modification or substitution within the technical scope disclosed in those embodiments of this application shall fall within the scope of protection of those embodiments of this application. Therefore, the scope of protection of those embodiments of this application shall be in accordance with the scope of protection of the claimed inventions.

Claims (13)

A method for managing application permissions, the method comprising:
displaying a home screen by the electronic device, the home screen including an icon for a first application;
displaying a first interface by the electronic device in response to a first action of a user tapping the icon;
allowing the first application to use a first application permission by the electronic device when displaying the first interface;
displaying, by the electronic device, a second interface in response to a second operation of the user on the first interface;
denying, by the electronic device, the first application from using the first application permission when displaying the second interface;
The usage scenario indicated by the first interface is a first scenario, and the usage scenario indicated by the second interface is a second scenario,
The step of allowing the first application to use a first application permission by the electronic device comprises:
A scenario identification model is applied by the electronic device to determine screen information in a screenshot of the currently displayed interface, keywords extracted from the currently displayed interface, or layout features of the currently displayed interface. determining whether the first application permission corresponds to the first scenario or the second scenario based on
allowing, by the electronic device, the first application to use the first application permission when the first application permission corresponds to the first scenario;
said step of denying, by said electronic device, said first application to use said first application permission;
A method comprising denying, by the electronic device, the first application from using the first application permission when the first application permission does not correspond to the second scenario. When the electronic device denies the first application to use the first application permission, the method includes:
further comprising displaying, by the electronic device, a first notification in the second interface, the first notification requesting to use the first application permission by the first application. 2. The method of claim 1 , wherein the method is used to inform the user that the user is currently being rejected. 3. The method of claim 2 , wherein the first notification includes the usage scenario corresponding to the second interface. After the step of displaying a first notification in the second interface by the electronic device, the method includes:
2. The method of claim 2 , further comprising displaying, by the electronic device, a settings interface for managing application permissions when the electronic device detects that the user has opened the first notification. The method described in. When displaying the second interface, the method:
displaying a dialog box within the second interface by the electronic device when the electronic device detects that the first application is applying for use of the first application permission; further comprising the step, the dialog box including a first button that does not allow the first application to use the first application permission;
said step of denying, by said electronic device, said first application to use said first application permission;
denying, by the electronic device, the first application from using the first application permission if the electronic device detects that the user selects the first button; 2. The method of claim 1 , comprising the steps. The first application permission includes permission to obtain location information, permission to read/modify address book, permission to read/modify calendar, permission to use camera, permission to use microphone, permission to use Bluetooth, 6. The method according to any one of claims 1 to 5 , comprising permitting the use of a voice recognition function. An electronic device,
a touch screen including a touch-sensitive surface and a display;
one or more processors;
one or more memories;
one or more computer programs, the one or more computer programs stored in the one or more memories, the one or more computer programs including instructions, and the one or more computer programs comprising instructions for the When the instructions are executed by the electronic device, the electronic device:
displaying a home screen, the home screen including an icon of a first application;
displaying a first interface in response to a first action of a user tapping the icon;
allowing the first application to use a first application permission when displaying a first interface;
displaying a second interface in response to the user's second operation on the first interface;
denying the first application to use the first application permission when displaying a second interface;
makes it possible to execute
The usage scenario indicated by the first interface is a first scenario, and the usage scenario indicated by the second interface is a second scenario,
The step of allowing the first application to use a first application permission by the electronic device specifically includes:
A scenario identification model is applied to identify the first screen based on screen information in a screenshot of the currently displayed interface, keywords extracted from the currently displayed interface, or layout features of the currently displayed interface. determining whether one application permission corresponds to the first scenario or the second scenario;
allowing the first application to use the first application permission when the first application permission corresponds to the first scenario;
The step of denying the first application from using the first application permission by the electronic device specifically includes:
An electronic device comprising: denying the first application to use the first application permission when the first application permission does not correspond to the second scenario. When the electronic device denies the first application to use the first application permission, the electronic device further:
The first notification is configured to perform the step of displaying a first notification within the second interface, the first notification indicating that a request for use of the first application permission by the first application has been made. 8. The electronic device of claim 7 , wherein the electronic device is used to inform the user that he is currently being rejected. After said step of displaying a first notification in said second interface by said electronic device, said electronic device further:
9. The electronic device is configured to perform the step of displaying a settings interface for managing application permissions if the electronic device detects that the user has opened the first notification. Electronic devices described in . When displaying the second interface, the electronic device further:
the electronic device is configured to perform the step of displaying a dialog box within the second interface when the electronic device detects that the first application is applying for use of the first application permission; configured to, the dialog box including a first button that does not allow the first application to use the first application permission;
The step of denying the first application from using the first application permission by the electronic device comprises:
The claim further comprises: denying the first application to use the first application permission if the electronic device detects that the user has selected the first button. Item 8. The electronic device according to item 8 . The dialog box further includes prompt information, the prompt information being used to educate the user of a security risk in allowing the first application to use the first application permission. The electronic device according to claim 10 . The first application permission includes permission to obtain location information, permission to read/modify address book, permission to read/modify calendar, permission to use camera, permission to use microphone, permission to use Bluetooth, or an electronic device according to any one of claims 7 to 11 , comprising permission to use a voice recognition function. 7. A computer-readable storage medium, the computer-readable storage medium storing instructions, and when the instructions are executed by an electronic device, the electronic device executes the instructions according to any one of claims 1 to 6 . A computer-readable storage medium that allows performing the method described in paragraph 1.

Images