CN112131556A - 权限控制方法、装置、设备及存储介质 - Google Patents

Abstract

本申请公开了权限控制方法、装置、设备及存储介质。方法包括：基于应用程序的启动指令，确定应用程序对应的协议信息的处理状态；响应于协议信息的处理状态为协议信息未被确认过，展示协议信息；基于协议信息的确认指令，展示应用程序对应的权限说明信息；基于权限说明信息的确认指令，利用轮询的方式获取至少一个必要权限的授权结果；响应于至少一个必要权限的授权结果均为授权，跳转到应用程序对应的启动主页面。基于上述方式，在应用程序成功启动之前就进行了权限控制，能够规避在应用程序一启动时就执行侵犯用户隐私的操作的现象，权限控制更加规范有效，有利于提高对用户隐私的保护力度，安全性较高。

Description

权限控制方法、装置、设备及存储介质

技术领域

本申请实施例涉及计算机技术领域，特别涉及一种权限控制方法、装置、设备及存储介质。

背景技术

随着计算机技术的发展，应用程序的种类越来越多。通常情况下，在应用程序的某些权限未得到用户授权的情况下，终端无法执行需要依赖这些权限对应的资源的操作，从而达到基于权限控制保护用户隐私的效果。

相关技术中，在应用程序成功启动后，判断应用程序对应的待执行操作是否需要依赖某种权限对应的资源，在确定应用程序对应的待执行操作需要依赖某种权限对应的资源时，再执行关于该权限的权限控制过程。基于此种权限控制方式，容易出现在应用程序一启动时就执行侵犯用户隐私的操作的现象，权限控制的局限性较大，权限控制的规范性和有效性较差，安全性较差。

发明内容

本申请实施例提供了一种权限控制方法、装置、设备及存储介质，可用于提高安全性。所述技术方案如下：

一方面，本申请实施例提供了一种权限控制方法，所述方法包括：

基于应用程序的启动指令，确定所述应用程序对应的协议信息的处理状态；

响应于所述协议信息的处理状态为所述协议信息未被确认过，展示所述协议信息；

基于所述协议信息的确认指令，展示所述应用程序对应的权限说明信息，所述权限说明信息用于对所述应用程序对应的至少一个必要权限进行提示说明；

基于所述权限说明信息的确认指令，利用轮询的方式获取所述至少一个必要权限的授权结果；

响应于所述至少一个必要权限的授权结果均为授权，跳转到所述应用程序对应的启动主页面。

在一种可能实现方式中，所述选择控件还包括退出控件，所述展示选择控件之后，所述方法还包括：

基于所述退出控件的触发操作，退出所述应用程序。

另一方面，提供了一种权限控制装置，所述装置包括：

确定模块，用于基于应用程序的启动指令，确定所述应用程序对应的协议信息的处理状态；

展示模块，用于响应于所述协议信息的处理状态为所述协议信息未被确认过，展示所述协议信息；

所述展示模块，还用于基于所述协议信息的确认指令，展示所述应用程序对应的权限说明信息，所述权限说明信息用于对所述应用程序对应的至少一个必要权限进行提示说明；

获取模块，用于基于所述权限说明信息的确认指令，利用轮询的方式获取所述至少一个必要权限的授权结果；

跳转模块，用于响应于所述至少一个必要权限的授权结果均为授权，跳转到所述应用程序对应的启动主页面。

在一种可能实现方式中，所述展示模块，还用于响应于所述至少一个必要权限中存在授权结果为未授权的至少一个目标权限，展示选择控件，所述选择控件包括重新授权控件和设置控件；

所述获取模块，还用于基于所述重新授权控件的触发操作，利用轮询的方式获取至少一个第一权限的授权结果，所述至少一个第一权限为所述至少一个目标权限中满足条件的目标权限，所述满足条件的目标权限为允许利用轮询的方式再次获取授权结果的目标权限；基于所述设置控件的触发操作，利用跳转到系统设置页面的方式获取至少一个第二权限的授权结果，所述至少一个第二权限为所述至少一个目标权限中除所述至少一个第一权限外的各个目标权限；

所述跳转模块，还用于响应于所述至少一个第一权限和所述至少一个第二权限的授权结果均为授权，跳转到所述应用程序对应的启动主页面。

在一种可能实现方式中，所述选择控件还包括退出控件，所述装置还包括：

退出模块，用于基于所述退出控件的触发操作，退出所述应用程序。

在一种可能实现方式中，所述至少一个必要权限在获取授权结果之前均处于必要权限列表中；所述装置还包括：

剔除模块，用于将授权结果为授权的必要权限从所述必要权限列表中剔除；

所述确定模块，还用于响应于剔除处理后的必要权限列表不为空列表，确定所述至少一个必要权限中存在授权结果为未授权的至少一个目标权限。

在一种可能实现方式中，所述装置还包括：

检测模块，用于响应于所述协议信息的处理状态为所述协议信息被确认过，检测所述应用程序对应的至少一个必要权限的处理状态；

所述展示模块，还用于响应于所述至少一个必要权限的处理状态指示所述至少一个必要权限中存在未被授权的至少一个参考权限，展示所述权限说明信息；

所述获取模块，还用于基于所述权限说明信息的确认指令，利用轮询的方式获取所述至少一个参考权限的授权结果；

所述跳转模块，还用于响应于所述至少一个参考权限的授权结果均为授权，跳转到所述应用程序对应的启动主页面。

在一种可能实现方式中，所述确定模块，还用于响应于所述应用程序的第一本地存储信息中包括所述协议信息的确认标记信息，确定所述协议信息的处理状态为所述协议信息被确认过；或者，响应于所述应用程序的第二本地存储信息中包括所述应用程序的登录信息，确定所述协议信息的处理状态为所述协议信息被确认过。

在一种可能实现方式中，所述获取模块，还用于响应于所述应用程序对应的待执行操作需要依赖任一非必要权限对应的资源，获取所述任一非必要权限的授权结果；

所述装置还包括：

执行模块，用于响应于所述任一非必要权限的授权结果为授权，执行所述待执行操作。

在一种可能实现方式中，所述应用程序配置有用于指示所述应用程序的权限控制方式的目标权限控制信息，所述目标权限控制信息通过对直接调用的通用权限控制信息中的模板配置信息进行自定义配置得到。

另一方面，提供了一种计算机设备，所述计算机设备包括处理器和存储器，所述存储器中存储有至少一条程序代码，所述至少一条程序代码由所述处理器加载并执行，以实现上述任一所述的权限控制方法。

另一方面，还提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有至少一条程序代码，所述至少一条程序代码由处理器加载并执行，以实现上述任一所述的权限控制方法。

另一方面，还提供了一种计算机程序产品或计算机程序，所述计算机程序产品或计算机程序包括计算机指令，所述计算机指令存储在计算机可读存储介质中。计算机设备的处理器从所述计算机可读存储介质读取所述计算机指令，处理器执行所述计算机指令，使得所述计算机设备执行上述任一所述的权限控制方法。

本申请实施例提供的技术方案至少带来如下有益效果：

在本申请实施例中，在应用程序启动的过程中进行权限控制，且在权限控制的过程中融入了协议信息的确认过程，在协议信息被确认后再获取必要权限的授权结果，在必要权限均被授权后，再跳转到应用程序的启动主页面。基于此种过程，在应用程序成功启动之前就进行了权限控制，能够规避在应用程序一启动时就执行侵犯用户隐私的操作的现象，权限控制更加规范有效，有利于提高对用户隐私的保护力度，安全性较高。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请实施例提供的一种权限控制方法的实施环境的示意图；

图2是本申请实施例提供的一种权限控制方法的流程图；

图3是本申请实施例提供的一种展示协议信息的过程的示意图；

图4是本申请实施例提供的一种权限说明信息的展示过程的示意图；

图5是本申请实施例提供的一种展示第一个必要权限的授权请求文本框的过程的示意图；

图6是本申请实施例提供的一种选择控件的展示示意图；

图7是本申请实施例提供的一种权限控制方法的流程图；

图8是本申请实施例提供的一种权限控制过程的示意图；

图9是本申请实施例提供的一种权限控制装置的示意图；

图10是本申请实施例提供的一种权限控制装置的示意图；

图11是本申请实施例提供的一种权限控制设备的结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。

需要说明的是，本申请的说明书和权利要求书中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

本申请实施例提供了一种权限控制方法，请参考图1，图1示出了本申请实施例提供的权限控制方法的实施环境的示意图。该实施环境包括：终端101。

终端101安装有需要进行权限控制的应用程序，当该应用程序需要进行权限控制时，可应用本申请实施例提供的方法进行控制。权限控制的过程是指获取权限的授权结果，进而执行与权限的授权结果匹配的操作的过程。终端101可以泛指多个终端中的一个。本领域技术人员可以知晓，上述终端101的数量可以更多或更少，比如上述终端101可以仅为一个，或者上述终端101为几十个或几百个，或者更多数量，本申请实施例对终端的数量和设备类型不加以限定。

在一种可能实现方式中，终端101可以是任何一种可与用户通过键盘、触摸板、触摸屏、遥控器、语音交互或手写设备等一种或多种方式进行人机交互的电子产品，例如PC(Personal Computer，个人计算机)、手机、智能手机、PDA(Personal Digital Assistant，个人数字助手)、可穿戴设备、掌上电脑PPC(Pocket PC)、平板电脑、智能车机、智能电视、智能音箱等。在示例性实施例中，终端101能够与应用程序的后台服务器进行交互。终端101与应用程序的后台服务器通过有线或无线网络建立通信连接。

本领域技术人员应能理解上述终端101仅为举例，其他现有的或今后可能出现的终端如可适用于本申请，也应包含在本申请保护范围以内，并在此以引用方式包含于此。

基于上述图1所示的实施环境，本申请实施例提供一种权限控制方法，以该方法应用于终端101为例。如图2所示，本申请实施例提供的方法包括如下步骤：

在步骤201中，基于应用程序的启动指令，确定应用程序对应的协议信息的处理状态。

终端中安装有一个或多个应用程序，当交互对象触发终端主屏幕中的某一应用程序的图标时，终端获取该应用程序的启动指令。应用程序的启动指令用于指示交互对象需要使用该应用程序。在本申请实施例中，在获取到应用程序的启动指令之后、在成功启动该应用程序之前，进行了权限控制，以避免应用程序一启动就执行侵犯交互对象的隐私的操作，安全性较高。

在一种可能实现方式中，应用程序配置有用于指示应用程序的权限控制方式的目标权限控制信息，该目标权限控制信息通过对直接调用的通用权限控制信息中的模板配置信息进行自定义配置得到。目标权限控制信息用于指示条件与权限控制操作的对应关系，也就是说，在目标权限控制信息中规定了在什么的条件下执行什么样的权限控制操作，从而能够使得终端根据目标权限控制信息实现权限控制过程。在示例性实施例中，目标权限控制信息的形式为代码。

目标权限控制信息是通过对直接调用的通用权限控制信息中的模板配置信息进行自定义配置得到的。通用权限控制信息用于为多个应用程序提供通用的权限控制信息。示例性地，通用权限控制信息适用的多个应用程序为在某一相同的系统下运行的应用程序，例如，通用权限控制信息适用在Android(安卓)系统下运行的应用程序。

通用权限控制信息预先设定好并供应用程序的开发者直接调用。在一种可能实现方式中，通用权限控制信息中包括供应用程序的开发者自定义展示信息或UI(UserInterface，用户界面)展示效果的模板配置信息，以满足不同应用程序的不同需求。本申请实施例对通用权限控制信息中的模板配置信息的类型及数量不加以限定，这可以由通用权限控制信息的开发者灵活设定。通过对直接调用的通用权限控制信息中的模板配置信息进行自定义配置，即可得到目标权限控制信息。也就是说，目标权限控制信息是指对直接调用的通用权限控制信息中的模板配置信息进行自定义配置后得到的控制信息。

在示例性实施例中，任一模板配置信息中可以包含默认信息，也可以不包含任何信息，本申请实施例对此不加以限定。

在一种可能实现方式中，通用权限控制信息中的模板配置信息至少包括协议配置信息、权限说明配置信息、必要权限列表配置信息和启动主页面配置信息。协议配置信息用于供应用程序的开发者自定义配置应用程序对应的协议信息，权限说明配置信息用于供应用程序的开发者自定义配置应用程序对应的权限说明信息，必要权限列表配置信息用于供应用程序的开发者自定义配置应用程序对应的必要权限列表，启动主页面配置信息用于供应用程序的开发者自定义配置应用程序对应的启动主页面。基于此，通过对通用控制信息中的协议配置信息、权限说明配置信息、必要权限列表配置信息以及启动主页面配置信息进行自定义配置，即可得到目标权限控制信息。需要说明的是，应用程序对应的协议信息、应用程序对应的权限说明信息、应用程序对应的必要权限列表和应用程序对应的启动主页面将在后续内容进行详细介绍，此处暂不赘述。

需要说明的是，以上模板配置信息仅为举例，在示例性实施例中，还可以包括其他类型的模板配置信息，以满足应用程序的开发者更多自定义需求，如，还可以包括UI配置信息，以供应用程序的开发者灵活设定UI展示样式。

获取目标权限控制信息的过程在应用程序的开发终端进行。在获取目标权限控制信息后，应用程序的开发者将目标权限控制信息配置到应用程序启动时调用，然后得到配置有目标权限控制信息的应用程序。在得到配置有目标权限控制信息的应用程序后，应用程序的开发终端将该配置有目标权限控制信息的应用程序发布到应用市场，然后交互对象的终端能够在应用市场中下载并安装该配置有目标权限控制信息的应用程序。基于此，交互对象的终端能够基于目标权限控制信息，实现对应用程序的权限控制过程。

在本申请实施例中，应用程序的开发人员只需在直接调用通用权限控制信息的基础上，自定义配置协议信息、权限说明信息、必要权限列表，并且指定好启动后跳转到的启动主页面即可得到目标权限控制信息，在将目标权限控制信息配置到应用程序启动时调用即可实现权限控制过程，无需关心中间的具体逻辑细节，权限控制信息的接入方便高效。此外，对于应用程序有自己的自定义UI展示需求的，也可以通过修改页面样式、图标样式等方式，轻松自定义适合自己应用程序的风格的UI展示样式。

在获取到应用程序的启动指令后，交互对象的终端即可基于目标权限控制信息指示的权限控制方式进行权限控制过程。在进行权限控制过程中，首先需要确定应用程序对应的协议信息的处理状态。

在一种可能实现方式中，应用程序对应的协议信息的处理状态包括两种，分别为协议信息未被确认过和协议信息被确认过。若应用程序的协议信息的处理状态为协议信息未被确认过，则说明交互对象在此次触发应用程序之前，未同意过该应用程序的协议信息。若应用程序的协议信息的处理状态为协议信息被确认过，说明交互对象在此次触发应用程序之前，同意过该应用程序的协议信息。

在示例性实施例中，在获取到应用程序的启动指令时，无法确定交互对象是否已经授权网络权限，无法通过远端存储的网络数据确定应用程序对应的协议信息的处理状态。在一种可能实现方式中，确定应用程序对应的协议信息的处理状态的方式包括但不限于以下三种：

方式1：根据应用程序的第一本地存储信息中是否包括协议信息的确认标记信息，确定应用程序对应的协议信息的处理状态。

应用程序的第一本地存储信息用于存储协议信息的确认标记信息类型的信息。协议信息的确认标记信息会在协议信息被确认后记录在应用程序的第一本地存储信息中。示例性地，应用程序的第一本地存储信息是指应用程序本地的SharePreference(分享偏好)信息。

基于此种方式1，响应于应用程序的第一本地存储信息中包括协议信息的确认标记信息，确定应用程序对应的协议信息的处理状态为该协议信息被确认过；响应于应用程序的第一本地存储信息中不包括协议信息的确认标记信息，确定应用程序对应的协议信息的处理状态为该协议信息未被确认过。本申请实施例对协议信息的确认标记信息的形式不加以限定，例如，协议信息的确认标记信息的形式为标记位。

方式2：根据应用程序的第二本地存储信息中是否包括应用程序的登录信息，确定应用程序对应的协议信息的处理状态。

应用程序的第二本地存储信息用于存储应用程序的登录信息类型的信息。应用程序的登录信息会在交互对象成功登录应用程序后记录在第二本地存储信息中，本申请实施例对应用程序的登录信息的存储方式不加以限定，例如，应用程序的登录信息以文件的形式进行存储，当第二本地存储信息中包括应用程序的登录信息对应的文件的标记时，认为应用程序的第二本地存储信息中包括应用程序的登录信息。

需要说明的是，由于应用程序的登录信息会在交互对象成功登录应用程序后记录在第二本地存储信息中，所以若应用程序的第二本地存储信息中包括应用程序的登录信息，则说明交互对象成功登录过该应用程序。由于在应用程序成功启动后才允许登录，协议信息被确认后才允许成功启动，所以，当应用程序的第二本地存储信息中包括应用程序的登录信息时，说明该协议信息被确认过。

基于此种方式2，响应于应用程序的第二本地存储信息中包括应用程序的登录信息，确定应用程序对应的协议信息的处理状态为该协议信息被确认过；响应于应用程序的第二本地存储信息中不包括应用程序的登录信息，确定应用程序对应的协议信息的处理状态为该协议信息未被确认过。此种方式2能够兼容老版本的应用程序。

方式3：根据应用程序的第一本地存储信息中是否包括协议信息的确认标记信息以及应用程序的第二本地存储信息中是否包括应用程序的登录信息，确定应用程序对应的协议信息的处理状态。

在此种方式3下，通过综合考虑应用程序的第一本地存储信息中是否包括协议信息的确认标记信息以及应用程序的第二本地存储信息中是否包括应用程序的登录信息来确定应用程序对应的协议信息的处理状态，有利于提高应用程序对应的协议信息的处理状态的确定准确性。

基于此种方式3，响应于应用程序的第一本地存储信息中包括协议信息的确认标记信息，或者响应于应用程序的第二本地存储信息中包括应用程序的登录信息，确定应用程序对应的协议信息的处理状态为该协议信息被确认过。响应于应用程序的第一本地存储信息中不包括协议信息的确认标记信息，且应用程序的第二本地存储信息中不包括应用程序的登录信息，确定应用程序对应的协议信息的处理状态为该协议信息未被确认过。

在确定应用程序对应的协议信息的处理状态之后，根据协议信息的处理状态处理后续权限控制过程。在不同的协议信息的处理状态下，具体不同的处理过程。当协议信息的处理状态为协议信息未被确认过时，执行下述步骤202；当协议信息的处理状态为协议信息被确认过时，处理过程参见图7所示的实施例，此次暂不赘述。

在步骤202中，响应于协议信息的处理状态为协议信息未被确认过，展示协议信息。

若确定应用程序对应的协议信息的处理状态为协议信息未被确认过，则展示该应用程序对应的协议信息。在示例性实施例中，协议信息以弹窗的形式进行展示。应用程序对应的协议信息用于指示该应用程序在运行过程中遵守的协议，该应用程序在运行过程中遵守的协议用于指示应用程序在运行过程中对交互对象的个人信息的处理规则。

应用程序对应的协议信息用于提示交互对象该应用程序在运行过程中遵守的一个或多个协议，例如，许可协议、隐私数据协议等。在示例性实施例中，在展示的协议信息中包括各个协议的名称，各个协议的名称为可触发模式，在任一协议的名称被触发时，终端展示该协议的具体内容。当检测到协议的具体内容的关闭指令时，再返回展示协议信息的页面。示例性地，协议的具体内容的关闭指令可以是指交互对象触发关闭控件，也可以是指终端检测到协议的具体内容已经完整展示完毕等，本申请实施例对此不加以限定。

在示例性实施例中，应用程序对应的协议信息配置在目标权限控制信息中。通用权限控制信息中包括供由应用程序的开发者自定义配置协议信息的协议配置信息，以适应自定义配置协议信息的需求。应用程序的开发者在通过直接调用的方式得到通用权限控制信息后，能够在协议配置信息中自定义配置该应用程序对应的需要展示给交互对象查看的协议信息。示例性地，协议配置信息标记为“msdk_policy_content.html”。应用程序的开发者自定义配置的协议信息会被展示给交互对象查看。示例性地，协议信息的展示方式为：在协议信息展示页面的TextView(文本视图)控件中展示该协议信息。示例性地，在协议信息展示页面的WebView(网页视图)控件中展示该协议信息。

需要说明的是，不同应用程序对应的协议信息可以相同，也可以不同，本申请实施例对此不加以限定。

在一种可能实现方式中，在展示协议信息的页面中，还展示确认控件和拒绝控件，以供交互对象通过触发控件做出是否同意协议信息的选择。本申请实施例对确认控件和拒绝控件的展示方式不加以限定，示例性地，确认控件和拒绝控件的展示方式可以是指通用启动控制信息指示的默认的展示方式。在示例性实施例中，若通用启动控制信息中用于指示确认控件和拒绝控件的展示方式的信息为可自定义配置的信息，则确认控件和拒绝控件的展示方式还可以为开发者自定义配置的展示方式。在示例性实施例中，确认控件利用标记有“同意”字样的按钮进行展示，拒绝控件利用标记有“不同意”字样的按钮进行展示。

例如，展示协议信息的过程如图3所示。当检测到图3中的(1)中的名称为APP5的应用程序的触发操作时，获取名称为APP5的应用程序的启动指令。若获取名称为APP5的应用程序的启动指令时，确定该名称为APP5的应用程序对应的协议信息未被确认过，则展示如图3中的(2)所示协议信息展示页面，在协议信息展示页面中，显示有协议信息、利用标记有“同意”字样的按钮进行展示的确认控件301和利用标记有“不同意”字样的按钮进行展示的拒绝控件302。

在图3中的(2)中展示的协议信息中，包括名称“游戏用户协议和隐私政策”以及说明内容“在您使用我们服务前，请您务必审慎阅读、充分理解游戏许可及服务协议和游戏隐私保护指引的各条款，了解我们对您个人信息的处理规则。如您已详细阅读并同意游戏许可及服务协议和游戏隐私保护指引，请点击“同意”开始使用我们的服务”。在说明内容中，带有下划线的内容“游戏许可及服务协议”和“游戏隐私保护指引”为协议的名称，协议的名称为可触发状态。

在展示协议信息、确认控件以及拒绝控件后，交互对象能够通过触发确认控件或者拒绝控件来对是否同意协议信息进行选择。响应于检测到确认控件的触发指令，获取协议信息的确认指令，此种情况下，执行步骤203。响应于拒绝控件的触发指令，获取协议信息的拒绝指令，此种情况下，不执行后续权限控制过程，直接退出应用程序。也就是说，基于协议信息的拒绝指令，退出应用程序。此种方式能够很好地规避在应用程序启动时执行一些不合规的操作的现象，只有在交互对象同意协议信息的情况下，才能够继续执行权限控制过程，以保证合规。

在步骤203中，基于协议信息的确认指令，展示应用程序对应的权限说明信息，权限说明信息用于对应用程序对应的至少一个必要权限进行提示说明。

在获取协议信息的确认指令时，说明交互对象许可协议信息中的协议中阐述的内容，展示权限说明信息。权限说明信息用于对应用程序对应的至少一个必要权限进行提示说明。必要权限是指启动应用程序必须需要的权限。应用程序对应的必要权限的类型及数量与应用程序本身有关，不同的应用程序对应的必要权限的类型和数量可能相同，也可能不同，本申请实施例对此不加以限定。

在一种可能实现方式中，权限说明信息除了用于对应用程序对应的至少一个必要权限进行提示说明外，还用于对该应用程序对应的全部非必要信息进行提示说明。在此种情况下，权限说明信息用于对应用程序运行过程中所需的全部权限进行提示说明，以使交互对象知晓应用程序运行过程所需的全部权限。在示例性实施例中，在权限说明信息中，对必要权限的说明信息和非必要权限的说明信息进行区别标记，以便于直观区分。

在一种可能实现方式中，在权限说明信息中，通过展示任一权限的类型以及该任一权限的用途，实现对任一权限进行提示说明的功能。

在一种可能实现方式中，应用程序对应的权限说明信息配置在目标权限控制信息中。通用权限控制信息中包括供应用程序的开发者自定义配置权限说明信息的权限说明配置信息，以满足不同应用程序对于权限说明信息的不同需求。应用程序的开发者在通过直接调用的方式得到通用权限控制信息后，能够在权限说明配置信息中自定义配置该应用程序对应的需要展示给交互对象查看的权限说明信息。示例性地，权限说明配置信息标记为“msdk_permission_content.html”。应用程序的开发者自定义配置的权限说明信息会被展示给交互对象查看。示例性地，权限说明信息的展示方式为：在权限说明信息展示页面的TextView(文本视图)控件中展示该权限说明信息。示例性地，在权限说明信息展示页面的WebView(网页视图)控件中展示该权限说明信息。

在示例性实施例中，在展示权限说明信息的页面中，还展示确定控件。该确定控件用于供交互对象触发以执行后续过程。示例性地，权限说明信息的展示过程如图4所示，当在图4中的(1)中检测到利用标记有“同意”字样的按钮进行展示的确认控件401的触发操作时，获取协议信息的确认指令。在获取协议信息的确认指令后，基于协议信息的确认指令，展示如图4中的(2)所示的权限说明信息和确定控件402。在图4中的(2)中，展示的权限说明信息包括名称“权限请求”、相关说明内容“为确保您的游戏体验，我们将在您使用我们的服务过程中申请以下权限”和各个权限的名称及用途等。例如，存储权限的用途为缓存图片/视频。在图4中的(2)中，对必要权限利用“必选”的字样进行标记，例如，根据图4中的(2)所示的权限说明信息可知，存储权限和手机/电话权限均为必要权限。

在步骤204中，基于权限说明信息的确认指令，利用轮询的方式获取至少一个必要权限的授权结果。

当检测到交互对象对展示权限说明信息的页面中的确定控件的触发操作时，获取权限说明信息的确认指令，然后基于权限说明信息的确认指令，进入必要权限授权流程。在必要权限授权流程中，先利用轮询的方式获取至少一个必要权限的授权结果。

在一种可能实现方式中，利用轮询的方式获取至少一个必要权限的授权结果的过程为是指在展示权限说明信息的页面中依次获取至少一个必要权限的授权结果。也就是说，在获取到上一个必要权限的授权结果后，再获取下一个必要权限的授权结果。

在一种可能实现方式中，在利用轮询的方式获取至少一个必要权限的授权结果的过程中，获取任一必要权限的授权结果的实现方式为：弹窗显示该任一必要权限的授权请求文本框，基于交互对象对该任一必要权限的授权请求文本框中的候选控件的触发操作，得到该任一必要权限的授权结果。任一必要权限的授权请求文本框用于请求获取该任一必要权限的授权结果。

在示例性实施例中，候选控件包括用于指示禁止授权的第一控件和用于指示允许授权的第二控件。基于交互对象对该任一必要权限的授权请求文本框中的候选控件的触发操作，得到该任一必要权限的授权结果的过程为：响应于检测到交互对象对该任一必要权限中的授权请求文本框中的第一控件的触发操作，将授权作为该任一必要权限的授权结果；响应于检测到交互对象对该任一必要权限中的授权请求文本框中的第二控件的触发操作，将未授权作为该任一必要权限的授权结果。

在一种可能实现方式中，任一必要权限的授权请求文本框中除包括候选控件外，还包括候选选项，该候选选项用于指示不允许再次利用轮询的方式获取未被授权的权限的授权结果。若检测到交互对象对该选项的选中操作，则说明交互对象不希望再次展示未被授权的权限的授权请求文本框。需要说明的是，由于候选选项用于对未被授权的权限进行限定，所以当交互对象触发第二控件时，该候选选项的选中操作才会有效。在示例性实施例中，对于任一必要权限，在基于轮询的方式获取该任一必要权限的授权结果的过程中，对于交互对象触发第二控件的情况，若交互对象选中了候选选项，则说明该任一必要权限的授权结果为未授权且该不允许再次利用轮询的方式获取该任一必要权限的授权结果；若交互对象未选中候选选项，则说明该任一必要权限的授权结果为未授权且允许再次利用轮询的方式获取该任一必要权限的授权结果。

在示例性实施例中，任一必要权限的授权请求文本框中还包括该任一必要权限在至少一个必要权限中的排列顺序信息和该任一必要权限对应的授权请求文本。在一种可能实现方式中，任一必要权限在至少一个必要权限中的排列顺序信息根据该至少一个必要权限的总项数以及该任一必要权限在至少一个必要权限中的排列顺序直接确定。任一必要权限对应的授权请求文本可以基于权限类型和授权请求文本的对应关系确定，权限类型和授权请求文本的对应关系记录有各种类型的权限对应的授权请求文本，进而可以直接确定该任一必要权限对应的授权请求文本。

示例性地，展示第一个必要权限的授权请求文本框的过程如图5所示。当在图5中的(1)中检测到确定控件501的触发操作时，获取权限说明信息的确认指令。在获取权限说明信息的确认指令后，基于权限说明信息的确认指令，展示如图5中的(2)所示的第一个必要权限的授权请求文本框502。在第一个必要权限的授权请求文本框502中，包括该第一个必要权限在至少一个必要权限中的排列顺序信息“第1项权限(共2项)”、该第一个必要权限对应的授权请求文本“是否允许XX访问您设备上的照片、媒体内容和文件”、用于指示禁止授权的第一控件503、用于指示允许授权的第二控件504和用于指示不允许再次利用轮询的方式获取未被授权的权限的授权结果的候选选项505。

在一种可能实现方式中，目标权限控制信息中配置有必要权限列表。通用权限控制信息中包括供应用程序的开发者自定义配置必要权限列表的必要权限列表配置信息，以满足不同应用程序对于必要权限列表的不同需求。应用程序的开发者在通过直接调用的方式得到通用权限控制信息后，能够在必要权限列表配置信息中自定义必要权限列表。示例性地，必要权限列表配置信息为列表的形式，必要权限列表配置信息标记为“msdk_permission_list.xml”。

应用程序对应的必要权限列表由应用程序的开发者根据应用程序的实际情况进行设定。需要说明的是，应用程序对应的必要权限列表中包括该应用程序的启动过程所需的全部必要权限，也就是说，应用程序对应的必要权限列表中包括在权限说明信息中展示的全部必要权限，以避免出现无法启动应用程序的情况。

在配置好必要权限列表后，终端会基于权限说明信息的确认指令，读取必要权限列表，以根据读取出的必要权限列表进一步确定需要获取授权结果的必要权限。

在一种可能实现方式中，终端根据读取出的必要权限列表进一步确定需要获取授权结果的必要权限的过程为：终端基于应用程序本地的权限配置文件对必要权限列表中的各个必要权限进行过滤，保留满足保留条件的必要权限，将保留的必要权限作为需要获取授权结果的必要权限。应用程序本地的权限配置文件用于声明应用程序对应的全部权限以及各个权限的处理状态，任一权限的处理状态用于指示该权限是否被授权。示例性地，满足保留条件的必要权限是指在应用程序本地的权限配置文件中声明的未被授权的必要权限。在示例性实施例中，未被授权包括两种情况：不具有授权结果，或者，具有授权结果但授权结果为未授权。在示例性实施例中，应用程序本地的权限配置文件为AndroidManifest.xml配置文件。

在示例性实施例中，对于协议信息未被确认过的情况，应用程序对应的各个必要权限均未获取过授权结果(即均未被授权)，因此，必要权限列表中的各个必要权限均为满足保留条件的必要权限，必要权限列表中会保留全部的必要权限。也就是说，应用程序对应的至少一个必要权限在获取授权结果之前均处于必要权限列表中。在一种可能实现方式中，在轮询获取至少一个必要权限的授权结果的过程中，若某一必要权限的授权结果为授权，则将该必要权限从必要权限列表中剔除。也就是说，在轮询获取至少一个必要权限的授权结果的过程中，将授权结果为授权的必要权限从必要权限列表中剔除。

在一种可能实现方式中，在利用轮询的方式获取至少一个必要权限的授权结果之后，至少一个必要权限的授权结果包括以下两种情况：

情况1：至少一个必要权限的授权结果均为授权。

在此种情况1下，执行步骤205。

情况2：至少一个必要权限的授权结果不均为授权，也就是说，至少一个必要权限中存在授权结果为未授权的至少一个目标权限。

在一种可能实现方式中，对应将授权结果为授权的必要权限从必要权限列表中剔除的情况，响应于剔除处理后的必要权限列表不为空列表，确定至少一个必要权限中存在授权结果为未授权的至少一个目标权限。

在此种情况2下，展示选择控件，选择控件包括重新授权控件和设置控件。在一种可能实现方式中，展示选择控件的方式为：在展示权限说明信息的页面中展示选择控件。在示例性实施例中，选择控件除包括重新授权控件和设置控件外，还包括退出控件。例如，选择控件的展示示意图如6所示，在图6展示的选择控件中，包括重新授权控件601、设置控件602和退出控件603。

选择控件中的不同控件具有不同的功能。重新授权控件用于控制利用轮询的方式获取至少一个第一权限的授权结果；设置控件用于控制利用跳转到系统设置页面的方式获取至少一个第二权限的授权结果；退出控件用于控制退出应用程序。其中，至少一个第一权限为至少一个目标权限中满足条件的目标权限，至少一个第二权限为至少一个目标权限中除至少一个第一权限外的各个目标权限；满足条件的目标权限为允许利用轮询的方式再次获取授权结果的目标权限。

通过展示选择控件，能够为交互对象的选择提供参考。交互对象能够选择重新授权必要权限，也能够选择到系统设置页面中授权必要权限，还能够选择退出当前应用程序。终端会根据交互对象的选择执行对应的操作。

在一种可能实现方式中，在展示选择控件后，包括：基于重新授权控件的触发操作，利用轮询的方式获取至少一个第一权限的授权结果；基于设置控件的触发操作，利用跳转到系统设置页面的方式获取至少一个第二权限的授权结果；响应于所述至少一个第一权限和至少一个第二权限的授权结果均为授权，跳转到应用程序对应的启动主页面。

在一种可能实现方式中，利用跳转到系统设置页面的方式获取至少一个第二权限的授权结果的过程为：跳转到系统设置页面，根据交互对象在系统设置页面对至少一个第二权限的设置获取至少一个第二权限的授权结果。

需要说明的是，以上所述为至少一个目标权限中既包括第一权限又包括第二权限的情况。在示例性实施例中，至少一个目标权限中可能仅包括第一权限，至少一个目标权限中还可能仅包括第二权限。

在一种可能实现方式中，对应至少一个目标权限中仅包括第二权限的情况，由于第二权限为不允许利用轮询的方式再次获取授权结果的目标权限，所以在检测到交互对象对重新授权控件的触发操作后，不会执行利用轮询的方式获取授权结果的过程。在此种情况下，显示提示文字，以告知交互对象需要通过触发设置控件到系统设置页面中进行授权。

在一种可能实现方式中，对于至少一个目标权限中既包括至少一个第一权限又包括至少一个第二权限的情况，响应于至少一个第一权限和至少一个第二权限的授权结果均为授权，跳转到应用程序对应的启动主页面。对于至少一个目标权限中仅包括至少一个第一权限情况，响应于至少一个第一权限的授权结果均为授权，跳转到应用程序对应的启动主页面。对于至少一个目标权限中仅包括至少一个第二权限情况，响应于至少一个第二权限的授权结果均为授权，跳转到应用程序对应的启动主页面。也就是说，响应于至少一个目标权限的授权结果均为授权，跳转到应用程序对应的启动主页面。

应用程序对应的启动主页面是指应用程序成功启动后需要显示的页面。在示例性实施例中，应用程序对应的启动主页面配置在目标权限控制信息中。通用权限控制信息中包括供应用程序的开发者自定义启动主页面的启动主页面配置信息，以满足不同应用程序对于启动主页面的不同需求。应用程序的开发者在通过直接调用的方式得到通用权限控制信息后，能够在启动主页面配置信息中自定义配置启动主页面。当跳转到应用程序对应的启动主页面后，完成权限控制的整套流程闭环。

在一种可能实现方式中，对于选择控件除包括重新选择控件和设置控件外，还包括退出控件的情况，在展示选择控件之后，还包括：基于退出控件的触发操作，退出应用程序。

在一种可能实现方式中，若再次获取至少一个目标权限的授权结果后，该至少一个目标权限中仍然存在未被授权的权限，则再次展示选择控件，直至交互对象主动触发退出控件，或者全部的必要权限均被授权，或者展示选择控件的次数达到次数阈值。当交互对象主动触发退出控件时，则退出应用程序；若全部的必要权限均被授权，则跳转到应用程序的启动主页面；若展示选择控件的次数达到次数阈值，则退出应用程序。次数阈值根据经验设置，或者根据应用场景灵活调整，本申请实施例对此不加以限定。

在步骤205中，响应于至少一个必要权限的授权结果均为授权，跳转到应用程序对应的启动主页面。

若在利用轮询的方式获取至少一个必要权限的授权结果后，该至少一个必要权限的授权结果均为授权，则直接跳转到应用程序对应的启动主页面。至此，完成权限控制流程闭环。

在一种可能实现方式中，在跳转应用程序对应的启动主页面之后，还包括：响应于应用程序对应的待执行操作需要依赖任一非必要权限对应的资源，获取任一非必要权限的授权结果；响应于任一非必要权限的授权结果为授权，执行待执行操作。由于应用程序的启动过程中仅对必要权限进行了授权，应用程序对应的非必要权限可能会影响某些执行操作。在应用程序的运行过程中，若应用程序对应的待执行操作需要依赖某一非必要权限对应的资源，则获取该非必要权限的授权结果，以便于根据该非必要权限的授权结果确定是否执行该待执行操作。基于此种方式，能够在需要使用非必要权限对应的资源时，再动态获取该非必要权限的授权结果。

在一种可能实现方式中，获取任一非必要权限的授权结果的方式可以由应用程序的开发者设定，本申请实施例对此不加以限定。示例性地，获取任一非必要权限的授权结果的方式为：弹窗显示该任一非必要权限的授权请求文本框，基于交互对象对该任一非必要权限的授权请求文本框中的候选控件的触发操作，得到该任一非必要权限的授权结果。

在示例性实施例中，根据该非必要权限的授权结果确定是否执行该待执行操作的过程为：获取该非必要权限的授权结果为授权，则执行该待执行操作；若该非必要权限的授权结果为未授权，则进行该待执行操作。在一种可能实现方式中，执行待执行操作的过程为：调用该非必要权限对应的资源，基于该非必要权限对应的资源执行待执行操作。

在本申请实施例中，将协议信息确认过程和必要权限授权过程整合，得到一套权限控制的合规流程。需要先展示协议信息得到交互对象的确认，然后再申请必要权限的授权，解决了应用程序一启动未得到交互对象允许就开始上报数据等不合规的问题。通过简明的应用界面流程引导并告知交互对象本应用程序对应的协议信息和运行本应用程序所需的权限，使得权限控制过程更加规范透明，符合当前政策趋势。

在本申请实施例中，在应用程序启动的过程中进行权限控制，且在权限控制的过程中融入了协议信息的确认过程，在协议信息被确认后再获取必要权限的授权结果，在必要权限均被授权后，再跳转到应用程序的启动主页面。基于此种过程，在应用程序成功启动之前就进行了权限控制，能够规避在应用程序一启动时就执行侵犯用户隐私的操作的现象，权限控制更加规范有效，有利于提高对用户隐私的保护力度，安全性较高。

基于上述图1所示的实施环境，本申请实施例提供一种权限控制方法，以该方法应用于终端101为例。如图7所示，本申请实施例提供的方法包括如下步骤：

在步骤701中，基于应用程序的启动指令，确定应用程序对应的协议信息的处理状态。

此步骤701的实现过程参见步骤201，此处不再赘述。

在步骤702中，响应于协议信息的处理状态为协议信息被确认过，检测应用程序对应的至少一个必要权限的处理状态。

当协议信息的处理状态为协议信息被确认过时，说明交互对象在之前确认过该协议信息。在一种可能实现方式中，确定协议信息的处理状态为协议信息被确认过的方式为：响应于应用程序的第一本地存储信息中包括协议信息的确认标记信息，确定协议信息的处理状态为协议信息被确认过；或者，响应于应用程序的第二本地存储信息中包括应用程序的登录信息，确定协议信息的处理状态为协议信息被确认过。

在协议信息的处理状态为协议信息被确认过的情况下，检测应用程序对应的至少一个必要权限的处理状态。任一必要权限的处理状态用于指示该任一必要权限是否被授权。

在一种可能实现方式中，应用程序对应的至少一个必要权限的处理状态在应用程序本地的权限配置文件中进行声明，通过检测应用程序本地的权限配置文件中声明的各个必要权限的处理状态，即可得到应用程序对应的至少一个必要权限的处理状态。

至少一个必要权限的处理状态包括以下两种情况：

情况1：至少一个必要权限的处理状态指示至少一个必要权限均被授权。

在此种情况1下，直接跳转到应用程序的启动主页面。

情况2：至少一个必要权限的处理状态指示至少一个必要权限中存在未被授权的至少一个参考权限。

在此种情况2下，执行步骤703。

在一种可能实现方式中，至少一个必要权限的处理状态指示至少一个必要权限中存在未被授权的至少一个参考权限的情况的发生条件包括但不限于以下两种：

发生条件1：在获取到应用程序的启动指令之前，未成功启动过任何版本的该应用程序。

在此种发生条件1下，由于协议信息被确认过，所以导致未成功启动过的原因为至少一个必要权限中存在未被授权的必要权限。在示例性实施例中，在一次权限控制过程中，若未成功启动应用程序，则不会保存在该次权限控制过程中已经获取的授权结果。基于此，若未成功启动过任何版本的该应用程序，则说明各个必要权限均不具有授权结果，也就是说，每个必要权限均为一个未被授权的参考权限，参考权限的数量与必要权限的数量相同。

发生条件2：启动指令需要开启的应用程序为覆盖旧版本的应用程序后得到的新版本的应用程序，新版本的应用程序对应的至少一个必要权限中除包括旧版本的应用程序对应的全部必要权限外，还包括新增必要权限，此外，在获取该新版本的应用程序的启动指令之前，成功启动过旧版本的应用程序但未成功启动过该新版本的应用程序。

由于需要开启的应用程序为覆盖旧版本的应用程序后得到的应用程序且旧版本的应用程序成功启动过，所以，旧版本的应用程序对应的全部必要权限均被授权。由于新版本的应用程序对应的至少一个必要权限中除包括旧版本的应用程序对应的全部必要权限外，还包括新增必要权限，因此，若未成功启动过该新版本的应用程序，则说明新增必要权限中存在未被授权的必要权限。

在示例性实施例中，对于在一次权限控制过程中，若未成功启动应用程序，则不会保存在该次权限控制过程中已经获取的授权结果的情况，新版本的应用程序对应的至少一个必要权限中的新增必要权限均不具有授权结果。此种情况下，每个新增必要权限均为一个未被授权的参考权限。参考权限的数量与新增必要权限的数量相同。

在步骤703中，响应于至少一个必要权限的处理状态指示至少一个必要权限中存在未被授权的至少一个参考权限，展示权限说明信息。

当至少一个必要权限的处理状态指示至少一个必要权限中存在未被授权的至少一个参考权限时，展示权限说明信息，以提示交互对象接下来需要进入权限授权流程。

展示权限说明信息的过程可以参考步骤203，此处不再赘述。在示例性实施例中，此处展示的权限说明信息仍用于对应用程序对应的全部权限进行提示说明。

在步骤704中，基于权限说明信息的确认指令，利用轮询的方式获取至少一个参考权限的授权结果。

此步骤704的实现过程参见步骤204，此处不再赘述。需要说明的是，相比于步骤204中利用轮询的方式获取至少一个必要权限的授权结果，由于此时仅有至少一个参考权限未被授权，所以仅需利用轮询的方式获取至少一个参考权限的授权结果。

在示例性实施例中，该至少一个参考权限在获取授权结果之前处于参考权限列表中。示例性地，参考权限列表是指基于应用程序本地的权限配置文件对必要权限列表中的各个必要权限进行过滤后保留的必要权限构成的权限列表。

在一种可能实现方式中，当至少一个参考权限中存在授权结果为未授权的权限时，展示选择控件。此过程的实现方式参见步骤204的相关过程，此处步骤赘述。

在步骤705中，响应于至少一个参考权限的授权结果均为授权，跳转到应用程序对应的启动主页面。

当至少一个参考权限的授权结果均为授权时，说明应用程序对应的至少一个必要权限均被授权，此时跳转到应用程序对应的启动主页面。

在本申请实施例中，在应用程序启动的过程中进行权限控制，且在权限控制的过程中融入了协议信息的确认过程，在协议信息被确认后再获取必要权限的授权结果，在必要权限均被授权后，再跳转到应用程序的启动主页面。基于此种过程，在应用程序成功启动之前就进行了权限控制，能够规避在应用程序一启动时就执行侵犯用户隐私的操作的现象，权限控制更加规范有效，有利于提高对用户隐私的保护力度，安全性较高。

在示例性实施例中，权限控制过程如图8所示。在获取应用程序的启动指令后，判断协议信息是否被确认过。当协议信息未被确认过时，展示协议信息。判断协议信息是否被确认，当协议信息未被确认时，退出应用程序。当协议信息被确认时，展示权限说明信息，然后获取全部必要权限的授权结果。判断全部必要权限的授权结果是否均为授权，若全部必要权限的授权结果均为授权，则跳转到启动主页面；若全部必要权限的授权结果不均为授权，则返回展示权限说明信息的步骤，在展示权限说明信息的页面中展示选择控件。若检测到重新授权控件或者设置控件的触发操作，则继续获取必要权限的授权结果；若检测到退出控件中的触发操作，则退出应用程序。

当协议信息未被确认过且至少一个必要权限中存在未被授权的参考权限时，执行展示权限说明信息的步骤。然后获取全部参考权限的授权结果。判断全部必要权限的授权结果是否均为授权，若全部必要权限的授权结果均为授权，则跳转到启动主页面；若全部必要权限的授权结果不均为授权，则返回展示权限说明信息的步骤，在展示权限说明信息的页面中展示选择控件。若检测到重新授权控件或者设置控件的触发操作，则继续获取参考权限的授权结果；若检测到退出控件中的触发操作，则退出应用程序。

参见图9，本申请实施例提供了一种权限控制装置，该装置包括：

确定模块901，用于基于应用程序的启动指令，确定应用程序对应的协议信息的处理状态；

展示模块902，用于响应于协议信息的处理状态为协议信息未被确认过，展示协议信息；

展示模块902，还用于基于协议信息的确认指令，展示应用程序对应的权限说明信息，权限说明信息用于对应用程序对应的至少一个必要权限进行提示说明；

获取模块903，用于基于权限说明信息的确认指令，利用轮询的方式获取至少一个必要权限的授权结果；

跳转模块904，用于响应于至少一个必要权限的授权结果均为授权，跳转到应用程序对应的启动主页面。

在一种可能实现方式中，展示模块902，还用于响应于至少一个必要权限中存在授权结果为未授权的至少一个目标权限，展示选择控件，选择控件包括重新授权控件和设置控件；

获取模块903，还用于基于重新授权控件的触发操作，利用轮询的方式获取至少一个第一权限的授权结果，至少一个第一权限为至少一个目标权限中满足条件的目标权限，满足条件的目标权限为允许利用轮询的方式再次获取授权结果的目标权限；基于设置控件的触发操作，利用跳转到系统设置页面的方式获取至少一个第二权限的授权结果，至少一个第二权限为至少一个目标权限中除至少一个第一权限外的各个目标权限；

跳转模块904，还用于响应于至少一个第一权限和至少一个第二权限的授权结果均为授权，跳转到应用程序对应的启动主页面。

在一种可能实现方式中，选择控件还包括退出控件，参见图10，该装置还包括：

退出模块905，用于基于退出控件的触发操作，退出应用程序。

在一种可能实现方式中，至少一个必要权限在获取授权结果之前均处于必要权限列表中；参见图10，该装置还包括：

剔除模块906，用于将授权结果为授权的必要权限从必要权限列表中剔除；

确定模块901，还用于响应于剔除处理后的必要权限列表不为空列表，确定至少一个必要权限中存在授权结果为未授权的至少一个目标权限。

在一种可能实现方式中，参见图10，该装置还包括：

检测模块907，用于响应于协议信息的处理状态为协议信息被确认过，检测应用程序对应的至少一个必要权限的处理状态；

展示模块902，还用于响应于至少一个必要权限的处理状态指示至少一个必要权限中存在未被授权的至少一个参考权限，展示权限说明信息；

获取模块903，还用于基于权限说明信息的确认指令，利用轮询的方式获取至少一个参考权限的授权结果；

跳转模块904，还用于响应于至少一个参考权限的授权结果均为授权，跳转到应用程序对应的启动主页面。

在一种可能实现方式中，确定模块901，还用于响应于应用程序的第一本地存储信息中包括协议信息的确认标记信息，确定协议信息的处理状态为协议信息被确认过；或者，响应于应用程序的第二本地存储信息中包括应用程序的登录信息，确定协议信息的处理状态为协议信息被确认过。

在一种可能实现方式中，获取模块903，还用于响应于应用程序对应的待执行操作需要依赖任一非必要权限对应的资源，获取任一非必要权限的授权结果；

参见图10，该装置还包括：

执行模块908，用于响应于任一非必要权限的授权结果为授权，执行待执行操作。

在一种可能实现方式中，应用程序配置有用于指示应用程序的权限控制方式的目标权限控制信息，目标权限控制信息通过对直接调用的通用权限控制信息中的模板配置信息进行自定义配置得到。

在本申请实施例中，在应用程序启动的过程中进行权限控制，且在权限控制的过程中融入了协议信息的确认过程，在协议信息被确认后再获取必要权限的授权结果，在必要权限均被授权后，再跳转到应用程序的启动主页面。基于此种过程，在应用程序成功启动之前就进行了权限控制，能够规避在应用程序一启动时就执行侵犯用户隐私的操作的现象，权限控制更加规范有效，有利于提高对用户隐私的保护力度，安全性较高。

需要说明的是，上述实施例提供的装置在实现其功能时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将设备的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的装置与方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。

图11是本申请实施例提供的一种权限控制设备的结构示意图。该设备可以为终端，例如可以是：智能手机、平板电脑、笔记本电脑或台式电脑。终端还可能被称为用户设备、便携式终端、膝上型终端、台式终端等其他名称。

通常，终端包括有：处理器1101和存储器1102。

处理器1101可以包括一个或多个处理核心，比如4核心处理器、8核心处理器等。处理器1101可以采用DSP(Digital Signal Processing，数字信号处理)、FPGA(Field-Programmable Gate Array，现场可编程门阵列)、PLA(Programmable Logic Array，可编程逻辑阵列)中的至少一种硬件形式来实现。处理器1101也可以包括主处理器和协处理器，主处理器是用于对在唤醒状态下的数据进行处理的处理器，也称CPU(Central ProcessingUnit，中央处理器)；协处理器是用于对在待机状态下的数据进行处理的低功耗处理器。在一些实施例中，处理器1101可以集成有GPU(Graphics Processing Unit，图像处理器)，GPU用于负责显示屏所需要显示的内容的渲染和绘制。一些实施例中，处理器1101还可以包括AI(Artificial Intelligence，人工智能)处理器，该AI处理器用于处理有关机器学习的计算操作。

存储器1102可以包括一个或多个计算机可读存储介质，该计算机可读存储介质可以是非暂态的。存储器1102还可包括高速随机存取存储器，以及非易失性存储器，比如一个或多个磁盘存储设备、闪存存储设备。在一些实施例中，存储器1102中的非暂态的计算机可读存储介质用于存储至少一个指令，该至少一个指令用于被处理器1101所执行以实现本申请中方法实施例提供的权限控制方法。

在一些实施例中，终端还可选包括有：外围设备接口1103和至少一个外围设备。处理器1101、存储器1102和外围设备接口1103之间可以通过总线或信号线相连。各个外围设备可以通过总线、信号线或电路板与外围设备接口1103相连。具体地，外围设备包括：射频电路1104、显示屏1105、摄像头组件1106、音频电路1107、定位组件1108和电源1109中的至少一种。

外围设备接口1103可被用于将I/O(Input/Output，输入/输出)相关的至少一个外围设备连接到处理器1101和存储器1102。在一些实施例中，处理器1101、存储器1102和外围设备接口1103被集成在同一芯片或电路板上；在一些其他实施例中，处理器1101、存储器1102和外围设备接口1103中的任意一个或两个可以在单独的芯片或电路板上实现，本实施例对此不加以限定。

射频电路1104用于接收和发射RF(Radio Frequency，射频)信号，也称电磁信号。射频电路1104通过电磁信号与通信网络以及其他通信设备进行通信。射频电路1104将电信号转换为电磁信号进行发送，或者，将接收到的电磁信号转换为电信号。可选地，射频电路1104包括：天线系统、RF收发器、一个或多个放大器、调谐器、振荡器、数字信号处理器、编解码芯片组、用户身份模块卡等等。射频电路1104可以通过至少一种无线通信协议来与其它终端进行通信。该无线通信协议包括但不限于：城域网、各代移动通信网络(2G、3G、4G及5G)、无线局域网和/或WiFi(Wireless Fidelity，无线保真)网络。在一些实施例中，射频电路1104还可以包括NFC(Near Field Communication，近距离无线通信)有关的电路，本申请对此不加以限定。

显示屏1105用于显示UI(User Interface，用户界面)。该UI可以包括图形、文本、图标、视频及其它们的任意组合。当显示屏1105是触摸显示屏时，显示屏1105还具有采集在显示屏1105的表面或表面上方的触摸信号的能力。该触摸信号可以作为控制信号输入至处理器1101进行处理。此时，显示屏1105还可以用于提供虚拟按钮和/或虚拟键盘，也称软按钮和/或软键盘。在一些实施例中，显示屏1105可以为一个，设置在终端的前面板；在另一些实施例中，显示屏1105可以为至少两个，分别设置在终端的不同表面或呈折叠设计；在再一些实施例中，显示屏1105可以是柔性显示屏，设置在终端的弯曲表面上或折叠面上。甚至，显示屏1105还可以设置成非矩形的不规则图形，也即异形屏。显示屏1105可以采用LCD(Liquid Crystal Display，液晶显示屏)、OLED(Organic Light-Emitting Diode，有机发光二极管)等材质制备。

摄像头组件1106用于采集图像或视频。可选地，摄像头组件1106包括前置摄像头和后置摄像头。通常，前置摄像头设置在终端的前面板，后置摄像头设置在终端的背面。在一些实施例中，后置摄像头为至少两个，分别为主摄像头、景深摄像头、广角摄像头、长焦摄像头中的任意一种，以实现主摄像头和景深摄像头融合实现背景虚化功能、主摄像头和广角摄像头融合实现全景拍摄以及VR(Virtual Reality，虚拟现实)拍摄功能或者其它融合拍摄功能。在一些实施例中，摄像头组件1106还可以包括闪光灯。闪光灯可以是单色温闪光灯，也可以是双色温闪光灯。双色温闪光灯是指暖光闪光灯和冷光闪光灯的组合，可以用于不同色温下的光线补偿。

音频电路1107可以包括麦克风和扬声器。麦克风用于采集用户及环境的声波，并将声波转换为电信号输入至处理器1101进行处理，或者输入至射频电路1104以实现语音通信。出于立体声采集或降噪的目的，麦克风可以为多个，分别设置在终端的不同部位。麦克风还可以是阵列麦克风或全向采集型麦克风。扬声器则用于将来自处理器1101或射频电路1104的电信号转换为声波。扬声器可以是传统的薄膜扬声器，也可以是压电陶瓷扬声器。当扬声器是压电陶瓷扬声器时，不仅可以将电信号转换为人类可听见的声波，也可以将电信号转换为人类听不见的声波以进行测距等用途。在一些实施例中，音频电路1107还可以包括耳机插孔。

定位组件1108用于定位终端的当前地理位置，以实现导航或LBS(Location BasedService，基于位置的服务)。定位组件1108可以是基于美国的GPS(Global PositioningSystem，全球定位系统)、中国的北斗系统、俄罗斯的格雷纳斯系统或欧盟的伽利略系统的定位组件。

电源1109用于为终端中的各个组件进行供电。电源1109可以是交流电、直流电、一次性电池或可充电电池。当电源1109包括可充电电池时，该可充电电池可以支持有线充电或无线充电。该可充电电池还可以用于支持快充技术。

在一些实施例中，终端还包括有一个或多个传感器1110。该一个或多个传感器1110包括但不限于：加速度传感器1111、陀螺仪传感器1112、压力传感器1113、指纹传感器1114、光学传感器1115以及接近传感器1116。

加速度传感器1111可以检测以终端建立的坐标系的三个坐标轴上的加速度大小。比如，加速度传感器1111可以用于检测重力加速度在三个坐标轴上的分量。处理器1101可以根据加速度传感器1111采集的重力加速度信号，控制显示屏1105以横向视图或纵向视图进行用户界面的显示。加速度传感器1111还可以用于游戏或者用户的运动数据的采集。

陀螺仪传感器1112可以检测终端的机体方向及转动角度，陀螺仪传感器1112可以与加速度传感器1111协同采集用户对终端的3D动作。处理器1101根据陀螺仪传感器1112采集的数据，可以实现如下功能：动作感应(比如根据用户的倾斜操作来改变UI)、拍摄时的图像稳定、游戏控制以及惯性导航。

压力传感器1113可以设置在终端的侧边框和/或显示屏1105的下层。当压力传感器1113设置在终端的侧边框时，可以检测用户对终端的握持信号，由处理器1101根据压力传感器1113采集的握持信号进行左右手识别或快捷操作。当压力传感器1113设置在显示屏1105的下层时，由处理器1101根据用户对显示屏1105的压力操作，实现对UI界面上的可操作性控件进行控制。可操作性控件包括按钮控件、滚动条控件、图标控件、菜单控件中的至少一种。

指纹传感器1114用于采集用户的指纹，由处理器1101根据指纹传感器1114采集到的指纹识别用户的身份，或者，由指纹传感器1114根据采集到的指纹识别用户的身份。在识别出用户的身份为可信身份时，由处理器1101授权该用户执行相关的敏感操作，该敏感操作包括解锁屏幕、查看加密信息、下载软件、支付及更改设置等。指纹传感器1114可以被设置在终端的正面、背面或侧面。当终端上设置有物理按键或厂商Logo时，指纹传感器1114可以与物理按键或厂商Logo集成在一起。

光学传感器1115用于采集环境光强度。在一个实施例中，处理器1101可以根据光学传感器1115采集的环境光强度，控制显示屏1105的显示亮度。具体地，当环境光强度较高时，调高显示屏1105的显示亮度；当环境光强度较低时，调低显示屏1105的显示亮度。在另一个实施例中，处理器1101还可以根据光学传感器1115采集的环境光强度，动态调整摄像头组件1106的拍摄参数。

接近传感器1116，也称距离传感器，通常设置在终端的前面板。接近传感器1116用于采集用户与终端的正面之间的距离。在一个实施例中，当接近传感器1116检测到用户与终端的正面之间的距离逐渐变小时，由处理器1101控制显示屏1105从亮屏状态切换为息屏状态；当接近传感器1116检测到用户与终端的正面之间的距离逐渐变大时，由处理器1101控制显示屏1105从息屏状态切换为亮屏状态。

本领域技术人员可以理解，图11中示出的结构并不构成对终端的限定，可以包括比图示更多或更少的组件，或者组合某些组件，或者采用不同的组件布置。

在示例性实施例中，还提供了一种计算机设备，该计算机设备包括处理器和存储器，该存储器中存储有至少一条程序代码。该至少一条程序代码由一个或者一个以上处理器加载并执行，以实现上述任一种权限控制方法。

在示例性实施例中，还提供了一种计算机可读存储介质，该计算机可读存储介质中存储有至少一条程序代码，该至少一条程序代码由计算机设备的处理器加载并执行，以实现上述任一种权限控制方法。

在一种可能实现方式中，上述计算机可读存储介质可以是只读存储器(Read-OnlyMemory，ROM)、随机存取存储器(Random Access Memory，RAM)、只读光盘(Compact DiscRead-Only Memory，CD-ROM)、磁带、软盘和光数据存储设备等。

在示例性实施例中，还提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述任一种权限控制方法。

应当理解的是，在本文中提及的“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。

以上所述仅为本申请的示例性实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (10)

1.一种权限控制方法，其特征在于，所述方法包括：

基于应用程序的启动指令，确定所述应用程序对应的协议信息的处理状态；

响应于所述协议信息的处理状态为所述协议信息未被确认过，展示所述协议信息；

基于所述协议信息的确认指令，展示所述应用程序对应的权限说明信息，所述权限说明信息用于对所述应用程序对应的至少一个必要权限进行提示说明；

基于所述权限说明信息的确认指令，利用轮询的方式获取所述至少一个必要权限的授权结果；

响应于所述至少一个必要权限的授权结果均为授权，跳转到所述应用程序对应的启动主页面。

2.根据权利要求1所述的方法，其特征在于，所述利用轮询的方式获取所述至少一个必要权限的授权结果之后，所述方法还包括：

响应于所述至少一个必要权限中存在授权结果为未授权的至少一个目标权限，展示选择控件，所述选择控件包括重新授权控件和设置控件；

基于所述重新授权控件的触发操作，利用轮询的方式获取至少一个第一权限的授权结果，所述至少一个第一权限为所述至少一个目标权限中满足条件的目标权限，所述满足条件的目标权限为允许利用轮询的方式再次获取授权结果的目标权限；

基于所述设置控件的触发操作，利用跳转到系统设置页面的方式获取至少一个第二权限的授权结果，所述至少一个第二权限为所述至少一个目标权限中除所述至少一个第一权限外的各个目标权限；

响应于所述至少一个第一权限和所述至少一个第二权限的授权结果均为授权，跳转到所述应用程序对应的启动主页面。

3.根据权利要求2所述的方法，其特征在于，所述至少一个必要权限在获取授权结果之前均处于必要权限列表中；所述响应于所述至少一个必要权限中存在授权结果为未授权的至少一个目标权限，展示选择控件之前，所述方法还包括：

将授权结果为授权的必要权限从所述必要权限列表中剔除；

响应于剔除处理后的必要权限列表不为空列表，确定所述至少一个必要权限中存在授权结果为未授权的至少一个目标权限。

4.根据权利要求1所述的方法，其特征在于，所述基于应用程序的启动指令，确定所述应用程序对应的协议信息的处理状态之后，所述方法还包括：

响应于所述协议信息的处理状态为所述协议信息被确认过，检测所述应用程序对应的至少一个必要权限的处理状态；

响应于所述至少一个必要权限的处理状态指示所述至少一个必要权限中存在未被授权的至少一个参考权限，展示所述权限说明信息；

基于所述权限说明信息的确认指令，利用轮询的方式获取所述至少一个参考权限的授权结果；

响应于所述至少一个参考权限的授权结果均为授权，跳转到所述应用程序对应的启动主页面。

5.根据权利要求4所述的方法，其特征在于，所述响应于所述协议信息的处理状态为所述协议信息被确认过，检测所述应用程序对应的至少一个必要权限的处理状态之前，所述方法还包括：

响应于所述应用程序的第一本地存储信息中包括所述协议信息的确认标记信息，确定所述协议信息的处理状态为所述协议信息被确认过；或者，

响应于所述应用程序的第二本地存储信息中包括所述应用程序的登录信息，确定所述协议信息的处理状态为所述协议信息被确认过。

6.根据权利要求1-5任一所述的方法，其特征在于，所述跳转到所述应用程序对应的启动主页面之后，所述方法还包括：

响应于所述应用程序对应的待执行操作需要依赖任一非必要权限对应的资源，获取所述任一非必要权限的授权结果；

响应于所述任一非必要权限的授权结果为授权，执行所述待执行操作。

7.根据权利要求1-5任一所述的方法，其特征在于，所述应用程序配置有用于指示所述应用程序的权限控制方式的目标权限控制信息，所述目标权限控制信息通过对直接调用的通用权限控制信息中的模板配置信息进行自定义配置得到。

8.一种权限控制装置，其特征在于，所述装置包括：

确定模块，用于基于应用程序的启动指令，确定所述应用程序对应的协议信息的处理状态；

展示模块，用于响应于所述协议信息的处理状态为所述协议信息未被确认过，展示所述协议信息；

所述展示模块，还用于基于所述协议信息的确认指令，展示所述应用程序对应的权限说明信息，所述权限说明信息用于对所述应用程序对应的至少一个必要权限进行提示说明；

获取模块，用于基于所述权限说明信息的确认指令，利用轮询的方式获取所述至少一个必要权限的授权结果；

跳转模块，用于响应于所述至少一个必要权限的授权结果均为授权，跳转到所述应用程序对应的启动主页面。

9.一种计算机设备，其特征在于，所述计算机设备包括处理器和存储器，所述存储器中存储有至少一条程序代码，所述至少一条程序代码由所述处理器加载并执行，以实现如权利要求1至7任一所述的权限控制方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有至少一条程序代码，所述至少一条程序代码由处理器加载并执行，以实现如权利要求1至7任一所述的权限控制方法。

Images