CN117407848A - 自定义权限的授权机制优化方法、装置、设备及存储介质 - Google Patents

Abstract

本申请公开了一种自定义权限的授权机制优化方法、装置、电子设备及存储介质，该方法包括：在接收到目标应用发送的权限请求指令的情况下，获取目标应用对应的已获取的权限集合；确定权限请求指令所对应的目标权限，并根据权限集合和目标权限的来源信息进行授权判定，其中，来源信息包括权限组别信息和开发者信息；在判定确定对目标权限进行授权的情况下，确定目标应用对目标权限申请成功。实现了在权限申请和授权判定时，根据来源信息对所申请的目标权限进行授权判定，只有在来源信息都相同的情况下，才可以进行授权处理，在提高自定义权限的授权高效性的同时，提高对自定义权限授权的安全性。

Description

自定义权限的授权机制优化方法、装置、设备及存储介质

技术领域

本申请涉及权限优化技术领域，尤其涉及一种自定义权限的授权机制优化方法、装置、电子设备及存储介质。

背景技术

Android系统的权限机制中，除系统权限外，允许应用程序自定义权限，用于保护应用的组件、接口等资源。定义方应用自定义一个权限时，可规定该权限的名称、保护等级和归属的权限组，其中，归属的权限组既可以是自定义的组名，也可以是Android系统权限所在的组名。同时，自定义权限在定义，若其归属的权限组定义为某个系统权限组，则Android系统将该自定义权限和该组内原本的权限(包括系统权限和更早归属到该组的自定义权限)，均视为同组权限。

而在Android系统中的规定，应用已获得某一权限组内的某一dangerous权限，则该应用后续申请获得该组内其他dangerous权限时，应用只需在其程序中写申请权限的代码逻辑，即可在不再弹窗获取用户点击确认的情况下，获得该组内的其他dangerous权限。而使得权限的安全保护强度相对不足，存在应用的自定义权限被其他恶意应用非法获取的潜在攻击面。

发明内容

本申请实施例的目的是提供一种自定义权限的授权机制优化方法、装置、电子设备及存储介质，以解决相关技术中自定义权限的授权机制的安全性不足的技术问题。

第一方面，本申请实施例提供了一种自定义权限的授权机制优化方法，包括：

在接收到目标应用发送的权限请求指令的情况下，获取所述目标应用对应的已获取的权限集合；

确定所述权限请求指令所对应的目标权限，并根据所述权限集合和所述目标权限的来源信息进行授权判定，其中，来源信息包括权限组别信息和开发者信息；

在判定确定对所述目标权限进行授权的情况下，确定所述目标应用对所述目标权限申请成功。

第二方面，本申请实施例提供了一种自定义权限的授权机制优化装置，包括：

请求接收模块，用于在接收到目标应用发送的权限请求指令的情况下，获取所述目标应用对应的已获取的权限集合；

权限判定模块，用于确定所述权限请求指令所对应的目标权限，并根据所述权限集合和所述目标权限的来源信息进行授权判定，其中，来源信息包括权限组别信息和开发者信息；

判定处理模块，用于在判定确定对所述目标权限进行授权的情况下，确定所述目标应用对所述目标权限申请成功。

第三方面，本申请实施例提供了一种电子设备，电子设备包括处理器、存储器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述任一项所述的自定义权限的授权机制优化方法中的步骤。

第四方面，本申请实施例提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现上述任一项所述的自定义权限的授权机制优化方法中的步骤。

本申请实施例提供了一种自定义权限的授权机制优化方法、装置、电子设备及存储介质，在进行权限的申请和授权判定时，接收目标应用所发出的权限请求指令，并且获取与目标应用相关联的已经获取的权限的权限集合，同时根据权限请求指令确定当前进行申请的目标权限，接着根据权限集合中每一个权限的来源信息和目标权限的来源信息进行授权判定处理，而所得到的来源信息包括权限组别信息和开发者信息，进而在通过判定确定对目标权限进行授权的情况下，确定目标应用对目标权限申请成功。实现了在权限申请和授权判定时，根据来源信息对所申请的目标权限进行授权判定，只有在来源信息都相同的情况下，才可以进行授权处理，在提高自定义权限的授权高效性的同时，提高对自定义权限授权的安全性。

附图说明

图1是本申请实施例提供的自定义权限的授权机制优化方法的一种流程示意；

图2是本申请实施例提供的得到权限集合的步骤的一种流程示意图；

图3是本申请实施例提供的进行授权判定的步骤的一种流程示意图；

图4是本申请实施例提供的得到来源信息集合的步骤的一种流程示意图；

图5是本申请实施例提供的根据对比结果进行授权判定的步骤的一种流程示意图；

图6是本申请实施例提供的自定义权限的授权机制优化装置的一种结构示意图；

图7是本申请实施例提供的电子设备的一种结构示意图；

图8是本申请实施例提供的电子设备的另一种结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

应当理解的是，本公开的方法实施方式中记载的各个步骤可以按照不同的顺序执行，和/或并行执行。此外，方法实施方式可以包括附加的步骤和/或省略执行示出的步骤。本公开的范围在此方面不受限制。

本文使用的术语“包括”及其变形是开放性包括，即“包括但不限于”。术语“基于”是“至少部分地基于”。术语“一个实施例”表示“至少一个实施例”；术语“另一实施例”表示“至少一个另外的实施例”；术语“一些实施例”表示“至少一些实施例”。其他术语的相关定义将在下文描述中给出。

在相关技术中，

为了解决相关技术中存在的技术问题，本申请实施例提供了一种自定义权限的授权机制优化方法，请参见图1，图1是本申请实施例提供的自定义权限的授权机制优化方法的一种流程示意图，该方法包括步骤101至步骤103。

步骤101，在接收到目标应用发送的权限请求指令的情况下，获取目标应用对应的已获取的权限集合。

在一实施例中，在进行权限的申请和授权判定时，首先设备或者终端接收目标应用所发送的权限请求指令，以进行相应的权限判定，而在进行判定时，首先琥珀比目标应用所对应的已经获取的权限的权限集合，其中，权限集合中包含有所有已经对目标应用所授权的权限。

在实际应用中，权限可以是设备或者终端已经定义好的，如系统权限，还可以是应用在开发时为了保护应用的组件、接口等资源而自定义的权限，而在进行权限的自定义时，需要将其与系统权限进行相同的处理，包括归属于不同的系统权限组别，同时，不同的权限组别的安全等等级也是有所不同的，比如有的权限为常规的默认权限，不需要用户进行人为的授权处理，而有的权限级别较高，如dangerous权限，在应用需要对该权限进行申请时，需要进行弹窗提示，只有在用户确认授权的情况下，才能完成对该权限的授权。

示例性地，在进行权限的申请和授权判定时，对于申请权限的目标应用而言，在设备或者系统中可能已经存在有已经针对目标应用而授权的权限，因此在进行处理时，可以获取与目标应用相对应的已经获取使用权限的权限集合。

同样地，除了存在已经进行授权的权限之外，也可能不存在任何相关的已经授权的权限，而此时则需要进行弹窗处理，以完成授权判定的处理，具体包括：在确定目标应用不存在权限集合的情况下，根据权限请求指令生成相应的反馈信息，并根据反馈信息进行弹窗提示；在接收到基于弹窗提示输入的接受指令的情况下，确定目标应用对目标权限申请成功；在接收到基于弹窗提示输入的拒绝指令的情况下，确定目标应用对目标权限申请失败。

具体地，在接收到目标应用发送的权限请求指令之后，在确定系统中不存在针对目标应用进行授权的权限时，将根据所接收到的权限请求指令申城相应的反馈信息，进而根据反馈信息进行弹窗处理来进行相应的提示，然后在接收到用户输入的接受指令时确定授权成功，也就是此时目标应用对目标权限申请成功，反之则申请失败。

进一步地，在接收到权限请求指令来获取相对应的权限集合时，可以参照图2，图2是本申请实施例提供的得到权限集合的步骤的一种流程示意图，其中，该步骤包括步骤201至步骤202。

步骤201，在接收到目标应用发送的权限请求指令的情况下，识别目标应用的应用标识；

步骤202，根据应用标识在权限列表中进行查询，得到目标应用对应的已获取的权限集合。

在一实施例中，在接收到目标应用发送的权限请求指令时，可以获取到目标应用的相关信息，比如应用唯一的标识信息，同时，对于目标应用所关联的已经授权的权限，在授权的时候可以进行相应的记录和存储，如记录和存储在相应的权限列表中，然后根据所得到的目标应用的应用标识在权限列表中进行相应的查询和汇总，便可以得到目标应用相关联的权限集合。

示例性地，系统权限是系统所自带的权限，自定义权限需要预先进行定义和设置，这样才能在系统中存在该权限，然后在进行权限的申请时，可以按照相应的权限授权方式进行权限的授权判定。

步骤102，确定权限请求指令所对应的目标权限，并根据权限集合和目标权限的来源信息进行授权判定，其中，来源信息包括权限组别信息和开发者信息。

在一实施例中，在进行权限的授权判定时，首先根据权限请求指令确定当前所申请的目标权限，然后根据所获取到的权限集合对目标权限进行权限的判定处理，具体地，通过将目标权限的来源信息与权限集合中各权限的来源信息进行对比处理，以完成对目标权限的授权判定，其中，用于进行授权判定的来源信息，至少包括有权限组别信息和开发者信息。

示例性地，不同的应用所对应的开发者不同，且不同的应用所属的权限组别信息也可以不同。实际上，对于需要进行弹窗来进行人为授权的权限，都可以属于同一个权限组别，也可以根据不同的安全级别将其分在不同的权限组别。通常情况下，对于属于同一个权限组别的权限，在完成其中一个权限的授权之后，可以对该权限组别中其他的权限进行使用，但是该方式在实际使用时存在一定的安全隐患，因此，在进行授权判定时，利用包含有权限组别信息和开发者信息的来源信息进行判定，考虑开发者信息的不同，提高授权判定的安全性。

具体地，在对目标权限进行授权判定时，包括：对权限请求指令进行信息识别，得到权限请求指令对应的目标权限；获取权限集合中每一个权限与目标权限分别对应的来源信息，得到来源信息集合和目标来源信息，并根据来源信息集合和目标来源信息对目标权限进行授权判定。

由于在进行判定时是利用来源信息进行判断的，因此，在进行处理时，首先对权限请求指令信息进行信息识别，确定所对应的目标权限，然后对目标权限的目标来源信息进行识别，以及对权限集合中每一个权限的来源信息进行识别和获取，进而将目标来源信息与权限集合所对应的来源信息集合进行对比，来完成授权判定。通常情况下，在对目标权限进行授权时，需要保证来源信息集合中存在与目标来源信息相同的一个信息，即具有相同的权限组别和相同的开发者。

因此，在进行授权判定时，可以参照图3，图3是本申请实施例提供的进行授权判定的步骤的一种流程示意图，其中，该步骤包括步骤301至步骤303。

步骤301，识别目标权限所对应的目标应用信息，并对目标应用信息进行信息获取，得到目标权限对应的目标来源信息；

步骤302，对权限集合中每一个权限的来源信息进行识别，得到来源信息集合；

步骤303，将目标来源信息在来源信息集合中进行对比，并根据对比结果对目标权限进行授权判定。

具体地，目标应用在进行权限的申请时，可以是对系统权限的申请，也可以时对其他应用的权限的申请，在此，以对其他应用的权限进行申请为例，在进行处理时，首先识别目标权限所对应的目标应用信息，然后对目标应用信息进行信息获取，得到目标权限所对应的目标来源信息，而对于权限集合中的每一个权限，都可以通过对其所对应的应用信息的获取，得到每一个权限的来源信息，最后在进行对比处理时，确定来源信息集合中是否包含有目标权限对应的目标来源信息，进而根据对比结果完成授权判定。

需要说明的是，在进行权限的申请时，无论是对系统权限的申请，还是对自定义权限的申请，都需要进行相应的授权判定处理，对于系统权限而言，在进行权限的申请时，通常需要通过弹窗处理来实现权限的授予，也就是此时通过弹窗信息的提示，然后在接收到授权指令时，确定授权成功，反之则授权失败。

示例性地，在默认权限组别为一个时，在进行权限的申请和授权判定时，授权判定的方式分为两种，一种为弹窗的主动授权，另一种为基于来源信息(仅包含有开发者信息)的自动授权。在基于来源信息进行自动授权处理时，通过将进行授权判定的权限的开发者信息与已经授权的权限的开发者信息进行比较，确定是否相同，且在相同时确定授权成功，反之则授权失败。

另外，在权限组别为多个时，同样采用两种方式进行判定，一种为弹窗的主动授权，另一种为基于来源信息(包括权限组别信息和开发者信息)的自动授权。同样地，在进行判定处理时，在权重组别信息和开发者信息都相同时，才确定授权成功，反之则失败。

进一步地，在权限组别的数量为多个时，在进行授权判定时，对于来源信息集合的获取，需要针对不同的权限组别信息进行划分，因此，此时在得到来源信息集合时，可以参照图4，图4是本申请实施例提供的得到来源信息集合的步骤的一种流程示意图，其中，该步骤包括步骤401至步骤402。

步骤401，根据权限集合中每一个权限的权限组别信息进行组别划分，得到若子权限集合，其中，每一个子权限集合对应一个权限组别信息；

步骤402，对每一个子权限集合中的每一个权限的来源信息进行获取，得到每一个子权限集合所对应的子来源信息集合，以得到权限集合对应的来源信息集合。

在一实施例中，在确定权限组别的数量为多个的情况下，首先可以对权限集合按照权限组别信息进行组别的划分，得到若干子权限集合，且每一个字权限集合对应一个权限组别信息，然后再对每一个子权限集合中的每一个权限的来源信息进行获取，得到相应的子来源信息集合，进而汇总得到相应的来源信息集合。

由前述描述可知，在进行授权判定时，首先需要使得目标权限对应的目标权限组别中有已经被授权的权限，进而再根据具体的开发者信息进行进一步的判定。在权限集合所对应的权限组别信息中没有目标权限相对应的一个权限组别信息，则可以直接确定无法进行自动的授权处理，需要进行弹窗和主动授权。

需要说明的是，对于系统权限和自定义权限而言，可以根据需要直接分我默认权限和dangerous权限，其中，默认权限为无需进行授权判定的权限，dangerous权限为需要进行授权判定的权限，也就是上述描述的权限组别为一，还可以将dangerous权限进行进一步的等级划分，比如，分为：权限组别相同即可授权、权限组别和开发者信息均相同才可以授权。对于不同权限组别的权限，可以根据不同的设定按照相应的授权规则进行授权判定处理。

进一步地，在根据来源信息进行授权判定时，可以参照图5，图5是本申请实施例提供的根据对比结果进行授权判定的步骤的一种流程示意图，其中，该步骤包括步骤501至步骤504。

步骤501，确定来源信息集合中是否包含有目标权限组别信息，其中，目标来源信息包括目标权限组别信息和目标开发者信息；

步骤502，在确定包含有目标权限组别信息的情况下，确定目标权限组别信息对应的目标子权限集合中是否包含有目标开发者信息；

步骤503，在确定包含有目标开发者信息的情况下，确定目标应用对目标权限申请成功；

步骤504，在确定不包含有目标开发者信息的情况下，确定目标应用对目标权限申请失败。

其中，确定来源信息集合中是否包含有目标权限组别信息之后，还包括：在确定不包含有目标权限组别信息的情况下，确定目标应用对目标权限申请失败。

具体地，目标来源信息包括目标权限组别信息和目标开发者信息，然后在进行授权判定时，确定来源信息集合中是否包含有目标权限组别信息，而在确定来源信息集合中包含有目标权限组别信息时，再确定目标全下组别信息对应的目标子权限集合中是否包含有目标开发者信息，进而在确定包含有目标开发者信息的情况下确定申请成功，反之则确定申请失败，同时，在确定来源信息集合中不包含有目标权限组别信息的情况下，确定申请失败。

示例性地，在进行授权判定时，通过两次对比处理来实现，而在确定目标应用对目标权限申请成功时，需要确保来源信息集合中包含有目标来源信息的组合，即同时包含有目标权限组别信息和目标开发者信息的组合。

比如，来源信息集合如下表1所示。

表1

在目标来源信息的组合为权限组别1和开发者1的情况下，由上表1可知，来源信息集合中存在有权限1已经授权成功，且权限1所对应的来源信息为：权限组别1和开发者1，那么此时对于目标权限而言，可以直接授权成功，即不需要进行弹窗处理。另外，在目标来源信息的组合为权限组别1和开发者3的情况下，由于在上表1中在权限组别1中不存在开发者3所开发的应用的权限，因此，此时需要进行弹窗处理。

步骤103，在判定确定对目标权限进行授权的情况下，确定目标应用对目标权限申请成功。

在一实施例中，在通过授权判定确定对目标权限进行授权的情况下，将需要进行弹窗处理，而是直接确定目标应用对目标权限申请成功，此时用户可以直接进行权限信息的无感访问。

进一步地，在进行授权机制的优化处理时，整个的处理过程可以如下：

第一，自定义权限的定义。

应用A定义一个自定义权限(记为permissionA)，定义其名称为permissionA、保护等级为dangerous、归属权限组为某一系统权限组(记为sysGroup)，sysGroup中存在dangerous级别的系统权限(记为sysPermission)。

应用B定义一个自定义权限(记为permissionB)，定义其名称为permissionB、保护等级为dangerous、归属权限组为sysGroup。

应用C定义一个自定义权限(记为permissionC)，定义其名称为permissionC、保护等级为dangerous、归属权限组为sysGroup。

其中，应用C和应用A使用相同的开发者证书签发，且与应用B的不同

第二，权限管理模块区分不同来源的权限。

对于每个权限组中的每个权限，系统中的权限管理模块(为软件模块，记为PMS)各个权限来源方数据，在系统中查询各个权限的定义方身份(例如应用包名为身份标识，结合开发者证书的信息进行分析)。

对于每个权限组，PMS识别判断权限的来源方，区分同一权限组中的系统权限、以及来源于不同开发者团队的自定义权限。

例如，Android权限由Android系统模块、或谷歌开发的预置应用而定义；如存在使用同一张开发者证书签名的多个三方应用，这些应用定义的自定义权限判断来源于同一开发者团队。

需要说明的是，同一开发团队签发的多个应用可能采取不同的开发者证书进行签名，因此，在PMS判断和区分三方应用定义者归属团队时，可以结合人工分析，进而制定PMS自动化判断策略。

同时，在使用过程中，还可以根据系统中权限定义方的变化情况，例如自定义权限定义方应用卸载、新增等，PMS定期维护和刷新权限来源方数据。

第三，权限申请。

应用A在申请系统权限时，用A运行时进行弹窗，请求用户将sysPermission对应用A授权，然后用户点击确认，以使得应用A成功获得sysPermission。

接着，应用A在自定义权限时，若申请permissionA，系统中的PMS将查询其记录的权限的来源方数据，通过判断应用A已获取的sysPermission与申请的permissionA不属于同一来源(开发者证书)，表明此时不可以直接进行授权，而是需要进行系统弹窗，请求用户将permissionA对应用A授权，进而在用户点击确认时，应用A成功获得permissionA。

应用A在申请permissionB，同样地，利用系统中的PMS查询其记录的权限的来源方数据，通过判断应用A已获取的sysPermission和permissionA与所申请的permissionB不属于同一来源(开发者证书)，表明此时不可以直接进行授权，同样需要进行系统弹窗来授权。

在应用A获取了sysPermission、permissionA和permissionB之后，在申请permissionC时，通过查询权限的来源方数据，且判断应用A已获取的权限中permissionA与所申请的permissionC属于同一来源(开发者证书)，因此，此时将不需要进行系统弹窗，而是直接permissionC。

基于上述处理方式，对不同来源的自定义权限单独弹窗获取用户授权，提升了对自定义权限的安全保护强度，减小了自定义权限非法授权的攻击面，提升了方案安全性。同时，对于同一来源的自定义权限，采用无弹窗授权的方式，在不降低安全性的同时，简化了自定义权限授权的处理流程。

综上，本申请公开了一种自定义权限的授权机制优化方法，在进行权限的申请和授权判定时，接收目标应用所发出的权限请求指令，并且获取与目标应用相关联的已经获取的权限的权限集合，同时根据权限请求指令确定当前进行申请的目标权限，接着根据权限集合中每一个权限的来源信息和目标权限的来源信息进行授权判定处理，而所得到的来源信息包括权限组别信息和开发者信息，进而在通过判定确定对目标权限进行授权的情况下，确定目标应用对目标权限申请成功。实现了在权限申请和授权判定时，根据来源信息对所申请的目标权限进行授权判定，只有在来源信息都相同的情况下，才可以进行授权处理，在提高自定义权限的授权高效性的同时，提高对自定义权限授权的安全性。

根据上述实施例所描述的方法，本实施例将从自定义权限的授权机制优化装置的角度进一步进行描述，该自定义权限的授权机制优化装置具体可以作为独立的实体来实现，也可以集成在电子设备，比如终端中来实现，该终端可以包括手机、平板电脑等。

请参见图6，图6是本申请实施例提供的自定义权限的授权机制优化装置的一种结构示意图，如图6所示，本申请实施例提供的自定义权限的授权机制优化装置600，包括：

请求接收模块601，用于在接收到目标应用发送的权限请求指令的情况下，获取目标应用对应的已获取的权限集合；

权限判定模块602，用于确定权限请求指令所对应的目标权限，并根据权限集合和目标权限的来源信息进行授权判定，其中，来源信息包括权限组别信息和开发者信息；

判定处理模块603，用于在判定确定对目标权限进行授权的情况下，确定目标应用对目标权限申请成功。

在一实施例中，请求接收模块601还用于：

在接收到目标应用发送的权限请求指令的情况下，识别目标应用的应用标识；

根据应用标识在权限列表中进行查询，得到目标应用对应的已获取的权限集合。

在一实施例中，权限判定模块602还用于：

对权限请求指令进行信息识别，得到权限请求指令对应的目标权限；

获取权限集合中每一个权限与目标权限分别对应的来源信息，得到来源信息集合和目标来源信息，并根据来源信息集合和目标来源信息对目标权限进行授权判定。

在一实施例中，权限判定模块602还用于：

识别目标权限所对应的目标应用信息，并对目标应用信息进行信息获取，得到目标权限对应的目标来源信息；

对权限集合中每一个权限的来源信息进行识别，得到来源信息集合；

将目标来源信息在来源信息集合中进行对比，并根据对比结果对目标权限进行授权判定。

在一实施例中，权限判定模块602还用于：

根据权限集合中每一个权限的权限组别信息进行组别划分，得到若子权限集合，其中，每一个子权限集合对应一个权限组别信息；

对每一个子权限集合中的每一个权限的来源信息进行获取，得到每一个子权限集合所对应的子来源信息集合，以得到权限集合对应的来源信息集合。

在一实施例中，权限判定模块602还用于：

确定来源信息集合中是否包含有目标权限组别信息，其中，目标来源信息包括目标权限组别信息和目标开发者信息；

在确定包含有目标权限组别信息的情况下，确定目标权限组别信息对应的目标子权限集合中是否包含有目标开发者信息；

在确定包含有目标开发者信息的情况下，确定目标应用对目标权限申请成功；

在确定不包含有目标开发者信息的情况下，确定目标应用对目标权限申请失败；

其中，确定来源信息集合中是否包含有目标权限组别信息之后，还包括：

在确定不包含有目标权限组别信息的情况下，确定目标应用对目标权限申请失败。

在一实施例中，权限判定模块602还用于：

在确定目标应用不存在权限集合的情况下，根据权限请求指令生成相应的反馈信息，并根据反馈信息进行弹窗提示；

在接收到基于弹窗提示输入的接受指令的情况下，确定目标应用对目标权限申请成功；

在接收到基于弹窗提示输入的拒绝指令的情况下，确定目标应用对目标权限申请失败。

另外，请参见图7，图7是本申请实施例提供的电子设备的一种结构示意图，该电子设备可以是移动终端如智能手机、平板电脑等设备。如图7所示，电子设备700包括处理器701、存储器702。其中，处理器701与存储器702电性连接。

处理器701是电子设备700的控制中心，利用各种接口和线路连接整个电子设备的各个部分，通过运行或加载存储在存储器702内的应用程序，以及调用存储在存储器702内的数据，执行电子设备700的各种功能和处理数据，从而对电子设备700进行整体监测。

在本实施例中，电子设备700中的处理器701会按照如下的步骤，将一个或一个以上的应用程序的进程对应的指令加载到存储器702中，并由处理器701来运行存储在存储器702中的应用程序，从而实现上述实施例提供的自定义权限的授权机制优化方法中的任一步骤。

该电子设备700可以实现本申请实施例所提供的自定义权限的授权机制优化方法任一实施例中的步骤，因此，可以实现本申请实施例所提供的任一自定义权限的授权机制优化方法所能实现的有益效果，详见前面的实施例，在此不再赘述。

请参见图8，图8是本申请实施例提供的电子设备的另一种结构示意图，如图8所示，图8示出了本申请实施例提供的电子设备的具体结构框图，该电子设备可以用于实施上述实施例中提供的自定义权限的授权机制优化方法。该电子设备800可以为移动终端如智能手机或笔记本电脑等设备。

RF电路810用于接收以及发送电磁波，实现电磁波与电信号的相互转换，从而与通讯网络或者其他设备进行通讯。RF电路810可包括各种现有的用于执行这些功能的电路元件，例如，天线、射频收发器、数字信号处理器、加密/解密芯片、用户身份模块(SIM)卡、存储器等等。RF电路810可与各种网络如互联网、企业内部网、无线网络进行通讯或者通过无线网络与其他设备进行通讯。上述的无线网络可包括蜂窝式电话网、无线局域网或者城域网。上述的无线网络可以使用各种通信标准、协议及技术，包括但并不限于全球移动通信系统(Global System for Mobile Communication,GSM)、增强型移动通信技术(Enhanced DataGSM Environment,EDGE)，宽带码分多址技术(Wideband Code Division MultipleAccess,WCDMA)，码分多址技术(Code Division Access,CDMA)、时分多址技术(TimeDivision Multiple Access,TDMA)，无线保真技术(Wireless Fidelity，Wi-Fi)(如美国电气和电子工程师协会标准IEEE 802.11a，IEEE 802.11b,IEEE802.11g和/或IEEE802.11n)、网络电话(Voice over Internet Protocol,VoIP)、全球微波互联接入(Worldwide Interoperability for Microwave Access，Wi-Max)、其他用于邮件、即时通讯及短消息的协议，以及任何其他合适的通讯协议，甚至可包括那些当前仍未被开发出来的协议。

存储器820可用于存储软件程序以及模块，如上述实施例中自定义权限的授权机制优化方法对应的程序指令/模块，处理器880通过运行存储在存储器820内的软件程序以及模块，从而执行各种功能应用以及对自定义权限的授权机制优化方法。

存储器820可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器820可进一步包括相对于处理器880远程设置的存储器，这些远程存储器可以通过网络连接至电子设备800。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

输入单元830可用于接收输入的数字或字符信息，以及产生与用户设置以及功能控制有关的键盘、鼠标、操作杆、光学或者轨迹球信号输入。具体地，输入单元830可包括触敏表面831以及其他输入设备832。触敏表面831，也称为触摸显示屏或者触控板，可收集用户在其上或附近的触摸操作(比如用户使用手指、触笔等任何适合的物体或附件在触敏表面831上或在触敏表面831附近的操作)，并根据预先设定的程式驱动相应的连接装置。可选的，触敏表面831可包括触摸检测装置和触摸控制器两个部分。其中，触摸检测装置检测用户的触摸方位，并检测触摸操作带来的信号，将信号传送给触摸控制器；触摸控制器从触摸检测装置上接收触摸信息，并将它转换成触点坐标，再送给处理器880，并能接收处理器880发来的命令并加以执行。此外，可以采用电阻式、电容式、红外线以及表面声波等多种类型实现触敏表面831。除了触敏表面831，输入单元830还可以包括其他输入设备832。具体地，其他输入设备832可以包括但不限于物理键盘、功能键(比如音量控制按键、开关按键等)、轨迹球、鼠标、操作杆等中的一种或多种。

显示单元840可用于显示由用户输入的信息或提供给用户的信息以及电子设备800的各种图形用户接口，这些图形用户接口可以由图形、文本、图标、视频和其任意组合来构成。显示单元840可包括显示面板841，可选的，可以采用LCD(Liquid Crystal Display，液晶显示器)、OLED(Organic Light-Emitting Diode,有机发光二极管)等形式来配置显示面板841。进一步的，触敏表面831可覆盖显示面板841，当触敏表面831检测到在其上或附近的触摸操作后，传送给处理器880以确定触摸事件的类型，随后处理器880根据触摸事件的类型在显示面板841上提供相应的视觉输出。虽然在图中，触敏表面831与显示面板841是作为两个独立的部件来实现输入和输出功能，但是在某些实施例中，可以将触敏表面831与显示面板841集成而实现输入和输出功能。

电子设备800还可包括至少一种传感器850，比如光传感器、运动传感器以及其他传感器。具体地，光传感器可包括环境光传感器及接近传感器，其中，环境光传感器可根据环境光线的明暗来调节显示面板841的亮度，接近传感器可在翻盖合上或者关闭时产生中断。作为运动传感器的一种，重力加速度传感器可检测各个方向上(一般为三轴)加速度的大小，静止时可检测出重力的大小及方向，可用于识别手机姿态的应用(比如横竖屏切换、相关游戏、磁力计姿态校准)、振动识别相关功能(比如计步器、敲击)等；至于电子设备800还可配置的陀螺仪、气压计、湿度计、温度计、红外线传感器等其他传感器，在此不再赘述。

音频电路860、扬声器861，传声器862可提供用户与电子设备800之间的音频接口。音频电路860可将接收到的音频数据转换后的电信号，传输到扬声器861，由扬声器861转换为声音信号输出；另一方面，传声器862将收集的声音信号转换为电信号，由音频电路860接收后转换为音频数据，再将音频数据输出处理器880处理后，经RF电路810以发送给比如另一终端，或者将音频数据输出至存储器820以便进一步处理。音频电路860还可能包括耳塞插孔，以提供外设耳机与电子设备800的通信。

电子设备800通过传输模块870(例如Wi-Fi模块)可以帮助用户接收请求、发送信息等，它为用户提供了无线的宽带互联网访问。虽然图中示出了传输模块870，但是可以理解的是，其并不属于电子设备800的必须构成，完全可以根据需要在不改变发明的本质的范围内而省略。

处理器880是电子设备800的控制中心，利用各种接口和线路连接整个手机的各个部分，通过运行或执行存储在存储器820内的软件程序和/或模块，以及调用存储在存储器820内的数据，执行电子设备800的各种功能和处理数据，从而对电子设备进行整体监测。可选的，处理器880可包括一个或多个处理核心；在一些实施例中，处理器880可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解地，上述调制解调处理器也可以不集成到处理器880中。

电子设备800还包括给各个部件供电的电源890(比如电池)，在一些实施例中，电源可以通过电源管理系统与处理器880逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。电源890还可以包括一个或一个以上的直流或交流电源、再充电系统、电源故障检测电路、电源转换器或者逆变器、电源状态指示器等任意组件。

尽管未示出，电子设备800还包括摄像头(如前置摄像头、后置摄像头)、蓝牙模块等，在此不再赘述。具体在本实施例中，电子设备的显示单元是触摸屏显示器，移动终端还包括有存储器，以及一个或者一个以上的程序，其中一个或者一个以上程序存储于存储器中，且经配置以由一个或者一个以上处理器执行一个或者一个以上程序实现上述实施例提供的自定义权限的授权机制优化方法中的任一步骤。

具体实施时，以上各个模块可以作为独立的实体来实现，也可以进行任意组合，作为同一或若干个实体来实现，以上各个模块的具体实施可参见前面的方法实施例，在此不再赘述。

本领域普通技术人员可以理解，上述实施例的各种方法中的全部或部分步骤可以通过指令来完成，或通过指令控制相关的硬件来完成，该指令可以存储于一计算机可读存储介质中，并由处理器进行加载和执行。为此，本申请实施例提供一种存储介质，其中存储有多条指令，该指令能够被处理器执行时实现上述实施例所提供的自定义权限的授权机制优化方法中的任一步骤。

其中，该存储介质可以包括：只读存储器(ROM，Read Only Memory)、随机存取记忆体(RAM，Random Access Memory)、磁盘或光盘等。

由于该存储介质中所存储的指令，可以执行本申请实施例所提供的自定义权限的授权机制优化方法任一实施例中的步骤，因此，可以实现本申请实施例所提供的任一自定义权限的授权机制优化方法所能实现的有益效果，详见前面的实施例，在此不再赘述。

以上对本申请实施例所提供的一种自定义权限的授权机制优化方法、装置、电子设备及存储介质进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上，本说明书内容不应理解为对本申请的限制。并且，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也视为本申请的保护范围。

Claims (10)

1.一种自定义权限的授权机制优化方法，其特征在于，包括：

在接收到目标应用发送的权限请求指令的情况下，获取所述目标应用对应的已获取的权限集合；

确定所述权限请求指令所对应的目标权限，并根据所述权限集合和所述目标权限的来源信息进行授权判定，其中，来源信息包括权限组别信息和开发者信息；

在判定确定对所述目标权限进行授权的情况下，确定所述目标应用对所述目标权限申请成功。

2.如权利要求1所述的方法，其特征在于，所述在接收到目标应用发送的权限请求指令的情况下，获取所述目标应用对应的已获取的权限集合，包括：

在接收到目标应用发送的权限请求指令的情况下，识别目标应用的应用标识；

根据所述应用标识在权限列表中进行查询，得到所述目标应用对应的已获取的权限集合。

3.如权利要求1所述的方法，其特征在于，所述确定所述权限请求指令所对应的目标权限，并根据所述权限集合和所述目标权限的来源信息对所述目标权限进行授权判定，包括：

对所述权限请求指令进行信息识别，得到所述权限请求指令对应的目标权限；

获取所述权限集合中每一个权限与所述目标权限分别对应的来源信息，得到来源信息集合和目标来源信息，并根据所述来源信息集合和所述目标来源信息对所述目标权限进行授权判定。

4.如权利要求1所述的方法，其特征在于，所述获取所述权限集合中每一个权限与所述目标权限分别对应的来源信息，得到来源信息集合和目标来源信息，并根据所述来源信息集合和所述目标来源信息对所述目标权限进行授权判定，包括：

识别所述目标权限所对应的目标应用信息，并对所述目标应用信息进行信息获取，得到所述目标权限对应的目标来源信息；

对所述权限集合中每一个权限的来源信息进行识别，得到来源信息集合；

将所述目标来源信息在所述来源信息集合中进行对比，并根据对比结果对所述目标权限进行授权判定。

5.如权利要求4所述的方法，其特征在于，所述对所述权限集合中每一个权限的来源信息进行识别，得到来源信息集合，包括：

根据所述权限集合中每一个权限的权限组别信息进行组别划分，得到若子权限集合，其中，每一个子权限集合对应一个权限组别信息；

对每一个子权限集合中的每一个权限的来源信息进行获取，得到每一个子权限集合所对应的子来源信息集合，以得到所述权限集合对应的来源信息集合。

6.如权利要求5所述的方法，其特征在于，所述将所述目标来源信息在所述来源信息集合中进行对比，并根据对比结果对所述目标权限进行授权判定，包括：

确定所述来源信息集合中是否包含有目标权限组别信息，其中，所述目标来源信息包括目标权限组别信息和目标开发者信息；

在确定包含有所述目标权限组别信息的情况下，确定所述目标权限组别信息对应的目标子权限集合中是否包含有目标开发者信息；

在确定包含有目标开发者信息的情况下，确定所述目标应用对所述目标权限申请成功；

在确定不包含有目标开发者信息的情况下，确定所述目标应用对所述目标权限申请失败；

其中，所述确定所述来源信息集合中是否包含有目标权限组别信息之后，还包括：

在确定不包含有目标权限组别信息的情况下，确定所述目标应用对所述目标权限申请失败。

7.如权利要求1所述的方法，其特征在于，所述方法还包括：

在确定所述目标应用不存在所述权限集合的情况下，根据所述权限请求指令生成相应的反馈信息，并根据所述反馈信息进行弹窗提示；

在接收到基于所述弹窗提示输入的接受指令的情况下，确定所述目标应用对所述目标权限申请成功；

在接收到基于所述弹窗提示输入的拒绝指令的情况下，确定所述目标应用对所述目标权限申请失败。

8.一种自定义权限的授权机制优化装置，其特征在于，包括：

请求接收模块，用于在接收到目标应用发送的权限请求指令的情况下，获取所述目标应用对应的已获取的权限集合；

权限判定模块，用于确定所述权限请求指令所对应的目标权限，并根据所述权限集合和所述目标权限的来源信息进行授权判定，其中，来源信息包括权限组别信息和开发者信息；

判定处理模块，用于在判定确定对所述目标权限进行授权的情况下，确定所述目标应用对所述目标权限申请成功。

9.一种电子设备，其特征在于，所述电子设备包括处理器、存储器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如权利要求1至7任一项所述的方法中的步骤。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现如权利要求1至7任一项所述的方法中的步骤。