CN114154141A

CN114154141A - Method, device, equipment and storage medium for determining access authority

Info

Publication number: CN114154141A
Application number: CN202111467626.XA
Authority: CN
Inventors: 宋思亭; 邓远铤
Original assignee: Netease Hangzhou Network Co Ltd
Current assignee: Netease Hangzhou Network Co Ltd
Priority date: 2021-12-02
Filing date: 2021-12-02
Publication date: 2022-03-08

Abstract

The application provides a method, a device, equipment and a storage medium for determining access authority. The method is applied to a terminal device, an application program is installed on the terminal device, configuration information of a target access authority is determined in a preset configuration item by acquiring at least one target access authority in the application program according to the target access authority, and the configuration item comprises: configuration information of a plurality of preset access rights comprises a right description which indicates the purpose of the access rights after being authorized, and the right description of the target access rights is displayed on a page of the terminal equipment. The technical scheme starts from the authority explanation in the configuration item, and shows the reason for applying the authority to the user so as to increase the possibility of user authorization and standardize the rule for applying the access authority.

Description

Method, device, equipment and storage medium for determining access authority

Technical Field

The present application relates to the field of computer technologies, and in particular, to a method, an apparatus, a device, and a storage medium for determining an access right.

Background

Different applications are installed on the terminal equipment, the applications run in a sandbox of the terminal equipment with access authority, if the applications need to use resources or information outside the sandbox, the authority needs to be declared, and the authority which needs to access the resources or information outside the sandbox, namely dangerous authority, is obtained by setting an authority request.

In the prior art, the workflow of requesting the permission is: and declaring the authority in the manifest file, checking whether the current application acquires the required authority when the service requiring the dangerous authority is operated, if not, applying the authority and finally needing to operate a system authority prompt, and checking the response of the user in a page for applying the authority.

However, in practical application, only the authorization of requesting a certain authority to the user is prompted, and the problem that the user refuses to grant the authority exists because the application authority is not standardized.

Disclosure of Invention

The embodiment of the application provides a method, a device, equipment and a storage medium for determining access authority, which are used for solving the problems that the application authority is not standard and the user easily refuses to grant the authority.

In a first aspect, an embodiment of the present application provides a method for determining an access right, where the method is applied to a terminal device, and an application program is installed on the terminal device, and the method includes:

acquiring at least one target access right in an application program, wherein the target access right is an access right which is not authorized by a user;

according to the target access authority, determining configuration information of the target access authority in a preset configuration item, wherein the configuration item comprises: configuration information of a plurality of preset access rights, wherein the configuration information comprises: a rights expression indicating a use of the access rights after authorization;

and displaying the authority description of the target access authority on a page of the terminal equipment.

In a possible design of the first aspect, after the obtaining of the at least one target access right in the application, the method further includes:

and according to the target access authority, the authority description of the target access authority is not determined in the configuration items, and the default authority description in the configuration items is set as the authority description of the target access authority.

In another possible design of the first aspect, the configuration information further includes: an identification of a plurality of business logics indicating business processes performed in response to a selection operation authorized by a user, the method further comprising:

displaying the operation identifiers corresponding to the plurality of service logics on a page of the terminal equipment;

responding to the selection operation of a user, and selecting an operation identifier corresponding to a target service logic from operation identifiers corresponding to the plurality of service logics;

and executing the target service logic according to the operation identifier corresponding to the target service logic.

In this possible design, the identification of the business logic includes any of: grant, deny authorization and no longer alert.

In yet another possible design of the first aspect, the method further includes:

if the operation identifier corresponding to the target service logic is the authorization refusal and is not reminded, displaying a jump option on a page of the terminal equipment, wherein the jump option is used for prompting a user to jump to a system setting page of the application program to modify and acquire the target access authority;

and responding to the operation corresponding to the skip option of the user, and executing the business logic corresponding to the authorization agreement after the user confirms the authorization.

In yet another possible design of the first aspect, the obtaining at least one target access right in the application includes:

calling a permission judgment interface to obtain a return value corresponding to each access permission;

determining whether the access authority is authorized by a user according to whether a return value corresponding to the access authority is equal to a type constant defined by the application program;

and if the return value corresponding to the access authority is not equal to the type constant, recording the access authority as a target access authority.

In this possible design, after the target service logic is executed according to the operation identifier corresponding to the target service logic, the method further includes:

detecting the running state of the fragments and the running state of the workflow;

and when the running state of the fragments and the running state of the workflow are in a stop state, clearing the memory overhead.

In a second aspect, an embodiment of the present application provides an apparatus for determining an access right, where the apparatus is applied to a terminal device, and an application program is installed on the terminal device, and the apparatus includes: the device comprises an acquisition module, a processing module and a display module;

the acquisition module is used for acquiring at least one target access right in an application program, wherein the target access right is an access right which is not authorized by a user;

the processing module is configured to determine configuration information of the target access right in a preset configuration item according to the target access right, where the configuration item includes: configuration information of a plurality of preset access rights, wherein the configuration information comprises: a rights expression indicating a use of the access rights after authorization;

and the display module is used for displaying the authority description of the target access authority on a page of the terminal equipment.

In a possible design of the second aspect, the processing module is further configured to set, according to the target access right, a right description of the target access right in the configuration item where the right description of the target access right is not determined, as the right description of the target access right, a default right description in the configuration item.

In another possible design of the second aspect, the configuration information further includes: the display module is further configured to display operation identifiers corresponding to the plurality of service logics on a page of the terminal device;

and the processing module is also used for responding to the selection operation of the user, selecting the operation identifier corresponding to the target service logic from the operation identifiers corresponding to the plurality of service logics, and executing the target service logic according to the operation identifier corresponding to the target service logic.

In yet another possible design of the second aspect, the processing module is further configured to:

In yet another possible design of the second aspect, the obtaining module is specifically configured to:

In this possible design, the processing module is further configured to:

In a third aspect, an embodiment of the present application provides a terminal device, including: a processor, a memory;

the memory stores computer-executable instructions;

the processor executes the computer-executable instructions to cause the terminal device to perform the method for determining access rights as described in the first aspect and various possible designs above.

In a fourth aspect, embodiments of the present application provide a computer-readable storage medium, in which computer-executable instructions are stored, and when the computer-executable instructions are executed by a processor, the method for determining access rights is implemented as described in the first aspect and various possible designs.

In a fifth aspect, embodiments of the present application provide a computer program product, which includes a computer program, and when the computer program is executed by a processor, the computer program is used to implement the method for determining access rights as described in the first aspect and various possible designs.

The method, the device, the equipment and the storage medium for determining the access right are provided by the embodiment of the application. The method is applied to a terminal device, an application program is installed on the terminal device, configuration information of a target access authority is determined in a preset configuration item by acquiring at least one target access authority in the application program according to the target access authority, and the configuration item comprises: configuration information of a plurality of preset access rights comprises a right description which indicates the purpose of the access rights after being authorized, and the right description of the target access rights is displayed on a page of the terminal equipment. The technical scheme starts from the authority explanation in the configuration item, and shows the reason for applying the authority to the user so as to increase the possibility of user authorization and standardize the rules for applying the authority.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present disclosure and together with the description, serve to explain the principles of the disclosure.

FIG. 1 is a schematic diagram illustrating a process for applying access rights provided by the prior art;

fig. 2 is a schematic flowchart of a first embodiment of a method for determining access rights according to an embodiment of the present application;

fig. 3 is a schematic flowchart of a second embodiment of a method for determining access rights according to an embodiment of the present application;

fig. 4 is a schematic flowchart of a third embodiment of a method for determining access rights according to an embodiment of the present application;

fig. 5 is a schematic structural diagram of an apparatus for determining access rights according to an embodiment of the present application;

fig. 6 is a schematic structural diagram of a terminal device according to an embodiment of the present application.

With the foregoing drawings in mind, certain embodiments of the disclosure have been shown and described in more detail below. These drawings and written description are not intended to limit the scope of the disclosed concepts in any way, but rather to illustrate the concepts of the disclosure to those skilled in the art by reference to specific embodiments.

Detailed Description

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the exemplary embodiments below are not intended to represent all implementations consistent with the present disclosure. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present disclosure, as detailed in the appended claims.

Before introducing the embodiments of the present application, the background of the present application is explained first:

each Android application runs in a sandbox with limited access rights, and if the application needs to use resources or information except the sandbox of the application, the application can declare the rights and acquire the required access rights by setting a rights request. The ordinary permissions can be directly used after the statement of the manifest file, but dangerous permissions (also called runtime permissions) need to be acquired, if the application is installed on the Android 6.0 or higher device, the dangerous permissions need to be requested in runtime according to a specific workflow, including checking whether the user is authorized, checking whether the application reason needs to be displayed, checking the user response and making corresponding feedback, and the like.

In the actual development process, on one hand, the above-mentioned work may be discounted in the execution specification degree, and a certain step in the processing is omitted, which results in poor user experience of the application authority process, and on the other hand, due to the complex service, the workflow may be logically dispersed, which is not beneficial to the subsequent maintenance.

In the prior art, there is an Android developer platform, that is, fig. 1 is a schematic diagram of an application flow of an access right provided in the prior art, and as shown in fig. 1, a workflow of requesting an authority is as follows:

step 1, declaring authority in a manifest file;

step 2, when the dangerous service is operated, the required authority is required to be obtained;

step 3, checking whether the current application acquires the required authority, and if not, executing step 4 a; if yes, executing 7 a;

step 4a, whether the authority reason is displayed or not is judged, if yes, step 4b is executed; if not, executing;

step 4b, showing the authority reason to the user;

step 5, applying the authority to finally need to operate a system authority prompt;

wherein, the execution logic under this step is ended, which is described in detail below.

Step 6, checking the response of the user in the page of the application authority, and if the response is received, executing step 7 a; if not, executing step 7 b;

step 7a, running dangerous service;

and 7b, refusing to operate dangerous service.

Optionally, in order to solve the problem that the flow is not connected between the step 5 of executing the application permission and the step 6 of confirming the user feedback, the rxstandards provide the functions of aggregating the application permission and confirming the user feedback, that is, the functions of obtaining the current running state context, initiating the permission request, prompting the running system permission request and checking the user response are realized in a continuous code block in a centralized manner.

Part of the code is as follows:

optionally, step 4a and step 4b are not steps forcibly executed in the workflow, and step 3 is directly skipped to step 5 to execute without affecting the application of the right and processing the user response, and then the business logic is continuously executed, so that the work of step 4a and step 4b is easily omitted in the actual development, and the result is that the specific purpose of the usage right may not be explicitly stated to the user when the right is applied, which results in non-specification of the operation of the application right on one hand, and on the other hand, the risk of the user rejecting the right is also increased.

Further, between the step 5 of executing the application authority and the step 6 of confirming the user feedback, the flow is not directly communicated, that is, the code for completing the step 5 is in an x file, and the code for completing the step 6 is in a y file, wherein the y file describes a page (activity or fragment), and the x file may be a sub-module in the page described by the y file, and the reference between the multi-layer modules may be passed between them, which means that the code logic of the two may be split during the actual development process.

The permission application scheme provided by RxPermissions solves the problem of permission application workflow process splitting to a certain extent, but the steps such as the reason for displaying the permission application to the user and the like can be omitted, and extra memory overhead can be brought.

In order to solve the technical problems, the technical conception process of the inventor is as follows: in the prior art, aiming at the authorization reason of access authority, the existing process can be directly filtered, if in the process design, the context of the current application is injected when the authority is applied, the authority which needs to be applied through workflow is inquired from the system through the context, all the authorities which need to be applied are obtained through the context to the page container created by the current application, an invisible container is created in the current page container to execute the complete authority application process application and process the user response, the reason for applying the authority is used as a necessary option and is set or is not set according to the default reason, and then the invisible container is displayed, so that the technical problems in the prior art can be solved.

The technical solution of the present application will be described in detail by specific examples. It should be noted that the following specific embodiments may be combined with each other, and the same or similar concepts or processes may not be described in detail in some embodiments. Embodiments of the present application will be described below with reference to the accompanying drawings.

Fig. 2 is a schematic flowchart of a first embodiment of a method for determining access rights according to an embodiment of the present application. As shown in fig. 2, the method for determining access rights is applied to a terminal device, and an application program is installed on the terminal device, and the method includes the following steps:

and step 21, acquiring at least one target access right in the application program.

Wherein the target access right is an access right which is not authorized by the user.

In this step, in order to enable the application program to provide a better service for the user to the greatest extent, the application program needs to acquire access permissions corresponding to different target paths and the like, that is, when the application program is started, whether the access permission required by the application program is started is first judged, and then it is determined that no authorized access permission is obtained, and the access permission is recorded as a target access permission.

Optionally, the target access right needs to be authorized by the user to provide support for the function of the application program, and this way also provides an example for the normalization of the access right.

Optionally, the number of the target access rights may be one or more, and the embodiment of the application may support applying one or more access rights simultaneously.

In one possible implementation, the steps are implemented as follows:

step 1, calling a permission judgment interface to obtain a return value corresponding to each access permission.

Specifically, a context _ checkSelfpermission (String permission) interface is executed to sequentially obtain return values corresponding to each access permission.

And 2, determining whether the access right is authorized by the user according to whether the return value corresponding to the access right is equal to the type constant defined by the application program.

Specifically, an int type constant, package manager, policy _ GRANTED, defined by the application program determines whether the int type constant is equal to the return value, thereby determining whether the access right is authorized by the user.

And 3, if the return value corresponding to the access right is not equal to the type constant, recording the access right as a target access right.

Specifically, if the return value corresponding to the access right is equal to the type constant, it indicates that the access right has been authorized by the user, and no repeated application is needed, and if the return value corresponding to the access right is not equal to the type constant, it indicates that the access right has not been authorized by the user, and it needs to apply, that is, the access right that has not been authorized by the user is marked as the target access right.

And step 22, determining the configuration information of the target access authority in the preset configuration items according to the target access authority.

Wherein the configuration items include: configuration information of a plurality of preset access rights, wherein the configuration information comprises: a rights expression indicating the use of the access rights after authorization.

In this step, in order to standardize the application of the access right so that the user can know the usage of the access right, the usage of each access right, that is, the right description, can be set in the configuration item.

Further, after obtaining the target access right which is the access right not authorized by the user, the right description corresponding to the target access right is obtained in the configuration item.

For example, the target access right may be "right to acquire a gallery," and the corresponding right description may be "picture generated by the application is saved in the gallery to increase fluency and save traffic when the application calls the picture next time," and the like.

In addition, according to the target access authority, the authority description of the target access authority is not determined in the configuration item, and the default authority description in the configuration item is set as the authority description of the target access authority.

Optionally, in the configuration item of the application, the technician does not set an authority description of the target access authority in advance, and at this time, a default authority description in the configuration item may be used as the authority description of the target access authority.

Specifically, the permission specification in the configuration item, the preset permission specification and the default permission specification may be access permission and optional items (permission specification) defined under the android system library management.

For example, the authority explains the content of the popup, the set file is displayed on the popup after the authority is set, and the explanation content corresponding to the default authority explanation is not displayed; if the authority description popup is displayed, displaying the authority description popup by default, and setting to not display; whether the prompt is displayed or not is sent to the system permission setting popup window, the default display is sent to the system permission setting popup window, and the default display can be set without displaying.

And step 23, displaying the authority description of the target access authority on the page of the terminal equipment.

In this step, after acquiring the rights expression of the target rights from the configuration item, in order to improve the authorization rate of the user to the target rights, the rights expression of the target access rights is displayed on the display interface of the terminal device at this time.

In one possible implementation, the current page context can be set to create a unique fragment for exposing the access permission application popup to display the permission specification.

Specifically, when the target access right (e.g., applying for opening a traffic network) is not authorized, the "applying for opening a traffic network" and the corresponding right description are displayed in a popup window of the current page of the terminal device (the device is not networked, cannot perform game interaction with other users, can only access a single version of the game, and part of the interaction function cannot be realized).

The method for determining the access authority provided by the embodiment of the application is applied to terminal equipment, wherein the terminal equipment is provided with an application program, configuration information of the target access authority is determined in preset configuration items according to the target access authority by acquiring at least one target access authority in the application program, and the configuration items comprise: configuration information of a plurality of preset access rights comprises a right description which indicates the purpose of the access rights after being authorized, and the right description of the target access rights is displayed on a page of the terminal equipment. The technical scheme starts from the authority explanation in the configuration item, and shows the reason for applying the authority to the user so as to increase the possibility of user authorization and standardize the rules for applying the authority.

On the basis of the foregoing embodiment, fig. 3 is a flowchart illustrating a second embodiment of a method for determining access rights provided in the embodiment of the present application. As shown in fig. 3, when the configuration information further includes: when the service logics are identified, the method for determining the access right further comprises the following steps:

and 31, displaying operation identifiers corresponding to a plurality of service logics on a page of the terminal equipment.

Wherein the business logic indicates a business process performed in response to a selection operation authorized by the user.

In this step, after the right description of the target access right is displayed on the page of the terminal device, the user needs to perform corresponding operations on the page to determine whether the target access right is authorized, and when the user determines whether the target access right is authorized, and feeds back the determination to the terminal device, the processing flows (service logics) of the terminal device are different.

Optionally, the identification of the service logic includes any one of: the authorization, the authorization refusal and the authorization refusal are agreed and not reminded any more, that is, in the configuration item, whether the user agrees to authorize the target access right or not is preset, and the business logics corresponding to different feedbacks of the user are different.

In one possible implementation, keys such as "agree with authorization", "deny authorization and no longer remind" are displayed on the page of the terminal device.

And step 32, responding to the selection operation of the user, and selecting the operation identifier corresponding to the target service logic from the operation identifiers corresponding to the plurality of service logics.

In this step, according to the identifier of the service logic displayed on the page and the right description for the target access right, the user selects "grant authorization", "deny authorization", or "deny authorization and no longer remind", that is, the operation identifier corresponding to the target service logic.

And step 33, executing the target service logic according to the operation identifier corresponding to the target service logic.

In this step, the identifier of the target service logic is selected on the page of the terminal device, and after clicking, the terminal device performs an operation corresponding to the identifier of the target service logic.

Optionally, based on the permission popup applied by the fragment created in the frame, the user's selection result is also received by the onrequestpermission (int requestCode, String [ ] permissions, int [ ] gradtresults) callback method of the fragment, and the following processing results are obtained:

1. if the user selects "grant authorization," the granted method is executed;

2. if the user selects 'refusing authorization', executing a subscribed method and returning a false parameter;

3. if the user selects "deny authorization and no longer remind," the trusted method is executed and the true parameter is returned.

Specifically, as an example, when the user responds to the selection operation of the access right application, and selects to approve, reject or reject the access right application request and no longer prompts, the corresponding method of the setting will be automatically executed, and the following is a part of codes:

for example, a service logic executed after an access permission application is granted is set in the granted method, a service logic executed after an authority is rejected is set in the signed method, and meanwhile, a parameter for judging the signed method can be selected as true, which represents that a user selects rejection and does not prompt any more, and a corresponding service logic is set.

Optionally, if the operation identifier corresponding to the target service logic is authorization rejection and no longer prompts, the page of the terminal device displays a skip option, where the skip option is used to prompt the user to skip to a system setting page of the application program to modify and acquire the target access right, and after the user confirms authorization, the operation corresponding to the skip option of the user is performed to agree with the service logic corresponding to the authorization.

Specifically, in the configuration item, the service logic of "deny authorization and no longer remind" is: prompting the user whether to jump to the system setup page of the current application to modify and obtain the requested access rights. In addition, when the access authority is requested, if the user selects 'deny authorization and no longer remind' for a certain access authority, the same application requests the same authority again for the user, the system no longer allows the user to select whether the authorization is allowed, and the service logic corresponding to the deny authorization and no longer remind identification is directly executed. In this case, only the user actively modifies the access right corresponding to the current application on the system setting page to obtain authorization. The system is additionally provided with page guidance, so that the possibility of user authorization is improved.

It should be understood that: the business logic may be in the configuration item by default or may be closed.

Optionally, after the user authorizes the target access right, the corresponding service logic after the user agrees to the authorization is executed, that is, the application program is normally started, and a graphical user interface and the like are provided for the user, so that the user experiences the application program.

After the step, the terminal equipment also detects the running state of the fragments and the running state of the workflow; and when the running state of the fragments and the running state of the workflow are in a stop state, clearing the memory overhead.

Optionally, this embodiment provides a fragment (activity) and a workflow (fragment) including page lifecycle aware capability, which are inherited by all business layer pages as a base class, and are recommended to be injected into the business layer as a context, and when it is sensed that a page itself is about to be recycled by the system, memory overhead generated in the whole process is cleared.

Specifically, the listener may be a listener that uses a subscriber mode to create a subscription that is not timely released after a fragment in a frame, and perceives the life cycle of a page.

Optionally, in the process of the foregoing embodiment, the mapping between the current page and the application authority entity may be stored in a container manner. After the current page is obtained through the context, whether an entity applying the authority exists in the container is tried to be found, if so, the entity is directly used for continuing to execute subsequent operation; if not, a transparent fragment is created in the current page for applying for the authority to the system and is stored in the container.

It should be noted that the container may be a common key-value mapping table, and may also include an automatic recycle function, that is, when the mapped key has been recycled, the mapped value is automatically recycled to ensure that no memory leak occurs.

In addition, the Context provides an interface to global information about the application environment, which is an abstract class whose implementation is provided by the android system. The Context described herein contains page type fragments in addition to Context and activity that inherits from Context.

According to the method for determining the access authority, the operation identifications corresponding to the plurality of service logics are displayed on the page of the terminal equipment, the operation identification corresponding to the target service logic is selected from the operation identifications corresponding to the plurality of service logics in response to the selection operation of the user, and then the target service logic is executed according to the operation identification corresponding to the target service logic. In the technical scheme, the application program can continuously execute the corresponding flow according to the selection of the user from the service logic corresponding to the operation of different users.

On the basis of the foregoing embodiment, fig. 4 is a flowchart illustrating a third embodiment of a method for determining an access right according to the embodiment of the present application. As shown in fig. 4, the design steps of the embodiment of the present application are summarized briefly, and the method for determining access rights includes the following steps:

step 1, when an access right needs to be applied, injecting a current page context;

the context provides an interface to global information about the application environment, i.e. an abstract class, the implementation of which is provided by the Android system. The Context described herein contains page type fragments in addition to Context and activity that inherits from Context.

Optionally, for most pages of the Android client application, the access permission application operation under a general condition is relatively low frequency, so that a lazy loading mode can be adopted, the current page context is obtained only when the permission application is really needed, and all workflows for applying the access permission are completed based on the context.

Step 2, adding configuration items containing specific authority content;

optionally, before applying for the access right, a configuration including specific right content needs to be added, including a necessary right limit value, that is, a right defined under the Android system library quality.

Wherein the selectable options include: the authority explains the content of the popup, the set file of the actual authority of the popup is explained after the authority is set, and the default explanation content is not set and displayed; if the authority description popup is displayed, displaying the authority description popup by default, and setting to not display; whether the prompt is displayed or not is sent to the system permission setting popup window, the default display is sent to the system permission setting popup window, and the default display can be set without displaying.

Step 3, adding responses aiming at different users and executing different service logics;

optionally, before applying for the access right, a method may be added, and when the user responds to the system right to apply for the popup, and selects to approve, reject or reject the request for applying the right and no longer prompts, the corresponding method set up will be automatically executed.

For example, in this embodiment, a service logic executed after granting the right may be set in the granted method, a service logic executed after denying the right may be set in the denied method, and meanwhile, a parameter for judging the denied method may be selected as true, which represents that the user selects to deny and does not prompt any more, and a corresponding service logic is set.

In the above embodiment, the method selected by the user is used as the target business logic.

Step 4, filtering the acquired access right according to the content of the applied access right;

the embodiment comprises a container used for storing the mapping between the current page and the application authority entity. After the current page is obtained through the context, whether an application authority entity exists in the container is tried to be searched.

Optionally, if the entity exists, the entity is directly used to continue to perform subsequent operations; if not, a transparent fragment is created in the current page for applying for the authority to the system and is stored in the container.

It should be understood that: the container may be a common key-value mapping table, and may also include an automatic recycle function, that is, when the mapped key has been recycled, the mapped value is automatically recycled to ensure that no memory leak occurs.

The specific implementation is as follows: if all the access rights of the application are authorized, directly executing the granted method set in the step 3; if the access right is required to be applied, the subsequent process is continuously executed for the rest access right (target access right).

Step 5, applying for the authority description of the access authority according to the configuration item description;

optionally, the right description in this step may be the content configuration file of the right description popup provided in step 2; or a default file in the scheme can be used, and the corresponding authority description is automatically displayed according to the applied access authority.

Step 6, showing the authority description of the access authority;

optionally, a unique fragment is created according to the current page context injected in step 1 to show the system access permission application popup, and the subsequent steps of permission application are executed based on the unique fragment.

7, executing different service logics according to the user response;

optionally, based on the permission popup applied by the fragment created in the frame, the processing result of the user is also received by the onrequestpermission (int requestCode, String [ ] permissions, int [ ] gradtresults) callback method of the fragment, and according to the obtained processing result, the method specifically includes:

1. if the user chooses to agree to authorization, executing the granted method;

2. if the user selects to reject the authorization, executing a trusted method and returning a false parameter;

3. if the user chooses to deny authorization and no longer prompts, a trusted method is executed and a true parameter is returned.

When the user selects to reject the authorization and does not remind any more, the user can go to the system permission setting popup window through the display prompt set in the step 2, and guidance to the system setting page is supported to be the application authorization.

And 8, closing the current page and recycling the memory overhead generated in the step.

Optionally, this embodiment provides activity and fragment including page lifecycle aware capability, and injects a service layer context into a module for which an access right application is independent through step 1, and when it is perceived that a page itself is to be recycled by a system, memory overhead generated in the module is cleared, which specifically includes:

1. creating a subscription that is not timely released after an in-frame fragment using a subscriber schema;

2. a listener that perceives the life cycle of the page.

According to the method for determining the access right, when the access right needs to be applied, the context of the current page is injected, the configuration item containing specific right content is added, different user responses are added, different business logics are executed, the obtained access right is filtered according to the applied access right content, the right description of the access right is applied according to the configuration item description, the right description of the access right is displayed, different business logics are executed according to the user responses, the current page is closed, and the memory overhead generated in the steps is recovered. In the technical scheme, the request rule for applying the authority is standardized by the application reason of the access authority in the configuration item, and the authorization rate of the user is improved.

On the basis of the above method embodiment, fig. 5 is a schematic structural diagram of an apparatus for determining access rights provided in the embodiment of the present application. As shown in fig. 5, the apparatus for determining access right is applied to a terminal device, on which an application is installed, and includes: an acquisition module 51, a processing module 52 and a display module 53;

an obtaining module 51, configured to obtain at least one target access right in an application, where the target access right is an access right that is not authorized by a user;

the processing module 52 is configured to determine configuration information of the target access right in preset configuration items according to the target access right, where the configuration items include: configuration information of a plurality of preset access rights, wherein the configuration information comprises: a rights expression indicating the use of the access rights after authorization;

and the display module 53 is configured to display the right description of the target access right on the page of the terminal device.

In a possible design of the embodiment of the present application, the processing module 52 is further configured to set, according to the target access right, the authority description of the target access right in the configuration item that is not determined, as the authority description of the target access right, the default authority description in the configuration item.

In another possible design of the embodiment of the present application, the configuration information further includes: the display module 53 is further configured to display, on a page of the terminal device, operation identifiers corresponding to the multiple service logics;

the processing module 52 is further configured to, in response to a selection operation of a user, select an operation identifier corresponding to a target service logic from the operation identifiers corresponding to the plurality of service logics, and execute the target service logic according to the operation identifier corresponding to the target service logic.

In yet another possible design of the embodiment of the present application, the processing module 52 is further configured to:

if the operation identifier corresponding to the target service logic is refused to authorize and does not remind any more, displaying a skip option on a page of the terminal equipment, wherein the skip option is used for prompting a user to skip to a system setting page of an application program to modify and acquire a target access right;

In yet another possible design of the embodiment of the present application, the obtaining module 51 is specifically configured to:

determining whether the access authority is authorized by the user according to whether the return value corresponding to the access authority is equal to the type constant defined by the application program;

and if the return value corresponding to the access right is not equal to the type constant, recording the access right as a target access right.

In this possible design, the processing module 52 is further configured to:

The device for determining the access right provided in the embodiment of the application can be used for executing the technical scheme corresponding to the method for determining the access right in the embodiment, and the implementation principle and the technical effect are similar, and are not described herein again.

It should be noted that the division of the modules of the above apparatus is only a logical division, and the actual implementation may be wholly or partially integrated into one physical entity, or may be physically separated. And these modules can be realized in the form of software called by processing element; or may be implemented entirely in hardware; and part of the modules can be realized in the form of calling software by the processing element, and part of the modules can be realized in the form of hardware. In addition, all or part of the modules can be integrated together or can be independently realized. The processing element described herein may be an integrated circuit having signal processing capabilities. In implementation, each step of the above method or each module above may be implemented by an integrated logic circuit of hardware in a processor element or an instruction in the form of software.

Fig. 6 is a schematic structural diagram of a terminal device according to an embodiment of the present application. As shown in fig. 6, the terminal device may include: a processor 60, a memory 61, and computer program instructions stored on the memory 61 and executable on the processor 60.

The terminal device can be a mobile phone, a computer, a tablet and other devices with a display function.

The processor 60 executes computer-executable instructions stored by the memory 61, causing the processor 60 to perform the aspects of the embodiments described above. The processor 60 may be a general-purpose processor including a central processing unit CPU, a Network Processor (NP), and the like; but also a digital signal processor DSP, an application specific integrated circuit ASIC, a field programmable gate array FPGA or other programmable logic device, discrete gate or transistor logic, discrete hardware components.

A memory 61 is coupled to the processor 60 via a system bus and communicates with each other, the memory 61 being used to store computer program instructions.

In one possible implementation, the terminal device may further include: and the display is used for displaying the display interface of the terminal equipment.

The system bus may be a Peripheral Component Interconnect (PCI) bus, an Extended Industry Standard Architecture (EISA) bus, or the like. The system bus may be divided into an address bus, a data bus, a control bus, and the like. For ease of illustration, only one thick line is shown, but this does not mean that there is only one bus or one type of bus.

The terminal device provided in the embodiment of the present application may be configured to execute the technical solution corresponding to the method for determining an access right in the foregoing embodiment, and the implementation principle and the technical effect are similar, which are not described herein again.

The embodiment of the application further provides a chip for executing the instruction, and the chip is used for executing the technical scheme of the method for determining the access authority in the embodiment.

An embodiment of the present application further provides a computer-readable storage medium, where a computer instruction is stored in the computer-readable storage medium, and when the computer instruction runs on a terminal device, the terminal device is enabled to execute the technical solution of the method for determining an access right in the foregoing embodiment.

The embodiment of the present application further provides a computer program product, which includes a computer program, and the computer program is used for executing the technical solution of the method for determining access rights in the foregoing embodiments when executed by a processor.

The computer-readable storage medium described above may be implemented by any type of volatile or non-volatile memory device or combination thereof, such as Static Random Access Memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic or optical disk. Readable storage media can be any available media that can be accessed by a general purpose or special purpose terminal device.

It will be understood that the present disclosure is not limited to the precise arrangements described above and shown in the drawings and that various modifications and changes may be made without departing from the scope thereof. The scope of the present disclosure is limited only by the appended claims.

Claims

1. A method for determining access authority is applied to a terminal device, wherein an application program is installed on the terminal device, and the method comprises the following steps:

2. The method of claim 1, wherein after the obtaining at least one target access right in the application, the method further comprises:

3. The method according to claim 1 or 2, wherein the configuration information further comprises: an identification of a plurality of business logics indicating business processes performed in response to a selection operation authorized by a user, the method further comprising:

4. The method according to claim 3, wherein the identification of the business logic comprises any of: grant, deny authorization and no longer alert.

5. The method of claim 4, further comprising:

6. The method of claim 1 or 2, wherein the obtaining at least one target access right in the application program comprises:

7. The method according to claim 6, wherein after the target service logic is executed according to the operation identifier corresponding to the target service logic, the method further comprises:

8. An apparatus for determining access rights, the apparatus being applied to a terminal device, the terminal device having an application installed thereon, the apparatus comprising: the device comprises an acquisition module, a processing module and a display module;

9. The apparatus of claim 8, wherein the processing module is further configured to:

10. The apparatus of claim 8 or 9, wherein the configuration information further comprises: the display module is further configured to display operation identifiers corresponding to the plurality of service logics on a page of the terminal device;

11. The apparatus of claim 10, wherein the identification of the business logic comprises any of: grant, deny authorization and no longer alert.

12. The method of claim 11, wherein the processing module is further configured to:

13. The apparatus according to claim 8 or 9, wherein the obtaining module is specifically configured to:

14. The apparatus of claim 13, wherein the processing module is further configured to:

15. A terminal device, comprising: processor, memory and computer program instructions stored on the memory and executable on the processor, characterized in that the processor implements the method of determining access rights according to any of the preceding claims 1 to 7 when executing the computer program instructions.

16. A computer-readable storage medium, having stored thereon computer-executable instructions for implementing the method of determining access rights of any one of claims 1 to 7 when executed by a processor.

17. A computer program product comprising a computer program for implementing a method for determining access rights according to any one of claims 1 to 7 when executed by a processor.