Application permission application method, device and computer equipment

Abstract

The application relates to an application permission application method and device, a computer device, a storage medium and a computer program product. The method comprises the following steps: in response to a permission application request initiated based on an application page, jumping to a callback page; wherein the permission application request is used to request to call a target system permission; detecting a current permission state of the target system permission by calling a first interface through the callback page; in the case that the current permission state is a to-be-started state, executing a permission application operation by calling a second interface through the callback page; obtaining permission description information corresponding to the target system permission, and displaying the permission description information through the callback page. The method can improve the permission control efficiency.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, computer device, storage medium, and computer program product for requesting permissions for an application. Background Technology

[0002] In recent years, mobile applications have been widely used and have played an irreplaceable role in promoting economic and social development and serving people's livelihoods. At the same time, phenomena such as forced authorization, excessive requests for permissions, and collection of personal information beyond the scope of applications have also attracted attention.

[0003] Typically, if an application lacks certain permissions granted by the user, the terminal cannot access system resources that require specific permissions, nor can it utilize these resources to perform corresponding functionalities. In related technologies, the application first determines whether the function it intends to perform requires the necessary system permissions. If the required permissions are available, the application then requests those permissions. However, this approach requires developers to modify every instance of system permission request logic within the application code, resulting in redundant, cumbersome, and error-prone code. Summary of the Invention

[0004] Therefore, it is necessary to provide a method, apparatus, computer device, computer-readable storage medium, and computer program product for requesting permissions for applications that can improve the efficiency of permission control, in order to address the above-mentioned technical problems.

[0005] Firstly, this application provides a method for requesting permissions for an application. The method includes:

[0006] In response to a permission request initiated from an application page, the user is redirected to a callback page; wherein the permission request is used to request access to the target system.

[0007] The callback page calls the first interface to detect the current permission status of the target system.

[0008] When the current permission status is pending, the second interface is invoked through the callback page to perform the permission request operation;

[0009] Obtain permission description information corresponding to the target system permissions, and display the permission description information through the callback page.

[0010] Secondly, this application also provides a permission request device for an application. The device includes:

[0011] The redirect module is used to respond to a permission request initiated by an application page and redirect to a callback page; wherein the permission request is used to request access to the target system.

[0012] The detection module is used to detect the current permission status of the target system permissions by calling the first interface through the callback page;

[0013] The application module is used to call the second interface through the callback page to perform a permission application operation when the current permission status is pending.

[0014] The display module is used to obtain permission description information corresponding to the permissions of the target system, and display the permission description information through the callback page.

[0015] In one embodiment, the jump module is further configured to respond to a permission request initiated based on the application page, pull up a callback page above the application page, and jump to the callback page, wherein the callback page is transparent and covers at least a portion of the application page.

[0016] In one embodiment, the above-mentioned apparatus further includes a first request initiation module, which is used to enter the application page of the application and, if the application page is an application permission page, directly initiate a permission request for the target system permission that matches the application permission page.

[0017] In one embodiment, the apparatus further includes a second request initiation module, configured to display an application page of the application, the application page displaying functional interactive elements; and in response to a triggering operation on the functional interactive elements in the application page, to initiate a permission request for a target system permission matching the functional interactive elements.

[0018] It should be noted that the first request initiating module and the second request initiating module mentioned above can be the same request initiating module or different request initiating modules. This application embodiment does not impose any restrictions on this.

[0019] In one embodiment, the target system permission is any system permission in the preset system permissions. Any system permission is a system permission required to ensure the normal use of the application page's functions. The preset system permissions include at least one of program execution permissions and function execution permissions.

[0020] In one embodiment, the device further includes a blacklist module, used to determine whether the application page that initiated the permission request is a blacklist page through a callback page; if the application page is not a blacklist page, the step of calling the first interface through the callback page to detect the current permission status of the target system permissions is executed; otherwise, the call to the target system permissions is prohibited.

[0021] In one embodiment, the detection module is further configured to obtain a permission identifier corresponding to the requested target system permission; pass the permission identifier to the system by calling the system interface through the callback page; and obtain the current permission status of the target system permission returned by the system based on the permission identifier.

[0022] In one embodiment, the current permission status includes an unenabled state and an enabled state. The device further includes a status judgment module, which is used to obtain the previous application time point corresponding to the previous permission application request by calling a third interface through a callback page when the current permission status is unenabled; and to determine that the current permission status is an unenabled state pending to be enabled when the time interval between the current application time point of the current permission application request and the previous application time point is greater than a preset time interval.

[0023] In one embodiment, the device further includes a status description module, which determines that the current permission status is a temporarily disabled status in the unenabled state when the time interval between the current application time and the previous application time is not greater than a preset time interval; and displays status description information associated with the temporarily disabled status through the application page when the current permission status is a temporarily disabled status.

[0024] In one embodiment, the apparatus further includes a startup module for displaying an introductory page by running an empty process in response to a startup operation on the application, wherein the introductory page includes at least two operation elements that are triggered to determine the startup state of the application; running the main process of the application in response to a triggering operation on a first operation element in the introductory page to initialize the application; and ending the empty process and closing the application in response to a triggering operation on a second operation element in the introductory page.

[0025] In one embodiment, the startup module is further configured to, in response to a startup operation on the application, run an empty process to display a simulated login page, and display an introduction page floating above the simulated login page; wherein the introduction page covers at least a portion of the display of the simulated login page.

[0026] In one embodiment, the startup module is further configured to, in response to a startup operation on the application, determine whether there is any historical consent operation information for the introductory page; if no historical consent operation information exists, display the introductory page by running an empty process.

[0027] Thirdly, this application also provides a computer device. The computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to perform the following steps:

[0028] In response to a permission request initiated from an application page, the user is redirected to a callback page; wherein the permission request is used to request access to the target system.

[0029] The callback page calls the first interface to detect the current permission status of the target system.

[0030] When the current permission status is pending, the second interface is invoked through the callback page to perform the permission request operation;

[0031] Obtain permission description information corresponding to the target system permissions, and display the permission description information through the callback page.

[0032] Fourthly, this application also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program thereon, which, when executed by a processor, performs the following steps:

[0033] In response to a permission request initiated from an application page, the user is redirected to a callback page; wherein the permission request is used to request access to the target system.

[0034] The callback page calls the first interface to detect the current permission status of the target system.

[0035] When the current permission status is pending, the second interface is invoked through the callback page to perform the permission request operation;

[0036] Obtain permission description information corresponding to the target system permissions, and display the permission description information through the callback page.

[0037] Fifthly, this application also provides a computer program product. The computer program product includes a computer program that, when executed by a processor, performs the following steps:

[0038] In response to a permission request initiated from an application page, the user is redirected to a callback page; wherein the permission request is used to request access to the target system.

[0039] The callback page calls the first interface to detect the current permission status of the target system.

[0040] When the current permission status is pending, the second interface is invoked through the callback page to perform the permission request operation;

[0041] Obtain permission description information corresponding to the target system permissions, and display the permission description information through the callback page.

[0042] The aforementioned application's permission request method, apparatus, computer device, storage medium, and computer program product, in response to a permission request initiated by an application page, redirects to a callback page. The callback page then calls a first interface to detect the current permission status of the target system. If the current permission status is pending, the callback page calls a second interface to execute the permission request operation and obtains the permission description information corresponding to the target system permissions, which is then displayed on the callback page. This unified execution of the permission request operation through the callback page eliminates the need for each application page to request permissions from the system separately. This not only improves the efficiency of permission requesting but also reduces redundancy at the code level, making the code logic more concise and less prone to errors. Attached Figure Description

[0043] Figure 1 This is an application environment diagram of a permission request method for an application in one embodiment;

[0044] Figure 2 This is a flowchart illustrating the permission request method of an application in one embodiment;

[0045] Figure 3A This is a schematic diagram of a calendar page in one embodiment;

[0046] Figure 3B This is a schematic diagram of a page displaying permission information on a callback page in one embodiment.

[0047] Figure 3C This is a schematic diagram of a chat window page displaying permission information in one embodiment.

[0048] Figure 3D This is a schematic diagram of a page displaying permission description information on a check-in page in one embodiment;

[0049] Figure 4 This is a schematic diagram of the process of launching an application in one embodiment;

[0050] Figure 5 This is a schematic diagram of a page in one embodiment;

[0051] Figure 6A This is a schematic diagram illustrating the principle of launching an application in one embodiment;

[0052] Figure 6B This is a flowchart illustrating the process of starting an application to run an empty process in one embodiment;

[0053] Figure 7A This is a schematic diagram illustrating the principle of an application's permission request method in one embodiment;

[0054] Figure 7BThis is a flowchart illustrating the permission request method for an application in another embodiment;

[0055] Figure 7C This is a flowchart illustrating the permission request method of an application in yet another embodiment;

[0056] Figure 8 This is a structural block diagram of an application permission request device in one embodiment;

[0057] Figure 9 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0058] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0059] The permission request method for applications provided in this application embodiment can be applied to, for example, Figure 1 In the application environment shown, terminal 102 communicates with server 104 via a network. A data storage system can store the data that server 104 needs to process. The data storage system can be integrated onto server 104, or it can be located in the cloud or on another server. Terminal 102 is equipped with an application that, in response to a permission request initiated by the application page, redirects to a callback page. The callback page detects the current permission status of the target system and, if the current permission status is pending, executes a permission request operation through the callback page to obtain permission description information corresponding to the target system permissions, which is then displayed on the callback page. After obtaining the operating permissions, the application on terminal 102 can interact with the server.

[0060] The terminals can be, but are not limited to, various desktop computers, laptops, smartphones, tablets, IoT devices, and portable wearable devices. IoT devices can include smart speakers, smart TVs, smart air conditioners, and smart in-vehicle devices. Portable wearable devices can include smartwatches, smart bracelets, and head-mounted devices. The servers can be independent physical servers, server clusters or distributed systems composed of multiple physical servers, or cloud servers providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms.

[0061] In one embodiment, such as Figure 2As shown, a method for requesting permissions for an application is provided. This embodiment illustrates the application of this method to a terminal. It is understood that this method can also be applied to a server, and further to a system including both a terminal and a server, and implemented through interaction between the terminal and the server. In this embodiment, the method includes the following steps:

[0062] Step S202: In response to the permission request initiated by the application page, redirect to the callback page; wherein, the permission request is used to request access to the target system permissions.

[0063] The application (APP) is loaded onto the terminal and runs on the operating system configured on the terminal. The operating system is the terminal's computer management and control program, such as Android, iOS, or other operating systems; this embodiment does not limit the specific operating system. For simplicity, the operating system will be referred to simply as the system below, and will not be elaborated further. The application page is the display page shown when the application runs. The application can be a standalone application installed via an installation package, or a mini-program application that can be used without downloading and installation. The terminal system has system calls to support the application. For convenience and security reasons, the application needs to request resources corresponding to its permissions from the system during runtime; this is the permission request operation in the system call.

[0064] The target system permission is any system permission from the preset system permissions. Any system permission is a system permission required to ensure the normal operation of the application page. The preset system permissions include at least one of the following: program execution permissions and function execution permissions. Program execution permissions refer to permissions related to the operation of the application, including but not limited to one or more of the following: auto-start permission, notification bar permission, background operation permission, network permission, and floating window permission. Function execution permissions refer to permissions related to the functions provided by the application and corresponding to the application page, including but not limited to one or more of the following: location permission, calendar permission, microphone permission, photo album permission, information collection permission, and camera permission. Therefore, the application requests permissions when making resource calls related to permissions, effectively protecting information security, enhancing the protection of system permissions, and thus ensuring the information security of users.

[0065] The callback page is configured to perform permission request operations. Unlike application pages, which provide various application functions, the callback page acts as an intermediary for data interaction and resource access between the application and the system. Whenever an application initiates a permission request based on an application page, the terminal redirects to and accesses the callback page. The callback page centrally handles the permission request operations of each application page, eliminating the need for each application page to request permissions from the system separately. This avoids frequent interactions between application pages and the system, effectively ensuring the security of resources within the system. For example, the callback page can be implemented using Hook technology to intercept permission request requests initiated by the application based on different application pages and uniformly execute the permission request operations through the callback page. This eliminates the need for each application page to request permissions from the system separately, improving the efficiency of permission requests and reducing redundancy at the code level, resulting in more concise and error-free code logic.

[0066] Specifically, the terminal displays an application page and detects permission request requests initiated by the application based on the application page. These permission requests request the system to access the target system permissions corresponding to the application page, ensuring the normal operation of the functions corresponding to the application page. When a permission request is detected, the terminal redirects to a callback page to perform subsequent permission request operations. The terminal may redirect to the callback page by closing the application page, opening and displaying the callback page, minimizing or collapsing the application page and switching to the callback page, or opening the callback page on top of the application page while keeping the application page open and displayed, etc. This embodiment does not limit the specific method used.

[0067] It should be noted that permission requests initiated based on an application page can be either requests initiated upon launching the application page or requests initiated based on operations performed on the application page. Specifically, permission requests initiated based on an application page can occur when the terminal navigates to an application page, at which point the application initiates a permission request based on the opening or launching of the application page. For example, when the terminal navigates from one application page to another, the application initiates a permission request simultaneously with the opening of the other application page.

[0068] Of course, this is not the only possibility. Permission requests initiated from an application page can also occur when the terminal opens or launches the application page, detecting triggering actions on the application page and responding to those actions by initiating a permission request. These triggering actions include, but are not limited to, one or more of the following: clicking, touching, swiping, dragging, and pressing. For example, when the system detects that a user has long-pressed an application page, the application initiates a permission request to request access to the target system permissions.

[0069] Step S204: Call the first interface through the callback page to detect the current permission status of the target system.

[0070] It should be understood that when an application requests permissions from the system, it needs to invoke resources through system interfaces provided by the system. Specifically, after an application initiates a permission request, the terminal redirects to a callback page, which then calls the first interface to detect the current permission status of the target system permission requested in the permission request. The current permission status includes both disabled and enabled states. The disabled state includes pending activation and temporarily disabled states. The temporarily disabled state refers to a state where permission requests are prohibited for a preset time period to avoid frequent permission requests.

[0071] For example, the callback page passes relevant parameters of the target system permission to the system through the first interface. These relevant parameters are used by the system to determine what kind of system permission the system permission to be detected is, and to query the current permission status of the target system permission. When the current permission status of the target system permission is pending, the terminal performs subsequent permission request operations through the callback page.

[0072] The relevant parameters may be the name of the system permission or a pre-configured permission identifier corresponding to each system permission. In some embodiments, detecting the current permission status of the target system permission by calling the first interface through the callback page includes: obtaining the permission identifier corresponding to the requested target system permission; passing the permission identifier to the system by calling the system interface through the callback page, and obtaining the current permission status of the target system permission returned by the system based on the permission identifier.

[0073] Specifically, the terminal obtains the permission identifier corresponding to the target system permission requested by the application page through the callback page, and then calls the system interface through the callback page to pass the permission identifier to the system. The system then queries the current permission status of the target system permission based on the permission identifier, and returns the query result to the callback page, which can then obtain the current permission status of the target system permission. This system interface can be the first interface or another system interface different from the first interface; this embodiment does not impose any restrictions on this.

[0074] For example, if the target system permission is location permission, used to obtain the terminal's real-time location, when the application initiates a permission request based on the application page, the application page passes the permission identifier corresponding to the target system permission to the callback page, which then obtains the permission identifier.

[0075] In some embodiments, since the requested target system permission is initiated based on an application page, there is a correspondence between the target system permission and the application page (e.g., the application's calendar page corresponds to calendar permissions, the camera page corresponds to camera permissions, etc.). The callback page can determine the corresponding target system permission and its permission identifier based on the application page. For example, different application pages are pre-configured with corresponding page numbers. The callback page can determine the corresponding target system permission based on parameters such as the application page's page number, and retrieve the permission identifier corresponding to the target system permission from memory or cache, etc.

[0076] In the above embodiments, the permission identifier is transmitted to the system through the system interface. The system can quickly locate the system permission to be queried based on the permission identifier, which improves the efficiency of querying the system permission status and thus improves the efficiency of requesting permissions.

[0077] Step S206: If the current permission status is pending, the second interface is called through the callback page to perform the permission request operation.

[0078] It's easy to understand that when the callback page receives a system-returned detection result indicating that the current permission status of the target system is "enabled," it means the system has already enabled the target system permission, and the callback page does not need to perform a permission request operation. When the callback page receives a system-returned detection result indicating that the target system permission has not yet been enabled, the callback page will continue to perform subsequent permission request operations.

[0079] Specifically, when the callback page obtains the detection result returned by the system and determines that the current permission status of the target system is in the pending state of not being enabled, the terminal calls the second interface through the callback page to perform the permission request operation so that the system can grant the corresponding permissions to the application.

[0080] In some embodiments, the first interface and the second interface can be different system interfaces. By pre-configuring the parameters of the first and second interfaces, they can be used to perform different functions. For example, the first interface can be used for data communication between the system and the callback page when called, allowing the system to receive a permission identifier transmitted by the callback page and detect the current permission status of the target system based on this identifier. Alternatively, after the system performs an operation to enable permissions for the target system, it can call the second interface to report the execution result of the permission request operation to the callback page. Thus, by executing different operation processes through different system interfaces, and by transmitting data that conforms to different interface usage specifications when calling different system interfaces, the system can directly parse the received data or parameters and perform the corresponding operation based on the interface usage specifications after receiving the data or parameters, without further identification. This improves the system's processing efficiency.

[0081] In other embodiments, for the purpose of rationally allocating system resources to save resource consumption, the first interface and the second interface can also be configured as the same system interface, eliminating the need to configure parameters for different system interfaces separately and reducing code redundancy.

[0082] It should be noted that the terms "first" and "second" mentioned above are used in this application to describe different system interfaces, but these system interfaces should not be limited by these terms. These terms are only used to distinguish one system interface from another. For example, the first interface can be called the second interface, and similarly, the second interface can be called the first interface. In some embodiments, the first interface and the second interface can be different system interfaces, while in other embodiments, the first interface and the second interface can be the same system interface. This application does not limit this aspect.

[0083] In some embodiments, after the terminal obtains the system permissions corresponding to the application page through the callback page, it can call the corresponding system resources through the application page to realize the functions provided by the application page. The terminal can then interact with the server through the application.

[0084] Step S208: Obtain permission description information corresponding to the target system permissions, and display the permission description information through the callback page.

[0085] The permission description information describes the relevant information of the system permissions that need to be enabled, including but not limited to one or more of the following: the name of the system permission, the reason for its use, and the usage scenario. For example, when the target system permission is calendar permission, the corresponding permission description information might be "This permission is used to display the calendar, create and modify calendars, and synchronize schedules." Another example is microphone permission, which might be "This permission is used to record audio for voice chat, voice calls, and live streaming." Yet another example is location permission, which might be "This permission is used to send location information," and so on.

[0086] Specifically, the terminal obtains permission description information corresponding to the target system permissions through a callback page, and displays the permission description information through the callback page. The display methods include, but are not limited to, text, images, video, voice, and a combination of two or more of the above. The callback page can display the permission description information near the top, bottom, or other page locations on the application page.

[0087] For example, the application displays as follows Figure 3A The calendar page shown allows users to create new events, such as setting participants, start time, end time, and whether to include reminders. For example, when a user clicks the "Create Schedule" button on the calendar page, the application requests calendar permissions, and the terminal is redirected to a callback page. To ensure the user is unaware of the callback page redirection, it is transparent and overlaid on the calendar page. Figure 3B As shown, the application can also display a pop-up window on the calendar page to prompt "Calendar permission required." After the callback page retrieves the permission description information corresponding to the calendar permission, it displays a pop-up window at the top showing the permission description, such as "Display calendar, create and modify calendar, calendar synchronization, etc." to indicate the usage scenarios of the calendar permission. To improve the user experience, the permission description information displayed on the callback page can be shown simultaneously with the pop-up window prompting for the required permission.

[0088] For example Figure 3C As shown, the application displays a chat window. For example, when the user triggers the "Press and hold to speak" button displayed in the chat window, the application initiates a permission request for microphone permissions, and the terminal redirects to a callback page. After the callback page obtains the permission description information corresponding to the microphone permissions, a pop-up window appears at the top of the callback page displaying the permission description information for the microphone permissions, such as "Record audio to enable voice chat, voice calls, live streaming, etc." to indicate the usage scenarios of the microphone permissions.

[0089] For example Figure 3DAs shown, when the application opens the check-in page, it directly initiates a permission request for location permissions. While the application displays a pop-up window stating "Location permissions required," it simultaneously displays permission descriptions for the location permissions at the top of the application page, such as "Create check-in rules, obtain check-in location, send location, set address, commuting reminders, reserve meeting rooms, etc." to indicate the usage scenarios for calendar permissions.

[0090] Of course, this is not the only option. The callback page can also display the permission information in any other suitable way, such as displaying it above the application page and at the bottom of the application page, or displaying it as a scrolling banner. Those skilled in the art will understand that any adaptive modifications made based on the inventive concept of this application are within the scope of this application.

[0091] In the permission request method of the aforementioned application, in response to a permission request initiated by an application page, a redirection to a callback page is initiated. The callback page calls a first interface to check the current permission status of the target system. If the current permission status is pending, the callback page calls a second interface to execute the permission request operation and obtains the permission description information corresponding to the target system permission, which is then displayed on the callback page. This unified permission request operation via the callback page eliminates the need for each application page to request permissions from the system separately, improving the efficiency of permission requesting and reducing redundancy at the code level, resulting in more concise and error-free code logic. Furthermore, this method ensures that the application runs legally and compliantly, achieving dynamic control over the application's access to various system permissions and effectively protecting user privacy. During application runtime, the system permission request operations for various functions of the application are uniformly controlled through the callback page, eliminating the need to modify the code logic at every point in the application code involving system permission requests, thus ensuring high reusability.

[0092] In some cases, if an application navigates to multiple application pages while providing a function, the user needs to close the new application page and return to the original application page after browsing the new one, which is cumbersome and results in a poor user experience. To ensure a good user experience when using the application, in some embodiments, in response to a permission request initiated from an application page, the user is redirected to a callback page. This includes: in response to the permission request initiated from an application page, a callback page is displayed above the application page, and the user is redirected to the callback page, wherein the callback page is transparent and covers at least a portion of the application page.

[0093] Specifically, in response to a permission request initiated by the application based on the application page, the terminal pulls up a callback page on top of the application page and redirects to the callback page. By pulling up the callback page on top of the existing application page, rather than opening and displaying the callback page, the user does not need to close the callback page to return to the original application page, avoiding cumbersome page switching operations. Simultaneously, the callback page is set to a transparent page and appears transparent, covering part or all of the application page. Therefore, the application still displays the content of the application page, and the user is unaware of the redirection to the callback page. The application's background operations (the permission request process executed through the callback page) are invisible. For the user, all operations are completed after the application page is opened, improving the user experience. In the above embodiment, by pulling up the callback page on top of the application page and configuring the callback page as a transparent page, the user is unaware of the switch between the callback page and the application page, ensuring a smooth user experience.

[0094] In some embodiments, before redirecting to a callback page in response to a permission request initiated on an application page, the method further includes: entering the application page of the application, and if the application page is an application permission page, directly initiating a permission request for a target system permission that matches the application permission page.

[0095] Application permission pages are the application pages displayed by an application during runtime that trigger the detection or determination of target system permissions. For example, during normal operation, the terminal switches between different application pages based on user actions, such as browser windows. These pages do not require system permissions to provide their functions, so opening such application pages on the terminal does not trigger the application to initiate permission requests based on the application page. However, application pages such as chat windows, calendar pages, and check-in pages require corresponding system permissions (such as voice permissions, calendar permissions, location permissions, etc.) to provide functions such as voice chat, creating schedules, and check-in. For example, when the terminal enters the check-in page, since the check-in function provided by the check-in page requires system location permissions to function properly, and the check-in function cannot be used normally without location permissions, the application directly initiates a permission request for location permissions matching the check-in page when entering this check-in page.

[0096] Specifically, when the terminal enters the application page during application execution, it checks whether the entered application page is an application permission page. When the application page is an application permission page, the application directly initiates a permission request for the target system permission that matches the application permission page. The terminal then redirects to the callback page and executes the subsequent permission request operation through the callback page.

[0097] In the above embodiments, permission request is initiated upon entering the application permission page, eliminating the need for user intervention and improving the efficiency of permission request.

[0098] In some cases, to improve interactivity and ensure a good user experience, functional interactive elements are set in the application page. The application only initiates a permission request when the functional interactive element is triggered. Therefore, in some embodiments, before redirecting to the callback page in response to a permission request initiated based on the application page, the method further includes: displaying the application page of the application, which displays the functional interactive elements; and in response to a triggering operation on the functional interactive element in the application page, initiating a permission request pointing to the target system permission matching the functional interactive element.

[0099] Interactive elements are displayed and interact with the user through page controls. These elements can be one or more of the following: virtual buttons, text, icons, etc., on the application page. The interactive elements are matched with the target system permissions corresponding to the application page. For example, in the application's chat window, the interactive element could be a microphone icon in the chat window, which matches the microphone permissions. Similarly, in the application's check-in page, the interactive element could be the text "Check-in Now," which matches the location permissions.

[0100] Specifically, the terminal displays the application's application page and its interactive elements for user interaction. When the terminal detects that the user triggers an interactive element, it responds by sending a permission request through the application to the system for the target system permissions that match the interactive element.

[0101] For example, the functional interaction element is the text, icon, or virtual button for "Create Schedule" displayed on the application's calendar page. When the terminal detects a triggered operation on the functional interaction element for "Create Schedule", the application initiates a permission request for calendar permissions.

[0102] In the above embodiments, the user interacts with the application page through functional interactive elements provided on the application page, and requests permissions only when the user triggers the functional interactive elements, thus providing diversified page functions and improving the user experience.

[0103] As applications are updated and iterated, some application pages may no longer meet the requirements of new permission control or privacy protection. Typically, developers need to locate and modify the corresponding code logic for each application page individually, a tedious and error-prone process. Therefore, in some embodiments, before calling the first interface via the callback page to check the current permission status of the target system, the method further includes: determining, via the callback page, whether the application page initiating the permission request is a blacklisted page; if the application page is not a blacklisted page, performing the step of calling the first interface via the callback page to check the current permission status of the target system; otherwise, prohibiting the invocation of target system permissions.

[0104] Specifically, after the terminal is redirected to the callback page, it checks whether the application page that initiated the permission request is a blacklisted page. If the terminal determines through the callback page that the application page is not a blacklisted page, it proceeds to the next step of calling the first interface through the callback page to check the current permission status of the target system. Otherwise, if the application page is determined to be a blacklisted page, the terminal prevents that callback page from invoking the target system's permissions.

[0105] In the above embodiments, the application page is checked for blacklisting by a callback page. If the page is in the blacklist, the access to the target system permissions is directly prohibited, which improves the efficiency of permission request and realizes the management of page permissions.

[0106] As mentioned above, the current permission status includes both the pending permission status and the temporarily disabled status. To avoid frequent permission requests, a preset time interval can be set to allow only one permission request operation within each interval, such as 1 hour, 24 hours, or 48 hours. Accordingly, in some embodiments, when the current permission status is pending permission, before calling the second interface via the callback page to execute the permission request operation, the method further includes: when the current permission status is not enabled, calling the third interface via the callback page to obtain the previous request time point corresponding to the previous permission request; if the time interval between the current request time point and the previous request time point is greater than the preset time interval, the current permission status is determined to be the pending permission status within the not enabled state.

[0107] Each time the terminal initiates a permission request to the system via the callback page, the callback page simultaneously records and stores the request time. The request time is the specific moment the permission request is initiated. The time interval is the duration between two adjacent permission request operations.

[0108] It should be noted that the third interface is a system interface, which may be the same system interface as the first / second interface or a different system interface. This application embodiment does not impose any restrictions on this.

[0109] Specifically, when the current permission status is "not enabled," the terminal calls a third-party interface via a callback page to extract the previous request time from the system, and compares the previous request time with the current request time corresponding to the current permission request. If the time interval between the previous and current request times is greater than a preset time interval, it indicates that permissions have not been frequently requested. The terminal then determines the current permission status as "pending enabling" within the "not enabled" state via the callback page and executes subsequent permission request operations.

[0110] In the above embodiments, by detecting the time interval between the current application time and the previous application time, and prohibiting permission application operations when the time interval is less than a preset time interval, frequent permission application operations are avoided, and the frequency of page application is controlled.

[0111] In some embodiments, if the time interval between the current application time and the previous application time is not greater than a preset time interval, the current permission status is determined to be a temporarily disabled status in the unenabled state; if the current permission status is a temporarily disabled status, status description information associated with the temporarily disabled status is displayed on the application page.

[0112] Specifically, the terminal compares the time of the previous permission request with the current time of the current permission request. If the time interval between the previous and current request times is not greater than a preset time interval, it indicates that the interval between two adjacent permission request operations is too short, suggesting frequent permission requests. The terminal then determines the current permission status as temporarily disabled (not enabled) via a callback page. Furthermore, when the current permission status is temporarily disabled, the terminal prevents the callback page from invoking the target system permissions.

[0113] In addition, to explain the situation to the user, the terminal also displays status information associated with the current permission status through the application page. This status information describes the specific details of the associated current permission status. For example, when the current permission status is "enabled," the terminal can display status information associated with the enabled status through the application page, such as "Permission xx enabled." As another example, when the current permission status is "temporarily disabled," the terminal prevents the callback page from invoking the target system permissions and displays status information associated with the temporary disabled status through the application page, such as "Due to excessive permission requests, please try again in xx hours."

[0114] In the above embodiments, the application frequency is limited by setting a temporary disabled state, which avoids frequent application operations. At the same time, by displaying status description information associated with the temporary disabled state, users can understand the relevant policies and explanations, thus improving the user experience.

[0115] It's easy to understand that, aside from requesting system permissions for application functions during application runtime and needing to explain this to the user when requesting such permissions, applications may need to access users' personal information at runtime, requiring user authorization beforehand. Typically, developers would inspect all places in the application code that use users' personal information and modify the corresponding code logic after the authorization request logic, thus ensuring that the application can only continue running with user authorization. This method is cumbersome, requiring developers to make numerous complex logical modifications to the application code, and forcibly modifying the code can sometimes cause other timing logic problems.

[0116] Furthermore, some applications are typically associated with several third-party libraries. Some of these libraries must be initialized upon application startup, and this initialization process uses the user's personal information. In related technologies, initializing third-party libraries upon application startup allows for the collection of user information without authorization or consent, resulting in a breach of user privacy. Therefore, in some embodiments, such as... Figure 4 As shown in the embodiments of this application, the permission request method for an application further includes the following steps:

[0117] In step S402, in response to the application launch operation, an empty process is run to display an introductory page, which includes at least two operation elements that are triggered to determine the application's launch status.

[0118] Specifically, when a terminal launches an application, it displays an introductory page by running an empty process. This page displays information such as a "Privacy Policy Statement" or "Disclaimer," and details about third-party SDKs (Software Development Kits) that collect user information. This informs the user about the third-party SDK's information collection practices and obtains the user's consent or authorization. For example, the "Privacy Policy Statement" explains what specific user information the application involves, how it collects, uses, stores, and shares user information, and the methods the application provides for accessing, updating, controlling, and protecting this information, etc.

[0119] The introduction page includes at least two types of operation elements, including at least a first operation element and a second operation element. When the first operation element and the second operation element are triggered, they correspond to different startup states of the application, respectively.

[0120] For example, such as Figure 5 As shown, when the terminal launches the application, it displays an introductory page by running an empty process. This introductory page displays a "Privacy Protection Guideline," including: "Welcome to XXX! We attach great importance to protecting your personal information. Please read and understand our Privacy Policy carefully. Please pay special attention to the following: 1. We may request system permissions from you based on your usage scenarios and with your consent, such as storage… 2. xxx…." The introductory page also includes two operation elements: a virtual "Agree" button and a virtual "Disagree" button.

[0121] In step S404, in response to the triggering operation of the first operation element in the introduction page, the main process of the application is run to initialize the application.

[0122] Specifically, in response to a triggering operation of the first operation element on the introduction page, the terminal runs the application's main process. The terminal then uses the main process to initialize the application, such as initializing third-party libraries. For example, the first operation element might be an icon indicating that the user has read the content of the introduction page, or an icon indicating that the user agrees to the privacy policy, or a virtual "Agree" button. When the user triggers the first operation element, the terminal determines that it has obtained the user's authorization before running the application's main process.

[0123] In step S406, in response to the triggering operation of the second operation element in the introduction page, the empty process is terminated and the application is closed.

[0124] Specifically, in response to the triggering of the second operation element on the introduction page, the terminal terminates the empty process and closes the application. For example, the second operation element may be an icon indicating that the user has not finished reading the content of the introduction page, or indicating that the user disagrees with the privacy policy, or a virtual button displaying "Disagree," etc. When the user triggers the second operation element, the terminal determines that it has failed to obtain user authorization. Since it cannot obtain user information without user authorization, and the initialization of the application involves the initialization of a third-party library that obtains user information, the terminal directly terminates the empty process and closes the application.

[0125] In the above embodiments, by not running the main process directly when the application starts, but instead running an empty process to handle the logic of the introduction page and display the introduction page to obtain user authorization, the original timing logic of the application code can be maintained without making significant modifications. At the same time, it ensures that the user's personal information is obtained only after user authorization, thereby improving the protection of user privacy.

[0126] Since the terminal has not yet run the application's main process before triggering the first operational element on the introductory page, the application's login interface is not accessed. To provide a good user experience and ensure that the user is unaware of the application starting an empty process, in some embodiments, in response to the application's launch operation, the introductory page is displayed by running an empty process, including: in response to the application's launch operation, running an empty process to display a simulated login page, and displaying the introductory page while it floats above the simulated login page; wherein the introductory page covers at least a portion of the simulated login page's display.

[0127] The simulated login page is used to mimic the style of the real login page, such as displaying the same page style and content as the real login page, so that when the main process is launched and the real login page is opened, the user will not be aware of the switch between the simulated login page and the real login page.

[0128] Specifically, in response to the application launch operation, when the terminal runs an empty process to display the introductory page, it simultaneously displays a simulated login page through the empty process. This simulated login page serves as the background of the introductory page, which floats above it. Typically, to clearly display the explanatory content, the introductory page has high opacity or zero opacity, and the simulated login page, as the background, is at least partially covered or obscured by the introductory page. For example, referring to Figure 6 again, below the introductory page displaying the "Privacy Protection Guidelines," the terminal also displays a simulated login page through the empty process, which is partially obscured by the introductory page.

[0129] In the above embodiments, by displaying a simulated login page as the background of the introductory page, users are unaware that an empty process is running, thus improving the user experience.

[0130] In some cases, if a user is not opening the application for the first time, it is unnecessary to repeatedly display the introductory page to obtain user authorization. Therefore, in some embodiments, in response to an application launch operation, displaying the introductory page by running an empty process includes: determining whether there is historical consent information regarding the introductory page in response to the application launch operation; and, if no historical consent information exists, displaying the introductory page by running an empty process.

[0131] The historical consent information refers to authorization actions performed on the introductory page prior to the current launch, such as agreeing to the "Privacy Policy" by triggering the first operation element to authorize the application to obtain user information. Specifically, in response to launching the application, the terminal checks whether historical consent information exists for the introductory page. If no historical consent information exists, the terminal displays the introductory page by running an empty process to obtain user authorization. If historical consent information exists, it indicates that the application is not launching for the first time and has already obtained user authorization during a previous launch process; in this case, the terminal directly runs the application's main program to launch the application.

[0132] In the above embodiments, if the user has not launched the application for the first time or has previously agreed to the privacy policy and other content, the user does not need to confirm again, thus improving the user experience.

[0133] In a specific scenario, such as Figure 6A As shown, when the application starts, the terminal displays the privacy policy content from the introductory page through an empty process, while simultaneously displaying a simulated login page to ensure the user is unaware of the changes. Once the user agrees, the terminal then starts the main process, which performs initialization, third-party SDK initialization, and displays the actual login page for the user to log in. Figure 6B As shown, the above process includes: launching the application; the terminal checks for historical operation information, i.e., determining whether the application is being launched for the first time (or has been launched before without user authorization); if historical consent operation information exists, the terminal launches the main process for initialization. If no historical consent operation information exists, the terminal launches an empty process, displays the privacy policy content on the introductory page through the empty process, and detects user actions on the operation elements on the introductory page. For example, when the terminal detects that the user has clicked the virtual "Agree" button, it launches the main process for initialization. Conversely, when the terminal detects that the user has clicked the virtual "Disagree" button, it terminates the empty process and closes the application. Thus, the original code logic of the application does not need to be changed, while effectively protecting user privacy.

[0134] When an application is running, it displays multiple application pages, such as page A, page B, and page C. Figure 7AAs illustrated in the example, an application can initiate permission requests based on page A, page B, or page C to request system permissions corresponding to those pages. In response to a permission request initiated by an application page, the terminal redirects to a callback page, which then performs the permission request operation with the system. The system returns the request result to the callback page, which in turn returns to the original application page. The callback page can detect the time interval between the application page's previous request and the current request. If the time interval is greater than a preset interval, the permission request is allowed; otherwise, if it is less than the preset interval, the application page's permission request is prohibited. This limits the frequency of permission requests and avoids frequent permission requests. The callback page also has a blacklist filtering function; if an application page is blacklisted, its permission requests are prohibited. In some embodiments, the callback page can also report the results of the permission request operation to the server for storage. This manages and controls the application page's permission requests, improves application security, and further protects user privacy.

[0135] For example Figure 7B As shown in the illustration, using a specific example, the above method corresponds to the following process: An application requests permissions based on page A, and the terminal redirects to a callback page. The terminal checks whether the system permissions corresponding to page A are enabled through the callback page, i.e., whether page A has permissions. If page A has permissions enabled, the terminal returns to the original page (i.e., page A) with permissions via the callback page. If page A does not have permissions, the terminal continues to check whether page A has been accessed and requested within a certain period. If so, it indicates that permission requests are too frequent, and the terminal returns to the original page with no permissions via the callback page. If the terminal determines that page A has not been accessed and requested within a certain period, the terminal calls the system interface through page A to perform a permission request operation, and simultaneously displays a pop-up window on page A displaying "Requires xx permissions" and checks whether the user agrees. When the user agrees, the terminal returns to the original page with permissions via the callback page; conversely, when the user disagrees, the terminal returns to the original page with no permissions via the callback page.

[0136] For example Figure 7CTo illustrate further with a specific example, the above method corresponds to the following process: An application requests permissions based on page A, and the terminal redirects to a callback page. The terminal checks if page A is on a blacklist via the callback page. If page A is on the blacklist, permission requests from page A are prohibited. If the terminal detects that page A is not on the blacklist via the callback page, it continues to determine if page A has requested permissions within a certain timeframe. The terminal checks the time interval between page A's previous request and the current request. If the time interval is less than a preset interval, it indicates that the interval between the two permission requests is too short, i.e., frequent requests. In this case, the terminal returns a "no permission" message to page A via the callback page, which is then displayed on page A. If the time interval is greater than the preset interval, permission requests are allowed. The terminal calls the system interface via the callback page to perform the permission request operation, and simultaneously displays permission description information on the callback page, showing relevant usage information for the system permissions corresponding to page A, such as usage scenarios. At the same time, the terminal displays a pop-up window on page A displaying "Requires xx permission" and checks if the user agrees. If the user does not agree, the terminal prohibits page A from requesting permissions. If the user agrees, the callback page receives the permission value returned by the system (e.g., a permission value of 1 indicates permission is enabled, a permission value of 0 indicates permission is not enabled, etc.), thus completing the application and enabling of system permissions for page A. Simultaneously, regardless of the result of the permission application operation for page A—whether page A is prohibited from requesting permission, has no permission, or the permission application is successful and enabled—the terminal reports the result to the server through the callback page for the server to record and store.

[0137] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0138] Based on the same inventive concept, this application also provides a permission request apparatus for implementing the permission request method for the application described above. The solution provided by this apparatus is similar to the implementation described in the above method; therefore, the specific limitations in the one or more application permission request apparatus embodiments provided below can be found in the limitations of the application permission request method described above, and will not be repeated here.

[0139] In one embodiment, such as Figure 8 As shown, an application permission request device 800 is provided, including: a jump module 801, a detection module 802, a request module 803, and a display module 804, wherein:

[0140] The jump module 801 is used to respond to a permission request initiated by the application page and jump to the callback page; wherein, the permission request is used to request the invocation of the target system permissions.

[0141] The detection module 802 is used to detect the current permission status of the target system by calling the first interface through the callback page.

[0142] The application module 803 is used to perform a permission application operation by calling the second interface through a callback page when the current permission status is pending.

[0143] The display module 804 is used to obtain permission description information corresponding to the permissions of the target system and display the permission description information through a callback page.

[0144] In one embodiment, the jump module is further configured to respond to a permission request initiated based on the application page, pull up a callback page above the application page, and jump to the callback page, wherein the callback page is transparent and covers at least a portion of the application page.

[0145] In one embodiment, the above-mentioned apparatus further includes a first request initiation module, which is used to enter the application page of the application and, if the application page is an application permission page, directly initiate a permission request for the target system permission that matches the application permission page.

[0146] In one embodiment, the apparatus further includes a second request initiation module, configured to display an application page of the application, the application page displaying functional interactive elements; and in response to a triggering operation on the functional interactive elements in the application page, to initiate a permission request for a target system permission matching the functional interactive elements.

[0147] It should be noted that the first request initiating module and the second request initiating module mentioned above can be the same request initiating module or different request initiating modules. This application embodiment does not impose any restrictions on this.

[0148] In one embodiment, the target system permission is any system permission in the preset system permissions. Any system permission is a system permission required to ensure the normal use of the application page's functions. The preset system permissions include at least one of program execution permissions and function execution permissions.

[0149] In one embodiment, the device further includes a blacklist module, used to determine whether the application page that initiated the permission request is a blacklist page through a callback page; if the application page is not a blacklist page, the step of calling the first interface through the callback page to detect the current permission status of the target system permissions is executed; otherwise, the call to the target system permissions is prohibited.

[0150] In one embodiment, the detection module is further configured to obtain a permission identifier corresponding to the requested target system permission; pass the permission identifier to the system by calling the system interface through the callback page; and obtain the current permission status of the target system permission returned by the system based on the permission identifier.

[0151] In one embodiment, the current permission status includes an unenabled state and an enabled state. The device further includes a status judgment module, which is used to obtain the previous application time point corresponding to the previous permission application request by calling a third interface through a callback page when the current permission status is unenabled; and to determine that the current permission status is an unenabled state pending to be enabled when the time interval between the current application time point of the current permission application request and the previous application time point is greater than a preset time interval.

[0152] In one embodiment, the device further includes a status description module, which determines that the current permission status is a temporarily disabled status in the unenabled state when the time interval between the current application time and the previous application time is not greater than a preset time interval; and displays status description information associated with the temporarily disabled status through the application page when the current permission status is a temporarily disabled status.

[0153] In one embodiment, the apparatus further includes a startup module for displaying an introductory page by running an empty process in response to a startup operation on the application, wherein the introductory page includes at least two operation elements that are triggered to determine the startup state of the application; running the main process of the application in response to a triggering operation on a first operation element in the introductory page to initialize the application; and ending the empty process and closing the application in response to a triggering operation on a second operation element in the introductory page.

[0154] In one embodiment, the startup module is further configured to, in response to a startup operation on the application, run an empty process to display a simulated login page, and display an introduction page floating above the simulated login page; wherein the introduction page covers at least a portion of the display of the simulated login page.

[0155] In one embodiment, the startup module is further configured to, in response to a startup operation on the application, determine whether there is any historical consent operation information for the introductory page; if no historical consent operation information exists, display the introductory page by running an empty process.

[0156] The modules in the permission request device of the aforementioned application can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0157] In one embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 9 As shown, the computer device includes a processor, memory, input / output interfaces, a communication interface, a display unit, and an input device. The processor, memory, and input / output interfaces are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The input / output interfaces are used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, NFC (Near Field Communication), or other technologies. When executed by the processor, the computer program implements a permission request method for an application. The display unit of the computer device is used to form a visually visible image. It can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.

[0158] Those skilled in the art will understand that Figure 9The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0159] In one embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above method embodiments.

[0160] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the above method embodiments.

[0161] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0162] It should be noted that the user information (including but not limited to users' personal information) and data (including but not limited to data used for analysis, data stored, data displayed) involved in this application are all information and data authorized by the users or fully authorized by all parties, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0163] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0164] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0165] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for requesting permissions for an application, characterized in that, The method includes: In response to an application launch operation, an empty process is run to display an introductory page, which includes at least two operation elements that are triggered to determine the application's launch status. In response to a triggering operation on the first operation element in the introduction page, the main process of the application is run to initialize the application; In response to a triggering operation on the second operation element in the introduction page, the empty process is terminated and the application is closed; When the application is running, in response to a permission request initiated based on an application page, a callback page is displayed above the application page and the user is redirected to the callback page. The permission request is used to request access to the target system permissions. The callback page is transparent and covers at least a portion of the application page. The callback page is configured to perform permission request operations for each application page. Whenever the application initiates a permission request based on an application page, it redirects to and accesses the callback page. The callback page is also used to determine whether the application page initiating the permission request is a blacklisted page. If the application page is not a blacklisted page, the step of calling the first interface through the callback page to detect the current permission status of the target system permissions is executed; otherwise, the application page is prohibited from requesting permissions. The callback page calls the first interface to detect the current permission status of the target system. When the current permission status is pending, the second interface is invoked through the callback page to perform the permission request operation; Obtain permission description information corresponding to the target system permissions, and display the permission description information through the callback page.

2. The method according to claim 1, characterized in that, Before redirecting to the callback page in response to a permission request initiated by the application page, the method further includes: Upon entering the application's application page, and if the application page is an application permissions page, a permission request is directly initiated that points to the target system permissions that match the application permissions page.

3. The method according to claim 1, characterized in that, Before redirecting to the callback page in response to a permission request initiated by the application page, the method further includes: The application page displays the application's application page, which includes interactive functional elements; In response to a triggered operation on a functional interactive element in the application page, a permission request is initiated for the target system permission that matches the functional interactive element.

4. The method according to claim 1, characterized in that, The target system permission is any system permission from the preset system permissions. Any system permission is a system permission required to ensure the normal use of the application page. The preset system permissions include at least one of program execution permission and function execution permission.

5. The method according to claim 1, characterized in that, The step of calling the first interface through the callback page to detect the current permission status of the target system includes: Obtain the permission identifier corresponding to the requested permission of the target system. The system interface is called through the callback page to pass the permission identifier to the system, and the current permission status of the target system permission is obtained by the system based on the permission identifier.

6. The method according to claim 1, characterized in that, The current permission status includes an inactive state and an enabled state. When the current permission status is pending activation, before calling the second interface through the callback page to perform the permission request operation, the method further includes: When the current permission status is not enabled, the callback page calls the third interface to obtain the previous application time point corresponding to the previous permission application request; If the time interval between the current request time and the previous request time is greater than a preset time interval, the current permission status is determined to be a pending-to-be-enabled state within the unenabled state.

7. The method according to claim 6, characterized in that, The method further includes: If the time interval between the current application time and the previous application time is not greater than the preset time interval, the current permission status is determined to be a temporarily disabled status in the unenabled state. If the current permission status is temporarily disabled, the application page will display status description information associated with the temporary disabled status.

8. The method according to claim 1, characterized in that, The response to the application launch operation, by running an empty process to display the introductory page, includes: In response to the application launch operation, an empty process is run to display a simulated login page, and the introductory page is displayed floating above the simulated login page; wherein the introductory page covers at least a portion of the display of the simulated login page.

9. The method according to claim 1, characterized in that, The response to the application launch operation, by running an empty process to display the introductory page, includes: In response to the launch operation of the application, determine whether there is any historical consent operation information for the introductory page; In the absence of historical consent information, an empty process is run to display the introductory page.

10. A permission request device for an application, characterized in that, The device includes: A startup module is configured to, in response to a startup operation on the application, display an introductory page by running an empty process, wherein the introductory page includes at least two operation elements, which are triggered to determine the startup state of the application; in response to a triggering operation of a first operation element in the introductory page, run the main process of the application to perform initialization operations on the application; and in response to a triggering operation of a second operation element in the introductory page, terminate the empty process and close the application. The jump module is used to, when the application is running, respond to a permission request initiated based on an application page, pull up a callback page on top of the application page, and jump to the callback page; wherein, the permission request is used to request access to the target system permissions, the callback page is transparent and covers at least a part of the application page, the callback page is a page configured to perform permission request operations for each application page, whenever the application initiates a permission request based on an application page, it jumps to and accesses the callback page, the callback page is also used to determine whether the application page that initiated the permission request is a blacklisted page, if the application page is not a blacklisted page, the step of calling the first interface through the callback page to detect the current permission status of the target system permissions is executed, otherwise the application page is prohibited from requesting permissions; The detection module is used to detect the current permission status of the target system permissions by calling the first interface through the callback page; The application module is used to call the second interface through the callback page to perform a permission application operation when the current permission status is pending. The display module is used to obtain permission description information corresponding to the permissions of the target system, and display the permission description information through the callback page.

11. The apparatus according to claim 10, characterized in that, The device further includes: The first request initiation module is used to enter the application page of the application and, if the application page is an application permission page, directly initiate a permission request pointing to the target system permission that matches the application permission page.

12. The apparatus according to claim 10, characterized in that, The device further includes: The first request initiation module is used to display the application page of the application, which displays functional interactive elements; in response to a trigger operation on the functional interactive elements in the application page, it initiates a permission request for the target system permission that matches the functional interactive elements.

13. The apparatus according to claim 10, characterized in that, The target system permission is any system permission from the preset system permissions. Any system permission is a system permission required to ensure the normal use of the application page. The preset system permissions include at least one of program execution permission and function execution permission.

14. The apparatus according to claim 10, characterized in that, The detection module is also used to obtain the permission identifier corresponding to the requested target system permission; to pass the permission identifier to the system through the callback page calling the system interface, and to obtain the current permission status of the target system permission returned by the system based on the permission identifier.

15. The apparatus according to claim 10, characterized in that, The current permission status includes an inactive state and an active state, and the device further includes: The status judgment module is used to obtain the previous application time point corresponding to the previous permission application request by calling a third interface through the callback page when the current permission status is not enabled; if the time interval between the current application time point of the current permission application request and the previous application time point is greater than a preset time interval, the module determines that the current permission status is a pending enable status in the not enabled state.

16. The apparatus according to claim 15, characterized in that, The device further includes: The status description module is used to determine that the current permission status is a temporarily disabled status in the "not enabled" state if the time interval between the current application time and the previous application time is not greater than the preset time interval; and to display status description information associated with the temporarily disabled status on the application page when the current permission status is a temporarily disabled status.

17. The apparatus according to claim 10, characterized in that, The startup module is also configured to, in response to a startup operation on the application, run an empty process to display a simulated login page, and display the introduction page while floating above the simulated login page; wherein the introduction page covers at least a portion of the display of the simulated login page.

18. The apparatus according to claim 10, characterized in that, The startup module is also used to determine whether there is any historical consent operation information for the introduction page in response to the startup operation of the application; if there is no historical consent operation information, the introduction page is displayed by running an empty process.

19. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 9.

20. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 9.

21. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 9.

Images