CN113591106A

CN113591106A - Application authorization method and device and terminal equipment

Info

Publication number: CN113591106A
Application number: CN202110739596.7A
Authority: CN
Inventors: 陈栋
Original assignee: Honor Device Co Ltd
Current assignee: Honor Device Co Ltd
Priority date: 2021-06-30
Filing date: 2021-06-30
Publication date: 2021-11-02
Anticipated expiration: 2041-06-30
Also published as: CN113591106B; WO2023273350A1

Abstract

The embodiment of the application provides an application authorization method, an application authorization device and terminal equipment. When a first application requests a first right, the terminal device responds to a first click operation of a user on the first application to obtain an application identifier of the first application and a right name of the first right, wherein the first click operation is used for indicating the terminal device to jump to a second application, and the second application is used for setting the right of the first application; the terminal equipment determines view resources of a first authorization interface corresponding to the application identifier and the authority name, wherein the first authorization interface comprises a plurality of authorization options of a first authority; and the terminal equipment generates a first authorization interface on the upper layer of the interface of the first application according to the view resource. Therefore, when the authority setting of the first application in the second application is needed, the interface of the terminal device does not need to jump to the second application completely, but the first authorization interface is generated directly on the upper layer of the interface of the first application, so that the user completes authorization operation in the first authorization interface, and the authorization interaction process is simplified.

Description

Application authorization method and device and terminal equipment

Technical Field

The present application relates to the field of terminal technologies, and in particular, to an application authorization method, an application authorization device, and a terminal device.

Background

In the terminal device, in order to implement some functions, the application program needs to acquire corresponding rights. For example, if an application is to access and modify a calendar, create a schedule, and so on, it needs to acquire a calendar permission; if the application program is to implement the related functions of Location Based Services (LBS), it needs to acquire the Location service authority; if the application program is to realize the recording function, the microphone authority needs to be acquired.

At present, a terminal device generally manages the authority of an application through an authority management mechanism, and taking a terminal device running an Android system as an example, the authority management mechanism may include an installation-time authority mode and a runtime authority mode. The runtime permission mode means that a user does not need to grant permission to an application program when the application program is installed, but grants permission to the application program when the application program runs. Taking the run-time permission mode as an example, if a certain application requests a certain permission from the terminal device during the run, the terminal device may authorize an interface on the display screen, and the authorization interface may prompt the user with the content of the permission requested by the application and provide the user with a plurality of options, including but not limited to some or all of the following options: always allowed, only allowed in use, denied, asked, allowed once, denied and no longer asked. If the user clicks the option of 'reject and no longer ask', when the terminal device requests the permission again, the authorization interface cannot pop up again, and at this time, the terminal device guides the user to the setting application of the system to set the permission.

Disclosure of Invention

In order to improve user experience when a user sets the authority of an application program, the embodiment of the application provides an application authorization method, an application authorization device and terminal equipment.

In a first aspect, an embodiment of the present application provides an application authorization method, including: when a first application requests a first authority, a terminal device responds to a first click operation of a user on the first application to obtain an application identifier of the first application and an authority name of the first authority, wherein the first click operation is used for indicating the terminal device to jump to a second application, and the second application is used for setting the authority of the first application; the terminal equipment determines view resources of a first authorization interface corresponding to the application identifier and the authority name, wherein the first authorization interface comprises a plurality of authorization options of a first authority; and the terminal equipment generates a first authorization interface on the upper layer of the interface of the first application according to the view resource.

Thus, when a jump is required from a first application to a second application to set the authority of the first application in the second application, the terminal device may not perform a complete jump of the interface (complete jump may be understood as that the interface currently displayed by the terminal is switched from the interface displaying the first application to the interface displaying the second application, and the interface of the first application becomes invisible from visible, after the complete jump occurs, after the user completes some operations on the interface of the second application, the user needs to manually switch the interface of the currently displayed second application to the interface of the first application again to perform subsequent operations, so that the user needs to perform operations back and forth among the interfaces of multiple applications, and the operations are cumbersome and inefficient), but rather, the corresponding view resource of the first authorization interface is directly obtained according to the application identifier of the first application and the requested authority name, and then the first authorization interface is directly generated on the upper layer of the interface of the first application, therefore, the user is prevented from executing complicated authorization operation in the second application, the authorization flow is simplified, and the user experience is improved.

In one implementation, the first application includes a first guide interface, the first guide interface is generated under the condition that the first application previously requests that the first permission is refused, the first guide interface includes a jump option, and the first click operation includes an operation of clicking the jump option by a user. Therefore, under the condition that the first application online requests that the first permission is rejected, the user does not need to execute complicated authorization operation in the second application, the authorization flow is simplified, and the user experience is improved.

In one implementation mode, the first application comprises a second authorization interface, the second authorization interface is generated under the condition that the first permission requested by the first application is not rejected, the second authorization interface comprises a jump option and a plurality of authorization options of the first permission, and the first click operation comprises an operation of clicking the jump option by a user. Therefore, under the condition that the first permission of the online request of the first application is not rejected, the user does not need to execute complicated authorization operation in the second application, the authorization flow is simplified, and the user experience is improved.

In one implementation, the plurality of authorization options in the first authorization interface are partially or completely different from the plurality of authorization options in the second authorization interface. In this way, if the authority to be granted is not in the second authorization interface, the first authorization interface can be opened by clicking the jump option of the second authorization interface, and the authorization is completed in the first authorization interface.

In one implementation, a terminal device generates a first authorization interface at an interface upper layer of a first application according to a view resource, including: the terminal equipment generates a first authorization interface on the upper layer of the interface of the first application in a window form according to the view resources, the height of the window is smaller than that of a display screen of the terminal equipment, and the width of the window is smaller than that of the display screen. In this way, the first authorization interface can be displayed in a small window form on the upper layer of the interface of the first application, and the user is not influenced to view the interface information of the first application while authorizing.

In one implementation manner, the second application includes a first authorization switch, and the obtaining, by the terminal device, the application identifier of the first application and the authority name of the first authority in response to a first click operation of the user includes: the terminal equipment responds to the first click operation of the user and acquires the state of the first authorization switch; when the first authorization switch is in an on state, the terminal equipment acquires an application identifier and an authority name; when the first authorization switch is in a closed state, the terminal equipment jumps from the first application to the second application. In this way, the terminal device allows the user to select whether to jump to the second application to set the authority of the first application.

In one implementation manner, the terminal device includes a rights manager, and the obtaining, by the terminal device, view resources of a first authorization interface corresponding to the application identifier and the rights name includes: the authority manager acquires the application identifier and the authority name from the second application; and the authority manager determines the view resource according to the application identifier and the authority name.

In one implementation, a terminal device generates a first authorization interface at an interface upper layer of a first application according to a view resource, including: the authority manager sends the view resources to a system user interface (system _ UI) process of the terminal equipment; the system _ UI process draws a first authorization interface on an interface upper layer of the first application according to the view resource.

In one implementation, a terminal device generates a first authorization interface at an interface upper layer of a first application according to a view resource, including: the permission manager sends the view resource to a second application; the second application sends the view resource to a system user interface system _ UI process of the terminal equipment; the system _ UI process draws a first authorization interface on an interface upper layer of the first application according to the view resource.

In one implementation, the method further comprises: when the terminal device detects that the user clicks any authorization option in the first authorization interface, the corresponding authorization result is updated to the authority manager, so that when the first application requests the first authority again, the authorization result is obtained from the authority manager.

In one implementation, at least one of: the first permission comprises a positioning permission; the first application at least comprises a map application, a motion track record application and a taxi taking application; the second application comprises a setting application of the terminal equipment operating system; the size of the first authorization interface is smaller than the size of the interface of the first application.

In a second aspect, an embodiment of the present application provides an application authorization apparatus, including: the terminal device comprises a setting module, a first application and a second application, wherein the setting module is used for responding to a first click operation of a user on the first application when the first application requests a first authority, acquiring an application identifier of the first application and an authority name of the first authority, the first click operation is used for indicating the terminal device to jump to the second application, and the second application is used for setting the authority of the first application; the setting module is further used for determining view resources of a first authorization interface corresponding to the application identifier and the authority name, and the first authorization interface comprises a plurality of authorization options of the first authority; and the display module is used for generating a first authorization interface on the upper layer of the interface of the first application according to the view resources.

Therefore, when the first application needs to jump to the second application to set the authority of the first application in the second application, the terminal device can not execute the jump, but directly obtain the view resource of the corresponding first authorization interface according to the application identifier of the first application and the requested authority name, and then directly generate the first authorization interface on the upper layer of the interface of the first application, so that the user is prevented from executing complicated authorization operation in the second application, the authorization flow is simplified, and the user experience is improved.

In one implementation, the display module is configured to generate a first authorization interface on an upper layer of an interface of a first application in a form of a window according to the view resource, where a height of the window is smaller than a height of the display screen, and a width of the window is smaller than a width of the display screen. In this way, the first authorization interface can be displayed in a small window form on the upper layer of the interface of the first application, and the user is not influenced to view the interface information of the first application while authorizing.

In one implementation, the second application includes a first authorization switch; the setting module is used for responding to a first click operation of a user and acquiring the state of a first authorization switch; the setting module is also used for acquiring the application identifier and the authority name when the first authorization switch is in an opening state; the setting module is further used for jumping from the first application to the second application when the first authorization switch is in a closed state. In this way, the terminal device allows the user to select whether to jump to the second application to set the authority of the first application.

In one implementation, the authority control module is used for acquiring the application identifier and the authority name from the setting module; and the authority control module is used for determining the view resources according to the application identifier and the authority name.

In one implementation, the right control module is further configured to send the view resource to the display module.

In one implementation, the permission control module is further configured to send the view resource to the setting module; and the setting module is also used for sending the view resources to the display module.

In one implementation, the permission control module is further configured to update the corresponding authorization result when it is detected that the user clicks any one of the authorization options in the first authorization interface, so that the authorization result is obtained from the permission control module when the first application requests the first permission again.

In a third aspect, embodiments of the present application further provide a computer-readable storage medium, in which instructions are stored, and when the instructions are executed on a computer, the computer is caused to execute the methods of the above aspects and their respective implementation manners.

In a fourth aspect, the present application further provides a computer program product containing instructions, which when run on a computer, causes the computer to perform the method of the above aspects and its various implementations.

In a fifth aspect, the present application further provides a chip system, where the chip system includes a processor, configured to support the terminal device to implement the functions recited in the foregoing aspects, for example, to generate or process information recited in the foregoing method.

Drawings

FIG. 1 is a diagram illustrating a privilege granting scenario of a runtime privilege mode according to an embodiment of the present application;

FIG. 2 is a schematic diagram of a scenario A shown in an embodiment of the present application;

FIG. 3 is a schematic diagram of a scenario B shown in the embodiment of the present application;

fig. 4 is a schematic diagram of a hardware structure of a terminal device provided in an embodiment of the present application;

fig. 5 is a schematic diagram of a user interface of a terminal device corresponding to a scenario a in an application authorization method provided in an embodiment of the present application;

fig. 6 is a flowchart of an application authorization method applied to scenario a according to an embodiment of the present application;

fig. 7 is a schematic view of a user interface of a terminal device corresponding to a scenario B of an application authorization method provided in an embodiment of the present application;

fig. 8 is a flowchart of an application authorization method applied to scenario B according to an embodiment of the present application;

fig. 9 is a schematic view of a user interface of a terminal device corresponding to a scenario B of an application authorization method provided in the embodiment of the present application;

FIG. 10 is a diagram of a widget authorization switch implemented as a global switch according to an embodiment of the present application;

FIG. 11 is a schematic diagram of a widget authorization switch implemented with a non-global switch according to an embodiment of the present application;

FIG. 12 is another flowchart of an application authorization method provided by an embodiment of the present application;

fig. 13 is a schematic diagram illustrating software modules of a terminal device according to an embodiment of the present application;

FIG. 14 is a diagram of an implementation of an application authorization method at a software level according to an embodiment of the present application;

FIG. 15 is another schematic diagram of an implementation of the application authorization method provided by the embodiment of the present application at a software level;

fig. 16 is a schematic structural diagram of an application authorization apparatus according to an embodiment of the present application;

fig. 17 is a schematic structural diagram of another application authorization apparatus provided in an embodiment of the present application;

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

Detailed Description

Generally, a terminal device provides a plurality of different types of permissions for an application program, and the permissions are slightly different for terminal devices with different operating systems. Taking a terminal device running an Android system as an example, part of the permissions which can be provided for the application program include:

a body sensor: sensor information related to vital signs of a user is obtained.

And (3) calendar: the user's default calendar is used.

And call recording: and viewing and changing the call records of the user.

A camera: a user's camera is used to take a picture or record a video.

An address list: a contact list of the user is viewed.

Position information (positioning): and requesting to acquire the position information of the user equipment.

A microphone: and recording the audio.

Telephone: dialing and managing calls.

Physical activity: and acquiring the motion information of the user, such as walking, cycling, step number and the like.

Short message: and checking and sending the short message.

Storage space: photos and other files on the terminal device are acquired.

Files and media: photos, media and other files on the user's terminal device.

As can be seen from the permissions exemplified above, some permissions are closely related to the user privacy, and when the application acquires the permissions, the user privacy related to the permissions is acquired at the same time, for example: if the application program obtains the address list authority, the application program can read and upload the contact list of the user; if the application program obtains the position information authority, the position of the user can be mastered at any time; if the application program obtains the storage space authority, the photos in the user photo album can be read.

At present, a terminal device generally manages the authority of an application program through an authority management mechanism so as to reduce the disclosure of user privacy and improve the security of the device. Also taking a terminal device running an Android system as an example, the authority management mechanism of the terminal device can include an installation-time authority mode and a running-time authority mode.

The permission mode during installation refers to a mode in which a user grants permission to an application program when the application program is installed or updated, when the user installs the application program, the terminal device displays all permissions requested by the application program to the user, the application program starts to be installed after the user agrees authorization, and all permissions requested by the application program are obtained, and the permission mode during installation exists in the system version before the early Android 6.0 and is not in the discussion range of the embodiment of the application, so that the description is not given.

The runtime permission mode means that a user does not need to grant permission to an application program when the application program is installed, but grants permission to the application program when the application program is running. When an application applies for permission (e.g., at application startup or when a user uses a particular function) depends on the application itself.

Fig. 1 is a diagram illustrating a permission granting scenario of a runtime permission mode according to an embodiment of the present application. As shown in fig. 1, during the running of the application program, if the application program requests a certain right (for example, positioning right) from the terminal device, the terminal device may generate an authorization interface 10 as shown in fig. 1 on the display screen, and the authorization interface 10 may prompt the user about the content of the right requested by the application program and provide the user with a plurality of options, including but not limited to some or all of the following options: always allowed, only allowed in use, denied, asked, allowed once, denied and no longer asked.

In an operating system such as Android, IOS, hong meng harmony os, the authorization interface 10 is usually implemented in an N-state notification manner, that is, N authorization options are included, where N is generally 3 or 4. The authorization interface 10 may contain different numbers of authorization options in different operating systems, or different versions of the same operating system, or different custom ROMs. The description of the same authorization option may also differ in different operating systems, or different versions of the same operating system, or different custom ROMs, for example "allow only in use" may be referred to as "allow only during use", "allow once" may be referred to as "just this time", "deny and no longer ask" may be referred to as "always deny".

Next, the user may click 21 any one of the authorization options to complete the setting of the permissions of the application at his or her discretion. For example: when the user clicks 'allow', the authorization interface 10 is closed, the application program obtains the positioning authority, and corresponding functions, such as path planning, navigation and the like, are realized by using the positioning function; when the user clicks "deny," the authorization interface 10 is closed and the application is denied location authorization, at which point the location-based functionality of the application will not be implemented.

It should be added that "always allow" belongs to a high-risk authorization behavior, taking the positioning right as an example, when a user "always allows" an application program to acquire the positioning right, it means that the application program can acquire the location information of the user without limitation both during foreground operation and during background residence, and a risk of privacy disclosure is brought to the user. Therefore, in order to protect the privacy of the user and avoid the user from granting the application "always allowed" to obtain a certain right due to misoperation and the like, in the Android11 and subsequent versions, the authorization interface 10 has no longer provided an "always allowed" option, and if the user wants the application to be able to "always allowed" to obtain a certain right, the user needs to grant in the setting of the system.

In some scenarios (hereinafter scenario a), after the user refuses to grant the application a certain right, the terminal device will not generate the authorization interface 10 again if the application continues to request the right, considering the user experience. In this case, the application may generate a guidance dialog to guide the user to jump from within the application to an application information page of the terminal device, which is provided by a setup application of the system of the terminal device, to reset the rights of the application in the application information page, and then back to the application.

Fig. 2 is a schematic diagram of a scenario a shown in the embodiment of the present application.

As shown in fig. 2, taking an application requesting to obtain positioning right as an example, in case the application has been denied the positioning right, the application may generate a guidance dialog 30 as shown in a in fig. 2 at startup, the guidance dialog 30 may include a go to "set" button 31, and explanatory information 32 explaining to the user why the positioning right is requested and how the positioning right is granted in the application information page. When the user clicks 33 the go to "settings" button 31, the application starts the settings application of the terminal device system and jumps from the current interface of the application to the interface of the settings application, in particular to the application information page as shown in b in fig. 2. The application information page is a sub-interface for setting an application, and the application information page name may be different in different operating systems, or different versions of the same operating system, or different custom ROMs, and may also be referred to as an application detail page, for example. Generally, each application installed in the terminal device has its corresponding application information page in the setup application. For any application program, the application information page of the application program can include information such as storage space occupation, flow consumption, electricity consumption and the like, permission related options and other setting options, so that a user can check the permission state of the application program and set the permission of the application program in the application information page.

Next, the user can click 34 on the application information page to access the rights management interface of the application program as shown in c in fig. 2, then click 35 on the "locate" option in the rights management interface to open the authorization interface 40 for locating rights, finally click 36 on any one of the multiple authorization options provided by the authorization interface 40 for locating rights to complete the rights setting, and finally manually switch back to the application program interface.

In other scenarios (hereinafter referred to as scenario B),

the authorization interface 10 of fig. 1 may not contain options corresponding to the rights required by the application. In this case, the application may also guide the user to jump from within the application to the application information page of the terminal device, grant the rights required by the application in the application information page, and then return to the application.

Fig. 3 is a schematic diagram of a scenario B shown in the embodiment of the present application.

As shown in fig. 3, taking an example that a map application requests to obtain a positioning right, the map application needs to obtain location information of a user in real time when implementing a navigation function, so that the map application wants to obtain a "always allowed" location right, so as to obtain the location information of the user when a terminal device is turned off or the map application is located in a system background. However, the terminal device may not include an option of "always allowed" in the authorization interface 10 for security and the like. In this case, the authorization interface 10 may include a "allow in" button 37, and when the user clicks 38 the "allow in" button 37, the application jumps to the application information page of the terminal device, and the user manually switches back to the application interface after the application information page completes the permission setting.

As can be seen from fig. 2 and 3, in a case that the application has been denied a certain permission, or in a case that the authorization interface 10 does not include a permission requested by the application, the application may jump to an application information page of the terminal device, so that the user performs an operation in the application information page to grant the permission, however, this process requires the user to perform a plurality of click operations and application switching operations, which is cumbersome and affects user experience.

In order to avoid interface jump in the process of granting the authority to the application program by the user, simplify user operation, and improve user experience, the embodiment of the application provides an application authorization method.

The application authorization method of the embodiment of the application can be applied to the terminal equipment. The terminal devices include, but are not limited to, mobile phones, tablet computers, personal computers, workstation devices, large-screen devices (e.g., smart screens, smart televisions, etc.), wearable devices (e.g., smart bracelets, smart watches), handheld game machines, home game machines, virtual reality devices, augmented reality devices, mixed reality devices, etc., vehicle-mounted smart terminals, etc.

Fig. 4 is a schematic diagram of a hardware structure of a terminal device according to an embodiment of the present application. As shown in fig. 4, the terminal device 100 may include a processor 110, a memory 120, a Universal Serial Bus (USB) interface 130, a radio frequency circuit 140, a mobile communication module 150, a wireless communication module 160, a camera 170, a display 180, a touch sensor 190, an air pressure sensor 210, keys 220, and the like.

Processor 110 may include one or more processing units, such as: the processor 110 may include an Application Processor (AP), a modem processor, a Graphics Processing Unit (GPU), an Image Signal Processor (ISP), a video codec, a Digital Signal Processor (DSP), a baseband processor, and/or a neural-Network Processing Unit (NPU), among others. The different processing units may be independent devices, or may be integrated into one or more processors, for example, a system on a chip (SoC). A memory may also be provided in processor 110 for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. The memory may hold instructions or data that have just been used or recycled by the processor 110.

In some embodiments, processor 110 may include one or more interfaces. The interface may include an integrated circuit (I2C) interface, an integrated circuit built-in audio (I2S) interface, a Pulse Code Modulation (PCM) interface, a universal asynchronous receiver/transmitter (UART) interface, a Mobile Industry Processor Interface (MIPI), a general-purpose input/output (GPIO) interface, a Subscriber Identity Module (SIM) interface, and/or a Universal Serial Bus (USB) interface, etc.

The memory 120 may be used to store computer-executable program code, which includes instructions. The memory 120 may include a program storage area and a data storage area. The storage program area may store an operating system, an application program required by at least one function (such as a sound playing function, an image playing function, and the like), and the like. The storage data area may store data (such as audio data, a phonebook, etc.) created during use of the terminal device 100, and the like. Further, the memory 120 may include one or more memory units, for example, may include a volatile memory (volatile memory), such as: dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), and the like; non-volatile memory (NVM) may also be included, such as: read-only memory (ROM), flash memory (flash memory), and the like. The processor 110 executes various functional applications of the terminal device 100 and data processing by executing instructions stored in the memory 120 and/or instructions stored in a memory provided in the processor.

It should be added that the operating system referred to in the embodiments of the present application includes, but is not limited to, an Android operating system, an IOS operating system, an iPad OS, a dammony operating system (harmony OS), a Windows operating system, a Linux operating system, a MAC OS operating system, an embedded system, and the like.

The wireless communication function of the terminal device 100 may be implemented by the radio frequency circuit 140, the mobile communication module 150, the wireless communication module 160, a modem processor, a baseband processor, and the like.

The radio frequency circuit 140 may include at least one antenna 141 for transmitting and receiving electromagnetic wave signals. Each antenna in terminal device 100 may be used to cover a single or multiple communication bands. In some embodiments, the antenna may be used in conjunction with a tuning switch.

The mobile communication module 150 may provide a solution for an application program to wireless communication on the terminal device 100 including 2G/3G/4G/5G, etc. The mobile communication module 150 may include at least one filter, a switch, a power amplifier, a Low Noise Amplifier (LNA), and the like. The mobile communication module 150 may receive electromagnetic waves from the antenna 141, filter, amplify, etc. the received electromagnetic waves, and transmit the electromagnetic waves to the modem processor for demodulation. The mobile communication module 150 may also amplify the signal modulated by the modem processor, and convert the signal into electromagnetic wave through the antenna 141 to radiate the electromagnetic wave. In some embodiments, at least some of the functional modules of the mobile communication module 150 may be disposed in the processor 110. In some embodiments, at least some of the functional modules of the mobile communication module 150 may be disposed in the same device as at least some of the modules of the processor 110.

The modem processor may include a modulator and a demodulator. The modulator is used for modulating a low-frequency baseband signal to be transmitted into a medium-high frequency signal. The demodulator is used for demodulating the received electromagnetic wave signal into a low-frequency baseband signal. The demodulator then passes the demodulated low frequency baseband signal to a baseband processor for processing. The low frequency baseband signal is processed by the baseband processor and then transferred to the application processor. The application processor outputs sound signals through audio devices (including but not limited to speakers, headphones, etc.) or displays images or video through the display screen 180. In some embodiments, the modem processor may be a stand-alone device. In other embodiments, the modem processor may be provided in the same device as the mobile communication module 150 or other functional modules, independent of the processor 110.

The wireless communication module 160 may include a wireless fidelity (Wi-Fi) module, a Bluetooth (BT) module, a GNSS module, a Near Field Communication (NFC) module, an Infrared (IR) module, and the like. The wireless communication module 160 may be one or more devices integrating at least one of the modules described above. The wireless communication module 160 receives electromagnetic waves via the antenna 141, performs frequency modulation and filtering processing on electromagnetic wave signals, and transmits the processed signals to the processor 110. The wireless communication module 160 can also receive a signal to be transmitted from the processor 110, frequency modulate it, amplify it, and convert it into electromagnetic waves via the antenna 141 to radiate it.

In the embodiment of the present application, the wireless communication function of the terminal device 100 may include, for example, global system for mobile communications (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), time division code division multiple access (time-division code division multiple access, TD-SCDMA), Long Term Evolution (LTE), new radio interface (5G NR), GNSS, WLAN, FM, BT, and/or NFC IR. GNSS may include Global Positioning System (GPS), global navigation satellite system (GLONASS), beidou satellite navigation system (BDS), quasi-zenith satellite system (QZSS), and/or Satellite Based Augmentation System (SBAS).

The camera 170 is used to capture still images or video. The camera 170 includes a lens and a photosensitive element, and an object generates an optical image through the lens and is projected onto the photosensitive element. The photosensitive element may be a Charge Coupled Device (CCD) or a complementary metal-oxide-semiconductor (CMOS) phototransistor. The light sensing element converts the optical signal into an electrical signal, which is then passed to the ISP where it is converted into a digital image signal. And the ISP outputs the digital image signal to the DSP for processing. The DSP converts the digital image signals into image signals in standard RGB, YUV, RYYB and other formats. In some embodiments, the terminal device 100 may include 1 or N cameras 170, N being a positive integer greater than 1.

The NPU is a neural-network (NN) computing processor that processes input information quickly by using a biological neural network structure, for example, by using a transfer mode between neurons of a human brain, and can also learn by itself continuously. The NPU can implement applications such as intelligent recognition of the terminal device 100, for example: image recognition, face recognition, speech recognition, text understanding, and the like.

The display screen 180 is used to display images, videos, and the like. The display screen 180 includes a display panel. The display panel may be a Liquid Crystal Display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (AMOLED) or an active-matrix organic light-emitting diode (active-matrix organic light-emitting diode), a flexible light-emitting diode (FLED), a MiniLED, a Micro led, a Micro-OLED, a quantum dot light-emitting diode (QLED), or the like. In some embodiments, the terminal device 100 may include 1 or N display screens 180, N being a positive integer greater than 1.

The touch sensor 190 is also referred to as a "touch device". The touch sensor 190 may be disposed on the display screen 180, and the touch sensor 190 and the display screen 180 form a touch screen, which is also called a "touch screen". The touch sensor 190 is used to detect a touch operation applied thereto or nearby. The touch sensor can pass the detected touch operation to an application processor to determine the touch event type. Visual output associated with the touch operation may be provided through the display screen 180. In other embodiments, the touch sensor 190 may be disposed on the surface of the terminal device 100 at a different position than the display screen 180.

The air pressure sensor 210 is used to measure air pressure. In some embodiments, the terminal device 100 calculates an altitude from the barometric pressure measured by the barometric pressure sensor 210 to assist in positioning and navigation.

The keys 220 include a power-on key, a volume key, and the like. The keys 220 may be mechanical keys. Or may be touch keys. The terminal device 100 may receive a key input, and generate a key signal input related to user setting and function control of the terminal device 100.

It is to be understood that the illustrated structure of the embodiment of the present application does not constitute a specific limitation to the terminal device 100. In other embodiments of the present application, a terminal device may include more or fewer components than shown, or some components may be combined, some components may be split, or a different arrangement of components may be used. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

The following provides an exemplary description of the method steps of the application authorization method provided in the embodiments of the present application.

The application authorization method provided by the embodiment of the application can be applied to the scene A.

In scenario a, the application may request certain rights from the terminal device during runtime. Applications herein include, but are not limited to during runtime: when the application program is started, the application program is started and then runs in the foreground, and the application program is started and then runs in the background. In the Android system, an application program can apply for permission to an operating system of a terminal device by calling requestPermissions (). In the following embodiments, for convenience of description, an application program requesting a right is referred to as a target application.

Taking the target application requesting the positioning authority as an example:

when finding that the target application has previously applied for the permission, but is permanently rejected by the user (for example, the user has previously selected "permanently reject" or "reject and no longer ask" in the authorization interface 10 shown in fig. 1), the terminal device may notify the target application of the result that the permission requested by the target application is rejected, in the Android system, the terminal device may notify the target application of the result that the permission requested by the target application is rejected by calling a shouldshowrequestpermission ratio () method, and in addition, the terminal device may not display the authorization interface 10 shown in a in fig. 1 on a display screen.

Fig. 5 is a schematic view of a user interface of a terminal device corresponding to a scenario a in an application authorization method provided in an embodiment of the present application.

Fig. 6 is a flowchart of an application authorization method applied to scenario a according to an embodiment of the present application.

After learning that the target application requests a certain right to be rejected, the target application may generate a guidance interface 30 as shown in a in fig. 5 to guide the user to grant the right required by the target application in the setup application of the terminal device system.

If the user wants to set the rights of the target application in the setup application of the terminal device system, a click 33 operation may be performed on a go to "setup" button 31 in the guidance interface 30. Generally, when detecting that the user performs a click 33 operation on the go to "setup" button 31, the terminal device jumps from the current target application interface to the setup application of the terminal device system in response to the click operation, for example, jumps to an application information page of the setup application, so that the user completes the permission grant in the application information page by multiple operations. However, in the embodiment of the present application, the terminal device does not jump to the setting application of the terminal device system when detecting that the user performs the click 33 operation on the go to "setting" button 31, but performs the following steps S101 to S103 as shown in fig. 6:

step S101, the terminal device responds to the click operation of the user on the button turning to the 'setting', and obtains the application identifier of the target application and the authority name of the target application request.

The application identifier of the target application may be, for example, a Package Name (Package Name) and an application ID of the target application, or may be other information for determining a unique identity of the target application, which is not limited in this embodiment of the present application.

For example, in an Android terminal device, the package name of the target application may be: xxx, where xxx may be information used to indicate the identity of application developers and application types, names, etc. For example, the package name for the "map" application may be: com. In the IOS terminal, the packet name may be a string of numbers, with different numbers for different applications.

The authority name may include, for example, an authority name, such as: location information, address book, body sensor, storage space, etc. The authority name may include the name of an authority if the target application applies for an authority, and the authority name may include the names of multiple authorities if the target application applies for multiple authorities.

Step S102, the terminal device determines the view resource of the first authorization interface corresponding to the application identifier and the authority name.

In specific implementation, after detecting that a user clicks a "set" button in a guidance interface, the terminal device does not jump to an application information page, but searches a setting application of an operating system in the background according to an obtained application identifier and an authority name to find view resources of a first authorization interface corresponding to the authority requested by a target application, where the view resources include text resources, image resources, style resources, and the like required for generating the first authorization interface. It should be added that the whole process of the terminal device executing step S102 is not shown in the display screen, and the user does not perceive the process.

Illustratively, when the package name acquired by the terminal device is com.horor.map (the package name of the "map" application) and the requested permission is the positioning permission, the terminal device may retrieve an application information page of the "map" application in a setting application of the system according to the package name com.hor.map, and then further retrieve an authorization interface for positioning the permission in the application information page of the "map" application.

And step S103, the terminal equipment generates the first authorization interface on the upper layer of the interface of the target application according to the view resource.

As shown in b in fig. 5, in an implementation manner, the terminal device may draw a first authorization interface according to text resources, image resources, style resources, and the like included in the view resources, display the first authorization interface 50 in the form of a window (also referred to as a small window) on the display screen, and display the small window on the upper layer of the interface 60 of the target application. The height of the window is smaller than the height of the display screen of the terminal device, and the width of the window is smaller than the width of the display screen, so that the user can still see part of the content of the interface 60 of the target application after the first authorization interface 50 is displayed.

In the embodiment of the present application, the first authorization interface 50 may be understood as displaying the authorization interface 40 shown in d in fig. 2 directly on the upper layer of the interface 60 of the target application, and therefore the style and content of the first authorization interface 50 and the authorization interface 40 may be the same or different. Specifically, the method comprises the following steps: if the terminal device generates the first authorization interface 50 directly in the style and content of the view resource after acquiring the view resource of the first authorization interface 50, the style and content of the first authorization interface 50 are the same as those of the authorization interface 40, and if the terminal device optimally modifies the style and content of the view resource according to the current theme setting, user setting, and the like of the terminal device after acquiring the view resource of the first authorization interface 50, the style and content of the first authorization interface 50 may be different from those of the authorization interface 40.

As shown in b of FIG. 5, in one implementation, the first authorization interface 50 may include a description of the target application requesting permission and provide a plurality of authorization options for the user to request permission for selection by the user. Taking the first authorization interface 50 of the positioning authority of the "map" application as an example, the first authorization interface 50 may include an application name 51 of a "map", an icon 52 of the "map" application, an authority name 53 of the "map" application request of "positioning", and a usage description 54 of the "positioning" authority (for example, providing peripheral information, precise road conditions and navigation services for you), and the like. By way of example, the first authorization interface 50 provides the user with four authorization options: deny, ask, allow only in use, always allow.

After the generation of the first authorization interface 50 in the form of a window, the user may click 55 any one of the authorization options to complete the rights setting at his or her discretion. In a specific implementation, when detecting that the user clicks 55 any one of the options in the first authorization interface 50, the terminal device closes the first authorization interface 50, stores an authorization result corresponding to the user click 55 in an authority manager of the system, and restarts the target application. Taking the positioning authority of the map application as an example:

when the user clicks the "always allowed" option in the first authorization interface 50, the terminal device may close the first authorization interface 50, update the positioning authority of the "map" application to "always allowed", and restart the "map" application. In this way, the "map" application can request the result of "always permitted" when requesting the positioning right again after the restart, so that various functions based on the location information can be performed.

When the user clicks the "deny" option in the first authorization interface 50, the terminal device may close the first authorization interface 50, maintain the positioning authority for "map" as "deny," and restart the "map" application. In this way, when the "map" application requests the positioning right again after the restart, the result of "reject" can be requested, so that functions related to the positioning right not being acquired can be executed, for example: prompting the user for failed positioning, closing the target application, regenerating the guide interface, and the like.

It should be added that, in step S103 in the embodiment of the present application, the terminal device may display the first authorization interface 50 at any position of the display screen, which is not limited in the embodiment of the present application.

In one implementation, the first authorization interface 50 may be displayed in a center area of the display screen so as not to obscure the name of the target application, considering that the target application will typically display the name of the target application below the screen-open interface when the target application is started.

In an implementation manner, the first authorization interface 50 may be displayed at the bottom of the display screen, and this implementation manner may be applied to a terminal device such as a smart phone that can be held with a single hand, so that a user can perform a single-handed operation on the first authorization interface 50 when holding the terminal device with a single hand.

In one implementation, the first authorization interface 50 may be displayed on the top of the display screen, so that the user can hold the terminal device with one hand and operate the first authorization interface 50 with the other hand, thereby realizing two-handed operation.

In one implementation, when the terminal device is a folding screen mobile phone or other device with a wider display screen, the first authorization interface 50 may be displayed on a side surface of the display screen to avoid a bending region of the display screen.

According to the technical scheme, under the condition that a certain permission requested by a target application is permanently rejected by a user, if the operation executed by the user in the target application indicates that the user wants to jump to the setting application of the terminal device system for permission setting, the terminal device can acquire the application identifier of the target application and the permission name of the requested permission, a first authorization interface corresponding to the application identifier and the permission name is directly generated in an interface mall of the target application, so that the user can directly complete permission setting on the target application in the first authorization interface without jumping to the setting application or switching between different applications, the user operation is simplified, and the user experience is improved.

The application authorization method provided by the embodiment of the application can also be applied to a scene B.

Fig. 7 is a schematic view of a user interface of a terminal device corresponding to a scenario B of an application authorization method provided in the embodiment of the present application.

Fig. 8 is a flowchart of an application authorization method applied to scenario B according to an embodiment of the present application.

In scenario B, the target application may request the terminal device to obtain a certain right during runtime. Target applications herein include, but are not limited to during runtime: when the target application is started, the target application is started and then runs in the foreground, and the target application is started and then runs in the background. In the Android system, the target application can apply for the authority to the operating system of the terminal device by calling a requestPermissions () method. Taking the target application requesting the positioning authority as an example:

when the terminal device finds that the target application does not have the right and the user has not previously rejected the target application from acquiring the right, a second authorization interface 10 as shown in fig. 7 may be displayed on the display screen so that the user can perform an authorization operation. For a certain right, the terminal device may provide various authorization options for the user to select, for example: always allowed, only allowed in use, denied, asked, allowed once, always denied, etc. However, based on system settings or from a security perspective, the terminal device will only list some of the options in the second authorization interface 10, resulting in some options not being displayed in the second authorization interface 10.

As shown in a of fig. 7, the terminal device may display some prompt information in the second authorization interface 10 to prompt the user to select other authorization options in the setup application of the terminal device system and provide the user with a button 37 for jumping to the setup application. For example: the second authorization interface 10 contains three authorization options (i.e., tri-state notifications) of "allow only this time during use", "deny only", and "allow" respectively. Considering that some application programs need to acquire the position information (corresponding to the "always allowed" option) of the user in the background to complete functions such as background navigation and recording the motion trajectory of the user, the second authorization interface 10 further includes the following prompt information: "the application may want to acquire your location information at any time (even though you are not using the application)", and also includes a jump button 37: "allowed in" settings ".

If the user wants to set the rights of the target application in the setting application of the terminal device system, a click 38 operation may be performed on the "allow in settings" button 37 in the second authorization interface 10. Generally, when detecting that the user performs a click 38 operation on the "allow in" button 37, the terminal device jumps from the current target application interface to the setting application of the terminal device system in response to the click operation, for example, jumps to an application information page of the setting application, so that the user completes the permission grant in the application information page by multiple operations. However, in the embodiment of the present application, upon detecting that the click 38 operation is performed on the "allow in" button 37, the terminal device does not jump to the setting application of the terminal device system, but performs the lean-press steps S201 to S203 as shown in fig. 8.

In step S201, the terminal device obtains the application identifier of the target application and the authority name requested by the target application in response to the click operation of the user on the "allow in" button.

The application identifier of the target application may be, for example, a Package Name (Package Name) and an application ID of the target application, or may be other information for determining a unique identity of the target application, which is not limited in this embodiment of the present application. The rights name may include, for example, a rights name such as: location information, address book, body sensor, storage space, etc.

For other details not specifically developed in step S201, please refer to step S101 in the embodiment of the present application, which is not described herein again.

Step S202, the terminal device determines the view resource of the first authorization interface corresponding to the application identifier and the authority name.

Step S202 is similar to step S102, and in a specific implementation, after detecting that the user clicks the "allow in setting" button in the notification interface, the terminal device does not jump to an interface of the setting application, but searches the setting application of the operating system according to the obtained application identifier and the authority name in the background to find a view resource of the first authorization interface corresponding to the authority requested by the target application, where the view resource includes a text resource, an image resource, a style resource, and the like required for generating the first authorization interface. The whole process of the terminal device executing step S202 is not reflected in the display screen, and the user does not perceive the process.

For other details not specifically developed in step S202, please refer to step S102 in the embodiment of the present application for implementation, and details are not described here.

Step S203, the terminal device generates the first authorization interface on the upper layer of the interface of the target application according to the view resource.

As shown in b of fig. 7, in one implementation, a first authorization interface is drawn according to text resources, image resources, style resources and the like contained in view resources, the first authorization interface 50 is displayed in a display screen in the form of a window (also called a small window), and the small window is displayed on the upper layer of the interface 60 of the target application. The height of the window is smaller than the height of the display screen of the terminal device, and the width of the window is smaller than the width of the display screen, so that the user can still see part of the content of the interface 60 of the target application after the first authorization interface 50 is displayed.

Similar to step S103, further as shown in fig. 5 b, the first authorization interface 50 may include a description of the target application requesting the rights and provide a plurality of authorization options for the user to request the rights for selection by the user. Taking the first authorization interface 50 of the positioning authority of the "map" application as an example, the first authorization interface 50 may include an application name 51 of a "map", an icon 52 of the "map" application, an authority name 53 of the "map" application request of "positioning", and a usage description 54 of the "positioning" authority (for example, providing peripheral information, precise road conditions and navigation services for you), and the like. By way of example, the first authorization interface 50 provides the user with four authorization options: deny, ask, allow only in use, always allow.

In one implementation, the first authorization interface 50 may display more options than the second authorization interface 10. As an example, as shown in b in fig. 8, when three options of "allow only during use", "only this time" and "reject" are included in the second authorization interface 10, the first authorization interface 50 may add one or more options on the basis, for example, add an "always allow" option, further add an "reject once" option, and so on.

In one implementation, the first authorization interface 50 and the second authorization interface 10 contain the same number of options, but the first authorization interface 50 may contain different options than the second authorization interface 10, where different means that the options in the first authorization interface 50 and the second authorization interface 10 are partially or completely different. As an example, as shown in fig. 9, when the second authorization interface 10 includes three options of "allow only during use", "only this time", and "reject", the first authorization interface 50 may also include: "allowed only during use", "always allowed", "rejected". In this way, the user may additionally select the "always allowed" option at the first authorization interface 50, as compared to the second authorization interface 10, so that the target application obtains sufficient rights for implementing functions such as background navigation, recording the user's motion trajectory, and the like.

After the generation of the first authorization interface 50 in the form of a small window, the user may click 55 any one of the options to complete the rights setting at his or her discretion. In a specific implementation, when detecting that the user clicks 55 any one of the options in the first authorization interface 50, the terminal device closes the first authorization interface 50, stores an authorization result corresponding to the user click 55 in an authority manager of the system, and restarts the target application.

For other contents not specifically developed in step S203, please refer to step S203 in this embodiment of the application for implementation, which is not described herein again.

According to the technical scheme, under the condition that a certain authority requested by a target application is not rejected before, if the operation executed by a user in the target application indicates that the user wants to jump to the setting application of the terminal equipment system for authority setting, the terminal equipment can acquire the application identifier of the target application and the authority name of the requested authority, a first authorization interface corresponding to the application identifier and the authority name is directly generated in an interface mall of the target application, so that the user can directly complete the authority setting of the target application in the first authorization interface without jumping to the setting application or switching among different applications, the user operation is simplified, and the user experience is improved.

In one embodiment, the terminal device may provide a widget authorization switch in a setup application of its system, the widget authorization switch indicating whether generation of the first authorization interface in the form of a widget (window) is allowed in scene a and scene B.

Taking scene a as an example, when the small window authorization switch is in an open state, if the terminal device detects that the user clicks a turn-to-set button in the guidance interface, the terminal device does not jump to the application information page, but executes step S101 to step S103; when the small window authorization switch is in a closed state, if the terminal device detects that the user clicks a turn-to-setting button in the guide interface, the steps S101-S103 are not executed, but the terminal device jumps to an application information page, the user finds the authority setting entry of the target application in the application information page by himself, completes corresponding authorization operation, and then the terminal device is manually switched back to the target application interface.

Taking scene B as an example, when the small window authorization switch is in the on state, if the terminal device detects that the user clicks the permission button in "setup" in the second authorization interface, the terminal device does not jump to the application information page, but performs step S201 to step S203; when the small window authorization switch is in a closed state, if the terminal device detects that the user clicks an allow button in 'setup' in the second authorization interface, the step S201 to the step S203 are not executed, but the terminal device jumps to an application information page, the user finds the authority setting entry of the target application in the application information page by himself, completes the corresponding authorization operation, and then manually switches back to the target application interface.

In one implementation, the widget authorization switch may be a global switch.

Fig. 10 is a schematic diagram of a widget authorization switch implemented in a global switch according to an embodiment of the present application. As shown in FIG. 10, the widget authorization switch 71 may be located in the primary interface or some secondary interface of the setup application, such as in the rights management interface 72. The user can turn on or off the widget authorization switch 71 by clicking 73, when the widget authorization switch 71 is turned on, the terminal device allows the first authorization interface to be generated in the form of a widget for all target applications, and when the widget authorization switch 71 is turned off, the terminal device does not allow the first authorization interface to be generated in the form of a widget for all target applications.

In one implementation, the widget authorization switch may be a non-global switch.

Fig. 11 is a schematic diagram of a widget authorization switch implemented with a non-global switch according to an embodiment of the present application. As shown in fig. 11, the widget authorization switches 71 may be located in application information pages 74, the application information page 74 of each target application may include one widget authorization switch 71, and each widget authorization switch 71 is only active for its corresponding one target application. The user can open or close the small window authorization switch 71 of a certain target application in a clicking mode, when the small window authorization switch 71 is opened, the terminal device allows the first authorization interface to be generated in the form of a small window for the certain target application, and when the small window authorization switch is closed, the terminal device does not allow the first authorization interface to be generated in the form of a small window for the certain target application.

In an implementation manner, when the terminal device provides a widget authorization switch, the application authorization method according to the embodiment of the present application may further include a process of determining whether widget authorization is allowed.

Fig. 12 is another flowchart of an application authorization method provided in an embodiment of the present application. As shown in fig. 12, taking a target application start scenario as an example, the application authorization method including a determination process of whether to allow widget authorization may include the following steps:

step S301, when the target application is started, the terminal device judges whether to jump to an application information page.

In a specific implementation, when a terminal device requests that a certain right is rejected, a guidance interface as shown in fig. 5 a may be generated. If the terminal device allows the direct jump from the target application to the application information page and detects that the user clicks a 'set' button in the guide interface, determining that the jump to the application information page is required, and at this time, the terminal device executes the step S302; if the terminal device does not allow a jump directly from the target application to the application information page, or detects that the user has clicked on a "cancel" button in the guidance interface, the method flow ends.

Step S302, the terminal device judges whether the target application allows the small window authorization.

In a specific implementation, the terminal device may determine whether widget authorization is allowed for the target application according to a state of a global widget authorization switch or a non-global widget authorization switch of the target application. If the small window authorization switch is turned on, it indicates that the small window authorization is allowed, and the terminal device performs steps S303 to S304. If the widget authorization switch is turned off, it indicates that the widget authorization is not allowed, and the terminal device performs step S305.

Step S303, the terminal device obtains a first authorization interface corresponding to the authority requested by the target application.

In specific implementation, the terminal device may obtain an application identifier of the target application and a requested authority name, and then retrieve the application information page of the target application according to the obtained application identifier and the acquired authority name, so as to find a first authorization interface corresponding to the application identifier and the authority name. The whole process of the terminal device executing step S303 is not reflected in the display screen, and the user does not perceive this process. For other contents not specifically developed in step S303, please refer to step S101 to step S102 in the embodiments of the present application for implementation, which are not described herein again.

And step S304, the terminal device displays the first authorization interface in a small window form on a display screen.

Step S304 may be implemented by specifically referring to step S103 in the embodiment of the present application, and details are not described here.

And when the user clicks any option in the authorization interface, the terminal device responds to the clicking operation of the user, refreshes the interface to close the small window, meanwhile updates the authorization result corresponding to the clicking operation of the user in the authority configuration of the system, and restarts the target application.

In step S305, the terminal device jumps to the application information page.

The embodiments provided in the present application introduce various aspects of the application authorization method provided in the present application. It will be appreciated that the terminal device, in order to implement the above-described functions, may contain corresponding software modules for performing the respective functions.

Fig. 13 is a schematic diagram illustrating software modules of a terminal device according to an embodiment of the present application. As shown in fig. 13, in the Android system, software modules involved in executing the application authorization method according to the embodiment of the present application may include at least a setting application of an operating system, a permission controller, a system user interface host process system _ UI, and a target application that is requesting permission.

The difference is that the set application, the permission controller and the system _ UI belong to system-level application of the Android system, the permission is high, the target application belongs to non-system-level application, and the permission is low. In addition, the Android system further comprises an application framework layer, a system operation library layer, a hardware abstraction layer and a Linux kernel layer, and the hierarchical structure belongs to a conventional structure of the Android system, which is not limited in the embodiment of the application.

Fig. 14 is a schematic diagram of an implementation of the application authorization method provided in the embodiment of the present application at a software level.

As shown in fig. 14, in an implementation manner, the application authorization method provided in the embodiment of the present application is implemented at a software level and includes at least the following steps:

step S401, when the application is started from the target application, the application identifier of the target application and the authority name of the request are obtained.

As shown in fig. 2 and fig. 3, in the embodiment of the present application, the setting application starting from inside the target application may include the following two scenarios: in scenario a, when a user clicks a go to "setup" button in a guidance interface, a setup application may be started from within a target application; in scenario B, the setup application may launch from within the target application when the user clicks the "allow in setup" button in the second authorization interface.

It should be added here that, after the setting application is started by the target application, the terminal device will continue to stay at the user interface of the target application, and will not jump from the user interface of the target application to the user interface of the setting application. The setting application execution step S402 and step S403 are both performed in the background.

Step S402, the setting application sends the application identifier of the target application and the requested authority name to the authority controller.

Step S403, the permission controller obtains the view resource of the first authorization interface according to the application identifier of the target application and the permission name of the request, and sends the view resource to the system _ UI.

And S404, drawing the authorization interface in a small window form on the upper layer of the target application by the system _ UI according to the view resource, and popping up and displaying the authorization interface in the display screen in the small window form.

Step S405, when the setting application detects that the user clicks any option in the authorization interface, the corresponding authorization result is updated to the authority controller.

In this way, when the terminal device application requests the authority again after restarting, the updated authorization result can be obtained from the authority controller, so that the corresponding function based on the authority can be executed according to the updated authorization result.

In step S406, the system _ UI refreshes the user interface to close the widget.

Fig. 15 is another schematic diagram of an implementation of the application authorization method provided in the embodiment of the present application at a software level.

As shown in fig. 15, in an implementation manner, the application authorization method provided in the embodiment of the present application is implemented at a software level and includes at least the following steps:

step S501, when the application is started from the target application, the application identifier of the target application and the authority name of the request are obtained.

Step S501 is the same as step S401, and is not described here again.

Step S502, the application identification of the target application and the requested authority name are sent to the authority controller.

Step S503, the authority controller obtains the view resource of the first authorization interface according to the application identifier of the target application and the authority name of the request, and sends the view resource to the setting application.

Step S504, the setting application sends the authorization interface to the system _ UI.

It should be noted that in the implementation shown in fig. 14, the permission controller directly sends the view resource to the system _ UI after acquiring the view resource of the first authorization interface, while in the implementation shown in fig. 15, the permission controller sends the view resource to the setting application after acquiring the view resource of the first authorization interface, and the setting application sends the view resource to the system _ UI. It can be seen that how the view resource is sent to the system _ UI may be implemented in different ways, which is not limited in this embodiment of the present application.

And step S505, drawing the authorization interface in a small window form by the system _ UI on the upper layer of the target application, and popping up and displaying the authorization interface in the display screen in the small window form.

Step S506, when the setting application detects that the user clicks any option in the authorization interface, the corresponding authorization result is updated to the authority configuration of the target application.

In step S507, the system _ UI refreshes the user interface to close the widget.

The embodiments provided in the present application introduce various aspects of the application authorization method provided in the present application. It is understood that the terminal device includes hardware structures and/or software modules for performing the respective functions in order to implement the functions. Those of skill in the art would readily appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as hardware or combinations of hardware and computer software. Whether a function is performed as hardware or computer software drives hardware depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

Fig. 16 is a schematic structural diagram of an application authorization apparatus according to an embodiment of the present application. In one embodiment, the terminal device may implement the corresponding functions by the hardware means shown in fig. 16. As shown in fig. 16, the application authorization apparatus may include: a touch screen 601, a memory 602, and a processor 603.

In one embodiment, touch screen 601 can include a display screen for displaying images and a touch sensor that can communicate detected touch operations to an application processor to determine a touch event type and provide visual output related to the touch operations through the display screen. The processor 603 may include one or more processing units, such as: the processor 603 may include an applications processor, modem processor, graphics processor, image signal processor, controller, video codec, digital signal processor, baseband processor, and/or neural network processor, among others. The different processing units may be separate devices or may be integrated into one or more processors. A memory 602 is coupled to the processor 603 for storing various software programs and/or sets of instructions, and the memory 602 may include volatile memory and/or non-volatile memory.

The software programs and/or sets of instructions in the memory 602, when executed by the processor 603, cause the terminal device to carry out the following method steps: when a first application requests a first authority, responding to a first click operation of a user on the first application, and acquiring an application identifier of the first application and an authority name of the first authority, wherein the first click operation is used for indicating to jump to a second application, and the second application is used for setting the authority of the first application; determining view resources of a first authorization interface corresponding to the application identifier and the authority name, wherein the first authorization interface comprises a plurality of authorization options of a first authority; and generating a first authorization interface on the interface upper layer of the first application according to the view resource. Therefore, when the first application needs to jump to the second application to set the authority of the first application in the second application, the terminal device can not execute the jump, but directly obtain the view resource of the corresponding first authorization interface according to the application identifier of the first application and the requested authority name, and then directly generate the first authorization interface on the upper layer of the interface of the first application, so that the user is prevented from executing complicated authorization operation in the second application, the authorization flow is simplified, and the user experience is improved.

In one implementation, when the software program and/or the sets of instructions are executed by the processor 603, the terminal device is caused to implement the following method steps: and generating a first authorization interface on the upper layer of the interface of the first application in a window form according to the view resources, wherein the height of the window is smaller than the height of the display screen, and the width of the window is smaller than the width of the display screen. In this way, the first authorization interface can be displayed in a small window form on the upper layer of the interface of the first application, and the user is not influenced to view the interface information of the first application while authorizing.

In one implementation, the second application comprises a first authorization switch, which when executed by the processor 603 causes the following method steps to be implemented: responding to a first click operation of a user, and acquiring the state of a first authorization switch; when the first authorization switch is in an on state, acquiring an application identifier and an authority name; when the first authorization switch is in an off state, jumping from the first application to the second application. In this way, the terminal device allows the user to select whether to jump to the second application to set the authority of the first application.

In one implementation, the software program and/or the plurality of sets of instructions comprise a rights manager, and when the software program and/or the plurality of sets of instructions are executed by the processor 603, the terminal device is enabled to implement the following method steps: the authority manager acquires the application identifier and the authority name from the second application; and the authority manager determines the view resource according to the application identifier and the authority name.

In one implementation, the software program and/or the plurality of sets of instructions comprise a rights manager and a system user interface system _ UI process, which when executed by the processor 603, causes the terminal device to implement the following method steps: the authority manager sends the view resources to a system _ UI process; the system _ UI process draws a first authorization interface on an interface upper layer of the first application according to the view resource.

In one implementation, the software program and/or the plurality of sets of instructions comprise a rights manager and a system _ UI process, which when executed by the processor 603, causes the terminal device to implement the following method steps: the permission manager sends the view resource to a second application; the second application sends the view resource to a system user interface system _ UI process of the terminal equipment; the system _ UI process draws a first authorization interface on an interface upper layer of the first application according to the view resource.

In one implementation, the software program and/or the sets of instructions, when executed by the processor 603, further cause the terminal device to implement the method steps of: and when detecting that the user clicks any authorization option in the first authorization interface, updating the corresponding authorization result into the authority manager so as to obtain the authorization result from the authority manager when the first application requests the first authority again.

In one implementation, the first permission includes a positioning permission; the first application at least comprises a map application, a motion track record application and a taxi taking application; the second application comprises a setting application of the terminal equipment operating system; the size of the first authorization interface is smaller than the size of the interface of the first application.

Fig. 17 is a schematic structural diagram of another application authorization apparatus provided in an embodiment of the present application. In one embodiment, the terminal device may implement the corresponding functions by the software means shown in fig. 17. As shown in fig. 17, the application authorization apparatus may include: a setting module 701, a display module 702 and a permission control module 703. Wherein:

a setting module 701, configured to, when a first application requests a first permission, respond to a first click operation of a user on the first application, obtain an application identifier of the first application and a permission name of the first permission, where the first click operation is used to instruct a terminal device to jump to a second application, and the second application is used to set the permission of the first application; the setting module 701 is further configured to determine view resources of a first authorization interface corresponding to the application identifier and the authority name, where the first authorization interface includes multiple authorization options of the first authority; a display module 702, configured to generate a first authorization interface on an upper layer of an interface of a first application according to the view resource. Therefore, when the first application needs to jump to the second application to set the authority of the first application in the second application, the terminal device can not execute the jump, but directly obtain the view resource of the corresponding first authorization interface according to the application identifier of the first application and the requested authority name, and then directly generate the first authorization interface on the upper layer of the interface of the first application, so that the user is prevented from executing complicated authorization operation in the second application, the authorization flow is simplified, and the user experience is improved.

In one implementation, the display module 702 is configured to generate a first authorization interface on an upper layer of an interface of a first application in the form of a window according to a view resource, where a height of the window is smaller than a height of the display screen, and a width of the window is smaller than a width of the display screen. In this way, the first authorization interface can be displayed in a small window form on the upper layer of the interface of the first application, and the user is not influenced to view the interface information of the first application while authorizing.

In one implementation, the second application includes a first authorization switch; a setting module 701, configured to obtain a state of a first authorization switch in response to a first click operation of a user; the setting module 701 is further configured to obtain an application identifier and an authority name when the first authorization switch is in an on state; the setting module 701 is further configured to jump from the first application to the second application when the first authorization switch is in an off state. In this way, the terminal device allows the user to select whether to jump to the second application to set the authority of the first application.

In one implementation manner, the authority control module 703 is configured to obtain the application identifier and the authority name from the setting module 701; and the authority control module 703 is configured to determine the view resource according to the application identifier and the authority name.

In one implementation, the right control module 703 is further configured to send the view resource to the display module 702.

In an implementation manner, the authority control module 703 is further configured to send the view resource to the setting module 701; the setting module 701 is further configured to send the view resource to the display module 702.

In an implementation manner, the permission control module 703 is further configured to update the corresponding authorization result when it is detected that the user clicks any authorization option in the first authorization interface, so that when the first application requests the first permission again, the authorization result is obtained from the permission control module 703.

Embodiments of the present application also provide a computer-readable storage medium having stored therein instructions, which when executed on a computer, cause the computer to perform the method of the above-mentioned aspects.

Embodiments of the present application also provide a computer program product containing instructions which, when executed on a computer, cause the computer to perform the method of the above aspects.

The embodiment of the application also provides a chip system, and fig. 18 is a schematic structural diagram of the chip system. The chip system comprises a processor 801 for enabling the apparatus to perform the functions referred to in the above aspects, e.g. to generate or process information referred to in the above methods. In one possible design, the chip system further comprises a memory 802 for holding computer instructions 803 and data necessary for the private information generating means. The chip system may be constituted by a chip, or may include a chip and other discrete devices.

The above embodiments are only intended to be specific embodiments of the present application, and are not intended to limit the scope of the embodiments of the present application, and any modifications, equivalent substitutions, improvements, and the like made on the basis of the technical solutions of the embodiments of the present application should be included in the scope of the embodiments of the present application.

Claims

1. An application authorization method, comprising:

when a first application requests a first right, a terminal device responds to a first click operation of a user on the first application to acquire an application identifier of the first application and a right name of the first right, wherein the first click operation is used for indicating the terminal device to jump to a second application, and the second application is used for setting the right of the first application;

the terminal equipment determines view resources of a first authorization interface corresponding to the application identifier and the authority name, wherein the first authorization interface comprises a plurality of authorization options of the first authority;

and the terminal equipment generates the first authorization interface on the upper layer of the interface of the first application according to the view resource.

2. The method of claim 1,

the first application comprises a first guide interface, the first guide interface is generated under the condition that the first application requests that the first permission is rejected, the first guide interface comprises a jump option, and the first click operation comprises an operation of clicking the jump option by the user.

3. The method of claim 1,

the first application comprises a second authorization interface which is generated under the condition that the first application requests that the first permission is not rejected, the second authorization interface comprises a jump option and a plurality of authorization options of the first permission, and the first click operation comprises an operation of clicking the jump option by the user.

4. The method of claim 3,

the plurality of authorization options in the first authorization interface are partially or completely different from the plurality of authorization options in the second authorization interface.

5. The method according to any one of claims 1 to 4, wherein the terminal device generates the first authorization interface on an upper layer of the interface of the first application according to the view resource, and includes:

the terminal device generates the first authorization interface on the interface upper layer of the first application in a window form according to the view resource, wherein the height of the window is smaller than that of a display screen of the terminal device, and the width of the window is smaller than that of the display screen.

6. The method according to any one of claims 1 to 5, wherein the second application comprises a first authorization switch, and the terminal device acquires the application identifier of the first application and the authority name of the first authority in response to a first click operation of a user, and comprises:

the terminal equipment responds to a first click operation of a user and acquires the state of the first authorization switch;

when the first authorization switch is in an on state, the terminal equipment acquires the application identifier and the authority name;

and when the first authorization switch is in a closed state, the terminal equipment jumps from the first application to the second application.

7. The method according to any one of claims 1 to 6, wherein the terminal device includes a rights manager, and the obtaining, by the terminal device, the view resource of the first authorization interface corresponding to the application identifier and the rights name includes:

the authority manager acquires the application identifier and the authority name from the second application;

and the permission manager determines the view resource according to the application identifier and the permission name.

8. The method according to claim 7, wherein the terminal device generates the first authorization interface on an upper layer of the interface of the first application according to the view resource, and includes:

the permission manager sends the view resource to a system user interface (system _ UI) process of the terminal equipment;

and the system _ UI process draws the first authorization interface on the upper layer of the interface of the first application according to the view resource.

9. The method according to claim 7, wherein the terminal device generates the first authorization interface on an upper layer of the interface of the first application according to the view resource, and includes:

the permission manager sends the view resource to the second application;

the second application sends the view resource to a system user interface system _ UI process of the terminal equipment;

10. The method according to any one of claims 7-9, further comprising:

and when the terminal equipment detects that the user clicks any authorization option in the first authorization interface, updating the corresponding authorization result into the authority manager so as to obtain the authorization result from the authority manager when the first application requests the first authority again.

11. The method according to any one of claims 1-10, characterized in that the method comprises one or more of the following:

the first permission comprises a positioning permission;

the first application at least comprises a map application, a motion track record application and a taxi taking application;

the second application comprises a setting application of a terminal equipment operating system;

the size of the first authorization interface is smaller than the size of the interface of the first application.

12. An application authorization apparatus, characterized in that,

the terminal device comprises a setting module, a first application and a second application, wherein the setting module is used for responding to a first click operation of a user on the first application when the first application requests a first authority, acquiring an application identifier of the first application and an authority name of the first authority, the first click operation is used for indicating the terminal device to jump to the second application, and the second application is used for setting the authority of the first application;

the setting module is further configured to determine view resources of a first authorization interface corresponding to the application identifier and the authority name, where the first authorization interface includes multiple authorization options of the first authority;

and the display module is used for generating the first authorization interface on the upper layer of the interface of the first application according to the view resource.

13. The apparatus of claim 12,

14. The apparatus of claim 13,

15. The apparatus of claim 13,

16. The apparatus according to any one of claims 12 to 15,

the display module is configured to generate the first authorization interface on an upper layer of the interface of the first application in a form of a window according to the view resource, where a height of the window is smaller than a height of the display screen, and a width of the window is smaller than a width of the display screen.

17. The apparatus according to any one of claims 12 to 16,

the second application comprises a first authorization switch;

the setting module is used for responding to a first click operation of a user and acquiring the state of the first authorization switch;

the setting module is further configured to acquire the application identifier and the authority name when the first authorization switch is in an on state;

the setting module is further configured to jump from the first application to the second application when the first authorization switch is in an off state.

18. The apparatus of any one of claims 12-17, further comprising: an authority control module;

the authority control module is used for acquiring the application identifier and the authority name from the setting module;

and the authority control module is used for determining the view resources according to the application identifiers and the authority names.

19. The apparatus of claim 18,

the permission control module is further configured to send the view resource to the display module.

20. The apparatus of claim 18,

the authority control module is also used for sending the view resources to a setting module;

the setting module is further configured to send the view resource to the display module.

21. The apparatus of any one of claims 18-20,

the authority control module is further configured to update a corresponding authorization result when it is detected that the user clicks any authorization option in the first authorization interface, so that the authorization result is obtained from the authority control module when the first application requests the first authority again.

22. The apparatus according to any one of claims 12-21, further comprising at least one of:

the first permission comprises a positioning permission;

23. A terminal device, comprising: a processor, a memory and a display screen; the memory stores program instructions that, when executed by the processor, cause the terminal device to perform the method of any of claims 1-11.