WO2023273350A1

WO2023273350A1 - Application authorization method and apparatus, and terminal device

Info

Publication number: WO2023273350A1
Application number: PCT/CN2022/075491
Authority: WO
Inventors: 陈栋
Original assignee: 荣耀终端有限公司
Priority date: 2021-06-30
Filing date: 2022-02-08
Publication date: 2023-01-05
Also published as: CN113591106B; CN113591106A

Abstract

Embodiments of the present application provide an application authorization method and apparatus, and a terminal device. When a first application requests a first permission, the terminal device obtains an application identifier of the first application and the permission name of the first permission in response to a user's first click operation in the first application, the first click operation being used for instructing the terminal device to jump to a second application, and the second application being used for setting permissions of the first application; the terminal device determines a view resource of a first authorization interface corresponding to the application identifier and the permission name, the first authorization interface comprising multiple authorization options of the first permission; and the terminal device generates the first authorization interface over an interface of the first application according to the view resource. In this way, when permissions are to be set for the first application in the second application, the interface of the terminal device does not need to completely jump to the second application, but the first authorization interface is directly generated over the interface of the first application, such that the user can complete an authorization operation in the first authorization interface, thus simplifying the authorization interaction process.

Description

An application authorization method, device and terminal equipment

This application claims the priority of the Chinese patent application with the application number 202110739596.7 and the title of the invention "A method, device and terminal device for application authorization" submitted to the State Intellectual Property Office on June 30, 2021, the entire contents of which are incorporated by reference incorporated in this application.

technical field

The present application relates to the technical field of terminals, in particular to an application authorization method, device and terminal equipment.

Background technique

In the terminal device, in order to realize some functions, the application program needs to obtain corresponding permissions. For example, if an application wants to access and modify calendars, create schedules, etc., it needs to obtain the calendar permission; if the application wants to realize location-based services (Location Based Services, LBS) related functions, it needs to obtain the location service permission; If the application needs to implement the recording function, it needs to obtain the microphone permission.

At present, terminal devices generally manage application permissions through a permission management mechanism. Taking a terminal device running an Android system as an example, the permission management mechanism may include an installation-time permission mode and a runtime permission mode. Wherein, the runtime permission mode means that the user does not need to grant permission to the application program when the application program is installed, but grants permission to the application program when the application program is running. Taking the runtime permission mode as an example, if an application requests a certain permission from the terminal device during operation, the terminal device can authorize the interface on the display screen, and the authorization interface can prompt the user for the permission content requested by the application and provide it to the user. Multiple options, including but not limited to some or all of the following options: Allow always, Allow only while in use, Deny, Ask, Allow once, Deny and never ask again. If the user clicks the option "Deny and don't ask again", then when the terminal device requests the permission again, the authorization interface will not pop up again, and the terminal device will guide the user to set the permission in the system's setting application. The process requires the user to perform multiple click operations and application switching operations, which is very cumbersome and affects the user experience.

Contents of the invention

In order to improve user experience when a user sets permissions for an application program, embodiments of the present application provide an application authorization method, device, and terminal device.

In the first aspect, the embodiment of the present application provides an application authorization method, including: when the first application requests the first permission, the terminal device obtains the application identification of the first application in response to the user's first click operation on the first application and the permission name of the first permission, the first click operation is used to instruct the terminal device to jump to the second application, and the second application is used to set the permission of the first application; the terminal device determines the first authorization interface corresponding to the application ID and the permission name The view resource, the first authorization interface includes multiple authorization options of the first permission; the terminal device generates the first authorization interface on an upper layer of the interface of the first application according to the view resource.

In this way, when it is necessary to jump from the first application to the 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 (full jump can be understood as: the terminal is currently The displayed interface is switched from displaying the interface of the first application to displaying the interface of the second application, and the interface of the first application changes from visible to invisible. After the complete jump occurs, after the user completes some operations on the interface of the second application, the user It is necessary to manually switch the currently displayed interface of the second application to the interface of the first application to perform subsequent operations, causing the user to operate back and forth between the interfaces of multiple applications, which is cumbersome and inefficient), but directly according to The application ID of the first application and the requested permission name obtain the view resource of the corresponding first authorization interface, and then directly generate the first authorization interface on the upper layer of the interface of the first application, thereby avoiding the user from performing cumbersome authorization in the second application operation, simplify the authorization process, and improve user experience.

In one implementation, the first application includes a first guide interface, the first guide interface is generated when the first application's previous request for the first permission is rejected, the first guide interface includes a jump option, and the first click Actions include actions where the user clicks on a jump option. In this way, when the online request of the first application for the first permission is rejected, the user does not need to perform cumbersome authorization operations in the second application, which simplifies the authorization process and improves user experience.

In one implementation, the first application includes a second authorization interface, the second authorization interface is generated when the first application's previous request for the first permission is not rejected, and the second authorization interface includes a jump option and a second authorization interface. Multiple authorization options for one permission, the first click operation includes the operation of the user clicking the jump option. In this way, when the online request of the first application for the first permission is not rejected, the user does not need to perform cumbersome authorization operations in the second application, which simplifies the authorization process and improves user experience.

In an implementation manner, the multiple authorization options in the first authorization interface are partly or completely different from the multiple authorization options in the second authorization interface. In this way, if the permission to be granted is not in the second authorization interface, the first authorization interface can be opened by clicking the jump option on the second authorization interface, and the authorization is completed in the first authorization interface.

In an implementation manner, the terminal device generates the first authorization interface on the upper layer of the first application interface according to the view resource, including: the terminal device generates the first authorization interface on the upper layer of the first application interface in the form of a window according to the view resource, and the window 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. In this way, the first authorization interface can be displayed in the form of a small window on the upper layer of the interface of the first application, without affecting the user's viewing of the interface information of the first application while authorizing.

In one implementation, the second application includes a first authorization switch, and the terminal device acquires the application identifier of the first application and the permission name of the first permission in response to the user's first click operation, including: the terminal device responds to the user's The first click operation obtains the state of the first authorization switch; when the first authorization switch is on, the terminal device obtains the application ID and permission name; when the first authorization switch is off, the terminal device jumps from the first application to the second application. In this way, the terminal device allows the user to choose whether to jump to the second application to set the permission of the first application.

In one implementation, the terminal device includes a permission manager, and the terminal device obtains the view resource of the first authorization interface corresponding to the application identifier and the permission name, including: the permission manager obtains the application identifier and the permission name from the second application; permission management The server determines the view resource based on the application ID and permission name.

In one implementation, the terminal device generates the first authorization interface on the upper layer of the interface of the first application according to the view resource, including: the permission manager sends the view resource to the system user interface system_UI process of the terminal device; The upper layer of the interface of the first application draws the first authorization interface.

In an implementation manner, the terminal device generates the first authorization interface on the upper layer of the interface of the first application according to the view resource, including: the rights manager sends the view resource to the second application; the second application sends the view resource to the terminal device's The system user interface system_UI process; 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.

In an implementation manner, the method further includes: when the terminal device detects that the user clicks any authorization option in the first authorization interface, updating the corresponding authorization result to the rights manager, so that the first application requests the second authorization option again. When a permission is granted, the authorization result is obtained from the permission manager.

In one implementation, it also includes at least one of the following: the first permission includes positioning permission; the first application includes at least a map application, a motion track recording application, and a taxi application; the second application includes terminal device operating system settings application; the size of the first authorization interface is smaller than the size of the interface of the first application.

In the second aspect, the embodiment of the present application provides an application authorization device, which includes: a setting module, configured to obtain the first permission in response to the user's first click operation on the first application when the first application requests the first permission. The application identifier of an application and the permission name of the first permission, the first click operation is used to instruct the terminal device to jump to the second application, and the second application is used to set the permission of the first application; the setting module is also used to determine the application identifier The view resource of the first authorization interface corresponding to the authority name, the first authorization interface includes multiple authorization options of the first authority; the display module is used to generate the first authorization interface on the upper layer of the interface of the first application according to the view resource.

In this way, when it is necessary to jump from the first application to the second application to set the permission of the first application in the second application, the terminal device may not execute the jump, but directly according to the application identification and request of the first application Obtain the view resources of the corresponding first authorization interface, and then directly generate the first authorization interface on the upper layer of the interface of the first application, thereby avoiding the user from performing cumbersome authorization operations in the second application, simplifying the authorization process, and improving the user experience. Use experience.

In one implementation, the display module is configured to generate the first authorization interface on the upper layer of the first application interface in the form of a window according to the view resource, 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 the form of a small window on the upper layer of the interface of the first application, without affecting the user's viewing of the interface information of the first application while authorizing.

In one implementation, the second application includes a first authorization switch; the setting module is configured to acquire the state of the first authorization switch in response to the user's first click operation; the setting module is also configured to obtain the status of the first authorization switch when the first authorization switch is When in the on state, obtain the application identification and permission name; the setting module is also used to jump from the first application to the second application when the first authorization switch is in the off state. In this way, the terminal device allows the user to choose whether to jump to the second application to set the permission of the first application.

In an implementation manner, the permission control module is configured to obtain the application identifier and the permission name from the setting module; the permission control module is configured to determine the view resource according to the application identifier and the permission name.

In an implementation manner, the permission control module is further configured to send the view resource to the display module.

In an implementation manner, the permission control module is further configured to send the view resource to the setting module; the setting module is further configured to send the view resource 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 on any authorization option in the first authorization interface, so that when the first application requests the first permission again, from Obtain the authorization result in the authority control module.

In the third aspect, the embodiment of the present application also provides a computer-readable storage medium, where instructions are stored in the computer-readable storage medium, and when the instruction is run on a computer, the computer executes the above-mentioned aspects and the methods of each implementation manner.

In a fourth aspect, the embodiment of the present application also provides a computer program product containing instructions, which when run on a computer, causes the computer to execute the above aspects and the methods of each implementation.

In the fifth aspect, the embodiment of the present application further provides a chip system, the chip system includes a processor, configured to support the terminal device to implement the functions involved in the above aspect, for example, generate or process the information involved in the above method .

Description of drawings

FIG. 1 is a scene diagram of granting permission in the runtime permission mode shown in the embodiment of the present application;

Fig. 2 is a schematic diagram of scene A shown in the embodiment of the present application;

Fig. 3 is a schematic diagram of scene 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 terminal device user interface corresponding to scenario A of the application authorization method provided by the embodiment of the present application;

FIG. 6 is a flow chart when the application authorization method provided by the embodiment of the present application is applied to scenario A;

FIG. 7 is a schematic diagram of a terminal device user interface corresponding to scenario B of the application authorization method provided by the embodiment of the present application;

FIG. 8 is a flow chart when the application authorization method provided by the embodiment of the present application is applied to scenario B;

FIG. 9 is a schematic diagram of a terminal device user interface corresponding to scenario B of the application authorization method provided by the embodiment of the present application;

Fig. 10 is a schematic diagram of a small window authorization switch realized by a global switch provided by the embodiment of the present application;

Fig. 11 is a schematic diagram of a small window authorization switch realized by a non-global switch provided in the embodiment of the present application;

Fig. 12 is another flow chart of the application authorization method provided by the embodiment of the present application;

FIG. 13 is a schematic diagram of a software module of a terminal device shown in an embodiment of the present application;

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

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

Fig. 16 is a schematic structural diagram of an application authorization device provided by an embodiment of the present application;

Fig. 17 is a schematic structural diagram of another application authorization device provided by the embodiment of the present application;

FIG. 18 is a schematic structural diagram of a chip system provided by an embodiment of the present application.

detailed description

Generally speaking, a terminal device provides various 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 the Android system as an example, some of the permissions it can provide to the application include:

Body Sensors: Obtain sensor information related to the user's vital signs.

Calendar: Use the user's default calendar.

Call History: View and change the user's call history.

Camera: Take pictures or record videos with the user's camera.

Contacts: View the user's contact list.

Location information (positioning): request to obtain the location information of the user equipment.

Microphone: Record audio.

Phone: Make and manage calls.

Physical activity: Get the user's sports information, such as walking, cycling, steps, etc.

SMS: View and send text messages.

Storage: Get photos and other files on the end device.

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

From the permissions shown in the above example, it can be seen that some permissions are closely related to user privacy. When the application obtains these permissions, it will also obtain the user privacy related to the permissions. For example: if the application obtains the address book permission, the application The user's contact list can be read and uploaded; if the application has obtained the location information permission, it can know the user's location at any time; if the application has obtained the storage space permission, it can read the photos in the user's album.

At present, terminal devices generally manage application program permissions through a permission management mechanism, so as to reduce leakage of user privacy and improve device security. Also taking a terminal device running an Android system as an example, its permission management mechanism may include an installation-time permission mode and a runtime permission mode.

The permission mode at installation time refers to the mode in which the user grants permissions to the application when installing or updating the application. When the user installs the application, the terminal device will display all the permissions requested by the application to the user. After the user agrees to the authorization, the application The program starts to install and obtains all the permissions requested by it. The permission mode exists in the early system version before Android 6.0 during installation, which is not within the scope of the discussion of the embodiment of this application, so no further explanation will be given.

The runtime permission mode means that the user does not need to grant permission to the application when the application is installed, but grants permission to the application when the application is running. When an app requests a permission (for example, at app launch or when a user uses a specific feature) is up to the app itself.

FIG. 1 is a scene diagram of permission granting in the runtime permission mode shown in the embodiment of the present application. As shown in Figure 1, during the running of the application program, if the application program requests a certain permission (such as location permission) from the terminal device, the terminal device can generate an authorization interface 10 as shown in Figure 1 on the display screen, the authorization interface 10 You can prompt the user for the permission content requested by the application and provide the user with multiple options, including but not limited to some or all of the following options: always allow, allow only in use, deny, ask, allow once, deny and not Ask again.

In operating systems such as Android, IOS, and HarmonyOS, the authorization interface 10 is usually implemented in the form of N-state notifications, that is, includes N authorization options, and N is generally 3 or 4. In different operating systems, or different versions of the same operating system, or different custom ROMs, the number of authorization options included in the authorization interface 10 may be different. In different operating systems, or in different versions of the same operating system or in different custom ROMs, the description of the same authorization option may also be different, for example, "allow only during use" can be called "allow only during use", "allow Once" could be called "this time only", and "deny and never ask again" could be called "always deny".

Next, the user can click any one of the authorization options in 21 according to his own wishes to complete the permission setting of the application. For example: when the user clicks "Allow", the authorization interface 10 is closed, and the application program obtains the location permission, and uses the location function to realize corresponding functions, such as path planning, navigation, etc.; when the user clicks "Deny", the authorization interface 10 is closed , the application is denied the location permission, at this time the location-based functions of the application will not be implemented.

What needs to be added here is that "always allow" is a high-risk authorization behavior. Taking location permission as an example, when the user "always allows" an application to obtain location permission, it means that the application is running in the foreground or During the period of staying in the background, the user's location information can be obtained without restriction, which will bring the risk of privacy leakage to the user. Therefore, in order to protect the user's privacy and prevent the user from granting the application "always allow" to obtain a certain permission due to misoperation, etc., in Android 11 and subsequent versions, the authorization interface 10 no longer provides the "always allow" option. If the user wants the application When a program can "always allow" to obtain a certain permission, it needs to be granted in the system settings.

In some scenarios (hereinafter referred to as scenario A), considering user experience, after the user refuses to grant the application a certain permission, if the application continues to request the permission, the terminal device will not generate the authorization interface 10 again. In this case, the application may generate a dialog box to guide the user to jump from the application to the application information page of the terminal device. The application information page is provided by the system settings application of the terminal device. In the application information page to reset the app's permissions before returning to the app.

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

As shown in Figure 2, taking an application requesting location permission as an example, in the case that the application has been denied the location permission, the application can generate a guide as shown in a in Figure 2 when starting Dialog box 30, which may include a go to "Settings" button 31, and explanatory information 32 explaining to the user why location permission is requested and how to grant location permission in the application information page. When the user clicks 33 to go to the "Settings" button 31, the application starts the setting application of the terminal device system, and jumps from the current interface of the application to the interface of the setting application, specifically, it can jump to the interface shown in b in Figure 2 App information page displayed. Wherein, the application information page is a sub-interface for setting the application. In different operating systems, or different versions of the same operating system or different custom ROMs, the name of the application information page may be different, for example, it may also be called the application details page. Generally speaking, each application program installed in the terminal device will have its corresponding application information page in the setting application. For any application, its application information page can include its storage space usage, traffic consumption, power consumption and other information, permission related options and other setting options, so that users can view the application permissions on the application information page Status and permissions to set the application.

Next, the user can click 34 Rights Management on the application information page to enter the rights management interface of the application as shown in c in Figure 2, and then click 35 "locate" option in the rights management interface to open the authorization interface 40 , and finally click any option 36 among multiple authorization options provided by the authorization interface 40 of the positioning authority to complete the authority 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 permissions required by the application. In this case, the application program may also guide the user to jump from the application program to the application information page of the terminal device, grant the required permissions to the application program in the application information page, and then return to the application program.

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

As shown in Figure 3, taking the location permission requested by the map application as an example, the map application needs to obtain the user's location information in real time when implementing the navigation function. Obtain the user's location information when the screen or map application is in the system background. However, the terminal device may not include the "always allow" option in the authorization interface 10 due to considerations such as security. In this case, the authorization interface 10 may include an "Allow in "Settings"" button 37, and when the user clicks 38 the "Allow in "Settings" button 37, the application program jumps to the application information page of the terminal device, After the user completes permission setting on the application information page, he manually switches back to the application interface.

Combining Figures 2 and 3, it can be seen that in the case that the application program has been denied a certain permission, or in the case that the authorization interface 10 does not include the permission requested by the application program, the application program can jump to the application program of the terminal device. The information page allows users to perform operations on the application information page to grant the permission. However, this process requires the user to perform multiple click operations and application switching operations, which is very cumbersome and affects the user experience.

In order to avoid interface jumps during the process of the user granting permissions to the application program, simplify user operations, and improve user experience, an embodiment of the present application provides an application authorization method.

The application authorization method in the embodiment of the present application can be applied to a terminal device. Among them, terminal devices include but are not limited to mobile phones, tablet computers, personal computers, workstation devices, large-screen devices (such as: smart screens, smart TVs, etc.), wearable devices (such as: smart bracelets, smart watches) handheld game consoles, Home game consoles, virtual reality devices, augmented reality devices, mixed reality devices, etc., vehicle-mounted intelligent terminals, etc.

FIG. 4 is a schematic diagram of a hardware structure of a terminal device provided by an embodiment of the present application. As shown in Figure 4, the terminal device 100 may include a processor 110, a memory 120, a universal serial bus (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 screen 180, touch sensor 190, air pressure sensor 210 and buttons 220, etc.

The processor 110 may include one or more processing units, for example: the processor 110 may include an application processor (application processor, AP), a modem processor, a graphics processing unit (graphics processing unit, GPU), an image signal processing Image signal processor (ISP), video codec, digital signal processor (digital signal processor, DSP), baseband processor, and/or neural network processor (neural-network processing unit, NPU), etc. Wherein, different processing units may be independent devices, or may be integrated in one or more processors, such as integrated in a system chip (system on a chip, SoC). A memory may also be provided in the processor 110 for storing instructions and data. In some embodiments, the memory in processor 110 is a cache memory. The memory may hold instructions or data that the processor 110 has just used or recycled.

It can be understood that, the structure shown in the embodiment of the present application does not constitute a specific limitation on the terminal device 100 . In other embodiments of the present application, the terminal device may include more or fewer components than shown in the figure, or combine certain components, or separate certain components, or arrange different components. The illustrated components can be realized in hardware, software or a combination of software and hardware.

Each method step of the application authorization method provided by the embodiment of the present application is illustrated below.

The application authorization method provided in the embodiment of this application can be applied in scenario A.

In scenario A, the application may request a certain permission from the terminal device during running. The running period of the application program here includes but is not limited to: when the application program is started, during the running period of the application program in the foreground after starting, and during the running period of the application program in the background after starting. In the Android system, the application program can apply for permission from the operating system of the terminal device by calling the requestPermissions() method. In the following embodiments, for ease of description, the application program requesting permission is called the target application program.

Take the target application requesting location permission as an example:

When the terminal device discovers that the target application has applied for this permission before, but is permanently rejected by the user (for example, the user has selected "permanently reject" or "deny and no longer ask" in the authorization interface 10 shown in Figure 1), the Inform the target application of the rejected result of the target application's permission request. In the Android system, the terminal device can notify the target application of the rejected result of the target application's permission request by calling the shouldShowRequestPermissionRationale() method. The authorization interface 10 as shown in a in FIG. 1 is displayed on .

FIG. 5 is a schematic diagram of a terminal device user interface corresponding to scenario A of the application authorization method provided by the embodiment of the present application.

FIG. 6 is a flow chart when the application authorization method provided by the embodiment of the present application is applied to scenario A.

After the target application learns that its request for a certain permission is rejected, it can generate a guide interface 30 as shown in a in FIG. 5 to guide the user to grant the required permission to the target application in the setting application of the terminal device system.

If the user wants to set the permission of the target application in the setting application of the terminal device system, the operation of clicking 33 can be performed on the Go to “Settings” button 31 in the guidance interface 30 . Generally speaking, when the terminal device detects that the user performs a click 33 operation on the go to "settings" button 31, it will respond to the click operation and jump from the current target application interface to the setting application of the terminal device system, for example, jump to Go to the application information page of the settings application, so that the user can complete the permission grant through multiple operations in the application information page. However, in the embodiment of the present application, when the terminal device detects that the user performs an operation of clicking 33 on the "Settings" button 31, it will not jump to the setting application of the terminal device system, but execute the The following steps S101-S103:

In step S101, the terminal device acquires the application identifier of the target application and the name of the permission requested by the target application in response to the user's click operation on the Go to "Settings" button.

Wherein, the application identifier of the target application may be, for example, the package name (Package Name) and the application ID of the target application, or other information used to determine the 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: com.xxx.xxx, where xxx.xxx may be information used to indicate the identity of the application developer, application type, and name. For example, the package name of the "Maps" application could be: com.honor.map. In the IOS terminal device, the package name can be a string of numbers, and the numbers of different applications are different.

Wherein, the permission name may include, for example, a permission name, such as location information, address book, body sensor, storage space, and the like. If the target application applies for one permission, the permission name may include the name of one permission, and if the target application applies for multiple permissions, the permission name may include the names of multiple permissions.

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

In the specific implementation, after the terminal device detects that the user has clicked the "Settings" button in the guidance interface, it will not jump to the application information page, but will apply the settings of the operating system in the background according to the obtained application identification and permission name. A search is performed to find the view resource of the first authorization interface corresponding to the permission requested by the target application, where the view resource includes text resources, image resources, style resources, etc. required for generating the first authorization interface. It should be added that the entire process of the terminal device performing step S102 will not be displayed on the display screen, and the user will not perceive this process.

For example, when the package name obtained by the terminal device is com.honor.map (the package name of the "map" application), and the requested permission is the positioning permission, the terminal device can set the package name com.honor.map in the system The application information page of the "map" application is retrieved in the application, and then the authorization interface of the location permission is further retrieved in the application information page of the "map" application.

Step S103, 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 in Figure 5, in one implementation, the terminal device can draw the first authorization interface according to the text resources, image resources and style resources contained in the view resources, and display the first authorization interface 50 as a window (also called a small window) is displayed on the display screen, 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. In this way, after the first authorization interface 50 is displayed, the user can still see part of the content of the interface 60 of the target application.

In the embodiment of the present application, the first authorization interface 50 can 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. The content can be the same or different. Specifically: if the terminal device directly generates the first authorization interface 50 with the style and content of the view resource after obtaining the view resource of the first authorization interface 50, then the first authorization interface 50 will be consistent with the style and content of the authorization interface 40 Similarly, if the terminal device optimizes and modifies the style and content of the view resource according to the current theme settings and user settings of the terminal device after obtaining the view resource of the first authorization interface 50, then the first authorization interface 50 will be consistent with the authorization interface. 40 may vary in style and content.

As shown in b in FIG. 5 , in an implementation manner, the first authorization interface 50 may include a description of the permission requested by the target application, and provide multiple authorization options for the user to choose from. Taking the first authorization interface 50 of the positioning authority of the "Maps" application as an example, the first authorization interface 50 may include an application name 51 "map", an icon 52 of the "map" application, and a permission name 53 "location location" requested by the "map" application. ", and the description of the purpose of the "location" permission54 (for example: to provide you with surrounding information, accurate traffic conditions and navigation services), etc. As an example, the first authorization interface 50 provides the user with four authorization options, which are: deny, ask, allow only in use, and always allow.

After the first authorization interface 50 is generated in the form of a window, the user can click 55 any authorization option according to his/her will to complete the authority setting. In a specific implementation, when the terminal device detects that the user has clicked 55 on any option in the first authorization interface 50, the first authorization interface 50 is closed, and the authorization result corresponding to the user's click 55 is saved in the authority manager of the system, and re- Start the target application. Take the location permission of the "Maps" application as an example:

When the user clicks the "always allow" option in the first authorization interface 50, the terminal device can close the first authorization interface 50, update the positioning permission of the "map" application to "always allow", and restart the "map" application . In this way, when the "map" application requests location permission again after restarting, it can request the result of "always allow", so that various functions based on location information can be performed.

When the user clicks the "deny" option in the first authorization interface 50, the terminal device can close the first authorization interface 50, keep the location permission of "map" as "deny", and restart the "map" application. In this way, when the "Maps" application requests location permission again after restarting, it can request the result of "denied", so that it can perform functions related to the failure to obtain the location permission, such as: prompting the user that the location fails, closing the target application, regenerating Guidance interface etc.

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

In one implementation, considering that the target application usually displays the name of the target application at the bottom of the screen opening interface when it is started, the first authorization interface 50 can be displayed in the central area of the display screen so as not to block the name of the target application .

In one implementation, the first authorization interface 50 can be displayed at the bottom of the display screen. This implementation can be applied to a terminal device that can be held with one hand, such as a smart phone, so that the user can hold the terminal device with one hand. At this time, the first authorization interface 50 can be operated with one hand.

In an implementation manner, 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 to achieve two-handed operation.

In an implementation manner, when the terminal device is a folding screen mobile phone or other devices with a large display screen width, the first authorization interface 50 may be displayed on the side of the display screen to avoid the bending area of the display screen.

It can be seen from the above technical solutions that in the application authorization method provided by the embodiment of the present application, if a permission requested by the target application has been permanently rejected by the user before, if the operation performed by the user in the target application indicates that the user wants to jump to The setting application of the terminal device system performs permission setting, and the terminal device will obtain the application ID of the target application and the permission name of the requested permission, and directly generate the first authorization interface corresponding to the application ID and permission name in the interface mall of the target application, so that the user can directly In the first authorization interface, the permission setting of the target application is completed without jumping to the setting application or switching between different applications, which simplifies user operations and improves user experience.

The application authorization method provided in this embodiment of the present application can also be applied to scenario B.

FIG. 7 is a schematic diagram of a terminal device user interface corresponding to scenario B of the application authorization method provided by the embodiment of the present application.

FIG. 8 is a flow chart when the application authorization method provided by the embodiment of the present application is applied to scenario B.

In scenario B, the target application may request a certain permission from the terminal device during operation. Here, the running period of the target application includes but is not limited to: when the target application is started, during the running period of the target application in the foreground after starting, and during the running period of the target application in the background after starting. In the Android system, the target application can apply for permission from the operating system of the terminal device by calling the requestPermissions() method. Take the target application requesting location permission as an example:

When the terminal device finds that the target application does not have this permission, and the user has not permanently denied the target application to obtain this permission before, the second authorization interface 10 shown in Figure 7 can be displayed on the display screen so that the user can perform the authorization operation. For a certain permission, the terminal device can provide multiple authorization options for the user to choose, such as: always allow, only allow in use, deny, ask, allow once, always deny, etc. However, based on system settings or from the perspective of security, the terminal device will only list some options on the second authorization interface 10 , resulting in some options not being displayed on the second authorization interface 10 .

As shown in a in FIG. 7, the terminal device may display some prompt information on the second authorization interface 10 to prompt the user to select other authorization options in the setting application of the terminal device system, and provide the user with an option to skip Go to button 37 of the Settings app. For example: the second authorization interface 10 includes three authorization options (ie, three-state notification), which are respectively "permit only during use", "only this time" and "deny". Considering that some application programs need to obtain the user's location information (corresponding to the "always allow" option) when they are in the background, so as to complete functions such as background navigation and recording the user's movement track, the second authorization interface 10 also includes the following prompt information: "This app may want to get your location at any time (even if you're not using the app)" and also includes a jump button 37: "Allow in Settings".

If the user wants to set the permission of the target application in the setting application of the terminal device system, the operation of clicking 38 can be performed on the "Allow in "Settings" button 37 in the second authorization interface 10 . Generally speaking, when the terminal device detects that the user performs a click 38 operation on the "Allow in "Settings" button 37, it will respond to the click operation and jump from the current target application interface to the setting application of the terminal device system , such as jumping to the application information page of the settings application, so that the user can complete permission granting through multiple operations on the application information page. However, in the embodiment of the present application, when the terminal device detects that the click 38 operation is performed on the "Allow in "Settings" button 37, it will not jump to the setting application of the terminal device system, but execute the The shown vaguely follows steps S201-S203.

In step S201, the terminal device obtains the application identifier of the target application and the name of the permission requested by the target application in response to the user's click operation on the "Allow in "Settings"" button.

Wherein, the application identifier of the target application may be, for example, the package name (Package Name) and the application ID of the target application, or other information used to determine the unique identity of the target application, which is not limited in this embodiment of the present application. The permission name may include, for example, a permission name, such as location information, address book, body sensor, storage space, and the like.

Please refer to step S101 in the embodiment of the present application for other contents of step S201 that are not specifically expanded, and will not be repeated here.

In 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. In specific implementation, after the terminal device detects that the user has clicked the "Allow in "Settings" button in the notification interface, it will not jump to the interface of the setting application, but in the background according to the Search the setting application of the operating system with the obtained application identifier and permission name to find the view resource of the first authorization interface corresponding to the permission requested by the target application, and the view resource includes text resources required for generating the first authorization interface , image resources, style resources, etc. The whole process of executing step S202 by the terminal device will not be displayed on the display screen, and the user will not perceive this process.

Please refer to step S102 in the embodiment of the present application for other contents of step S202 that are not specifically developed, and will not be repeated 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 in Figure 7, in one implementation, the first authorization interface is drawn according to the text resources, image resources and style resources contained in the view resources, and the first authorization interface 50 is represented by a window (also called The form of a small window) is displayed on the display screen, 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. In this way, after the first authorization interface 50 is displayed, the user can still see part of the content of the interface 60 of the target application.

Similar to step S103, as further shown in b in FIG. 5 , the first authorization interface 50 may include a description of the permission requested by the target application, and provide multiple authorization options for the user to request permission for the user to choose. Taking the first authorization interface 50 of the positioning authority of the "Maps" application as an example, the first authorization interface 50 may include an application name 51 "map", an icon 52 of the "map" application, and a permission name 53 "location location" requested by the "map" application. ", and the description of the purpose of the "location" permission54 (for example: to provide you with surrounding information, accurate traffic conditions and navigation services), etc. As an example, the first authorization interface 50 provides the user with four authorization options, which are: deny, ask, allow only in use, and always allow.

In an implementation manner, compared with the second authorization interface 10, the first authorization interface 50 may display more options. As an example, as shown in b in FIG. 8, when the second authorization interface 10 includes three options of "permit only during use", "only this time" and "deny", the first authorization interface 50 can be here Add one or more options on the basis, such as adding the "always allow" option, and you can also add the "deny once" option, etc.

In one implementation, the first authorization interface 50 includes the same number of options as the second authorization interface 10, but the first authorization interface 50 may include different options from the second authorization interface 10, where the difference refers to the first The options in the authorization interface 50 are partially or completely different from those in the second authorization interface 10 . As an example, as shown in FIG. 9, when the second authorization interface 10 includes three options of "permit only during use", "only this time" and "deny", the first authorization interface 50 may also include: " Allow only during use", "Always allow" and "Deny". In this way, compared with the second authorization interface 10, the user can additionally select the "always allow" option on the first authorization interface 50, so that the target application obtains sufficient permissions for functions such as background navigation and recording of the user's movement track.

After the first authorization interface 50 is generated in the form of a small window, the user can click 55 on any option to complete the authority setting according to his own wishes. In a specific implementation, when the terminal device detects that the user has clicked 55 on any option in the first authorization interface 50, the first authorization interface 50 is closed, and the authorization result corresponding to the user's click 55 is saved in the authority manager of the system, and re- Start the target application.

Please refer to step S203 in the embodiment of the present application for other content in step S203 that is not specifically developed, and will not be repeated here.

It can be seen from the above technical solutions that in the application authorization method provided by the embodiment of the present application, if a certain permission requested by the target application has not been rejected before, if the operation performed by the user in the target application indicates that the user wants to jump to the terminal device The system's setting application performs permission setting, and the terminal device will obtain the application ID of the target application and the permission name of the requested permission, and directly generate the first authorization interface corresponding to the application ID and permission name in the interface mall of the target application, so that the user can directly The permission setting of the target application is completed in the authorization interface, without jumping to the setting application, and without switching between different applications, which simplifies user operations and improves user experience.

In an embodiment, the terminal device can provide a widget authorization switch in its system setting application, and the widget authorization switch is used to indicate whether to allow the generation of the first Authorization interface.

Taking scenario A as an example, when the small window authorization switch is turned on, if the terminal device detects that the user has clicked the Go to "Settings" button in the guidance interface, it will not jump to the application information page, but execute step S101 - Step S103; when the small window authorization switch is turned off, if the terminal device detects that the user has clicked the Go to "Settings" button in the guidance interface, it will not execute steps S101-step S103, but jump to the application information page, the user finds the permission setting entry of the target application on the application information page, completes the corresponding authorization operation, and then manually switches back to the target application interface.

Taking Scenario B as an example, when the small window authorization switch is turned on, if the terminal device detects that the user has clicked the Allow button in "Settings" on the second authorization interface, it will not jump to the application information page, but Execute step S201-step S203; when the small window authorization switch is in the closed state, if the terminal device detects that the user has clicked the allow button in "Settings" in the second authorization interface, step S201-step S203 will not be executed, and It is to jump to the application information page, and the user finds the permission setting entry of the target application on the application information page, 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 small window authorization switch implemented by a global switch provided by the embodiment of the present application. As shown in FIG. 10 , the widget authorization switch 71 may be located in the main interface of the setting application or in a certain secondary interface, for example, in the authority management interface 72 . The user can turn on or off the small window authorization switch 71 by clicking 73. When the small window authorization switch 71 is turned on, the terminal device allows all target applications to generate the first authorization interface in the form of a small window. When the small window authorization switch When 71 is closed, the terminal device does not allow all target applications to generate the first authorization interface in the form of a small window.

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

FIG. 11 is a schematic diagram of a small window authorization switch implemented by a non-global switch provided in the embodiment of the present application. As shown in Figure 11, the small window authorization switch 71 can be located in the application information page 74, and the application information page 74 of each target application can include a small window authorization switch 71, and each small window authorization switch 71 only corresponds to it One of the target apps works. The user can turn on or off the small window authorization switch 71 of a certain target application by clicking. When the small window authorization switch 71 is turned on, the terminal device allows the target application to generate the first authorization interface in the form of a small window. When the window authorization switch is turned off, the terminal device is not allowed to generate the first authorization interface in the form of a small window.

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

Fig. 12 is another flow chart of the application authorization method provided by the embodiment of the present application. As shown in Figure 12, taking the target application startup scenario as an example, the application authorization method including the process of judging whether to allow widget authorization may include the following steps:

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

In a specific implementation, when the terminal device requests for a certain permission and is rejected, it may generate a guidance interface as shown in FIG. 5 . If the terminal device allows direct jumping to the application information page from the target application, and it is detected that the user clicks the "Settings" button in the guidance interface, then it is determined that a jump to the application information page is required, and the terminal device executes step S302; if the terminal If the device does not allow direct jumping from the target application to the application information page, or detects that the user clicks the "Cancel" button on the guidance interface, the method flow ends.

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

In a specific implementation, the terminal device may determine whether to allow widget authorization for the target application according to the status of the global widget authorization switch or the non-global widget authorization switch of the target application. If the small window authorization switch is turned on, it means that the small window authorization is allowed. At this time, the terminal device executes steps S303-S304. If the small window authorization switch is turned off, it means that the small window authorization is not allowed, and at this time, the terminal device executes step S305.

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

In a specific implementation, the terminal device can obtain the application ID of the target application and the requested permission name, and then search the application information page of the target application according to the obtained application ID and permission name to find the first application ID corresponding to the permission name. Authorization interface. The whole process of executing step S303 by the terminal device will not be displayed on the display screen, and the user will not perceive this process. Please refer to step S101-step S102 in the embodiment of the present application for other contents of step S303 that are not specifically expanded, and will not be repeated here.

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

Step S304 can be specifically implemented with reference to step S103 in the embodiment of the present application, and details are not repeated here.

Next, when the user clicks any option in the authorization interface, the terminal device responds to the user's click operation, refreshes the interface to close the small window, and at the same time updates the authorization result corresponding to the user click operation in the system permission configuration, and Restart the target application.

Step S305, the terminal device jumps to the application information page.

The above-mentioned embodiments provided by this application introduce various solutions of the application authorization method provided by this application. It can be understood that, in order to realize the above functions, the terminal device may include software modules corresponding to each function.

Fig. 13 is a schematic diagram of software modules of a terminal device shown in an embodiment of the present application. As shown in FIG. 13 , in the Android system, the software modules involved in performing the application authorization method of the embodiment of the present application may at least include the setting application of the operating system, the permission controller, the system user interface main process system_UI and the requesting permission target application.

Among them, the setting application, the permission controller, system_UI and the target application are all located in the application layer of the Android system. It is a non-system-level application with low permissions. In addition, the Android system also includes an application framework layer, a system runtime layer, a hardware abstraction layer, and a Linux kernel layer. The above-mentioned hierarchical structure belongs to the conventional structure of the Android system, which is not limited in the embodiments of the present application.

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

As shown in Figure 14, in an implementation manner, the application authorization method provided by the embodiment of the present application includes at least the following steps at the software level:

Step S401, when the setting application is started from the target application, obtain the application identification of the target application and the requested permission name.

As shown in FIG. 2 and FIG. 3 , in the embodiment of the present application, launching the setting application from the target application may include the following two scenarios: In scenario A, when the user clicks the Go to "Settings" button in the guidance interface, The setting application will be launched from the target application; in scenario B, when the user clicks the "Allow in "Settings" button in the second authorization interface, the setting application will be launched from the target application.

What needs to be added here is that after the setting application is started by the target application, the terminal device will continue to stay on 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. Therefore, the setting application performs step S402 and step S403 in the background.

Step S402, the setting application sends the application identifier of the target application and the requested permission name to the permission 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 requested permission name, and sends the view resource to system_UI.

Step S404, the system_UI draws the authorization interface in the form of a small window on the upper layer of the target application according to the view resource, so that the authorization interface is popped up and displayed in the form of a small window on the display screen.

Step S405, when the setting application detects that the user has clicked any option in the authorization interface, it updates the corresponding authorization result to the authority controller.

In this way, when the terminal device application requests the permission again after restarting, it can obtain the updated authorization result from the permission controller, so as to execute the corresponding function based on the permission according to the updated authorization result.

Step S406, system_UI refreshes the user interface to close the small window.

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

As shown in Figure 15, in an implementation manner, the application authorization method provided by the embodiment of the present application includes at least the following steps at the software level:

Step S501 , when the setting application is started from the target application, the application identifier and the requested permission name of the target application are acquired.

Step S501 is the same as step S401 and will not be repeated here.

Step S502, sending the application identifier of the target application and the requested permission name to the permission 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 requested authority name, and sends the view resource to the setting application.

Step S504, the setting application sends the authorization interface to system_UI.

What needs to be explained here is that in the implementation shown in FIG. 14 , after obtaining the view resource of the first authorization interface, the permission controller directly sends the view resource to system_UI, while in the implementation shown in FIG. 15 , After obtaining the view resource of the first authorization interface, the authority controller sends the view resource to the setting application, and the setting application sends the view resource to the system_UI. It can be seen that how to send view resources to system_UI can be implemented in different ways, which is not limited in this embodiment of the present application.

Step S505, the system_UI draws the authorization interface in the form of a small window on the upper layer of the target application, so that the authorization interface is popped up in the display screen in the form of a small window.

Step S506, when the setting application detects that the user has clicked any option in the authorization interface, it updates the corresponding authorization result into the permission configuration of the target application.

Step S507, system_UI refreshes the user interface to close the small window.

The above-mentioned embodiments provided by this application introduce various solutions of the application authorization method provided by this application. It can be understood that, in order to realize the above functions, the terminal device includes hardware structures and/or software modules corresponding to each function. Those skilled in the art should easily realize that the present application can be implemented in the form of hardware or a combination of hardware and computer software in combination with the units and algorithm steps of each example described in the embodiments disclosed herein. Whether a certain function is executed by hardware or computer software drives hardware depends on the specific application and design constraints of the technical solution. Skilled artisans may use different methods to implement the described functions for each specific application, but such implementation should not be regarded as exceeding the scope of the present application.

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

In one embodiment, the touch screen 601 may include a display screen and a touch sensor, wherein the display screen is used to display images, and the touch sensor may transmit the detected touch operation to the application processor to determine the type of the touch event. The screen provides visual output related to touch operations. The processor 603 may include one or more processing units, for example: the processor 603 may include an application processor, a modem processor, a graphics processor, an image signal processor, a controller, a video codec, a digital signal processor , baseband processor, and/or neural network processor, etc. Wherein, different processing units may be independent devices, or may be integrated in one or more processors. The memory 602 is coupled with the processor 603 for storing various software programs and/or multiple sets of instructions, and the memory 602 may include volatile memory and/or non-volatile memory.

When the software program and/or multiple sets of instructions in the memory 602 are executed by the processor 603, the terminal device is made to implement the following method steps: when the first application requests the first permission, responding to the user's first click operation on the first application , to obtain the application ID of the first application and the permission name of the first permission, the first click operation is used to indicate to jump to the second application, and the second application is used to set the permission of the first application; determine the corresponding application ID and permission name The view resource of the first authorization interface, the first authorization interface includes multiple authorization options of the first authority; the first authorization interface is generated on the upper layer of the interface of the first application according to the view resource. In this way, when it is necessary to jump from the first application to the second application to set the permission of the first application in the second application, the terminal device may not execute the jump, but directly according to the application identification and request of the first application Obtain the view resources of the corresponding first authorization interface, and then directly generate the first authorization interface on the upper layer of the interface of the first application, thereby avoiding the user from performing cumbersome authorization operations in the second application, simplifying the authorization process, and improving the user experience. Use experience.

In one implementation, when the software program and/or multiple sets of instructions are executed by the processor 603, the terminal device is made to specifically implement the following method steps: generate the first authorization on the upper layer of the interface of the first application in the form of a window according to the view resource In the interface, 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 the form of a small window on the upper layer of the interface of the first application, without affecting the user's viewing of the interface information of the first application while authorizing.

In one implementation, the second application includes a first authorization switch. When the software program and/or multiple sets of instructions are executed by the processor 603, the following method steps are specifically implemented: in response to the user's first click operation, obtain the second A state of the authorization switch; when the first authorization switch is on, obtain the application ID and permission name; when the first authorization switch is off, jump from the first application to the second application. In this way, the terminal device allows the user to choose whether to jump to the second application to set the permission of the first application.

In one implementation, the software program and/or multiple sets of instructions include a rights manager, and when the software program and/or multiple sets of instructions are executed by the processor 603, the terminal device specifically implements the following method steps: the rights manager starts from the first The second application obtains the application ID and permission name; the permission manager determines the view resource according to the application ID and permission name.

In one implementation, the software program and/or multiple sets of instructions include a rights manager and a system user interface system_UI process. When the software program and/or multiple sets of instructions are executed by the processor 603, the terminal device specifically implements the following method steps : The permission manager sends the view resource to the system_UI process; 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.

In one implementation, the software program and/or multiple sets of instructions include a rights manager and a system_UI process. When the software program and/or multiple sets of instructions are executed by the processor 603, the terminal device specifically implements the following method steps: rights management The controller sends the view resource to the second application; the second application sends the view resource to the system user interface system_UI process of the terminal device; 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.

In one implementation, when the software program and/or multiple sets of instructions are executed by the processor 603, the terminal device is further made to implement the following method steps: when detecting that the user clicks on any authorization option in the first authorization interface, the corresponding The authorization result of is updated to the permission manager, so that when the first application requests the first permission again, the authorization result is obtained from the permission manager.

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

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

The setting module 701 is configured to obtain the application identifier of the first application and the permission name of the first permission in response to the first click operation of the user on the first application when the first application requests the first permission, and the first click operation is used to Instruct the terminal device to jump to the second application, the second application is used to set the authority of the first application; the setting module 701 is also used to determine the view resource of the first authorization interface corresponding to the application identification and the authority name, the first authorization interface includes A plurality of authorization options for the first permission; a display module 702 configured to generate a first authorization interface on the upper layer of the interface of the first application according to the view resource. In this way, when it is necessary to jump from the first application to the second application to set the permission of the first application in the second application, the terminal device may not execute the jump, but directly according to the application identification and request of the first application Obtain the view resources of the corresponding first authorization interface, and then directly generate the first authorization interface on the upper layer of the interface of the first application, thereby avoiding the user from performing cumbersome authorization operations in the second application, simplifying the authorization process, and improving the user experience. Use experience.

In one implementation, the display module 702 is configured to generate the first authorization interface on the upper layer of the first application interface in the form of a window according to the view resource, 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 the form of a small window on the upper layer of the interface of the first application, without affecting the user's viewing of the interface information of the first application while authorizing.

In one implementation, the second application includes a first authorization switch; the setting module 701 is configured to acquire the state of the first authorization switch in response to the user's first click operation; the setting module 701 is also configured to When the switch is in the on state, obtain the application identification and permission name; the setting module 701 is also used to jump from the first application to the second application when the first authorization switch is in the off state. In this way, the terminal device allows the user to choose whether to jump to the second application to set the permission of the first application.

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

In an implementation manner, the permission control module 703 is further configured to send the view resource to the display module 702 .

In one implementation manner, the permission 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 one implementation, 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, Obtain the authorization result from the authority control module 703 .

The embodiment of the present application also provides a computer-readable storage medium, where instructions are stored in the computer-readable storage medium, and when the computer-readable storage medium is run on a computer, it causes the computer to execute the above-mentioned methods.

The embodiment of the present application also provides a computer program product containing instructions, which, when run on a computer, causes the computer to execute the methods in the above aspects.

The embodiment of the present application also provides a chip system, and FIG. 18 is a schematic structural diagram of the chip system. The system-on-a-chip includes a processor 801 configured to support the above-mentioned device to implement the functions involved in the above-mentioned aspect, for example, generate or process the information involved in the above-mentioned method. In a possible design, the chip system further includes a memory 802 for storing necessary computer instructions 803 and data of the private information generating device. The system-on-a-chip may consist of chips, or may include chips and other discrete devices.

The above specific implementation manners have further described the purpose, technical solutions and beneficial effects of the embodiments of the present application in detail. It should be understood that the above is only the specific implementation manners of the embodiments of the present application, and is not intended to limit the implementation of the present application. For the scope of protection of the examples, any modifications, equivalent replacements, improvements, etc. made on the basis of the technical solutions of the embodiments of the present application shall be included in the scope of protection of the embodiments of the present application.

Claims

An application authorization method, characterized by comprising:

When the first application requests the first permission, the terminal device acquires the application identifier of the first application and the permission name of the first permission in response to the user's first click operation on the first application, and the first The click operation is used to instruct the terminal device to jump to a second application, and the second application is used to set the permission of the first application;

The terminal device determines a view resource of a first authorization interface corresponding to the application identifier and the authorization name, where the first authorization interface includes multiple authorization options for the first authorization;

The terminal device generates the first authorization interface on an upper layer of the interface of the first application according to the view resource.
The method according to claim 1, characterized in that,

The first application includes a first guide interface, the first guide interface is generated when the first application's previous request for the first permission is rejected, the first guide interface includes a jump option, The first click operation includes an operation in which the user clicks the jump option.
The method according to claim 1, characterized in that,

The first application includes a second authorization interface, the second authorization interface is generated when the first application's previous request for the first permission is not rejected, and the second authorization interface includes a jump option and multiple authorization options of the first permission, the first click operation includes the user clicking the jump option.
The method according to claim 3, characterized in that,

The multiple authorization options in the first authorization interface are partly or completely different from the multiple authorization options in the second authorization interface.
The method according to any one of claims 1-4, wherein the terminal device generates the first authorization interface on the upper layer of the interface of the first application according to the view resource, including:

The terminal device generates the first authorization interface on the upper layer of the first application interface in the form of a window according to the view resource, the height of the window is smaller than the height of the display screen of the terminal device, and the height of the window is The width is less than the width of the display screen.
The method according to any one of claims 1-5, wherein the second application includes a first authorization switch, and the terminal device acquires the application of the first application in response to the user's first click operation ID and authority name of the first authority, including:

The terminal device acquires the state of the first authorization switch in response to the user's first click operation;

When the first authorization switch is turned on, the terminal device acquires the application identifier and the authorization name;

When the first authorization switch is in the off state, the terminal device jumps from the first application to the second application.
The method according to any one of claims 1-6, wherein the terminal device includes a permission manager, and the terminal device obtains the view resource of the first authorization interface corresponding to the application identifier and the permission name ,include:

The permission manager acquires the application identifier and the permission name from the second application;

The permission manager determines the view resource according to the application identifier and the permission name.
The method according to claim 7, wherein the terminal device generates the first authorization interface on the upper layer of the interface of the first application according to the view resource, comprising:

The permission manager sends the view resource to the system user interface system_UI process of the terminal device;

The system_UI process draws the first authorization interface on an upper layer of the interface of the first application according to the view resource.
The method according to claim 7, wherein the terminal device generates the first authorization interface on the upper layer of the interface of the first application according to the view resource, comprising:

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 device;

The system_UI process draws the first authorization interface on an upper layer of the interface of the first application according to the view resource.
The method according to any one of claims 7-9, further comprising:

When the terminal device detects that the user clicks any authorization option in the first authorization interface, it updates the corresponding authorization result to the authorization manager, so that the first application requests the first authorization again. , the authorization result is acquired from the authority manager.
The method according to any one of claims 1-10, wherein the method comprises one or more of the following:

The first permission includes positioning permission;

The first application includes at least map applications, motion track recording applications, and taxi-hailing applications;

The second application includes a setting application of the operating system of the terminal device;

The size of the first authorization interface is smaller than the size of the interface of the first application.
An application authorization device, characterized in that,

A setting module, configured to obtain the application identifier of the first application and the permission name of the first permission in response to the user's first click operation on the first application when the first application requests the first permission, The first click operation is used to instruct the 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 is further configured to determine the view resources of the first authorization interface corresponding to the application identifier and the authorization name, the first authorization interface includes multiple authorization options for the first authorization;

A display module, configured to generate the first authorization interface on an upper layer of the interface of the first application according to the view resource.
The device according to claim 12, characterized in that,

The first application includes a first guide interface, the first guide interface is generated when the first application's previous request for the first permission is rejected, the first guide interface includes a jump option, The first click operation includes an operation in which the user clicks the jump option.
The device according to claim 13, characterized in that,

The first application includes a second authorization interface, the second authorization interface is generated when the first application's previous request for the first permission is not rejected, and the second authorization interface includes a jump option and multiple authorization options of the first permission, the first click operation includes the user clicking the jump option.
The device according to claim 13, characterized in that,

The multiple authorization options in the first authorization interface are partly or completely different from the multiple authorization options in the second authorization interface.
The device according to any one of claims 12-15, characterized in that,

The display module is configured to generate the first authorization interface on the upper layer of the first application interface in the form of a window according to the view resource, the height of the window is smaller than the height of the display screen, and the height of the window is The width is less than the width of the display screen.
The device according to any one of claims 12-16, characterized in that,

the second application includes a first authorization switch;

The setting module is configured to acquire the state of the first authorization switch in response to the user's first click operation;

The setting module is further configured to acquire the application identifier and the permission name when the first authorization switch is turned on;

The setting module is further configured to jump from the first application to the second application when the first authorization switch is in the off state.
The device according to any one of claims 12-17, further comprising: an authority control module;

The permission control module is configured to obtain the application identifier and the permission name from the setting module;

The permission control module is configured to determine the view resource according to the application identifier and the permission name.
The device according to claim 18, characterized in that,

The permission control module is further configured to send the view resource to the display module.
The device according to claim 18, characterized in that,

The authority control module is further configured to send the view resource to a setting module;

The setting module is further configured to send the view resource to the display module.
The device according to any one of claims 18-20, characterized in that,

The permission control module 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, Obtain the authorization result from the authority control module.
The device according to any one of claims 12-21, further comprising at least one of the following:

The first permission includes positioning permission;

The first application includes at least map applications, motion track recording applications, and taxi-hailing applications;

The second application includes a setting application of the operating system of the terminal device;

The size of the first authorization interface is smaller than the size of the interface of the first application.
A terminal device, characterized in that it includes: a processor, a memory, and a display screen; the memory stores program instructions, and when the program instructions are executed by the processor, the terminal device performs claim 1- 11. The method described in any one of the items.
A chip system, characterized in that it includes: a memory and a processor; the memory stores program instructions, and when the program instructions are executed by the processor, the chip system performs any one of claims 1-11. method described in the item.
A computer storage medium, wherein program instructions are stored in the computer-readable storage medium, and when the program instructions are run on a computer, the computer is made to execute the method according to any one of claims 1-11.
A computer program product, characterized in that, when it is run on a computer, it causes the computer to execute the method described in any one of claims 1-11.