CN117235771B - 一种应用程序的权限管控方法和电子设备 - Google Patents

Abstract

本申请提供了一种应用程序的权限管控方法和电子设备。该方法可以确定调用请求是由SDK生成的，以及确定的鉴权结果用于指示API允许或禁止被SDK调用，也就是说，相对于相关方案中是以APP为管控粒度鉴定APP是否可以调用API，本申请可以以SDK为管控粒度鉴定APP中的SDK是否可以调用API，提升了用户体验。并且，在鉴权结果指示API允许被SDK调用的情况下，SDK调用API，在鉴权结果指示API禁止被SDK调用的情况下，禁止SDK调用API，可以根据鉴定结果管控APP中的SDK，其中，在鉴权结果指示API禁止被SDK调用的情况下，禁止SDK调用API，避免了SDK借助APP的权限调用API，降低了APP潜在的安全风险，提升了APP的安全性。

Description

一种应用程序的权限管控方法和电子设备

技术领域

本申请涉及终端领域，尤其涉及一种应用程序的权限管控方法和电子设备。

背景技术

目前的电子设备中可以安装各种应用程序（Application，APP）以满足用户需求，APP中可以内嵌多种第三方软件开发工具包（Software Development Kit，SDK）以降低APP的开发成本和运营成本。APP在安装或运行的过程中，可以向电子设备申请权限并通过鉴权后，APP通过调用应用程序编程接口（Application Programming Interface，API）实现APP的相关功能。例如APP向电子设备申请联网权限，在电子设备向APP授予联网权限并鉴定APP具有联网权限后，APP通过联网权限调用API以实现联网功能。

相关方案中的权限管控机制是以APP为管控粒度，即电子设备向APP授予权限并鉴定APP具有权限后，第三方SDK也会具有与APP相同的权限，第三方SDK会借助APP的权限调用API，可能会降低APP的安全性，影响用户体验。

发明内容

本申请提供一种应用程序的权限管控方法和电子设备，可以避免SDK借助APP的权限调用API，从而降低了APP潜在的安全风险，提升了APP的安全性，提升了用户体验。

第一方面，提供了一种应用程序的权限管控方法，该方法可以响应于对APP（第一APP）的触发事件，首先确定调用请求是由SDK生成，然后获取APP的上下文参数、待鉴定的权限参数（第一权限参数）和SDK（第一SDK）的包名，最后根据上述获取的数据，确定鉴权结果，鉴权结果用于指示API（第一API）允许或禁止被SDK调用，在鉴权结果指示API允许被SDK调用的情况下，SDK调用API，在鉴权结果指示API禁止被SDK调用的情况下，禁止SDK调用API。

本申请实施例，相对于以APP为管控粒度的权限管控方案，只能鉴定API允许或禁止被APP调用，可以确定调用请求是由SDK生成的，以及确定的鉴权结果用于指示API允许或禁止被SDK调用，也就是说，本申请实施例可以鉴定APP中的SDK是否可以调用API，提升了用户体验。

并且，在鉴权结果指示API允许被SDK调用的情况下，SDK调用API，在鉴权结果指示API禁止被SDK调用的情况下，禁止SDK调用API，可以根据鉴定结果管控APP中的SDK，其中，在鉴权结果指示API禁止被SDK调用的情况下，禁止SDK调用API，避免了SDK借助APP的权限调用API，降低了APP潜在的安全风险，提升了APP的安全性，提升了用户体验。

结合第一方面，在第一方面的某些实现方式中，根据第一APP的上下文参数、第一权限参数和第一SDK的包名，确定鉴权结果，包括：

根据第一APP的上下文参数和第一权限参数，确定第一授权结果，第一授权结果用于指示第一APP被授予第一权限；根据第一授权结果和第一SDK的包名，确定第二授权结果，以根据第二授权结果确定鉴权结果，第二授权结果用于指示第一SDK是否被授予第一权限。

本申请实施例，可以根据第一APP的上下文参数和第一权限参数，确定用于指示第一APP被授予第一权限的第一授权结果，那么，根据第一授权结果，在第一APP发起调用请求的情况下，第一APP可以基于第一权限调用第一API；随后，根据第一授权结果和第一SDK的包名，确定用于指示第一SDK是否被授予第一权限的第二授权结果，以根据第二授权结果确定用于指示第一API允许或禁止被第一SDK调用的鉴权结果，即在第一APP被授予第一权限的情况下，可以确定第一SDK是否被授予第一权限，在确定第一SDK未被授予第一权限的情况下，确定的鉴权结果用于指示第一API禁止被第一SDK调用，也就是说，本申请可以在第一APP基于第一权限调用第一API时，禁止第一APP中的第一SDK调用第一API，相对于相关方案中APP基于权限调用API时，APP中的SDK也会基于相同权限调用API，可以提升用户体验。

结合第一方面，在第一方面的某些实现方式中，电子设备包括框架层，框架层包括权限管理模块，权限管理模块配置用于记载授权结果的树结构，树结构用于指示用户状态、用户身份证明状态、权限状态和SDK状态的层级关系，用户状态为第一层级，第一层级用于指示树结构，用户身份证明状态为第二层级，第二层级用于指示至少一个APP的用户身份证明，至少一个APP包括第一APP，权限状态为第三层级，第三层级包括第一候选授权结果，第一候选授权结果用于指示至少一个权限参数是否被授权的授权结果，至少一个权限参数包括至少一个APP中每个APP对应的权限参数，至少一个权限参数包括第一权限参数，SDK状态为第四层级，第四层级包括第二候选授权结果，第二候选授权结果用于指示至少一个SDK是否被授权的授权结果，至少一个SDK包括至少一个权限参数中每个权限参数对应的SDK，至少一个SDK包括第一SDK。

本申请实施例，权限管理模块中配置的树结构具有四层层级关系，第四层级中包括用于指示至少一个SDK是否被授权的第二候选授权结果，相对于相关方案中具有三层层级关系的树结构，本申请可以在第四层级中确定SDK是否被授权，并且，通过本申请提供的树结构，可以使电子设备快速、便捷的确定SDK是否被授权，以尽快禁止或允许SDK调用API，降低用户的感知程度，提升用户体验。

结合第一方面，在第一方面的某些实现方式中，根据第一APP的上下文参数和第一权限参数，确定第一授权结果，包括：

根据第一APP的用户标识，确定用户状态，用户状态用于定位树结构的第一层级，第一APP的上下文参数用于指示第一APP的用户标识；根据第一APP的用户标识和第一APP的包名，确定第一APP的用户身份证明，第一APP的上下文参数还用于指示第一APP的包名；在第二层级的至少一个APP的用户身份证明中确定第一APP的用户身份证明；根据第一权限参数和第一APP的用户身份证明，在第三层级的第一候选授权结果中确定第一授权结果；

根据第一授权结果和第一SDK的包名，确定第二授权结果，以根据第二授权结果确定鉴权结果，包括：根据第一授权结果和第一SDK的包名，在第四层级的第二候选授权结果中确定第二授权结果，以根据第二授权结果确定鉴权结果。

本申请实施例，可以依据用户标识、第一APP的包名、第一权限参数和第一SDK的包名等数据在第一层级、第二层级、第三层级和第四层级中通过逐层确定的方式确定第二授权结果，可以提高确定第二授权结果的速度，进而提高了根据第二授权结果确定的鉴权结果的速度，提升了电子设备的运行速度。

结合第一方面，在第一方面的某些实现方式中，该方法还包括：

根据第一授权结果和第一SDK的包名，在第四层级的第二候选授权结果中未查询到第二授权结果的情况下，或者根据第一授权结果和第一SDK的包名，在第四层级的第二候选授权结果中查询到第二授权结果为每次询问的情况下，弹窗询问用户是否对第一SDK授予第一权限；根据用户选择将用户的第二授权结果记载在第四层级，用户选择包括允许、不允许和每次询问中的一种。

本申请实施例，可以在第四层级中未查询到第二授权结果的情况下，或者在第四层级中查询到第二授权结果，但是第二授权结果为每次询问的情况下，通过弹窗询问的方式，询问用户是否对第一SDK授予第一权限，并根据用户选择将第二授权结果记载在第四层级，可以使用户主动管控SDK的权限，由用户决定是否授予SDK权限，这样，避免了第三方SDK在用户无感知的情况下，借助APP权限调用API，提升了用户体验。

结合第一方面，在第一方面的某些实现方式中，确定基于第一软件开发工具包SDK生成的调用请求，包括：

获取SDK列表和第一API的调用栈，SDK列表中包括至少一个SDK的包名，至少一个SDK的包名中包括第一SDK的包名，至少一个SDK为具有发起敏感行为的能力的SDK和/或存在安全漏洞的SDK；在第一API的调用栈中查询到存在SDK列表中的第一SDK的包名的情况下，确定基于第一SDK生成的调用请求。

本申请实施例，由于可以在第一API的调用栈中查询是否存在SDK列表（SDK列表包括具有发起敏感行为的能力的SDK的包名和/或存在安全漏洞的SDK的包名）中的第一SDK的包名，以在查询到存在SDK列表中的第一SDK的包名的情况下，确定基于第一SDK生成的调用请求，从而确定生成调用请求的第一SDK具有发起敏感行为的能力和/或存在安全漏洞，在一种场景中，通过本申请实施例可以禁止具有发起敏感行为能力和/或存在安全漏洞的第一SDK调用第一API，实现对发起敏感行为和/或存在安全漏洞的第一SDK进行权限管控，提升了APP的安全性，提升了用户体验。

结合第一方面，在第一方面的某些实现方式中，在根据调用请求，获取第一APP的上下文参数、第一权限参数和第一SDK的包名之前，方法还包括：

获取第一APP的包名和对应关系，对应关系用于指示N个APP的包名和N个管控结果的对应关系，一个APP的包名对应一个管控结果，一个管控结果用于指示一个APP是否被允许以SDK为管控粒度进行权限管控，N个APP包括第一APP，N为大于或等于1的整数；根据第一APP的包名和对应关系，确定第一管控结果，第一管控结果用于指示第一APP被允许以SDK为管控粒度进行权限管控。

结合第一方面，在第一方面的某些实现方式中，根据第一APP的包名和对应关系，确定第一管控结果，包括：

根据第一APP的包名和对应关系，在对应关系中查询第一APP的包名对应的管控结果；

在查询到第一APP的包名对应的管控结果为第一APP被允许以SDK为管控粒度进行权限管控的情况下，确定第一管控结果。

结合第一方面，在第一方面的某些实现方式中，该方法还包括：

在对应关系中查询到不存在第一APP的包名对应的管控结果的情况下，或者在对应关系中查询到第一APP的包名对应的管控结果为第二管控结果的情况下，弹窗询问用户是否允许对第一APP以SDK为管控粒度进行权限管控，并将询问结果记载在对应关系，第二管控结果用于指示第一APP未被允许以SDK为管控粒度进行权限管控。

结合第一方面，在第一方面的某些实现方式中，对应关系保存在系统设置的数据库中。

结合第一方面，在第一方面的某些实现方式中，电子设备包括框架层，框架层包括鉴权模块、活动管理模块和权限管理模块，该方法还包括：

鉴权模块向活动管理模块发送第一APP的上下文参数、第一权限参数和第一SDK的包名；活动管理模块向权限管理模块发送第一APP的上下文参数、第一权限参数和第一SDK的包名；权限管理模块根据第一APP的上下文参数和第一权限参数，确定第一授权结果；权限管理模块根据第一授权结果和第一SDK的包名，确定第二授权结果；权限管理模块向活动管理模块返回第二授权结果；活动管理模块向鉴权模块返回第二授权结果；鉴权模块根据第二授权结果确定鉴权结果。

第二方面，提供一种电子设备，所述电子设备用于执行上述第一方面提供的方法。具体地，所述电子设备可以包括用于执行上述第一方面中任一种可能实现方式的处理单元。

第三方面，提供了一种电子设备，包括：一个或多个处理器；一个或多个存储器；所述一个或多个存储器存储有一个或者多个计算机程序，所述一个或者多个计算机程序包括指令，当所述指令被所述一个或多个处理器执行时，使得所述电子设备执行上述第一方面中任一项可能的实现中的方法。

第四方面，提供一种计算机可读存储介质，包括计算机指令，当计算机指令在电子设备上运行时，使得电子设备执行上述第一方面所述的方法。

第五方面，提供一种芯片，包括存储器，用于存储指令；还包括处理器，用于从存储器中调用并运行指令，使得安装有芯片的电子设备执行上述第一方面所述的方法。

附图说明

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

图2是本申请实施例的电子设备100的软件结构的示意图。

图3是本申请实施例提供的一组图形用户界面。

图4是本申请实施例提供的一组GUI。

图5是本申请实施例提供的一组GUI。

图6是本申请实施例提供的一组GUI。

图7提供了一种相关方案中的权限管控机制的示例图。

图8是本申请实施例提供的一种权限管控方法的数据流图。

图9是本申请实施例提供的一种树结构的示例图。

图10是本申请实施例提供的一种权限管控方法的时序图。

图11是本申请实施例提供的一种权限管控方法200的示意性流程图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。其中，在本申请实施例的描述中，除非另有说明，“/”表示或的意思，例如，A/B可以表示A或B；本文中的“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，在本申请实施例的描述中，“复数个”或者“多个”是指两个或多于两个。

以下，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。在本实施例的描述中，除非另有说明，“多个”的含义是两个或两个以上。

以下对本申请实施例中的部分用语进行解释说明，以便于本领域技术人员理解。

APP：APP是指通过预装、下载等方式获取并运行在电子设备上、向用户提供信息服务的应用软件。APP包括基于应用软件开放平台接口开发的、用户无需安装即可使用的小程序。

SDK：SDK是指辅助开发APP的相关文档、范例和工具的集合。APP开发者为了提高开发效率、降低成本，可以将某项功能交给第三方来开发，第三方服务提供商将服务封装为工具包（即SDK）供APP开发者使用。目前，常见的SDK 类型包括第三方登录分享类、支付类、推送类、广告类和数据统计分析类等。

API：一些预先定义的函数。操作系统除了协调应用程序的执行、内存分配、系统资源管理外，同时也是一个很大的服务中心，调用这个服务中心的各种服务（每一种服务是一个函数），可以帮助应用程序达到开启视窗、描绘图形、使用周边设备的目的。API为电脑操作系统 （Operating system）或程序库提供给应用程序调用而使用的代码”，其主要目的是让应用程序开发人员得以调用一组例程功能，而无须考虑其底层的源代码为何、或理解其内部工作机制的细节。API本身是抽象的，它仅定义了一个接口，而不涉及应用程序在实际实现过程中的具体操作。

用户身份证明（User Identification，UID）：UID用于标识一个应用程序，UID是一个整数，在应用程序安装时被分配，并且在应用程序的整个生命周期中都不会改变。一个应用程序只能有一个UID，多个应用程序可以共享一个UID。而且，UID由用户标识（UserIdentifier，UserID）和应用程序标识（Application Identification，APPID）共同决定。

示例性的，UserID×10000+APPID= UID，譬如，UserID为10，APPID为10087，那么UID=10×10000+10087=1010087。

用户标识（User Identifier，UserID）:每个Android用户都有一个唯一的UserID，用于标识该用户的所有应用程序和数据。UserID是一个整数，通常在创建用户时分配，并且在用户的整个生命周期中保持不变，UserID用于实现多用户环境下的隔离和安全性，以及控制用户对系统资源的访问权限。

应用程序标识（Application Identification，APPID）：在计算机软件开发中，APPID通常是一个独特的字符串，用于识别特定的应用程序。APPID通常在应用程序开发过程中创建，并且在应用程序的各个组件（如安装程序、注册表项、配置文件等）中使用。

本申请实施例提供的应用程序的权限管控方法，应用于电子设备。电子设备也可以称为终端（terminal）、用户设备（user equipment，UE）、移动台（mobile station，MS）、移动终端（mobile terminal，MT）等。电子设备可以是电子设备（mobile phone）、智能电视、穿戴式设备、平板电脑（Pad）、带无线收发功能的电脑、虚拟现实（virtual reality，VR）电子设备、增强现实（augmented reality，AR）电子设备、工业控制（industrial control）中的无线终端、无人驾驶（self-driving）中的无线终端、远程手术（remote medical surgery）中的无线终端、智能电网（smart grid）中的无线终端、运输安全（transportation safety）中的无线终端、智慧城市（smart city）中的无线终端、智慧家庭（smart home）中的无线终端等等。本申请的实施例对电子设备所采用的具体技术和具体设备形态不做限定。

图1是本申请实施例提供的一种电子设备100（以手机为例）的结构示意图。电子设备100可以包括处理器110，外部存储器接口120，内部存储器121，通用串行总线(universalserial bus，USB)接口130，天线1，天线2，移动通信模块140，无线通信模块150，传感器模块160，显示屏170等。其中传感器模块160可以包括压力传感器160A，触摸传感器160B等。

可以理解的是，本申请实施例示意的结构并不构成对电子设备100的具体限定。在本申请另一些实施例中，电子设备100可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。

处理器110可以包括一个或多个处理单元，例如：处理器110可以包括应用处理器(application processor，AP)，调制解调处理器，图形处理器(graphics processingunit，GPU)，图像信号处理器(image signal processor，ISP)，控制器，存储器，视频编解码器，数字信号处理器(digital signal processor，DSP)，基带处理器，和/或神经网络处理器(neural-network processing unit，NPU)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。

具体到本申请实施例，处理器110可以确定用户是否允许API以SDK为管控粒度对APP进行管控，以及确定是APP向API发送调用请求，还是APP中的SDK向API发送调用请求，在确定SDK向APP发送调用请求的情况下，确定用户是否对SDK授权特定权限，在用户未对API授予特定权限的情况下，禁止SDK调用API，在用户对API授予特定权限的情况下，允许SDK调用API。

其中，控制器可以是电子设备100的神经中枢和指挥中心。控制器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。

处理器110中还可以设置存储器，用于存储指令和数据。在一些实施例中，处理器110中的存储器为高速缓冲存储器。该存储器可以保存处理器110刚用过或循环使用的指令或数据。如果处理器110需要再次使用该指令或数据，可从所述存储器中直接调用。避免了重复存取，减少了处理器110的等待时间，因而提高了系统的效率。

具体到本申请实施例中，存储器中可以存储SDK列表，SDK列表中包括至少一个SDK的包名，以及至少一个SDK中的各个SDK对应的功能描述。处理器可以从存储器中获取SDK列表，根据SDK列表可以确定是否是SDK向API发送调用请求，具体确定是否是SDK向API发送调用请求的实现方式可以参考下文实施例，此处不在赘述。

在一些实施例中，处理器110可以包括一个或多个接口。接口可以包括集成电路(inter-integrated circuit，I2C)接口，集成电路内置音频(inter-integrated circuitsound，I2S)接口，脉冲编码调制(pulse code modulation，PCM)接口，通用异步收发传输器(universal asynchronous receiver/transmitter，UART)接口，移动产业处理器接口(mobile industry processor interface，MIPI)，通用输入输出(general-purposeinput/output，GPIO)接口，用户身份识别 (subscriber identity module，SIM)接口，和/或通用串行总线(universal serial bus，USB)接口等。

可以理解的是，本申请实施例示意的各模块间的接口连接关系，只是示意性说明，并不构成对电子设备100的结构限定。在本申请另一些实施例中，电子设备100也可以采用上述实施例中不同的接口连接方式，或多种接口连接方式的组合。

电子设备100的无线通信功能可以通过天线1，天线2，移动通信模块140，无线通信模块150，调制解调处理器以及基带处理器等实现。

天线1和天线2用于发射和接收电磁波信号。电子设备100中的每个天线可用于覆盖单个或多个通信频带。不同的天线还可以复用，以提高天线的利用率。例如：可以将天线1复用为无线局域网的分集天线。在另外一些实施例中，天线可以和调谐开关结合使用。

移动通信模块140可以提供应用在电子设备100上的包括2G/3G/4G/5G等无线通信的解决方案。移动通信模块140可以包括至少一个滤波器，开关，功率放大器，低噪声放大器(low noise amplifier，LNA)等。移动通信模块140可以由天线1接收电磁波，并对接收的电磁波进行滤波，放大等处理，传送至调制解调处理器进行解调。移动通信模块140还可以对经调制解调处理器调制后的信号放大，经天线1转为电磁波辐射出去。在一些实施例中，移动通信模块140的至少部分功能模块可以被设置于处理器110中。在一些实施例中，移动通信模块140的至少部分功能模块可以与处理器110的至少部分模块被设置在同一个器件中。

调制解调处理器可以包括调制器和解调器。其中，调制器用于将待发送的低频基带信号调制成中高频信号。解调器用于将接收的电磁波信号解调为低频基带信号。随后解调器将解调得到的低频基带信号传送至基带处理器处理。低频基带信号经基带处理器处理后，被传递给应用处理器。应用处理器通过音频设备(不限于扬声器，受话器等)输出声音信号，或通过显示屏170显示图像或视频。在一些实施例中，调制解调处理器可以是独立的器件。在另一些实施例中，调制解调处理器可以独立于处理器110，与移动通信模块140或其他功能模块设置在同一个器件中。

无线通信模块150可以提供应用在电子设备100上的包括无线局域网(wirelesslocal area networks，WLAN)(如无线保真(wireless fidelity，Wi-Fi)网络)，蓝牙(bluetooth，BT)，全球导航卫星系统(global navigation satellite system，GNSS)，调频(frequency modulation，FM)，近距离无线通信技术(near field communication，NFC)，红外技术(infrared，IR)等无线通信的解决方案。无线通信模块150可以是集成至少一个通信处理模块的一个或多个器件。无线通信模块150经由天线2接收电磁波，将电磁波信号调频以及滤波处理，将处理后的信号发送到处理器110。无线通信模块150还可以从处理器110接收待发送的信号，对其进行调频，放大，经天线2转为电磁波辐射出去。

在一些实施例中，电子设备100的天线1和移动通信模块140耦合，天线2和无线通信模块150耦合，使得电子设备100可以通过无线通信技术与网络以及其他设备通信。所述无线通信技术可以包括全球移动通讯系统(global system for mobile communications，GSM)，通用分组无线服务(general packet radio service，GPRS)，码分多址接入(codedivision multiple access，CDMA)，宽带码分多址(wideband code division multipleaccess，WCDMA)，时分码分多址(time-division code division multiple access，TD-SCDMA)，长期演进(long term evolution，LTE)，BT，GNSS，WLAN，NFC ，FM，和/或IR技术等。所述GNSS可以包括全球卫星定位系统(global positioning system，GPS)，全球导航卫星系统(global navigation satellite system，GLONASS)，北斗卫星导航系统(beidounavigation satellite system，BDS)，准天顶卫星系统(quasi-zenith satellitesystem，QZSS)和/或星基增强系统(satellite based augmentation systems，SBAS)。

具体到本申请实施例中，电子设备100可以通过天线1，天线2，移动通信模块140，无线通信模块150等与互联网进行连接，以实现电子设备100的无线通信功能，在电子设备100与互联网进行连接后，APP或SDK可以向电子设备100中的操作系统发送调用请求。

当然，在APP或SDK发送调用请求访问本地服务器中的一些资源或功能时，不需要电子设备100与互联网连接也可以发送调用请求。

显示屏170用于显示图像，视频等。显示屏170包括显示面板。显示面板可以采用液晶显示屏(liquid crystal display，LCD)，有机发光二极管(organic light-emittingdiode，OLED)，有源矩阵有机发光二极体或主动矩阵有机发光二极体(active-matrixorganic light emitting diode，AMOLED)，柔性发光二极管(flex light-emittingdiode，FLED)，Miniled，MicroLed，Micro-oLed，量子点发光二极管(quantum dot lightemitting diodes，QLED)等。在一些实施例中，电子设备100可以包括1个或N个显示屏170，N为大于1的正整数。

具体到本申请实施例中，显示屏170中显示一个或多APP的图标，以及显示屏170中显示一个APP中的按钮、选项卡、文本框等可视界面元素。

外部存储器接口120可以用于连接外部存储卡，例如Micro SD卡，实现扩展电子设备100的存储能力。外部存储卡通过外部存储器接口120与处理器110通信，实现数据存储功能。例如将音乐，视频等文件保存在外部存储卡中。

具体到本申请实施例中，外部存储卡可以存储SDK列表，处理器110可以从外部存储卡中获取SDK列表。

内部存储器121可以用于存储计算机可执行程序代码，所述可执行程序代码包括指令。处理器110通过运行存储在内部存储器121的指令，从而执行电子设备100的各种功能应用以及数据处理。内部存储器121可以包括存储程序区和存储数据区。其中，存储程序区可存储操作系统，至少一个功能所需的应用程序(比如声音播放功能，图像播放功能等)等。存储数据区可存储电子设备100使用过程中所创建的数据(比如音频数据，电话本等)等。此外，内部存储器121可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件，闪存器件，通用闪存存储器(universal flash storage，UFS)等。

具体到本申请实施例中，内部存储器121中也可以存储SDK列表，处理器110可以从内部存储器121中获取SDK列表。

压力传感器160A用于感受压力信号，可以将压力信号转换成电信号。在一些实施例中，压力传感器160A可以设置于显示屏170。压力传感器160A的种类很多，如电阻式压力传感器，电感式压力传感器，电容式压力传感器等。电容式压力传感器可以是包括至少两个具有导电材料的平行板。当有力作用于压力传感器160A，电极之间的电容改变。电子设备100根据电容的变化确定压力的强度。当有触摸操作作用于显示屏170，电子设备100根据压力传感器160A检测所述触摸操作强度。电子设备100也可以根据压力传感器160A的检测信号计算触摸的位置。在一些实施例中，作用于相同触摸位置，但不同触摸操作强度的触摸操作，可以对应不同的操作指令。例如：当有触摸操作强度小于第一压力阈值的触摸操作作用于短消息应用图标时，执行查看短消息的指令。当有触摸操作强度大于或等于第一压力阈值的触摸操作作用于短消息应用图标时，执行新建短消息的指令。

具体到本申请实施例中，电子设备100可以通过压力传感器160A检测到用户操作。

触摸传感器160B，也称“触控面板”。触摸传感器160B可以设置于显示屏170，由触摸传感器160B与显示屏170组成触摸屏，也称“触控屏”。触摸传感器160B用于检测作用于其上或附近的触摸操作。触摸传感器可以将检测到的触摸操作传递给应用处理器，以确定触摸事件类型。可以通过显示屏170提供与触摸操作相关的视觉输出。在另一些实施例中，触摸传感器160B也可以设置于电子设备100的表面，与显示屏170所处的位置不同。

具体到本申请实施例中，电子设备100还可以通过触摸传感器160B检测到用户操作。

关于电子设备100的硬件结构就介绍到此，可以理解的是，图1示出的硬件结构中包含的部件，并不构成对电子设备100的具体限定。电子设备100可以具有比图中所示的更多的或者更少的部件，可以组合两个或多个的部件，或者可以具有不同的部件配置。图中所示出的各种部件可以在包括一个或多个信号处理和/或专用集成电路在内的硬件、软件、或硬件和软件的组合中实现。

本申请实施例提供的电子设备可以是用户设备（user equipment，UE），例如可以为移动终端（例如手机）、平板电脑、桌面型、膝上型笔记本电脑、手持计算机、上网本、个人数字助理（personal digital assistant，PDA）等设备。

另外，在上述部件之上，运行有操作系统。例如苹果公司所开发的iOS操作系统，谷歌公司所开发的Android开源操作系统，微软公司所开发的Windows操作系统等。在该操作系统上可以安装运行应用程序。

电子设备100的操作系统可以采用分层架构，事件驱动架构，微核架构，微服务架构，或云架构。本申请实施例以分层架构的Android系统为例，示例性说明电子设备100的操作系统。

图2是本申请实施例的电子设备100的软件结构的示意图。软件结构包括若干个层，每一层都有清晰的角色和分工，层与层之间通过软件接口通信。在一些实施例中，将软件结构从上至下依次划分为应用层、应用程序框架层、系统库和硬件层。

应用层可以包括一系列的应用程序包，比如，相机、图库、日历、地图、导航等。

应用程序框架层，简称为框架层，框架层为应用层的应用程序提供API和编程框架。框架层包括一些预定义的函数。当应用层中的应用程序被运行时，可以通过调用API实现应用程序的相关功能。例如，某个游戏类APP需要联网才能实现用户登录，那么，该APP被运行时，可以通过调用API实现联网功能。

应理解，API直接暴露在互联网上是存在安全风险的，为了保证API的安全性，通常API会被特定权限所保护，因而，APP或SDK调用API时，API需要对APP或SDK进行鉴权，即鉴定APP或SDK是否具有调用API的权限，如果鉴权通过，那么APP或SDK可以调用API，如果鉴权不通过，那么APP或SDK不能调用API。例如，游戏类APP调用API实现联网功能时需要游戏类APP具有调用该API的联网权限，那么，API需要鉴定游戏类APP是否具有联网权限，如果鉴权通过，那么游戏类APP可以调用API以实现联网功能，如果鉴权不通过，那么游戏类APP不能调用API。

本申请实施例，可以通过图2中的框架层示出的鉴权模块、活动管理模块（Activity Manager Service，AMS）和权限管理模块（Permission Manager Service，PMS）对APP或SDK是否具有特定权限进行鉴定。

API中的鉴权模块可以通过AMS和PMS鉴定APP或SDK是否具有特定权限。

本申请实施例，鉴权模块可以包括Android.content.context类中的鉴权函数，鉴权函数可以是checkCallingOrSelfPermission、checkSelfPermission或者checkCallingOrSelfUriPermission等。类是面向对象语言的程序设计中的概念，是面向对象编程的基础，类的实质是一种数据类型，类是程序中用来描述具有相同的属性和方法的对象的集合。每个类包含数据说明和一组操作数据或传递消息的函数（例如鉴权函数）。在一些实施例中，函数也可以称为方法，鉴权函数也可称为鉴权方法。本申请实施例中，鉴权模块可以基于APP或SDK的调用请求，向AMS发送相关数据（例如，需要鉴定的权限参数等），以及接收AMS的返回数据，根据返回数据得到鉴权结果。

AMS用于负责操作系统中四大组件的启动、切换、调度以及应用程序的管理和调度工作，其职责与操作系统中的进程管理和调度模块类似。操作系统的四大组件包括活动（Activity），用于表现功能，服务（service），后台运行服务，不提供界面呈现，广播接收者（Broadcast Recevice），用于接收广播，内容提供者（Content Provider），支持多个应用中存储和读取数据，相当于数据库。本申请实施例中，AMS主要用于向PMS转发鉴权模块下发的数据，以及向鉴权模块返回PMS确定的用户的授权结果。在一些实施例中，活动管理模块也可称为活动管理单元、活动管理服务等，本申请实施例对此不作限定。

PMS中保存着用户是否授予APP或SDK特定权限的授权结果。PMS可以根据鉴权模块下发的数据，确定用户的授权结果，并将授权结果返回AMS。在一些实施例中，权限管理模块也可以称为权限管理单元、权限管理服务等，本申请实施例对此不作限定。

系统库，可以包括多个功能模块。例如：表面管理器(Surface manager)，媒体库(Media Libraries)，三维图形处理库(例如：OpenGL ES)，二维图形引擎(例如：SGL)等。

本申请实施例中，系统库中包含编译器和解释器。编译器，用于负责把一种编程语言编写的源码转换成另外一种计算机代码，后者往往是以二进制的形式被称为目标代码(objectcode)。这个转换的过程通常的目的是生成可执行的程序，再交由计算机硬件执行。例如：APP通过调用API实现应用程序的相关功能时，APP向API发送调用请求，API鉴权通过后，编译器会将调用请求的源代码编译成机器码，进而使得电子设备的硬件可以直接执行编译后的机器码。

解释器，用于直接执行由编程语言或脚本语言编写的代码，并不会把源代码预编译成机器码。示例性的，一个解释器，通常会用以下几种方式来执行程序代码：解释器会逐行读取第三方应用的源代码，即逐行分析源代码（例如：APP对应的java文件），并且直接执行；或，把源代码翻译成相对更加高效率的中间码，然后立即执行它；或，执行由解释器内部的编译器预编译后保存的代码。可以理解的是，可以把解释器看成一个黑盒子，输入源码，就会实时返回结果。

硬件层，包括存储器和处理器，关于存储器和处理器的定义和解释可以参考上文实施例，此处不再赘述。

可以理解的是，图2示出的软件结构中的层以及各层中包含的部件，并不构成对电子设备的具体限定。在本申请另一些实施例中，电子设备可以包括比图示更多或更少的层，以及每个层中可以包括更多或更少的部件，例如，软件结构还可以包括硬件抽象层、内核（kernel）层等，本申请对此不作限定。

其中，硬件抽象层是对Linux内核驱动程序的封装，向上提供接口，它隐藏了特定平台的硬件接口细节，为操作系统提供了虚拟硬件平台，使其具有硬件无关性，可在多种平台上进行移植。内核层利用文件描述符（file descriptor）来访问文件。文件描述符是非负整数。打开现存文件或新建文件时，内核会返回一个文件描述符。读写文件也需要使用文件描述符来指定待读写的文件。

可以理解的是，电子设备为了实现本申请实施例中的应用程序的权限管控方法，其包含了执行各个功能相应的硬件和/或软件模块。结合本文中所公开的实施例描述的各示例的算法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。本领域技术人员可以结合实施例对每个特定的应用来使用不同方法来实现所描述的功能。

需要说明的是，本申请实施例虽然以Android系统为例进行说明，但是其基本原理同样适用于基于iOS或Windows等操作系统的电子设备。

本申请实施例提供的应用程序的权限管控方法的执行主体可以为上述的电子设备，也可以为该电子设备中能够实现该应用程序的权限管控方法的功能模块和/或功能实体，并且本申请方案能够通过硬件和/或软件的方式实现，具体的可以根据实际使用需求确定，本申请实施例不作限定。下面以电子设备为例，结合附图对本申请实施例提供的应用程序的权限管控方法进行示例性的说明。

下面介绍本申请要解决的技术问题以及本申请的发明构思。

某届维护消费者协议晚会上曾经曝光了第三方SDK借助宿主APP窃取用户隐私的问题。某些APP嵌入了第三方SDK，由于这些第三方SDK的提供者和APP提供者不是同一主体，而这些第三方SDK可能会收集用户的个人信息并将其传输到第三方SDK提供者所使用的服务器，造成用户隐私数据的泄露，降低了使用APP的安全性。

另外，第三方SDK可能由于自身存在安全漏洞，在第三方SDK借助宿主APP的权限调用API时，可能会导致APP的安全性降低。应理解，SDK是一个代码的封装包，存在安全漏洞，常见的安全漏洞有源文件安全、数据存储安全等，由于这些安全漏洞的存在，SDK会存在被攻击，被篡改，被利用的系统风险，而这些风险也间接影响了宿主APP。

还有，部分恶意SDK利用APP执行恶意行为，导致APP的安全性降低。例如，部分恶意SDK利用APP的权限，执行劫持用户流量、静默安装恶意软件或病毒木马、推送恶意广告、消耗用户的套餐资费等恶意行为，导致APP的安全性降低。

造成上述问题的原因在于，相关方案中的权限管控机制是以APP为管控粒度，无法对APP内嵌的SDK进行管控。因而，在为了使用APP授予其特定权限并且通过权限鉴定后，APP中的SDK也具有与APP相同的权限，SDK会借助APP的权限调用API，这样会导致APP的安全性降低。例如，用户为了使用APP授予其访问隐私数据的权限（例如，访问相册、访问信息等），那么APP中的SDK也具有访问隐私数据的权限，造成用户隐私数据的泄露，导致APP的安全性降低。又例如，用户为了使用APP授予其特定权限，自身存在安全漏洞的SDK也会拥有相同权限，这样，APP也会存在被攻击，被篡改，被利用的系统风险，导致APP的安全性降低。又例如，用户为了使用APP授予其特定权限，恶意SDK也会拥有相同权限，那么恶意SDK会利用APP执行恶意行为等。

为了解决上述问题，本申请的权限管控机制是以SDK为管控粒度，可以使用户对APP中的SDK进行权限管控，提升用户体验。

具体的，本申请可以首先确定用户是否以SDK为管控粒度对APP进行管控，其次，在确定用户以SDK为管控粒度对APP进行管控之后，确定调用请求是否是由SDK生成的，然后，在确定调用请求是由SDK生成的之后，鉴定SDK是否具有调用API的权限，最后，根据鉴定结果决定是否允许SDK调用API。

其中，在鉴定SDK不具有调用API的权限，禁止SDK调用API，可以避免SDK借助APP的权限调用API，从而降低了APP潜在的安全风险，提升了APP的安全性，提升了用户体验。

下面介绍了本申请提供的权限管控方法的应用场景。

图3是本申请实施例提供的一组图形用户界面（graphic user interface，GUI）。

本示例中的应用场景为游戏类app中内嵌广告类SDK，游戏类app需要申请联网权限以登录游戏账号，通过用户授予广告类SDK网络访问权限，广告类SDK可以拥有与宿主APP（游戏类app）同样的网络访问权限，广告类SDK借此网络权限可以实现联网功能以获取广告内容，并在游戏类APP的用户界面上展示广告内容；通过用户不授予广告类SDK网络访问权限，广告类SDK不会拥有网络访问权限，那么，广告类SDK无法实现联网功能以在游戏类APP的用户界面上展示广告内容。

图3中的（a）示出的图形用户界面中包括一个或多个应用程序的图标（例如，应用1、应用2、应用3的图标），用户可以点击（或者其他用户点击）应用程序的图标（例如，用户点击应用1的图标，本示例的应用1是游戏类的应用程序），响应于用户对应用1的操作，电子设备显示图3中的（b）示出的图形用户界面，该图形用户界面中包括一个弹窗，弹窗内容为“是否以SDK为管控粒度对应用1进行权限管控”，弹窗中包括“是”和“否”两个控件，用户点击“是”控件代表用户允许以SDK为管控粒度对应用1进行权限管控，用户点击“否”控件代表用户不允许以SDK为管控粒度对应用1进行权限管控。

如图3中的（c）所示，用户点击弹窗中的“是”控件，响应于用户对弹窗中的控件的操作，电子设备显示图3中的（d）示出的图形用户界面，该图形用户界面中也包括一个弹窗，弹窗内容为“允许SDK1使用网络”，弹窗中包括“是”、“否”和“每次询问”三个控件，其中，SDK1代表应用1中内嵌的广告类SDK，用户点击“是”控件代表用户允许SDK1使用网络，用户点击“否”代表用户不允许SDK1使用网络，用户点击“每次询问”控件代表用户本次允许SDK1使用网络，以后SDK1申请联网权限需要再次询问用户是否允许SDK1使用网络。

再次参考图3中的（c），用户点击该图形用户界面中的“是”控件，SDK1拥有网络访问权限，SDK1借此网络权限可以实现联网功能以获取广告内容，响应于用户对弹窗中“是”控件的操作，电子设备显示图3中的（e）示出的图形用户界面，该用户界面中显示广告内容。

在一些实施例中，用户也可以点击图3中的（c）中的“每次询问”控件，SDK1也会拥有网络访问权限，SDK1借此网络权限可以实现联网功能以获取广告内容，只是本次用户允许SDK1使用网络后，以后SDK1申请联网权限需要再次询问用户是否允许SDK1使用网络，响应于用户对弹窗中“每次询问”控件的操作，电子设备显示图3中的（e）示出的图形用户界面，该用户界面中显示广告内容。

在另一些实施例中，用户也可以点击图3中的（c）中的“否”控件，SDK1不会拥有网络访问权限，响应于用户对弹窗中“否”控件的操作，电子设备显示图3中的（e）示出的图形用户界面，该用户界面中不显示广告内容。

根据图3示出的GUI可知：本申请实施例可以通过弹窗询问用户是否允许以SDK为管控粒度对APP进行权限管控，并且在用户允许以SDK为管控粒度对APP进行权限管控的情况下，弹窗询问用户是否对APP中的SDK（例如SDK1）授予特定权限（例如网络访问权限），在用户对SDK授予特定权限的情况下，SDK可以实现特定权限对应的功能（例如联网功能），在用户对SDK未授予特定权限的情况下，SDK无法实现特定权限对应的功能，相对于相关方案中以APP为管控粒度进行权限管控，本申请实施例中用户可以主动管控APP中的SDK，本申请实施例是以SDK为管控粒度进行权限管控，提升了用户体验，并且，在用户对SDK未授予特定权限的情况下，SDK无法实现特定权限对应的功能，避免了SDK借助APP的权限实现该权限对应的功能，降低了APP潜在的安全风险，提升了APP的安全性，提升了用户体验。

图4是本申请实施例提供的另一组GUI。

该组GUI示例性的说明了用户通过操作“设置”中的控件，允许或禁止以SDK为管控粒度对APP进行权限管控的一种操作方式。

图4中的（a）示出的图形用户界面中包括一个或多个应用程序的图标（例如，“时钟”应用程序的图标、“设置”应用程序的图标等），用户可以点击（或者其他用户点击）“设置”图标，响应于用户对“设置”的操作，显示图4中的（b）示出的图形用户界面，该图形用户界面中包括一个或多个控件，例如，包括“飞行模式”、“无线局域网”、“……”、“SDK管控粒度” 、“……”、“应用1”、“应用2” 、“……”等多个控件，用户可以通过操作该图形用户界面中的“SDK管控粒度”控件，允许或禁止以SDK为管控粒度对APP进行权限管控。

如图4中的（c）所示，用户点击“SDK管控粒度”控件，响应于用户点击“SDK管控粒度”控件的操作，显示如图4中的（d）示出的图形用户界面，该图形用户界面中包括至少一个应用程序的控件，例如：包括“应用1”、“应用2”、“……”、“应用6” 、“……”等多个控件，用户可以通过操作该图形用户界面中的“应用1”、“应用2”等控件，允许或禁止以SDK为管控粒度对“应用1”、“应用2”等进行权限管控。

如图4中的（e）所示，用户点击“应用1”控件，响应于用户点击“应用1”控件的操作，显示如图4中的（f）示出的图形用户界面，该图形用户界面中包括“允许”和“不允许”两个控件，用户点击“允许”控件代表用户允许以SDK为管控粒度对应用1进行权限管控，用户点击“不允许”控件代表用户不允许以SDK为管控粒度对应用1进行权限管控。

图5是本申请实施例提供的另一组GUI。

该组GUI示例性的说明了用户通过操作“设置”中的控件，允许或禁止以SDK为管控粒度对APP进行权限管控的另一种操作方式。

图5中的（a）示出的图形用户界面中包括一个或多个应用程序的图标（例如，“时钟”应用程序的图标、“设置”应用程序的图标等），用户可以点击（或者其他用户点击）“设置”图标，响应于用户对“设置”的操作，显示图5中的（b）示出的图形用户界面，该图形用户界面中包括一个或多个控件，例如，包括“飞行模式”、“无线局域网”、“……”、“SDK管控粒度” 、“……”、“应用1”、“应用2” 、“……”等多个控件，用户可以通过操作该图形用户界面中的“应用1”、“应用2”等控件，允许或禁止以SDK为管控粒度对“应用1”、“应用2”等进行权限管控。

如图5中的（c）所示，用户点击“应用1”控件，响应于用户点击“应用1”控件的操作，显示如图5中的（d）示出的图形用户界面，该图形用户界面中包括一个或多个控件，例如，包括“飞行模式”、“无线局域网”、“……”、“SDK管控粒度” 、“……”等，用户可以通过操作该图形用户界面中“SDK管控粒度”控件，允许或禁止以SDK为管控粒度对应用1进行权限管控。

如图5中的（e）所示，用户点击“SDK管控粒度”控件，响应于用户点击“SDK管控粒度”控件的操作，显示如图5中的（f）示出的图形用户界面，该图形用户界面中包括“允许”和“不允许”两个控件，用户点击“允许”控件代表用户允许以SDK为管控粒度对应用1进行权限管控，用户点击“不允许”控件代表用户不允许以SDK为管控粒度对应用1进行权限管控。

根据图4和图5示出的GUI可知：本申请实施例，用户可以通过操作“设置”中的控件，允许或禁止以SDK为管控粒度对APP进行权限管控，相对于相关方案中，用户无法主动管控APP中的SDK，本申请可以在用户允许以SDK为管控粒度对APP进行权限管控后，使用户主动管控APP中的SDK，提升了用户体验。

图6是本申请实施例提供的另一组GUI。

该组GUI示例性的说明了用户通过操作“设置”中的控件，授予或未授予SDK特定权限的一种操作方式。

图6中的（a）示出的图形用户界面中包括“允许”和“不允许”两个控件，可以理解的是，该图形用户界面可以是图4或图5中的（f）示出的图形用户界面，用户点击“允许”控件，响应于用户点击“允许”控件，电子设备显示图6中的（b）示出的图形用户界面，该图形用户界面中包括至少一个SDK的控件，例如：“SDK1”、“SDK2”、“……”、“SDK6” 、“……”等控件，用户通过操作该图形界面中的至少一个SDK的控件，授予或不授予SDK以特定权限。

如图6中的（c）示出的图形用户界面，用户点击“SDK1”控件，响应于用户点击“SDK1”控件的操作，电子设备显示如图6中的（d）示出的图形用户界面，该图形用户界面中包括至少一个特定权限的控件，例如：“位置”、“无线数据”、“……”、“通讯录” 、“……”等控件。用户通过操作该图形界面中的“位置”、“无线数据”等控件，授予或不授予SDK1“位置访问权限”、“网络访问权限”等。

如图6中的（e）示出的图形用户界面，用户点击“无线数据”控件，电子设备显示如图6中的（f）示出的图形用户界面，该图形用户界面中包括“允许”、“不允许”和“每次询问”三个控件，用户点击“允许”控件，代表用户授予SDK1网络访问权限，用户点击“不允许”控件，代表用户不授予SDK1网络访问权限，用户点击“每次询问”控件，代表本次SDK1申请网络访问权限时，用户授予SDK1网络访问权限，下次SDK1申请网络访问权限时，需要再次询问用户是否授予SDK1网络访问权限。

根据图6示出的GUI可知：本申请实施例可以由用户决定是否授予SDK特定权限，相对相关方案中用户只能决定是否授予APP特定权限，本申请可以使用户主动管控APP中的SDK，提升用户体验，并且，在用户未授予SDK特定权限的情况下，SDK无法实现特定权限对应的功能，避免了SDK借助APP的权限实现该权限对应的功能，降低了APP潜在的安全风险，提升了APP的安全性，提升了用户体验。

下面简单介绍了相关方案中的权限管控机制。

请参考图7，图7提供了一种相关方案中的权限管控机制的示例图。图7中的圆圈以及圆圈中的数字用于表示实现该权限管控机制的步骤。

步骤1、应用层向框架层发送调用请求。

应理解，应用层中包括一系列的应用程序，例如，图7示出的APP1为一系列APP中的一个。

框架层中包括多个API，例如，图7示出的API1为多个API中的一个。

应用层向框架层发送调用请求可以是APP1向API1发送调用请求。

还应理解，API通常使用标准协议与APP进行通信，标准协议可以是超文本传输协议（Hyper Text Transfer Protocol，HTTP）、简单对象访问协议（Simple Object AccessProtocol，SOAP）等，因而，APP向API发送的调用请求也应该遵循标准协议，例如，调用请求可以是HTTP请求。调用请求中包括请求方法、调用的API的统一资源定位符（UniformResource Location，URL）、请求数据等，其中，请求方法可以用于获取资源、传输实体主体、传输文件、追踪路径等，URL是指具体要访问的API的接口地址，请求数据包括待获取的资源数据。

同样可以理解，API直接暴露在互联网上是存在安全风险的，为了保证API的安全性，通常API会被特定权限所保护，因而，APP向API发送调用请求后，API需要对APP是否具有特定权限进行鉴权。当然，假设API未被特定权限保护，APP可以直接调用API而不用进行鉴权。

API可以通过鉴权模块对APP进行鉴权，即通过鉴权模块鉴定APP是否具有调用API的特定权限，如果鉴权通过，那么APP可以调用API，如果鉴权不通过，那么APP不能调用API。

鉴权模块可以是Android.content.context类中的鉴权函数，关于鉴权函数的具体类型可以参考上文实施例，此处不再赘述。

图7示出的步骤2至步骤6详细叙述了框架层通过API中的鉴权模块鉴定APP是否具有特定权限的实现方式。

步骤2、框架层通过鉴权模块基于调用请求，获取APP1的上下文参数1，并向AMS发送APP1的上下文参数以及权限参数1。

应理解，上下文参数（context）可以提供APP的全局信息，全局信息用于提供APP的包名、APP的用户标识等数据。图7示出的上下文参数1是指APP1的上下文参数。

框架层接收到调用请求后，可以通过调用获取上下文参数的函数获取APP1的上下文参数，获取上下文参数的函数可以是getApplicationContext、getBaseContext等。

还应理解，权限参数是指鉴权模块需要鉴定的权限参数。实现中，鉴权模块可以是鉴权函数，鉴权函数中会写明需要鉴定的权限参数，例如，图7示出的权限参数1是指APP1向API1发送调用请求后，API1中的鉴权函数需要鉴定APP1是否具有特定权限对应的权限参数。

可以理解，不论何种APP向被权限保护的API发送调用请求，API均需要鉴定APP是否具有调用API的特定权限，API根据鉴权模块的鉴权结果鉴定APP是否具有调用API的特定权限，鉴定通过后，APP可以调用API，鉴定未通过，APP不能调用API。其中，鉴权模块可以向AMS发送APP的上下文参数和需要鉴定的权限参数，AMS将上述数据转发给PMS，PMS中记载着用户的授权结果，PMS通过AMS将授权结果返回给鉴权模块，鉴权模块根据授权结果即可得到鉴权结果。

步骤3、框架层通过AMS向PMS发送上下文参数1和权限参数1。

关于AMS和PMS的定义已在上文详细叙述，此处不再赘述。

步骤4、框架层通过PMS根据上下文参数1和权限参数1确定用户是否对APP1授予特定权限。

应理解，PMS中维护着一个树结构，树结构中保存着用户是否授予APP特定权限的授权结果，树结构是一种非线性数据结构，它是由有限节点组成一个具有层次关系的集合。

示例性，请参考图7，树结构可以是由有限节点组成的具有三层层次关系的集合，第一层级为用户状态（UserState），第一层级可以被认为是树结构的根节点，第二层级为用户身份证明状态（User Identification State，UIDState），第二层级可以被认为是树结构的子节点，第二层级中包括至少一个APP的用户身份证明，例如：图7示出的APP1、APP2等，第三层级为权限状态（permissionState），第三层级可以被认为是树结构的叶子节点，第三层级中包括第二层级中每个APP对应的至少一个权限参数，例如：图7示出的APP1对应权限参数1和权限参数2，APP2对应权限参数3等，权限状态中还包括用户对至少一个权限参数的授权结果，例如：用户对权限参数1、权限参数2、权限参数3等的授权结果，授权结果可以是假（false）、真（true）、或者每次询问（ask everytime）。其中，授权结果为假，代表用户未对APP授权，授权结果为真，代表用户对APP授权，授权结果为每次询问，代表本次APP申请特定权限时，用户对该次申请的APP授权，以后APP申请特定权限时，每次询问是否对APP授权。

框架层通过PMS根据上下文参数1和权限参数1确定用户是否对APP1授予特定权限的实现过程可以为：

首先，框架层通过PMS确定用户状态。

实现中，PMS接收到APP1的上下文参数（context）后，通过context类中获取UserID的函数可以获取到APP1的UserID，根据UserID，从全局变量中确定UserState。全局变量是在函数外部定义的变量（没有定义在某一个函数内），所有函数内部都可以使用这个变量。

示例性的，获取APP的UserID的函数可以是getUserID等，全局变量可以是全局变量mState等。

通俗理解，由于用户状态位于树结构的第一层级，因而，通过确定用户状态便可定位树结构。

其次，框架层通过PMS在树结构的第二层级中确定APP1的用户身份证明。

实现中，PMS接收到APP1的上下文参数（context）后，通过context类中获取UserID的函数可以获取到APP1的UserID，以及通过context类中获取应用程序包名的函数可以获取到APP1的应用程序包名，例如，获取应用程序包名的函数可以是getPackageName。

根据APP1的包名通过context类中获取APPID的函数可以获取到APP1的APPID，例如，获取APPID的函数可以是getAppID等。

根据APP1的UserID和APP1的APPID，可以确定APP1的用户身份证明UID，例如，假设APP1的UserID，APPID为10087，那么，通过UserID×10000+APPID= UID，可以得到UID=10×10000+10087=1010087。

根据APP1的UID在第二层级中的多个UID中查询APP1的UID，例如，图7中树结构的第二层级中示出的APP1为APP1的UID，APP2为APP2的UID，假设在APP1和APP2中查询到APP1，那么在树结构的第二层级中可以确定APP1的用户身份证明。

最后，在第三层级中确定用户是否对APP1授予特定权限。

实现中，框架层通过PMS在树结构的第二层级中确定APP1的用户身份证明后，根据PMS接收到的权限参数1，在APP1对应的第三层级中查询权限参数1，例如，图7中APP1对应的第三层级中包括权限参数1和权限参数2，那么根据PMS接收到的权限参数1，在权限参数1和权限参数2中可以查询到权限参数1，随后，在权限参数1对应的授权结果中查询用户是否对APP1授予特定权限，从而可以确定用户是否对APP1授予特定权限。假设授权结果为“真”，则确定用户对APP1授予特定权限，通过步骤5返回“真”，假设授权结果为“假”，则确定用户未对APP1授予特定权限，通过步骤5返回“假”，假设授权结果为“每次询问”，则弹窗询问用户是否对APP1授予特定权限，如果用户对APP1授予特定权限，那么，将第三层级中权限参数1对应的授权结果“每次询问”更新为“真”，通过步骤5返回“真”，如果用户未对APP1授予特定权限，那么，将第三层级中权限参数1对应的授权结果“每次询问”更新为“假”，通过步骤5返回“假”，如果用户依然选择每次询问，那么，不更新第三层级中的授权结果，通过步骤5返回“真”。

步骤5、框架层通过PMS向AMS返回授权结果。

步骤6、框架层通过AMS向鉴权模块返回授权结果。

步骤7、框架层通过鉴权模块根据授权结果鉴定APP1是否具有特定权限。

假设步骤6返回的授权结果为真，那么框架层通过鉴权模块根据授权结果鉴定APP1具有特定权限，假设步骤6返回的授权结果为假，那么框架层通过鉴权模块根据授权结果鉴定APP1不具有特定权限。

步骤8、在框架层通过鉴权模块鉴定APP1具有特定权限的情况下，通过API1向应用层返回APP1调用API1的运行结果。

应理解，APP1具有特定权限，APP1才可以调用API1，APP1不具有特定权限，APP1不能调用API1。

由上述可知，相关方案中的权限管控机制，能够通过PMS中维护的具有三层层次关系的树结构确定用户是否对APP进行授权的授权结果，以及通过鉴权模块根据授权结果鉴定APP是否具有特定权限，而不能确定用户是否对APP中的SDK进行授权，以及不能鉴定SDK是否具有特定权限，可以通俗理解为，用户无法主动授予SDK权限以及鉴权模块不能鉴定SDK是否具有特定权限，因而，在用户为了使用APP授予其特定权限时，APP中的SDK也会被授予与APP相同的特定权限，在鉴权模块鉴定APP具有特定权限后，SDK也会通过鉴定，这样，SDK可以借助APP的权限实现特定权限对应的功能，可能会导致APP的安全性降低。

下面介绍了本申请实施提供的权限管控机制。

请参考图8，图8是本申请实施例提供的一种权限管控方法的数据流图。图8中的圆圈以及圆圈中的数字用于表示实现该权限管控方法的步骤。

步骤11、响应于对APP1的操作，应用层向框架层发送调用请求。

应理解，对APP1的操作是指用户对APP1的用户操作，例如，图3中的（a）示出用户点击“应用1”的操作，用户操作还可以是触摸、滑动、声控等操作，本申请对用户操作的类型不作限定。

还应理解，此处的应用层向框架层发送调用请求可能是图8示出的APP1向API1发送的调用请求，还可能是SDK1向API1发送的网络请求，此处暂不能确定，通过步骤13的方法可以确定调用请求是否是SDK1发送的。

步骤12、框架层通过鉴权模块基于调用请求，获取APP1的上下文参数1和权限管控列表，根据APP1的上下文参数1和权限管控列表确定用户是否允许API1以SDK为管控粒度对APP1进行权限管控。

关于基于调用请求，获取APP1的上下文参数1的实现方式可以参考上文实施例，此处不再赘述。

框架层通过鉴权模块基于调用请求，获取APP1的上下文参数1后，可以通过APP1的上下文参数1获取APP1的包名，关于通过APP1的上下文参数1获取APP1的包名的实现方式已在上文实施例中陈述，此处不再赘述。

应理解，权限参数管控列表中包括N个APP的包名和N个管控结果的对应关系，N为大于或者等于1的整数，一个APP的包名对应一个管控结果，示例性的，请参考表1，表1是本申请实施例提供的一种权限管控列表的示例表。

由表1可知，表1是通过键值对的形式保存数据，其中，关键字（key） 为APP的包名，值（value）为管控结果。管控结果共有三种情况，一种是“允许”、一种是“禁止”、一种是“\”，其中，“允许”代表用户允许对APP以SDK为管控粒度进行权限管控，例如，APP1的包名对应的管控结果为“允许”，“禁止”代表用户不允许对APP以SDK为管控粒度进行权限管控，例如，APP2的包名对应的管控结果为“禁止”， “\”代表在本次APP向API发送调用请求之前，API还未就“是否允许对APP以SDK为管控粒度进行权限管控” 的问题询问过用户（譬如电子设备中新安装的APP，该APP未就“是否允许对APP以SDK为管控粒度进行权限管控” 的问题询问过用户），例如，APP3的包名对应的管控结果为“\”。

还应理解，上述表1可以是在电子设备出厂之前预先配置的。

例如，在电子设备出厂之前，厂商根据经验或根据收集到的资料认为某些APP中的SDK具有私自收集用户的隐私数据、SDK自身具有安全漏洞等问题，会降低APP的安全性，那么，对这些APP需要以SDK为管控粒度对这些APP进行权限管控，因而，这些APP对应的管控结果为“允许”，厂商认为某些APP中的SDK合乎规定，不存在安全漏洞，不会执行恶意行为等，不会降低APP的安全性，那么，对这些APP不需要以SDK为管控粒度对这些APP进行权限管控，因而，这些APP对应的管控结果为“禁止”，厂商不确定APP中的SDK是否私自收集用户的隐私数据、是否具有安全漏洞、是否执行恶意行为，那么，对这些APP不确定是否以SDK为管控粒度对这些APP进行权限管控，因而，对这些APP对应的管控结果为“/”。

同样可以理解，上述表1中的管控结果可以是在应用电子设备的过程中，通过询问用户，根据用户的选择结果获得的。

例如，电子设备中新安装一个APP，该APP向API发送调用请求，通过图3中的（b）示出的询问用户的方式询问用户是否以SDK为管控粒度对APP进行权限管控，并将询问结果记载在表1中，譬如，用户点击图3中的（b）示出的“是”控件，管控结果为“允许”，用户点击图3中的（b）示出的“否”控件，管控结果为“禁止”。

在一种情况下，用户可以通过电子设备“设置” 中的“SDK管控粒度”的控件，写入或更改表1中的管控结果，具体的，用户可以通过图3示出的操作方式写入或更改表1中的管控结果，用户点击图3中的（a）示出的“设置”，点击图3中的（c）示出的“SDK管控粒度”，点击图3中的（e）示出的应用控件，例如，点击“应用1”，在图3中的（f）示出的用户界面中点击“允许”或“不允许”以写入或更改表1中的管控结果。

用户还可以通过图4示出的操作方式写入或更改表1中的管控结果，用户点击图4中的（a）示出的“设置”，点击图4中的（c）示出的应用控件，例如，点击“应用1”，点击图4中的（e）示出 “SDK管控粒度”，在图4中的（f）示出的用户界面中点击“允许”或“不允许”以写入或更改表1中的管控结果。

还可以理解，权限管控列表可以保存在系统设置（SystemSettings）的数据库中，SystemSettings为系统数据库，里面存放的数据大多为系统的一些配置数据，还有可以包括一些其他数据信息，比如权限管控列表。框架层的鉴权模块可以从SystemSettings中获取权限管控列表。

本申请实施例，根据APP1的上下文参数1和权限管控列表确定用户是否允许API1以SDK为管控粒度对APP1进行权限管控的实现方式可以为：

根据APP1的包名，在权限管控列表中查询是否存在APP1的包名对应的管控结果，在查询到APP1的包名对应的管控结果为“允许”的情况下，确定用户允许API1以SDK为管控粒度对APP1进行权限管控，在查询到APP1的包名对应的管控结果为“不允许”的情况下，确定用户不允许API1以SDK为管控粒度对APP1进行权限管控，在查询到APP1的包名对应的管控结果为“\”的情况下，弹窗询问用户是否允许API1以SDK为管控粒度对APP1进行权限管控，例如，通过图3中的（b）示出的弹窗询问用户，并将询问结果记载在权限管控列表，经过弹窗询问后，假设APP1的包名对应的管控结果为“允许”，确定用户允许API1以SDK为管控粒度对APP1进行权限管控，假设APP1的包名对应的管控结果为“不允许”，确定用户不允许API1以SDK为管控粒度对APP1进行权限管控。

步骤13、在框架层通过鉴权模块确定用户允许API1以SDK为管控粒度对APP1进行权限管控的情况下，获取SDK列表和API1的调用栈，根据SDK列表和API1的调用栈确定是否是APP1中的SDK1向框架层发送调用请求。

在一些实施例中，在框架层通过鉴权模块确定用户允许API1以SDK为管控粒度对APP1进行权限管控的情况下，可以通过获取API1的调用栈，根据API1的调用栈确定是否是APP1中的SDK1向框架层发送调用请求。

应理解，调用栈（Call stack），也可称为执行栈、控制栈、运行时栈、或机器栈等。调用栈是计算机科学中存储有关正在运行的子程序的消息的栈，调用栈用于保存函数运行时的状态信息，包括函数参数与局部变量等，具体到本申请实施例，API1的调用栈中保存着发起调用请求的应用程序或者SDK的包名。

本申请实施例中，可以通过调用获取调用栈的函数获取API的调用栈，获取调用栈的函数可以为builtin_ return_address函数，也可以是backtrace函数等，本申请实施例对此不作限定。

该实施例中，确定是否是APP1中的SDK1向框架层发送调用请求的实现方式为：

在API1的调用栈中查询是否存在SDK1的包名，若存在SDK1的包名，则确定是APP1中的SDK1向框架层发送调用请求，若不存在SDK1的包名，则确定不是APP1中的SDK1向框架层发送调用请求。

本申请实施例中，在框架层通过鉴权模块确定用户允许API1以SDK为管控粒度对APP1进行权限管控的情况下，还可以通过获取SDK列表和API1的调用栈，根据SDK列表和API1的调用栈确定是否是APP1中的SDK1向框架层发送调用请求。

应理解，SDK列表中保存着可能会发起私自收集用户隐私数据、劫持用户流量、静默安装恶意软件、静默安装病毒木马、推送恶意广告、消耗用户的套餐资费等敏感行为的SDK，也可以保存自身存在安全漏洞的SDK，当上述APP中的SDK调用API，会降低APP的安全性，因而，在框架层接收到调用请求时，需要确定调用请求是否是上述SDK发起的，以便对上述SDK进行管控。

示例性的，请参考表2，表2是本申请实施例提供的一种SDK列表的示例表。

表2也可以通过键值对的形式保存数据，其中，关键字（key） 为SDK的包名，值（value）为敏感行为。SDK列表可以保存在存储器中，本申请实施例对SDK列表的存储位置不作限定。

本申请实施例中，根据SDK列表和API1的调用栈确定是否是APP1中的SDK1向框架层发送调用请求的实现方式可以为：

在API1的调用栈中查询是否存在SDK列表中的SDK的包名，在查询到存在SDK列表中的SDK的包名的情况下，确定调用请求是基于SDK发送的，例如，在查询到存在SDK列表中的SDK1的包名的情况下，确定调用请求是基于SDK1发送的。随后依据步骤14至20鉴定SDK1是否具有特定权限。

在查询到不存在SDK列表中的SDK的包名的情况下，按照上文实施例中步骤2至步骤6鉴定APP是否具有特定权限。

步骤14、在框架层通过鉴权模块确定APP1中的SDK1向框架层发送调用请求的情况下，向AMS发送APP1的上下文参数1、权限参数1和SDK1的包名。

步骤15、框架层通过AMS向PMS发送APP的上下文参数1、权限参数1和SDK1的包名。

步骤16、框架层通过PMS根据APP的上下文参数1和权限参数1确定用户是否对APP1授予特定权限。

应理解，PMS中维护着一个树结构，该实施例中的树结构与图7的树结构的区别在于，图7的树结构具有三层层次关系，而本申请实施例的树结构具有四层层次关系。

示例性的，请参考图8，该树结构包括“用户状态（UserState）-用户身份证明状态（User Identification State，UIDState）-权限状态（permissionState）-SDK状态（SDKState）”四层层次关系，其中，前三层级与图7中的前三层级包括的数据相同，可以参考图7中的描述，此处不再赘述，本申请实施例中，第一层级是树结构的根节点，第二层级是树结构的子节点，第三层级也是树结构的子节点，第四层级是树结构的叶子节点，第四层级为SDKState，第四层级中包括第三层级中每个权限参数对应的至少一个SDK的包名，以及对至少一个SDK的授权结果。例如：图8示出的第三层级包括权限参数1和权限参数2两个权限参数，权限参数1对应SDK1的包名和SDK2的包名，权限参数2对应SDK1的包名和SDK2的包名，每个SDK对应一个对SDK的授权结果。授权结果可以是假（false）、真（true）、或者每次询问（ask everytime）。其中，授权结果为假，代表用户未对SDK授权，授权结果为真，代表用户对SDK授权，授权结果为每次询问，代表本次SDK申请特定权限时，用户对该次申请的SDK授权，以后SDK申请特定权限时，每次询问是否对SDK授权。

本申请实施例的树结构还可以参考图9，图9是本申请实施例提供的一种树结构的示例图。图9中第一层级为用户状态，第二层级为用户身份证明状态，包括APP1的UID和APP2的UID，第三层级为权限状态，其中，APP1对应权限参数1、权限参数2和权限参数3，APP2对应权限参数4和权限参数5，每个权限参数均有对应的授权结果，第四层级为SDK状态，其中，权限参数1对应SDK1和SDK2，权限参数2对应SDK3，权限参数3对应SDK4和SDK5，权限参数4对应SDK6，权限参数5对应SDK7和SDK8，每个SDK均有对应的授权结果。

本申请实施例中，根据APP的上下文参数1和权限参数1确定用户是否对APP1授予特定权限已在上文实施例中陈述，此处不再赘述。

本申请实施例，在确定用户对APP1授予特定权限的情况下，执行步骤17。

步骤17、框架层通过PMS根据SDK1的包名和用户对APP1的授权结果确定用户是否对APP1中的SDK1授予特定权限。

本实施例的实现方式可以为：

在第三层级中确定用户对APP1授予特定权限（由上文实施例可知，可以由第三层级中对权限参数1的授权结果确定用户对APP1授予特定权限）的情况下，根据SDK1的包名在树结构的第四层级中确定用户是否对APP1中的SDK1授予特定权限。

具体的，在第三层级中确定用户对APP1授予特定权限的情况下，根据SDK1的包名，在第四层级中查询是否存在SDK1的包名，例如图9所示，在第三层级中查询APP1对应的权限参数1，以及根据授权结果确定用户对APP1授予特定权限后，在第四层级中存在权限参数1对应SDK1和SDK2的包名，在这两个包名中查询是否存在SDK1的包名。

在第四层级中查询到SDK1的包名，根据SDK1的包名对应的授权结果确定用户是否对APP1中的SDK1授予特定权限，假设授权结果为“真”，确定用户对APP1中的SDK1授予特定权限，并通过步骤18返回授权结果“真”，假设授权结果为“假”，确定用户未对APP1中的SDK1授予特定权限，并通过步骤18返回授权结果“假”，假设授权结果为“每次询问”，弹窗询问用户是否对APP1中的SDK1授予特定权限，例如，通过图3中的（d）示出的弹窗界面询问用户，如果用户选择“是”，将第四层级中SDK1对应的授权结果“每次询问”更新为“真”，通过步骤18返回“真”，如果用户选择“否”，将第四层级中SDK1对应的授权结果“每次询问”更新为“假”，通过步骤18返回“假”，如果用户选择“每次询问”，那么，不更新第四层级中SDK1对应的授权结果，通过步骤18返回“真”。

在第四层级中未查询到SDK1的包名，代表在本次SDK1向API1发送调用请求之前，API还未就“是否对SDK1授予特定权限” 的问题询问过用户（譬如电子设备中新安装的APP1，APP1内嵌SDK1，该SDK1发送调用请求之前，API1未就“是否对SDK1授予特定权限” 的问题询问过用户），此时，在第四层级中新建SDK状态，SDK状态中包括SDK1的包名和对SDK1的授权结果（新建的授权结果中的数据为空），弹窗询问用户是否对APP1中的SDK1授予特定权限，例如，通过图3中的（d）示出的弹窗界面询问用户，如果用户选择“是”，将授权结果“真”写入第四层级，通过步骤18返回“真”，如果用户选择“否”，将授权结果“假”写入第四层级，通过步骤18返回“假”，如果用户选择“每次询问”，那么，将授权结果“每次询问”写入第四层级，通过步骤18返回“真”。

在一些实施例中，用户可以通过电子设备“设置” 中控件，写入或更改树结构中第四层级中的授权结果。具体的，用户可以通过图3和图5示出的操作方式或者通过图4和图5示出的操作方式写入或更改第四层级中的授权结果，用户在图3中的（f）或图4中的（f）显示的用户界面中点击“允许”之后，点击图5中的（c）示出的SDK控件，例如，点击“SDK1”，假设权限参数1是网络访问权限的参数，点击图5中的（e）示出的“无线数据”，在图5中的（f）示出的用户界面中点击“允许”或“不允许”或“每次询问”以写入或更改第四层级中的授权结果。

例如，假设第四层级中权限参数1对应的SDK1的包名对应的授权结果为“真”，用户通在图5中的（f）示出的用户界面中点击 “不允许”更改该授权结果为“假”。

步骤18、框架层通过PMS向AMS返回授权结果。

步骤19、框架层通过AMS向鉴权模块返回授权结果。

步骤20、框架层通过鉴权模块根据授权结果鉴定SDK1是否具有特定权限。

假设步骤20返回的授权结果为“真”，那么框架层通过鉴权模块根据授权结果鉴定SDK1具有特定权限，假设步骤20返回的授权结果为“假”，那么框架层通过鉴权模块根据授权结果鉴定SDK1不具有特定权限。

步骤21、在框架层通过鉴权模块鉴定SDK11具有特定权限的情况下，通过API1向应用层返回SDK1调用API1的运行结果。

应理解，SDK1具有特定权限，SDK1才可以调用API1，SDK1不具有特定权限，SDK1不能调用API1。

需要说明的是，调用请求只能由一个程序生成，要么是由APP1生成，要么是由SDK1生成，而本申请实施例中通过步骤13可以确定调用请求是由SDK1生成的，但是在鉴定SDK1是否具有特定权限的过程中，需要通过步骤16首先确定用户已经对APP1授予特定权限，然后才能通过步骤17确定用户是否对SDK1授予特定权限，通过步骤16以及结合图7可知，确定用户已经对APP1授予特定权限，以及通过图7中的步骤7鉴定APP1具有特定权限，如果调用请求是由APP1生成的，那么APP1是可以调用API1的，通过步骤17和步骤20可知，根据授权结果鉴定SDK1不具有特定权限的情况下，SDK1不可以调用APP1，因而，本申请实施例可以对APP授予特定权限，APP依据该特定权限调用API，而不对APP中的SDK授予特定权限，禁止SDK调用API，可以避免SDK借助APP的特定权限调用API，降低了APP潜在的安全风险，提升了APP的安全性，提升了用户体验。

图10是本申请实施例提供的一种权限管控方法的时序图，图10中步骤11至步骤21的实现过程与图9中步骤11至步骤12的实现过程相同，此处不再赘述。

下面介绍本申请实施例提供的权限管控方法的内部实现过程。

图11是本申请实施例提供的一种权限管控方法200的示意性流程图。该方法200可由电子设备执行，也可由电子设备中的处理器或芯片执行，本申请实施例不做任何限定。为了便于描述，以电子设备为例对方法200做详细说明。

S201、电子设备响应于对第一应用程序APP的触发事件，确定基于第一软件开发工具包SDK生成的调用请求。

应理解，第一程序APP可以是通过应用商店或者其他途径下载的众多APP中的一个，也可以是基于应用软件开放平台接口开发的、用户无需安装即可使用的众多小程序中的一个，第一APP可以是图3示出的应用1，也可以是图7或图8或图10示出的APP1。本申请实施例对应用程序的类型不作限定。

第一APP中配置第一SDK可以理解为第一APP中内嵌第一SDK，众所周知，为了降低APP的开发成本和运营成本，可以在APP中集成至少一个SDK，以实现SDK对应的功能，第一SDK为至少一个SDK中的一个，例如，第一SDK可以是图8或图10示出的SDK1。

触发事件是指触发第一APP或者第一SDK向API（第一API）发送调用请求的事件，由于本申请实施例的目的是为了对SDK进行权限管控，因而，本申请实施例的触发事件是指触发第一SDK向API发送调用请求的事件。

触发事件可以是基于对第一APP的用户操作产生的，对第一APP的用户操作可以是对第一APP进行点击、触摸、或滑动等操作，本申请实施例对用户操作的类型不作限定。例如，对第一APP的操作，可以是图3中的（a）示出用户点击“应用1”的操作。

触发事件还可以是基于第一APP接收到的消息产生的，例如，其他电子设备中的APP（譬如，即时通讯类APP）向本申请实施例中的电子设备上的第一APP（即时通讯类APP）发送聊天消息，第一APP接收到聊天消息后，触发第一APP向“通知API”发送调用请求以请求调用该API在电子设备的屏幕中弹出通知窗口以提示用户。本申请实施例对触发事件的类型不作限定。

还应理解，基于第一软件开发工具包SDK生成的调用请求可以认为是第一SDK向第一API发送的调用请求。第一API可以是图7或图8或图10示出的API1。

本申请实施例，确定基于第一SDK生成的调用请求的实现方式可以为:通过获取第一API的调用栈，根据第一API的调用栈确定基于第一SDK生成的调用请求。该实现方式的具体过程可以参考其他实施例，此处不再赘述。

确定基于第一SDK生成的调用请求的实现方式还可以为：通过获取第一API的调用栈和SDK列表，根据第一API的调用栈和SDK列表确定基于第一SDK生成的调用请求。该实现方式的具体过程可以参考其他实施例，此处不再赘述。

S202、电子设备根据调用请求，获取第一APP的上下文参数、第一权限参数和第一SDK的包名。

应理解，第一APP的上下文参数用于指示第一APP的全局信息，全局信息用于提供APP的包名、APP的用户标识等数据，第一APP的上下文参数可以是图7或图8或图10示出的上下文参数1。

关于获取第一APP的上下文参数的实现方式已在上文实施例中陈述，此处不再赘述。

还应理解，第一权限参数为第一应用程序编程接口API待鉴定的权限参数。不论何种SDK向被特定权限保护的API发送调用请求，API均需要鉴定SDK是否具有调用API的特定权限，因而第一权限参数可以理解为API需要鉴定的特定权限（为了便于描述，本申请实施例将特定权限称为第一权限）的参数。

同样可以理解，第一SDK的包名是指第一SDK的数据包的包名，数据包是通信传输中的数据单位，数据包包含发送者和接收者的地址信息以及数据包的包名，数据包的包名用于标识该数据包，本申请实施例中，第一SDK的包名用于标识第一SDK的数据包。

本申请实施例可以通过获取第一API的调用栈，在调用栈中获取第一SDK的数据包，API的调用栈中包含发起调用请求的第一SDK的数据包的包名，获取第一API的调用栈的实现方式可以参考上文实施例，此处不作限定，本申请实施对获取第一SDK的数据包的方式不作限定。

S203、电子设备根据第一APP的上下文参数、第一权限参数和第一SDK的包名，确定鉴权结果，鉴权结果用于指示第一API允许或禁止被第一SDK调用。

本申请实施例，电子设备根据第一APP的上下文参数、第一权限参数和第一SDK的包名，确定鉴权结果的实现方式可以为：电子设备根据第一APP的上下文参数和第一权限参数，确定第一授权结果，第一授权结果用于指示第一APP被授予第一权限；根据第一授权结果和第一SDK的包名，确定第二授权结果，以根据第二授权结果确定鉴权结果，第二授权结果用于指示第一SDK是否被授予第一权限。

实现中，首先，电子设备根据第一APP的上下文参数可以获取第一APP的包名、第一APP的用户标识等数据，关于获取第一APP的包名和第一APP的用户标识的实现方式可以参考上文实施例，此处不再赘述。

其次，电子设备根据第一APP的包名、第一APP的用户标识和第一权限参数可以确定用户是否对第一APP授予第一权限。

示例性的，请参考图9，电子设备根据第一APP的包名、第一APP的用户标识和第一权限参数可以在图9示出的树结构中定位到第三层级中第一权限参数（譬如权限参数1）对应的授权结果，根据授权结果可以确定用户是否对第一APP授权第一权限。

授权结果有三种情况，请参考图7，图7中权限参数1对应的授权结果分为“假”、“真”和“每次询问”，授权结果为假，可以确定用户未对第一APP授予第一权限，授权结果为真，可以确定用户对第一APP授予第一权限，授权结果为每次询问，需要弹窗询问用户是否对第一APP授权第一权限，并根据用户的选择更新图7的授权结果，如果用户选择对第一APP授予第一权限，那么，将授权结果中的“每次询问”更新为“真”，并且可以确定用户对第一APP授予第一权限，如果用户未对第一APP授予第一权限，那么，将授权结果“每次询问”更新为“假”，并且可以确定用户未对第一APP授予第一权限，如果用户依然选择每次询问，那么，不更新授权结果，可以确定用户对第一APP授予第一权限。

本申请实施例，将用户对第一APP授予第一权限的授权结果称为第一授权结果。

然后，在确定用户对第一APP授予第一权限的情况下，根据第一SDK的包名确定用户是否对第一SDK授予特定权限。

示例性的，请再次参考图9，在第三层级权限状态为权限参数1对应的第四层级定位包含第一SDK的包名（SDK1）的SDK状态，并在该SDK状态中确定SD1的包名对应的授权结果，根据授权结果可以确定用户是否对第一SDK授予第一权限。

授权结果有三种情况，请参考图8，图8中权限参数1下SDK1对应的授权结果分为“假”、“真”和“每次询问”，授权结果为假，可以确定用户未对第一SDK授予第一权限，授权结果为真，可以确定用户对第一SDK授予第一权限，授权结果为每次询问，需要弹窗询问用户是否对第一SDK授权第一权限，并根据用户的选择更新图8中SDK1对应的授权结果，如果用户选择对第一SDK授予第一权限，那么，将授权结果中的“每次询问”更新为“真”，并且可以确定用户对第一APP授予第一权限，如果用户未对第一SDK授予第一权限，那么，将授权结果“每次询问”更新为“假”，并且可以确定用户未对第一SDK授予第一权限，如果用户依然选择每次询问，那么，不更新授权结果，可以确定用户对第一SDK授予第一权限。

本申请实施例将用户对第一SDK授予第一权限和用户未对第一SDK授予第一权限的授权结果称为第二授权结果。

最后，根据第二授权结果确定鉴权结果。

应理解，假设第二授权结果为用户对第一SDK授予第一权限，鉴权结果可以是通过鉴权，那么第一SDK被鉴定具有第一权限，第一SDK可以调用第一API，假设第二授权结果为用户未对第一SDK授予第一权限，鉴权结果可以是未通过鉴权，那么第一SDK被鉴定不具有第一权限，第一SDK无法调用第一API。

本申请实施例，相对于以APP为管控粒度的权限管控方案，只能鉴定API允许或禁止被APP调用，可以确定调用请求是由SDK生成的，以及确定的鉴权结果用于指示API允许或禁止被SDK调用，也就是说，本申请实施例可以鉴定APP中的SDK是否可以调用API，提升了用户体验；

而且，在鉴权结果指示API允许被SDK调用的情况下，SDK调用API，在鉴权结果指示API禁止被SDK调用的情况下，禁止SDK调用API，可以根据鉴定结果管控APP中的SDK，其中，在鉴权结果指示API禁止被SDK调用的情况下，禁止SDK调用API，避免了SDK借助APP的权限调用API，降低了APP潜在的安全风险，提升了APP的安全性，提升了用户体验；

并且，本申请实施例，可以根据第一APP的上下文参数和第一权限参数，确定用于指示第一APP被授予第一权限的第一授权结果，那么，根据第一授权结果，在第一APP发起调用请求的情况下，第一APP可以基于第一权限调用第一API；随后，根据第一授权结果和第一SDK的包名，确定用于指示第一SDK是否被授予第一权限的第二授权结果，以根据第二授权结果确定用于指示第一API允许或禁止被第一SDK调用的鉴权结果，即在第一APP被授予第一权限的情况下，可以确定第一SDK是否被授予第一权限，在确定第一SDK未被授予第一权限的情况下，确定的鉴权结果用于指示第一API禁止被第一SDK调用，也就是说，本申请可以在第一APP基于第一权限调用第一API时，禁止第一APP中的第一SDK调用第一API，相对于相关方案中APP基于权限调用API时，APP中的SDK也会基于相同权限调用API，可以提升用户体验。

在其他实施例中，电子设备包括框架层，框架层包括鉴权模块、活动管理模块和权限管理模块，电子设备根据第一APP的上下文参数、第一权限参数和第一SDK的包名，确定鉴权结果的实现方式还可以为：

鉴权模块向活动管理模块发送第一APP的上下文参数、第一权限参数和第一SDK的包名；活动管理模块向权限管理模块发送第一APP的上下文参数、第一权限参数和第一SDK的包名；权限管理模块根据第一APP的上下文参数和第一权限参数，确定第一授权结果；权限管理模块根据第一授权结果和第一SDK的包名，确定第二授权结果；权限管理模块向活动管理模块返回第二授权结果；活动管理模块向鉴权模块返回第二授权结果；鉴权模块根据第二授权结果确定鉴权结果。

应理解，鉴权模块、活动管理模块和权限管理模块可以参考图2或图7或图8或图10示出的相关模块，本申请实施例对此不作限定。关于鉴权模块、活动管理模块和权限管理模块的定义和相关解释可以参考上文实施例，此处不再赘述。

关于实现本申请实施例的具体实现方式可以参考图8或图10中记载的实现方式，此处不再赘述。

以下实施例介绍了权限管理模块中维护的树结构。

权限管理模块配置用于记载授权结果的树结构，树结构用于指示用户状态、用户身份证明状态、权限状态和SDK状态的层级关系，用户状态为第一层级，第一层级用于指示树结构，用户身份证明状态为第二层级，第二层级用于指示至少一个APP的用户身份证明，至少一个APP包括第一APP，权限状态为第三层级，第三层级包括第一候选授权结果，第一候选授权结果用于指示至少一个权限参数是否被授权的授权结果，至少一个权限参数包括至少一个APP中每个APP对应的权限参数，至少一个权限参数包括第一权限参数，SDK状态为第四层级，第四层级包括第二候选授权结果，第二候选授权结果用于指示至少一个SDK是否被授权的授权结果，至少一个SDK包括至少一个权限参数中每个权限参数对应的SDK，至少一个SDK包括第一SDK。

示例性的，请参考图9，树结构可以是由有限节点组成的具有四层层次关系的集合，第一层级为用户状态（UserState），第一层级可以被认为是树结构的根节点，第一层级用于指示树结构，也就是说，确定用户状态便可定位到树结构，确定用户状态的实现方式可以参考上文实施例，此处不再赘述。

第二层级为用户身份证明状态（UIDState），第二层级可以被认为是树结构的子节点，第二层级中包括至少一个APP的用户身份证明，例如：图9示出的APP1为APP1的UID、APP2为APP2的UID等，至少一个APP中包名第一APP，例如，第一APP为APP1。

第三层级为权限状态（permissionState），第三层级可以被认为是树结构的子节点，第三层级中包括第二层级中每个APP对应的至少一个权限参数，例如：图9示出的APP1对应权限参数1、权限参数2和权限参数3，APP2对应权限参数4和权限参数5，权限状态中还包括用户对至少一个权限参数的授权结果， 例如：用户对权限参数1、权限参数2、权限参数3、权限参数4和权限参数5的授权结果，这些授权结果可以是假（false）、真（true）、或者每次询问（ask everytime），其中，授权结果为假，代表用户未对APP授权，授权结果为真，代表用户对APP授权，授权结果为每次询问，代表本次APP申请特定权限时，用户对该次申请的APP授权，以后APP申请特定权限时，每次询问是否对APP授权，本申请实施例将用户对至少一个权限参数的授权结果称为第一候选授权结果。至少一个权限参数包括第一权限参数，比如第一权限参数为权限参数1。

第四层级为SDK状态（SDK State），第四层级可以被认为是树结构的叶子节点，第四层级中包括第三层级中每个权限参数对应的至少一个SDK的包名，以及对至少一个SDK的授权结果。例如：图9示出的第三层级包括权限参数1和权限参数2两个权限参数，权限参数1对应SDK1的包名和SDK2的包名，权限参数2对应SDK3的包名，权限参数3对应SDK4的包名和SDK5的包名，权限参数4对应SDK6的包名，权限参数5对应SDK7的包名和SDK8的包名，每个SDK的包名均对应一个对SDK的授权结果。授权结果可以是假（false）、真（true）、或者每次询问（ask everytime）。其中，授权结果为假，代表用户未对SDK授权，授权结果为真，代表用户对SDK授权，授权结果为每次询问，代表本次SDK申请特定权限时，用户对该次申请的SDK授权，以后SDK申请特定权限时，每次询问是否对SDK授权，本申请实施例将用户对至少一个SDK的授权结果称为第二候选授权结果。至少一个SDK包括第一SDK，例如，第一SDK可以是SDK1。

本申请实施例，权限管理模块中配置的树结构具有四层层级关系，第四层级中包括用于指示至少一个SDK是否被授权的第二候选授权结果，相对于相关方案中具有三层层级关系的树结构，本申请可以在第四层级中确定SDK是否被授权，并且，通过本申请提供的树结构，可以使电子设备快速、便捷的确定SDK是否被授权，以尽快禁止或允许SDK调用API，降低用户的感知程度，提升用户体验。

在一些实施例中，S203中确定鉴定结果的实现方式还可以为：

电子设备根据第一APP的用户标识，确定用户状态，用户状态用于定位树结构的第一层级，第一APP的上下文参数用于指示第一APP的用户标识；根据第一APP的用户标识和第一APP的包名，确定第一APP的用户身份证明，第一APP的上下文参数还用于指示第一APP的包名；在第二层级的至少一个APP的用户身份证明中确定第一APP的用户身份证明；根据第一权限参数和第一APP的用户身份证明，在第三层级的第一候选授权结果中确定第一授权结果；根据第一授权结果和第一SDK的包名，在第四层级的第二候选授权结果中确定第二授权结果，以根据第二授权结果确定鉴权结果。

应理解，根据第一APP的用户标识，确定用户状态的实现方式已在上文实施例中陈述，此处不再赘述，根据第一APP的用户标识和第一APP的包名，确定第一APP的用户身份证明的实现方式也可以参考其他实施例，此处不再赘述。根据第二授权结果确定鉴权结果的实现方式可以参考其他实施例，此处不再赘述。

以下示例性的说明本实施例的实现方式：

请参考图9，假设第一APP的UID是图9中的APP1，第一SDK的包名是图9中的SDK1，第一权限参数是图9中的权限参数1，SDK1向APP1发起调用请求，首先，确定用户状态即可定位到树结构，其次在第二层级中包括的APP1和APP2中查询是否存在APP1，在查询存在APP1的情况下即可确定APP1，在第三层级包括的APP1对应的权限参数1、权限参数2和权限参数3中查询是否存在权限参数1，权限参数1、权限参数2和权限参数3对应的授权结果被认为是第一候选授权结果，在查询存在权限参数1的情况下，查询权限参数1对应的授权结果，在查询到授权结果为用户对APP1授予权限参数1对应的权限的情况下即可在第一候选授权结果中确定第一授权结果，在第四层级包括的权限参数1对应的SDK1和SDK2中查询是否存在SDK1，SDK1和SDK2对应的授权结果被认为是第二候选授权结果，在查询到存在SDK1的情况下，查询SDK1对应的授权结果，即可在第二候选授权结果中确定第二授权结果，根据第二授权结果确定鉴权结果。

本申请实施例，可以依据用户标识、第一APP的包名、第一权限参数和第一SDK的包名等数据在第一层级、第二层级、第三层级和第四层级中通过逐层确定的方式确定第二授权结果，可以提高确定第二授权结果的速度，进而提高了根据第二授权结果确定的鉴权结果的速度，提升了电子设备的运行速度。

在一些实施例中，方法200还包括：

电子设备根据第一授权结果和第一SDK的包名，在第四层级的第二候选授权结果中未查询到第二授权结果的情况下，或者根据第一授权结果和第一SDK的包名，在第四层级的第二候选授权结果中查询到第二授权结果为每次询问的情况下，弹窗询问用户是否对第一SDK授予第一权限；根据用户选择将用户的第二授权结果记载在第四层级，用户选择包括允许、不允许和每次询问中的一种。

应理解，在以下情况中，需要弹窗询问用户是否对第一SDK授权于第一权限：

情况1：根据第一授权结果和第一SDK的包名，在第四层级的第二候选授权结果中未查询到第二授权结果的情况，这种情况可以理解为：请参考图9，第一授权结果可以从第三层级中权限参数1的授权结果中得到，在第四层级中的权限参数1对应的SDK状态中，包括SDK1的包名和对SDK1的授权结果，以及SDK2的包名和对SDK2的授权结果，SDK1的授权结果和SDK2的授权结果可以被认为是第二候选授权结果，假设在权限参数1对应的SDK状态中没有查询到SDK1的包名，也就认为在第四层级的第二候选授权结果中未查询到第二授权结果，这种情况也可以通俗理解为电子设备中新下载的APP，第一API发送调用请求之前，第一API未就“是否对第一API授予特定权限” 的问题询问过用户。

情况2：根据第一授权结果和第一SDK的包名，在第四层级的第二候选授权结果中查询到第二授权结果为每次询问的情况，这种情况可以理解为：请再次参考图9，SDK1的授权结果和SDK2的授权结果可以被认为是第二候选授权结果，假设在权限参数1对应的SDK状态中查询到SDK1的包名，但是查询到SDK1的包名对应的授权结果为每次询问，也就认为在第二候选授权结果中查询到第二授权结果为每次询问。

还应理解，在出现情况1时，需要在第四层级中新建SDK状态，SDK状态中包括第一SDK的包名和对第一SDK的授权结果（新建的授权结果中的数据为空），弹窗询问用户是否对第一SDK授予第一权限，例如，通过图3中的（d）示出的弹窗界面询问用户，如果用户选择“是”，将授权结果“真”写入第四层级，如果用户选择“否”，将授权结果“假”写入第四层级，如果用户选择“每次询问”，将授权结果“每次询问”写入第四层级。

在出现情况2时，可以弹窗询问用户是否对第一SDK授予第一权限，并根据用户选择在第四层级中更改第一SDK的授权结果，例如，通过图3中的（d）示出的弹窗界面询问用户，如果用户选择“是”，将授权结果由“每次询问”更改为“真”，如果用户选择“否”，将授权结果由“每次询问”更改为“假”，如果用户选择“每次询问”，不更改授权结果。

本申请实施例，可以在第四层级中未查询到第二授权结果的情况下，或者在第四层级中查询到第二授权结果，但是第二授权结果为每次询问的情况下，通过弹窗询问的方式，询问用户是否对第一SDK授予第一权限，并根据用户选择将第二授权结果记载在第四层级，可以使用户主动管控SDK的权限，由用户决定是否授予SDK权限，这样，避免了第三方SDK在用户无感知的情况下，借助APP权限调用API，提升了用户体验。

在一些实施例中，电子设备确定基于第一SDK生成的调用请求，包括：

电子设备获取第一API的调用栈；在第一API的调用栈中查询到存在第一SDK的包名的情况下，确定基于第一SDK生成的调用请求。

关于获取第一API的调用栈的方式可以参考上文实施例，此处不再赘述。

实现中，示例性的，在第一API的调用栈中查询是否存在第一SDK的包名，若存在第一SDK的包名，则确定是第一SDK向框架层发送调用请求，若不存在第一SDK的包名，则确定不是第一SDK向框架层发送调用请求。

在一些实施例中，确定基于第一软件开发工具包SDK生成的调用请求，包括：

电子设备获取SDK列表和第一API的调用栈；在第一API的调用栈中查询到存在SDK列表中的第一SDK的包名的情况下，确定基于第一SDK生成的调用请求。

应理解，SDK列表中包括至少一个SDK的包名，至少一个SDK的包名中包括第一SDK的包名，SDK列表可以参考表2，第一SDK的包名可以是SDK1的包名，SDK列表中保存着可能会发起私自收集用户隐私数据、劫持用户流量、静默安装恶意软件、静默安装病毒木马、推送恶意广告、消耗用户的套餐资费等敏感行为的SDK，也可以保存自身存在安全漏洞的SDK。

实现时，示例性的，在第一API的调用栈中查询是否存在SDK列表中的SDK的包名，在查询到存在SDK列表中的SDK的包名的情况下，确定调用请求是基于SDK发送的，例如，在查询到存在SDK列表中的第一SDK的包名的情况下，确定调用请求是基于第一SDK发送的。

在查询到不存在SDK列表中的SDK的包名的情况下，确定调用请求不是基于第一SDK发送的。

本申请实施例，由于可以在第一API的调用栈中查询是否存在SDK列表（SDK列表包括具有发起敏感行为的能力的SDK的包名和/或存在安全漏洞的SDK的包名）中的第一SDK的包名，以在查询到存在SDK列表中的第一SDK的包名的情况下，确定基于第一SDK生成的调用请求，从而确定生成调用请求的第一SDK具有发起敏感行为的能力和/或存在安全漏洞，在一种场景中，通过本申请实施例可以禁止具有发起敏感行为能力和/或存在安全漏洞的第一SDK调用第一API，实现对发起敏感行为和/或存在安全漏洞的第一SDK进行权限管控，提升了APP的安全性，提升了用户体验。

在一些实施例中，在S202之前，方法200还包括：

电子设备获取第一APP的包名和对应关系，对应关系用于指示N个APP的包名和N个管控结果的对应关系，一个APP的包名对应一个管控结果，一个管控结果用于指示一个APP是否被允许以SDK为管控粒度进行权限管控，N个APP包括第一APP，N为大于或等于1的整数；根据第一APP的包名和对应关系，确定第一管控结果，第一管控结果用于指示第一APP被允许以SDK为管控粒度进行权限管控。

应理解，获取第一APP的包名的实现方式可以参考其他实施例，此处不再赘述。对应关系可以参考表1中示出的APP的包名与管控结果的对应关系，第一APP可以是表1中的APP1，第一管控结果可以是表1中APP1对应的管控结果，例如：“允许”。对应关系可以保存在系统设置（SystemSettings）的数据库中，SystemSettings为系统数据库，里面存放的数据大多为系统的一些配置数据，还有可以包括一些其他数据信息，比如对应关系。电子设备可以从SystemSettings中获取到对应关系。

在其他实施例中，电子设备根据第一APP的包名和对应关系，确定第一管控结果的实现方式可以为：

电子设备根据第一APP的包名和对应关系，在对应关系中查询第一APP的包名对应的管控结果；在查询到第一APP的包名对应的管控结果为第一APP被允许以SDK为管控粒度进行权限管控的情况下，确定第一管控结果。

实现中，示例性的，电子设备根据APP1的包名，在对应关系中查询是否存在APP1的包名对应的管控结果，在查询到APP1的包名对应的管控结果为“允许”的情况下，确定用户允许API1以SDK为管控粒度对APP1进行权限管控，即可确定第一管控结果，在查询到APP1的包名对应的管控结果为“\”的情况下，弹窗询问用户是否允许API1以SDK为管控粒度对APP1进行权限管控，并依据询问结果更新APP1对应的管控结果，譬如，通过图3中的（b）示出的询问用户的方式弹窗询问用户是否以SDK为管控粒度对APP进行权限管控，并将询问依据询问结果更新APP1对应的管控结果，例如，用户点击图3中的（b）示出的“是”控件，更新APP1对应的管控结果为“允许”，此时，即可确定第一管控结果，用户点击图3中的（b）示出的“否”控件，更新APP1对应的管控结果为“禁止”。

本申请实施例，由于可以根据第一APP的包名和对应关系，确定用于指示第一APP被允许以SDK为管控粒度进行权限管控的第一管控结果，因而，相对于相关方案中对APP是以APP为管控粒度进行权限管控，本申请可以以SDK为管控粒度对APP进行权限管控，提升了用户体验。

在一些实施例中，方法200还包括：电子设备在对应关系中查询到不存在第一APP的包名对应的管控结果的情况下，或者在对应关系中查询到第一APP的包名对应的管控结果为第二管控结果的情况下，弹窗询问用户是否允许对第一APP以SDK为管控粒度进行权限管控，并将询问结果记载在对应关系，第二管控结果用于指示第一APP未被允许以SDK为管控粒度进行权限管控。

应理解，对应关系中不存在第一APP的包名对应的管控结果可以理解为：请参考表1，APP3的包名对应的管控结果为“\”，这种情况下，可以认为对应关系中不存在第一APP的包名对应的管控结果。该情况可以通俗理解为：在本次第一SDK向第一API发送调用请求之前，第一API还未就“是否允许对第一APP以SDK为管控粒度进行权限管控” 的问题询问过用户。

电子设备在对应关系中查询到不存在第一APP的包名对应的管控结果的情况下，弹窗询问用户是否允许对第一APP以SDK为管控粒度进行权限管控，并将询问结果写入对应关系中，关于弹窗询问的方式可以参考其他实施例，此处不再赘述。

还应理解，对应关系中第一APP的包名对应的管控结果为第二管控结果可以理解为：请参考表1，APP2的包名对应的管控结果为“禁止”，这种情况下，可以认为对应关系中第一APP的包名对应的管控结果为第二管控结果。

电子设备在对应关系中查询到第一APP的包名对应的管控结果为第二管控结果的情况下，弹窗询问用户是否允许对第一APP以SDK为管控粒度进行权限管控，并根据询问结果更新对应关系中第一APP对应的管控结果，关于弹窗询问的方式可以参考其他实施例，此处不再赘述。

应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

本申请实施例提供一种计算机程序产品，当所述计算机程序产品在电子设备运行时，使得电子设备执行上述实施例中的技术方案。其实现原理和技术效果与上述方法相关实施例类似，此处不再赘述。

本申请实施例提供一种可读存储介质，所述可读存储介质包含指令，当所述指令在电子设备运行时，使得所述电子设备执行上述实施例的技术方案。其实现原理和技术效果类似，此处不再赘述。

本申请实施例提供一种芯片，所述芯片用于执行指令，当所述芯片运行时，执行上述实施例中的技术方案。其实现原理和技术效果类似，此处不再赘述。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线（例如同轴电缆、光纤、数字用户线（digital subscriber line，DSL））或无线（例如红外、无线、微波等）方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质（例如，软盘、硬盘、磁带）、光介质（例如，高密度数字视频光盘（digital video disc，DVD））、或者半导体介质（例如，固态硬盘（solid state disk，SSD））等。

应理解，说明书通篇中提到的“实施例”意味着与实施例有关的特定特征、结构或特性包括在本申请的至少一个实施例中。因此，在整个说明书各个实施例未必一定指相同的实施例。此外，这些特定的特征、结构或特性可以任意适合的方式结合在一个或多个实施例中。应理解，在本申请的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

还应理解，在本申请中，“当…时”、“若”以及“如果”均指在某种客观情况下UE或者基站会做出相应的处理，并非是限定时间，且也不要求UE或基站实现时一定要有判断的动作，也不意味着存在其它限定。

本领域普通技术人员可以理解：本申请中涉及的第一、第二等各种数字编号仅为描述方便进行的区分，并不用来限制本申请实施例的范围，也表示先后顺序。

本申请中对于使用单数表示的元素旨在用于表示“一个或多个”，而并非表示“一个且仅一个”，除非有特别说明。本申请中，在没有特别说明的情况下，“至少一个”旨在用于表示“一个或者多个”，“多个”旨在用于表示“两个或两个以上”。

本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况，其中A可以是单数或者复数，B可以是单数或者复数。

本文中术语“……中的至少一个”或“……中的至少一种”，表示所列出的各项的全部或任意组合，例如，“A、B和C中的至少一种”，可以表示：单独存在A，单独存在B，单独存在C，同时存在A和B，同时存在B和C，同时存在A、B和C这六种情况，其中A可以是单数或者复数，B可以是单数或者复数，C可以是单数或者复数。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参见前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备（可以是个人计算机，服务器，或者网络设备等）执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器（read-only memory，ROM）、随机存取存储器（random access memory，RAM）、磁碟或者光盘等各种可以存储程序代码的介质。

本申请中各个实施例之间相同或相似的部分可以互相参考。在本申请中各个实施例、以及各实施例中的各个实施方式/实施方法/实现方法中，如果没有特殊说明以及逻辑冲突，不同的实施例之间、以及各实施例中的各个实施方式/实施方法/实现方法之间的术语和/或描述具有一致性、且可以相互引用，不同的实施例、以及各实施例中的各个实施方式/实施方法/实现方法中的技术特征根据其内在的逻辑关系可以组合形成新的实施例、实施方式、实施方法、或实现方法。以上所述的本申请实施方式并不构成对本申请保护范围的限定。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准总之，以上所述仅为本申请技术方案的较佳实施例而已，并非用于限定本申请的保护范围。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (11)

1.一种应用程序的权限管控方法，应用于电子设备，所述电子设备包括框架层，所述框架层包括鉴权模块、活动管理模块和权限管理模块，其特征在于，所述权限管理模块配置用于记载授权结果的树结构，所述树结构用于指示用户状态、用户身份证明状态、权限状态和SDK状态的层级关系，所述用户状态为第一层级，所述第一层级用于指示所述树结构，所述用户身份证明状态为第二层级，所述第二层级用于指示至少一个APP的用户身份证明，所述至少一个APP包括第一APP，所述权限状态为第三层级，所述第三层级包括第一候选授权结果，所述第一候选授权结果用于指示至少一个权限参数是否被授权的授权结果，所述至少一个权限参数包括所述至少一个APP中每个APP对应的权限参数，所述至少一个权限参数包括第一权限参数，所述SDK状态为第四层级，所述第四层级包括第二候选授权结果，所述第二候选授权结果用于指示至少一个SDK是否被授权的授权结果，所述至少一个SDK包括所述至少一个权限参数中每个权限参数对应的SDK，所述至少一个SDK包括第一SDK，所述方法包括：

响应于对第一应用程序APP的触发事件，确定基于第一软件开发工具包SDK生成的调用请求，所述第一APP中配置所述第一SDK，所述触发事件用于指示所述第一SDK向第一应用程序编程接口API发送调用请求；

根据所述调用请求，获取所述第一APP的上下文参数、第一权限参数和所述第一SDK的包名，所述第一APP的上下文参数用于指示所述第一APP的全局信息，所述第一权限参数为第一API待鉴定的权限参数；

所述鉴权模块向所述活动管理模块发送所述第一APP的上下文参数、所述第一权限参数和所述第一SDK的包名；所述活动管理模块向所述权限管理模块发送所述第一APP的上下文参数、所述第一权限参数和所述第一SDK的包名；所述权限管理模块根据所述第一APP的上下文参数和所述第一权限参数，确定第一授权结果；所述权限管理模块根据所述第一授权结果和所述第一SDK的包名，确定第二授权结果；所述权限管理模块向所述活动管理模块返回所述第二授权结果；所述活动管理模块向所述鉴权模块返回所述第二授权结果；所述鉴权模块根据所述第二授权结果确定鉴权结果，所述鉴权结果用于指示所述第一API允许或禁止被所述第一SDK调用。

2.根据权利要求1所述的方法，其特征在于，所述根据所述第一APP的上下文参数和所述第一权限参数，确定第一授权结果，包括：

根据所述第一APP的用户标识，确定所述用户状态，所述用户状态用于定位所述树结构的所述第一层级，所述第一APP的上下文参数用于指示所述第一APP的用户标识；

根据所述第一APP的用户标识和所述第一APP的包名，确定所述第一APP的用户身份证明，所述第一APP的上下文参数还用于指示所述第一APP的包名；

在所述第二层级的所述至少一个APP的用户身份证明中确定所述第一APP的用户身份证明；

根据所述第一权限参数和所述第一APP的用户身份证明，在所述第三层级的所述第一候选授权结果中确定所述第一授权结果；

所述根据所述第一授权结果和所述第一SDK的包名，确定第二授权结果包括：

根据所述第一授权结果和所述第一SDK的包名，在所述第四层级的所述第二候选授权结果中确定所述第二授权结果。

3.根据权利要求1或2所述的方法，其特征在于，所述方法还包括：

根据所述第一授权结果和所述第一SDK的包名，在所述第四层级的所述第二候选授权结果中未查询到所述第二授权结果的情况下，或者根据所述第一授权结果和所述第一SDK的包名，在所述第四层级的所述第二候选授权结果中查询到所述第二授权结果为每次询问的情况下，弹窗询问用户是否对所述第一SDK授予所述第一权限；

根据用户选择将用户的所述第二授权结果记载在所述第四层级，所述用户选择包括允许、不允许和每次询问中的一种。

4.根据权利要求1或2所述的方法，其特征在于，所述确定基于第一软件开发工具包SDK生成的调用请求，包括：

获取SDK列表和所述第一API的调用栈，所述SDK列表中包括至少一个SDK的包名，所述至少一个SDK的包名中包括所述第一SDK的包名，所述至少一个SDK为具有发起敏感行为的能力的SDK和/或存在安全漏洞的SDK；

在所述第一API的调用栈中查询到存在所述SDK列表中的所述第一SDK的包名的情况下，确定基于所述第一SDK生成的调用请求。

5.根据权利要求1或2所述的方法，其特征在于，在所述根据所述调用请求，获取所述第一APP的上下文参数、第一权限参数和所述第一SDK的包名之前，所述方法还包括：

获取所述第一APP的包名和对应关系，所述对应关系用于指示N个APP的包名和N个管控结果的对应关系，一个APP的包名对应一个管控结果，所述一个管控结果用于指示一个APP是否被允许以SDK为管控粒度进行权限管控，所述N个APP包括第一APP，N为大于或等于1的整数；

根据所述第一APP的包名和对应关系，确定第一管控结果，所述第一管控结果用于指示所述第一APP被允许以SDK为管控粒度进行权限管控。

6.根据权利要求5所述的方法，其特征在于，所述根据所述第一APP的包名和对应关系，确定第一管控结果，包括：

根据所述第一APP的包名和所述对应关系，在所述对应关系中查询所述第一APP的包名对应的管控结果；

在查询到所述第一APP的包名对应的管控结果为所述第一APP被允许以SDK为管控粒度进行权限管控的情况下，确定所述第一管控结果。

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

在所述对应关系中查询到不存在所述第一APP的包名对应的管控结果的情况下，或者在所述对应关系中查询到所述第一APP的包名对应的管控结果为第二管控结果的情况下，弹窗询问用户是否允许对所述第一APP以SDK为管控粒度进行权限管控，并将询问结果记载在所述对应关系，所述第二管控结果用于指示所述第一APP未被允许以SDK为管控粒度进行权限管控。

8.根据权利要求5所述的方法，其特征在于，所述对应关系保存在系统设置的数据库中。

9.一种电子设备，其特征在于，包括：

一个或多个处理器；

一个或多个存储器；

所述一个或多个存储器存储有一个或者多个计算机程序，所述一个或者多个计算机程序包括指令，当所述指令被所述一个或多个处理器执行时，使得所述电子设备执行如权利要求1至8中任一项所述的方法。

10.一种计算机可读存储介质，其特征在于，包括计算机指令，当所述计算机指令在电子设备上运行时，使得所述电子设备执行如权利要求1至8中任一项所述的方法。

11.一种芯片，其特征在于，所述芯片包括：

存储器，用于存储指令；

处理器，用于从所述存储器中调用并运行所述指令，使得安装有所述芯片的电子设备执行如权利要求1至8中任一项所述的方法。