CN114969709A - 权限控制方法及装置 - Google Patents

Abstract

本申请提供一种权限控制方法及装置，涉及终端技术领域，能够解决组件权限授予窗口过大，使得系统存在潜在的安全风险的问题。该方法应用于电子设备，该电子设备包括多个应用，该方法包括：电子设备确定第一应用的第一组件调用第二应用的第二组件以访问电子设备的系统资源，第一应用以及第二应用属于多个应用。电子设备根据预设策略确定第二组件具备应用程序接口API权限，允许第二组件访问系统资源，API权限为访问系统资源所需要的权限。电子设备确定第二组件访问系统资源结束，撤回第二组件的API权限。

Description

权限控制方法及装置

技术领域

本申请涉及终端技术领域，尤其涉及一种权限控制方法及装置。

背景技术

当前操作系统(例如：安卓(android)、IOS)的权限控制模型是多方面以及多层次的，例如：应用程序接口(application programming interface，API)权限、文件系统权限、进程间通信(inter-process communication，IPC)权限等。其中，API权限用于控制访问高层次的功能，应用程序只有请求相应的API权限才能访问敏感的用户数据(例如：联系人、短信等)。

应用程序是由各种组件，例如：活动(activity)、服务(service)、广播接受者(broadcast receiver)、内容提供者(content provider)等构成的。如果启动某个组件需要申请某个API权限，需要在开发阶段先在应用程序的配置文件中定义清楚启动该组件所需要的API权限。当该组件被启动时，只有系统授权该API权限之后才可以正常启动该组件。

目前，该API权限授予的方式都是基于应用程序的用户名(user identifier，UID)来授予的，即启动该组件所需要的API权限会被授予该组件所在的应用程序。而且该权限一旦被授予之后长期有效，因此使得组件的权限授予窗口过大，导致系统存在潜在的安全风险。但是在现有技术中并没有给出任何相关方案来解决该技术问题。

发明内容

本申请提供一种权限控制方法及装置，能够实现API权限的更小化授权，增强操作系统的安全性。

第一方面，本申请提供一种权限控制方法，该方法应用于电子设备，电子设备包括多个应用，该方法包括：电子设备确定第一应用的第一组件调用第二应用的第二组件以访问电子设备的系统资源，第一应用以及第二应用属于多个应用。电子设备根据预设策略确定第二组件具备第一应用程序接口API权限，允许第二组件访问系统资源，API权限为访问系统资源所需要的权限。电子设备确定第二组件访问系统资源结束，撤回第二组件的API权限。

基于上述技术方案，跨应用组件间调用时，被调用的组件不真正拥有权限，只有当被调用时才会临时有权限访问资源，调用结束之后该组件的权限被收回，确保了组件的权限更小化管控，增强了系统安全保护能力。

一种可能的设计中，电子设备根据预设策略确定第二组件具备API权限，包括：若电子设备确定调用第二组件的目标组件所在的应用具备API权限，则确定第二组件具备API权限。其中，目标组件为包括目标子调用链路的调用链路中的首个组件，目标子调用链路为第一组件调用第二组件的调用链路，调用链路是由多个组件之间链式调用构成的一条调用链路。

基于上述技术方案，实现了基于“首调者+被调者”的调用链路权限控制，被调用的组件不真正拥有权限，只有当被调用时才会临时有权限访问资源，调用结束之后该组件的权限被收回，权限授予时间窗口更小化，确保了组件权限的更小化管控，增强了系统的安全保护能力。并且实现了基于组件的权限管理，管理对象更细粒度，权限控制对象更小化。

一种可能的设计中，在电子设备确定调用第二组件的目标组件所在的应用具备API权限，允许第二组件访问系统资源之前，该方法还包括：电子设备确定第一组件的调用链路信息不存在，第一组件的调用链路信息包括第三应用的第三组件调用第一组件的调用链路，第三应用属于多个应用。电子设备确定第一组件为调用第二组件的目标组件。

一种可能的设计中，在电子设备确定第一组件为调用第二组件的目标组件之后，该方法还包括：电子设备生成第一标识信息、包括目标子调用链路的调用链路信息、以及第二组件的API权限授予记录，第一标识信息用于指示第一组件为目标组件。基于该设计，系统记录组件的权限授予记录，做到恶意行为可追溯，增强了系统的安全保护能力。

一种可能的设计中，在电子设备确定调用第二组件的目标组件所在的应用具备API权限，允许第二组件访问系统资源之前，该方法还包括：电子设备确定第一组件的调用链路信息存在，第一组件的调用链路信息包括第三应用的第三组件调用第一组件的调用链路，第三应用属于多个应用。电子设备根据第一组件的调用链路信息确定调用第二组件的目标组件。

一种可能的设计中，该方法还包括：若电子设备确定调用第二组件的目标组件所在的应用不具备API权限，则向用户请求授予调用第二组件的目标组件所在的应用API权限。

一种可能的设计中，该方法还包括：电子设备确定第一应用和/或第二应用被卸载，则更新第二组件的调用链路信息，以及第二组件的API权限授予记录。基于该设计，系统动态更新组件的权限授予记录，做到了恶意行为可追溯。

一种可能的设计中，电子设备根据预设策略确定第二组件具备API权限，包括：电子设备确定第二组件为后台组件，且第一应用具备API权限，则确定第二组件具备API权限，后台组件为无用户界面UI交互的组件。

基于上述技术方案，实现了基于“调用者+被调者”的调用链路权限控制，前台组件单独授权，授权责任主体界面清晰，且系统不用记录调用链路信息，相对授权模式比较简单。后台组件被调用时由于自身无UI界面，用户无法感知，因此系统检查调用者的权限，后台组件临时拥有权限，调用结束之后该组件的权限被收回，对消费者来说易于理解。

一种可能的设计中，该方法还包括：若电子设备确定第二组件为后台组件，且第一应用不具备API权限，则向用户请求授予第一应用API权限。基于该设计，使得只有在用户同意授予第一应用权限之后，该组件才有权限访问系统资源，增强了系统的安全保护能力。

一种可能的设计中，电子设备根据预设策略确定第二组件具备第一应用程序接口API权限，允许第二组件访问系统资源之前，该方法还包括：若电子设备确定第二组件的实例不存在，则创建第二组件的实例。基于该设计，使得只有存在第二组件的实例的情况下，第一组件才可以成功调用第二组件，保证了组件调用的成功率。

第二方面，本申请提供一种电子设备，该电子设备包括：多个应用，一个或多个处理器，存储器，显示屏，以及一个或多个计算机程序。其中一个或多个计算机程序被存储在存储器中，一个或多个计算机程序包括指令。当指令被电子设备执行时，使得电子设备执行：确定第一应用的第一组件调用第二应用的第二组件以访问电子设备的系统资源，第一应用以及第二应用属于多个应用。根据预设策略确定第二组件具备API权限，允许第二组件访问系统资源，API权限为访问系统资源所需要的权限。确定第二组件访问系统资源结束，撤回第二组件的API权限。

一种可能的设计中，当指令被电子设备执行时，使得电子设备执行：若确定调用第二组件的目标组件所在的应用具备API权限，则确定第二组件具备API权限。其中，目标组件为包括目标子调用链路的调用链路中的首个组件，目标子调用链路为第一组件调用第二组件的调用链路，调用链路是由多个组件之间链式调用构成的一条调用链路。

一种可能的设计中，当指令被电子设备执行时，使得电子设备执行：确定第一组件的调用链路信息不存在，第一组件的调用链路信息包括第三应用的第三组件调用第一组件的调用链路，第三应用属于多个应用。确定第一组件为调用第二组件的目标组件。

一种可能的设计中，当指令被电子设备执行时，使得电子设备执行：生成第一标识信息、包括目标子调用链路的调用链路信息、以及第二组件的API权限授予记录，第一标识信息用于指示第一组件为目标组件。

一种可能的设计中，当指令被电子设备执行时，使得电子设备执行：确定第一组件的调用链路信息存在，第一组件的调用链路信息包括第三应用的第三组件调用第一组件的调用链路，第三应用属于多个应用。根据第一组件的调用链路信息确定调用第二组件的目标组件。

一种可能的设计中，当指令被电子设备执行时，使得电子设备执行：若确定调用第二组件的目标组件所在的应用不具备API权限，则向用户请求授予调用第二组件的目标组件所在的应用API权限。

一种可能的设计中，当指令被电子设备执行时，使得电子设备执行：确定第一应用和/或第二应用被卸载，则更新第二组件的调用链路信息，以及第二组件的API权限授予记录。

一种可能的设计中，当指令被电子设备执行时，使得电子设备执行：确定第二组件为后台组件，且第一应用具备API权限，则确定第二组件具备API权限，后台组件为无用户界面UI交互的组件。

一种可能的设计中，当指令被电子设备执行时，使得电子设备执行：若确定第二组件为后台组件，且第一应用不具备API权限，则向用户请求授予第一应用API权限。

一种可能的设计中，当指令被电子设备执行时，使得电子设备执行：若确定第二组件的实例不存在，则创建第二组件的实例。

第三方面，本申请提供一种电子设备，该电子设备具有实现如上述第一方面及其中任一设计提供的权限控制方法的功能。该功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。该硬件或软件包括一个或多个与上述功能相对应的模块。

第四方面，本申请提供一种计算机存储介质，包括计算机指令，当所述计算机指令在电子设备上运行时，使得电子设备执行如上述第一方面及其中任一设计中所述的权限控制方法。

第五方面，本申请提供一种计算机程序产品，当计算机程序产品在电子设备上运行时，使得电子设备执行如上述第一第一方面及其中任一设计中所述的权限控制方法。

第六方面，本申请提供一种电路系统，电路系统包括处理电路，处理电路被配置为执行如上述第一方面及其中任一设计所述的权限控制方法。

第七方面，本申请提供一种芯片系统，包括至少一个处理器和至少一个接口电路，至少一个接口电路用于执行收发功能，并将指令发送给一个处理器，当至少一个处理器执行指令时，至少一个处理器执行上述如第一方面及其中任一设计所述的权限控制方法。

需要说明的是，上述第二方面至第七方面中任一设计所带来的技术效果可以参见第一方面中对应设计所带来的技术效果，此处不再赘述。

附图说明

图1为本申请实施例提供的一种现有的权限控制架构图；

图2为本申请实施例提供的又一种现有的权限控制架构图；

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

图4为本申请实施例提供的一种电子设备的硬件示意图；

图5为本申请实施例提供的一种权限控制方法流程示意图；

图6为本申请实施例提供的又一种权限控制方法流程示意图；

图7a为本申请实施例提供的又一种权限控制方法流程示意图；

图7b为本申请实施例提供的又一种权限控制方法流程示意图；

图8为本申请实施例提供的一种权限控制逻辑示意图；

图9为本申请实施例提供的一种权限控制架构示意图；

图10为本申请实施例提供的又一种权限控制方法流程示意图；

图11为本申请实施例提供的又一种权限控制逻辑示意图；

图12a为本申请实施例提供的一种应用场景示意图；

图12b为本申请实施例提供的又一种应用场景示意图；

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

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

图15为本申请实施例提供的一种芯片系统的结构示意图。

具体实施方式

在本申请的描述中，除非另有说明，“/”表示“或”的意思，例如，A/B可以表示A或B。本文中的“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。此外，“至少一个”是指一个或多个，“多个”是指两个或两个以上。“第一”、“第二”等字样并不对数量和执行次序进行限定，并且“第一”、“第二”等字样也并不限定一定不同。

需要说明的是，本申请中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其他实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。

为了便于本领域技术人员理解，下面先对一些技术术语进行介绍。

1、组件

组件是应用系统的基本构成单元，组件之间可以相互交互，同时又各自承担不同的功能。消费者产品的操作系统(例如android、IOS等)的应用程序大多是由这些零散的有联系的组件构成。例如android系统的主要四大组件有：活动(activities)、服务(services)、广播接受者(broadcast receivers)、内容提供者(content providers)，一个android应用可以由android系统的主要四大组件构成。

前台组件：有用户界面(user interface，UI)交互的组件，如：android系统中的activity，本文称之为前台组件。

后台组件：后台运行的无UI交互界面的组件，如：android系统中的service，本文称为为后台组件。

公共组件：能够被多个应用调用的组件，本文称之为公共组件。

引用调用：跨应用组件间进行调用时，从体验上用户感知到是在同一个应用内的组件间调用，本文称之为引用调用。例如：对于无用户交互界面的组件(如：android系统中的service)只能是引用调用。

跳转调用：跨应用组件间进行调用时，从体验上用户能感知到应用间的跳转的组件间调用，本文称之为跳转调用。

2、API权限

当前操作系统的权限控制模型是多方面以及多层次的，例如：API权限、文件系统权限、IPC权限等。

其中，API权限用于控制访问高层次的功能，比如系统敏感资源等。例如，在android系统中一些常见的访问用户敏感数据的API权限有发送短信(send_sms)、读取联系人(read_contacts)、相机(camera)等。应用必须请求相应的API权限才能访问敏感的用户数据(例如联系人和短信)以及某些系统功能(例如相机和互联网)。

请求API权限的方式有两种，一种是系统自动授权，另一种是提示用户批准请求。至于具体采用何种方式，取决于访问的功能。但是在默认的情况下，任何应用都没有权限执行会对其他应用、操作系统或用户带来不利影响的任何操作。

目前操作系统的API权限的授予都是基于UID的，也即权限都是授予了应用。例如：一个应用被授予了网络(internet)权限，那么该应用的UID会被添加到inet用户组，在inet用户组的成员具有打开af_inet套接字的能力，也即该应用具有打开af_inet套接字的能力。而能够打开af_inet套接字是更高层次API功能(例如：创建HttpURLConnection对象)所必须的。

3、沙箱(sandbox)

默认情况下，一个应用程序是可以访问机器上的所有资源的，比如CPU、内存、文件系统、网络等等。但是这是不安全的，如果随意操作资源，有可能破坏其他应用程序正在使用的资源，或者造成数据泄漏。沙箱是为执行中的程序提供隔离环境的一种安全机制。它通过严格控制执行的程序所访问的资源，以确保系统的安全。

在android系统中，应用(通常)都在一个独立的沙箱中运行，即每一个android应用程序都在它自己的进程中运行，都拥有一个独立的Dalvik虚拟机实例。Dalvik虚拟机经过优化，允许在有限的内存中同时高效地运行多个Dalvik虚拟机的实例，并且每一个android应用程序作为一个独立的Linux进程执行。

其中，android沙箱模型包括：

(1)应用程序在独立的进程

应用程序进程之间，应用程序与操作系统之间的安全性由Linux操作系统的标准进程级安全机制实现。在默认状态下，应用程序之间无法交互，运行在进程沙箱内的应用程序没有被分配权限，无法访问系统或资源。android是一个多用户系统，每个应用是一个独立的用户。系统为每个应用分配一个唯一的用户标识(UID)，并为应用中所有文件设置该用户才能访问的权限。每个进程中有一个独立的虚拟机(VM)。每个应用在自己的进程中运行，应用的组件需要执行时，系统创建该进程；当系统内存不存时，系统会销毁该进程。

(2)应用程序在同一个进程(共享UID)

android应用程序运行在它们自己的Linux进程上，并被分配一个唯一的UID。默认情况下，运行在基本沙箱进程中的应用程序没有被分配权限，因而防止了此类应用程序访问系统或资源。但是android应用程序可以通过应用程序的manifest文件请求权限。通过做到以下两点，android应用程序可以允许其他应用程序访问它们的资源：1)声明适当的manifest权限；2)与其他受信任的应用程序运行在同一进程中，从而共享对其数据和代码的访问。android系统提供一种所谓共享UID(shared user ID)机制，使具备信任关系的应用程序可以运行于同一进程空间。通常，这种信任关系由应用程序的数字签名确定，并且需要应用程序在manifest文件中使用相同的UID。

以上是对本申请实施例所涉及到的技术术语的介绍，以下不再赘述。

如图1所示，为本申请提供的一种现有的权限控制方法。

目前，android系统中的权限级别包括：

(1)低风险(normal)级别：只要申请了就可以使用(例如：通过在androidmanifest.xml中添加<uses-permission>标签来申请)，安装时不需要用户确认。

(2)高风险(dangerous：)级别：安装时需要用户的确认才可使用。

(3)签名(signature)级别：只有当申请权限的应用程序的数字签名与声明此权限的应用程序的数字签名相同时(如果是申请系统权限，则需要与系统签名相同)，才能将权限授给该应用。

(4)系统/签名(signature or system)级别：签名相同，或者申请权限的应用为系统应用(在system image中)。

在android系统中，API权限都是授予给独立的应用。应用通过沙箱机制进行数据隔离，系统的敏感资源如摄像头、麦克风等都是以服务接口提供给应用进行访问的。该服务接口都配置了对应的接口权限(API权限)。如果一个应用需要访问这些服务接口时，需要在该应用的配置文件(例如：andriodmanifest.xml)中配置要申请的接口权限，当应用运行访问接口时，系统会处理该配置文件，如果确定该接口权限为高风险(dangrous)级别，则需要通过用户授权之后，授予该应用对应的权限。

如图1所示，APP1和APP2之间分别通过沙箱1和沙箱2进行隔离，APP1和APP2之间无法交互，并且运行在进程沙箱1和沙箱2的应用程序在没有被分配权限的情况下，无法访问系统资源或数据。若是APP1或者APP2想要访问某个接口，需要在自己的配置文件中配置好需要申请的接口权限。后续在APP1或者APP2访问该接口时，系统通过处理该应用程序的配置文件，向用户请求授予该应用程序对应的接口权限。

在图1所示的权限控制方法中，在APP1的组件调用APP2的组件时，请求用户授予的接口权限会被授予给APP2。因此，被调用的组件权限授予持久化，即一次授权，长期有效。只有当APP2被卸载或者用户手动撤销APP2被授予的权限时，该权限才会被撤销。但是实际上只有组件被调用运行某个高层次API功能时才会申请该权限。因此，在图1所示的方案中，组件的权限授予时间窗口过大，应用可能会在用户不感知的情况下，恶意调用系统的敏感资源，导致信息的泄露，使得系统存在潜在的安全风险。

如图2所示，为本申请提供的又一种现有的权限控制方法。

以社交应用为例进行说明，社交应用的小程序在该应用的沙箱内进行进程级隔离。所谓进程级隔离是指将不同的软件进程隔离开来，防止它们访问自己不具备的内存空间。

进程级隔离通过为某些程序提供不同级别的权限，限制这些程序可以使用的内存。进程级隔离的基本操作是给一个进程或程序分配一个明确定义的虚拟地址空间。这个空间包含程序和所有相关数据。如果进程需要更多的空间，则向操作系统申请，如果可用则分配。通过这种方式，操作系统可以防止两个进程意外或有意地访问对方的内存。

进程级隔离的目的是允许程序运行，同时确保不影响重要系统，防止程序试图访问操作系统的关键区域，并修改或更改它们。

进程级隔离可以分配处理权限，使进程可以访问系统中的特定资源，同时保护其他资源。还可以通过某些操作使得不同的进程相互之间进行安全的通信，但仍然可以保持进程间相互独立。通过IPC和共享内存等机制，进程可以交换信息，但仍然可以被限制在自己的内存空间内。

示例性的，小程序A和小程序B在社交应用的沙箱内进程级隔离，小程序A是不可以随意访问小程序B的资源和数据的。小程序A要想访问其他小程序内的资源和数据，要通过微信访问控制，被授权后才可以获取其他小程序内的资源和数据。

示例性的，如果社交应用中的小程序要访问系统资源或数据，还需要通过经过系统级别的访问控制，被授权之后，才可以获取系统资源或数据。也即，小程序A要想访问系统资源或数据，需要双重授权，只有当小程序和该社交应用都被授予权限之后才可以获取系统资源或数据。

在图2所示的方案中，在应用的沙箱内采用进程级别的隔离，与图1所示方案中的应用级别的隔离相比，由于社交应用有权限访问任意小程序内的数据，因此，安全风险较高，权限控制粒度比较粗。

因此，为了解决上述技术问题，本申请实施例提供了一种权限控制方法，该方法应用于电子设备。该电子设备可以是手机、平板电脑、可穿戴设备、增强现实(augmentedreality，AR)/虚拟现实(virtual reality，VR)设备、笔记本电脑、超级移动个人计算机(ultra-mobile personal computer，UMPC)、上网本、个人数字助理(personal digitalassistant，PDA)等，本申请实施例对此不作任何限制。

以该电子设备为手机为例，如图3所示，该手机100包括多个应用，例如：微信、微博、相机等。

如图4所示，为该手机100的具体结构。该手机100包括射频(radio frequency，RF)电路110、存储器120、输入单元130、一个或多个传感器140、处理器150、电源160、显示单元170、音频电路180等部件。本领域技术人员可以理解，图4中示出的手机结构并不构成对手机的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

下面分别对手机100的各功能组件进行介绍：

其中，RF电路110可用于收发信息或通话过程中，信号的接收和发送，特别地，将基站的下行信息接收后，给处理器150处理；另外，将上行的数据发送给基站。通常，RF电路110不限于天线、至少一个放大器、收发信机、耦合器、低噪声放大器(low noise amplifier，LNA)、双工器等。此外，RF电路110还可以通过无线通信与网络和其他设备通信。所述无线通信可以使用任一通信标准或协议，包括但不限于全球移动通讯系统(global system ofmobile communication，GSM)、通用分组无线服务(general packet radio service，GPRS)、码分多址(code division multiple access，CDMA)、宽带码分多址(wideband codedivision multiple access，WCDMA)、长期演进(long term evolution，LTE)、电子邮件、短消息服务(short messaging service，SMS)等。

存储器120可用于存储软件程序以及模块，该处理器150通过运行存储在存储器120的软件程序以及模块，从而执行手机100的各种功能应用以及数据处理。存储器120可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(Application，APP)等，比如声音播放功能、图像播放功能等；存储数据区可存储根据手机100的使用所创建的数据(比如音频数据、图像数据、电话本等)等。此外，存储器120可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。

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

传感器140包括用于进行生物特征识别的传感器，如指纹识别传感器、人脸识别传感器以及虹膜识别传感器等。以指纹识别传感器为例，指纹识别传感器能够采集用户的指纹信息并将采集的指纹信息上报给处理器150，处理器150根据该指纹信息对用户进行身份识别。

传感器140还包括重力传感器(gravity sensor)，可以检测手机在各个方向上(一般为三轴)加速度的大小，静止时可检测出重力的大小及方向，可用于识别手机姿态的应用(比如横竖屏切换、相关游戏、磁力计姿态校准)、振动识别相关功能(比如计步器、敲击)等。

手机100还可以包括其它传感器，比如光传感器。具体地，光传感器可包括环境光传感器及接近光传感器。其中，环境光传感器可根据环境光线的明暗来调节显示面板131的亮度；接近光传感器可以检测是否有物体靠近或接触手机，可在手机100移动到耳边时，关闭显示面板131和/或背光。手机100还可配置的陀螺仪、气压计、湿度计、温度计、红外线传感器等其他传感器，在此不再赘述。

显示单元170可用于显示由用户输入的信息或提供给用户的信息以及手机100的各种菜单。显示单元170可包括显示面板171，可选的，可以采用液晶显示器(liquidcrystal display，LCD)、有机发光二极管(organic light-emitting diode,OLED)等形式来配置显示面板171。进一步的，触摸屏131可覆盖显示面板171，当触摸屏131检测到在其上或附近的触摸操作后，传送给处理器150以确定触摸事件的类型，随后处理器150根据触摸事件的类型在显示面板171上提供相应的视觉输出。虽然在图4中，触摸屏131与显示面板171是作为两个独立的部件来实现手机100的输入和输入功能，但是在某些实施例中，可以将触摸屏131与显示面板171集成而实现手机100的输入和输出功能。

音频电路180、扬声器191、麦克风192可提供用户与手机100之间的音频接口。音频电路180可将接收到的音频数据转换后的电信号，传输到扬声器191，由扬声器191转换为声音信号输出；另一方面，麦克风192将收集的声音信号转换为电信号，由音频电路180接收后转换为音频数据，再将音频数据输出至RF电路110以发送给比如另一手机，或者将音频数据输出至存储器120以便进一步处理。

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

手机100还包括给各个部件供电的电源160(比如电池)，可选的，电源可以通过电源管理系统与处理器150逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。

尽管未示出，手机100还可以包括天线、无线保真(wireless-fidelity，WiFi)模块、近距离无线通信(near field communication，NFC)模块、蓝牙模块、扬声器、加速计、陀螺仪等。

此外，本申请实施例描述的应用场景是为了更加清楚的说明本申请实施例的技术方案，并不构成对于本申请实施例提供的技术方案的限定，本领域普通技术人员可知，随着新业务场景的出现，本申请实施例提供的技术方案对于类似的技术问题，同样适用。

如图5所示，为本申请实施例提供的一种权限控制方法，应用于图3所示的电子设备中，该方法包括：

S101、电子设备确定第一应用的第一组件调用第二应用的第二组件以访问电子设备的系统资源。

其中，第一应用以及第二应用属于电子设备中已安装的多个应用。示例性的，第一应用可以是微信，第二应用可以是联系人。可选的，电子设备的系统资源是系统的敏感资源，例如：联系人、短信、相机、互联网等。本申请对系统资源的具体内容不作限定。

S102、电子设备根据预设策略确定第二组件具备第一应用程序接口API权限，允许第二组件访问系统资源。

其中，API权限为访问所述系统资源所需要的权限。预设策略为系统预先设定的基于“首调者+被调者”的调用链路的权限控制策略，或者基于“调用者+被调者”的调用链路的权限控制策略。

示例性的，系统会将API权限传入ContextCompat.checkSelfPermission()方法中。根据应用是否具备该权限，此方法会返回permission_granted或者permission_denied。permission_granted代表应用具备该权限，permission_denied代表应用不具备该权限。电子设备可以通过这种方法根据预设策略来间接判定第二组件是否具备API权限。

在电子设备根据permission_granted确定第二组件具备API权限之后，该组件可以成功通过第一API接口访问系统资源。反之，在电子设备根据permission_denied确定第二组件不具备API权限之后，不会允许该组件第一API接口访问系统资源。只有在该组件被用户授予API权限之后，该组件才可以成功访问系统资源。

S103、电子设备确定第二组件访问系统资源结束，撤回第二组件的API权限。

应理解，所谓“撤回”第二组件的API权限，指的是第二组件是被临时授予了API权限，该API权限并不是一次授予长久有效，一旦该组件利用该API权限访问系统资源结束，系统会收回授予给该组件的API权限。也就是说，只有在第一应用的第一组件调用第二应用的第二组件访问系统资源的过程中，该第二组件临时拥有API权限。但是在第二组件访问系统资源结束，也即该调用过程结束之后，第二组件就不再拥有API权限。因此，在其他时间，第二组件在没有被授权的情况下，是没有权限访问系统资源的。

基于该方案，跨应用组件间调用时，被调用的组件不真正拥有访问资源的权限，只有当被调用时才会临时被赋予访问资源的权限，调用结束之后该组件的权限被收回，确保了组件的权限更小化管控，增强了系统的安全保护能力。

如图6所示，图5中的步骤S102可以具体实现为以下步骤：

S201、若电子设备确定调用第二组件的目标组件所在的应用具备API权限，则确定第二组件具备API权限。

其中，目标组件为包括目标子调用链路的调用链路中的首个组件，目标子调用链路为第一组件调用第二组件的调用链路，调用链路是由多个组件之间链式调用构成的一条调用链路。

示例性的，APP1的组件1调用APP2的组件2，APP2的组件2调用APP3的组件3，APP3的组件3调用APP4的组件4，用“{APP1：组件1}→{APP2：组件2}→{APP3：组件3}→{APP4：组件4}”表示，这就是一条调用链路。

以本申请实施例中的第一组件为组件3、第二组件为组件4为例，那么APP3的组件3调用APP4的组件4构成的调用链路用“{APP3：组件3}→{APP4：组件4}”表示，那么“{APP3：组件3}→{APP4：组件4}”为“{APP1：组件1}→{APP2：组件2}→{APP3：组件3}→{APP4：组件4}”的子调用链路。

组件1为组件4的目标组件，如果组件3调用组件4访问系统资源，组件4需要具备P1权限才可以访问系统资源，那么电子设备确定组件1所在的APP1具备P1权限，则可以确定组件4具备P1权限。

可选的，在存在多个目标组件的情况下，如果其中一个目标组件所在的应用具备API权限，则可以确定第二组件具备API权限。

示例性的，还是以本申请实施例中的第一组件为组件3、第二组件为组件4为例。假设，在组件3存储有多条包括目标子调用链路的调用链路，例如“{APP1：组件1}→{APP2：组件2}→{APP3：组件3}→{APP4：组件4}、{APP2：组件2}→{APP3：组件3}→{APP4：组件4}、{APP5：组件5}→{APP3：组件3}→{APP4：组件4}等”。那么组件1、组件2、组件5都是组件4的目标组件。只要组件1和/或组件2和/或组件5具备API权限，就可以确定组件4具备API权限。

此外，目标组件也可以称为首调者，本申请对此不作限定。图6所示的方案适用于引用调用。基于该方案，实现了基于“首调者+被调者”的调用链路权限控制，只有当被调用的组件被调用时才会临时被赋予访问资源的权限，调用结束之后该组件的权限被收回，确保组件的权限更小化管控，增强了系统安全保护能力。实现了基于组件的权限管理，管理对象更细粒度，权限控制对象更小化，且组件不真正拥有持久化权限，只有被调用时进行授权，权限授予时间窗口更小化。

对于如何确定图6所示的第二组件的目标组件，可以通过图7a的步骤S301、步骤S302和图7b所示的方法实现。

一种可能的设计中，如图7a所示，在电子设备确定调用所述第二组件的目标组件所在的应用具备API权限，允许所述第二组件访问所述系统资源之前，该方法还包括以下步骤：

S301、电子设备确定第一组件的调用链路信息不存在。

其中，第一组件的调用链路信息包括第三应用的第三组件调用第一组件的调用链路，所述第三应用属于电子设备安装的多个应用。

示例性的，以第一组件为组件3，第二组件为组件4，第三组件为组件2为例，如果存在一条调用链路为“{APP2：组件2}→{APP3：组件3}→{APP4：组件4}”，那么第一组件的调用链路信息，也即组件3的调用链路信息包括“{APP2：组件2}→{APP3：组件3}”。

示例性的，以第一组件为组件3，第二组件为组件4，第三组件为组件2和组件1为例，如果存在一条调用链路为“{APP1：组件1}→{APP2：组件2}→{APP3：组件3}→{APP4：组件4}”，那么第一组件的调用链路信息，也即组件3的调用链路信息包括“{APP1：组件1}→{APP2：组件2}→{APP3：组件3}”。

应理解，上述第三应用可以指一个应用，也可以指多个不同的应用，第三组件可以指一个应用中的一个组件，也可以指多个应用中，每个应用中的一个组件。本申请实施例对此不作限定。

应理解，第一组件的调用链路信息不存在，意为不存在上述示例中所提到的调用链路信息。

S302、电子设备确定第一组件为调用第二组件的目标组件。

其中，在电子设备确定第一组件的调用链路信息不存在的情况下，也即在第一组件调用第二组件之前，没有其他的组件调用第一组件，则可以确定第一组件就是调用第二组件的目标组件，也即第一组件为第二组件的首调者。

其中，在电子设备根据上述步骤S301和步骤S302确定目标组件之后，该方法还包括以下步骤：

S303、电子设备生成第一标识信息、包括目标子调用的调用链路信息、以及第二组件的API权限授予记录。

其中，第一标识信息用于指示所述第一组件为目标组件。示例性的，电子设备可以通过生成令牌(token)的方式，作为目标组件的唯一身份标识，也即首调者的唯一身份标识。

第二组件的API权限授予记录指的是当前第二组件使用过哪些API权限访问系统资源。示例性的，以第一组件为组件1，第二组件为组件2，API权限为P1进行说明，则第二组件的API权限授予记录的形式可以如表一所示：

表一

	目标组件	授予权限集合
			组件2	组件1	P1

可选的，表一中的目标组件一列也可以用目标组件所在的应用表示，将组件换成组件所在的应用，本申请实施例对此不作限定。

其中，生成包括第一组件调用第二组件的调用链路的调用链路信息，也可以称为初始调用链路信息。

示例性的，以第一组件为组件2、第二组件为组件5为例，那么初始化的调用链路信息可以表示为“组件5：{init组件2}”。

基于该方案，系统记录组件的权限授予记录，使得恶意行为做到可追溯，增强了系统的安全保护能力。

另一种可能的设计中，如图7b所示，在电子设备确定调用所述第二组件的目标组件所在的应用具备API权限，允许所述第二组件访问所述系统资源之前，该方法还包括以下步骤：

S401、电子设备确定第一组件的调用链路信息存在。

其中，第一组件的调用链路信息包括第三应用的第三组件调用第一组件的调用链路，所述第三应用属于电子设备安装的多个应用。

示例性的，此处第一组件的调用链路信息与图7a步骤S301中所述的调用链路信息相同，第三应用以及第三组件的含义也相同，此处不再赘述。S402、电子设备根据第一组件的调用链路信息确定调用第二组件的目标组件。

示例性的，以上述第一组件为组件3，第二组件为组件4，第三组件为组件2为例的情况下，电子设备根据第一组件的调用链路信息，可以确定APP2的组件2为第二组件的目标组件。

以上述第一组件为组件3，第二组件为组件4，第三组件为组件2和组件1为例的情况下，电子设备根据第一组件的调用链路信息，可以确定APP1的组件1为第二组件的目标组件。

可选的，以第一组件为组件3，第二组件为组件4，第三组件为组件2和组件1为例，如果存在两条调用链路，分别为“{APP2：组件2}→{APP3：组件3}→{APP4：组件4}”和“{APP1：组件1}→{APP3：组件3}→{APP4：组件4}”，那么第一组件的调用链路信息，也即组件3的调用链路信息包括：“{APP2：组件2}→{APP3：组件3}”和“{APP1：组件1}→{APP3：组件3}”。

在该示例下，电子设备根据第一组件的调用链路信息确定调用第二组件的目标组件为APP2的组件2和APP1的组件1。可选的，其中一个目标组件所在的应用，也即APP1和/或APP2具备API权限，则可以确定第二组件具备API权限。

可选的，上述实施例中，还可以包括以下步骤S501和步骤S502(图中未示出)：

S501、若电子设备确定调用第二组件的目标组件所在的应用不具备API权限，则向用户请求授予调用第二组件的目标组件所在的应用API权限。

示例性的，电子设备在第二组件的界面弹出指示框，向用户请求授予第一应用第一API权限。

S502、电子设备确定第一应用和/或第二应用被卸载，则更新第二组件的调用链路信息，以及第二组件的API权限授予记录。

其中，更新第一组件的调用链路信息，意为，删除所有包括第二组件的调用链路信息。示例性的，以第一组件为组件3，第二组件为组件4为例，假设目前电子设备在组件3存储有多个调用链路信息，“{APP2：组件2}→{APP3：组件3}”、“{APP1：组件1}→{APP2：组件2}→{APP3：组件3}”。

在组件4也存储有多个调用链路信息，“{APP2：组件2}→{APP3：组件3}→{APP4：组件4}”、“{APP1：组件1}→{APP2：组件2}→{APP3：组件3}→{APP4：组件4}”、“{APP2：组件2}→{APP3：组件3}→{APP4：组件4}”、“{APP3：组件5}→{APP4：组件4}”。

可选的，本申请实施例的方案中会在每个组件都存储有各自作为被调者的调用链路信息，而不会存储该组件调用其他组件的调用链路信息。例如：在组件3会存储有“{APP2：组件2}→{APP3：组件3}”调用链路信息，而不会存储“{APP3：组件3}→{APP4：组件4}”调用链路信息。

一种可能的设计中，在第一应用被卸载，第二应用未被卸载的情况下，则组件3中的全部调用链路信息都会被删除，而组件4中包括组件3的调用链路信息会被删除，不包括组件3的调用链路信息不会被删除，示例性的，上述“{APP3：组件5}→{APP4：组件4}”调用链路信息不会被删除。

另一种可能的设计中，在第一应用未被卸载，第二应用被卸载的情况下，组件3中的调用链路信息不会被删除，而组件4中的全部调用链路信息都会被删除。

另一种可能的设计中，在第一应用以及第二应用都被卸载的情况下，组件3和组件4中的调用链路信息都会被删除。

更新第二组件的API的权限授予记录，指的是删除API权限授予记录中第二组件的API权限授予记录。

示例性的，以第一组件为组件3、第二组件为组件4为例，电子设备目前存储的第二组件的权限授予记录可以如表二所示：

表二

	目标组件	授予权限集合
			组件4	组件1	P1、P2、P3
组件4	组件2	P2、P3
			组件4	组件3	P1、P3
…

其中，表二中的授予权限集合，指的是对应的组件被授予了哪些API权限。示例性的，P1代表访问摄像头的API权限，P2代表读取联系人的API权限，P3代表访问短信资源的API权限。

可选的，表二中的目标组件一列也可以用目标组件所在的应用表示，将组件换成组件所在的应用，本申请实施例对此不作限定。

结合表二，一种可能的设计中，在第一应用被卸载，也即组件3所在的应用被卸载，第二应用未被卸载，也即组件4所在的应用未被卸载的情况下，更新第二组件的API的权限授予记录意味着，删除表二第四行的内容。

另一种可能的设计中，在第一应用未被卸载，也即组件3所在的应用未被卸载，第二应用被卸载，也即组件4所在的应用被卸载的情况下，表二的全部内容都被删除。

另一种可能的设计中，第一应用以及第二应用都被卸载的情况下，表二的全部内容被删除。

基于该方案，系统动态更新组件的权限授予记录，做到了恶意行为可追溯。

示例性的，为了便于理解本申请实施例提供的权限控制方法，如图8所示，为本申请实施例提供的一种权限控制逻辑示意图。该示意图采用图6、图7a和图7b所示的权限控制方法。

①组件1→组件4：意为组件1调用组件4，组件4已经在APP3的配置文件中声明需要的权限P1，此时组件1为调用组件4的目标组件，也即组件1是组件4的首调者。电子设备会检查组件1所在的应用APP1是否具备P1权限，如果APP1已经具备P1权限，则电子设备不会向用户请求授权，如果APP1不具备P1权限，则电子设备可以在组件4的界面弹出指示框，向用户请求授予APP1 P1权限。

②组件2→组件5：意为组件2调用组件5，组件5已经在APP3的配置文件中声明了需要的权限P1和P2，此时组件2调用组件5的目标组件，也即组件2是组件5的首调者。电子设备会检查组件2所在的应用APP1是否具备权限P1和P2。由于在步骤①中，APP1已经具备了P1权限，因此不用再向用户请求授予APP1 P1权限，组件5可以直接利用P1权限访问该权限所对应的接口。如果APP1具备P2权限，则电子设备不用向用户请求授予APP1 P2权限，如果APP1不具备P2权限，则电子设备在组件5界面弹出指示框，向用户请求授予APP1 P2权限。

③组件3→组件5：意为组件3调用组件5，组件5已经在APP3的配置文件中声明了需要的权限P1和P2，此时组件3为调用组件5的目标组件，也即组件3是组件5的首调者。电子设备会检查组件3所在的应用APP2是否具备权限P1和P1，如果APP2已经具备P1和P2权限，则电子设备不会向用户请求授权，如果APP2不具备P1和P2权限，则电子设备可以在组件5的界面弹出指示框，向用户请求授予APP2 P1和P2权限。

④组件4/组件5→组件6：意为组件4或5调用组件6，组件6已经在APP3的配置文件中声明了需要的权限P3，其中，在组件4调用组件6时，由于在这之前有组件1调用过组件4，则确定组件1为调用组件6的目标组件，也即组件1为组件6的首调者。此时电子设备会检查APP1是否具备P3权限，如果APP21已经具备P3权限，则电子设备不会向用户请求授权，如果APP1不具备P3权限，则电子设备可以在组件6的界面弹出指示框，向用户请求授予APP1 P3权限。

在组件5调用组件6时，由于在这之前组件2和组件3都调用过组件5，则确定组件2和组件3为调用组件6的目标组件，也即组件2和组件3都是组件6的首调者。此时电子设备会检查APP1和/或APP2的是否具备P3权限，只要其中一个具备P3权限，就不用向用户请求授权。如果都没有P3权限，则向用户请求授予APP1和/APP2 P3权限。

⑤组件6→组件8：意为组件6调用组件8。由于图6、图7a、图7b所示的权限控制方法适用于引用调用，而组件6调用组件8也为引用调用，因此组件6调用组件8时授权逻辑与④相同，都是通过判断目标组件的权限。在此不再进行赘述。

应理解，对于跨应用间组件调用时，该调用模式是引用调用还是跳转调用是由电子设备的自己来识别的。通常情况下，前台组件调用前台组件是跳转调用，但是也有可能是引用调用。前台组件调用后台组件为引用调用。

⑥组件6→组件7：意为组件6调用组件7。示例性的，由于组件6调用组件7为跳转调用，因此该调用不能再采用上述图6、图7a、图7b所示的权限控制方法。在该调用模式下，电子设备直接检查组件7所在的应用APP4是否具备组件7所需要的权限P1，如果具备，则不需要向用户请求授权。如果不具备，则需要在组件7的界面弹出指示框，向用户请求授予组件4P1权限。

如图9所示，为本申请是实施例提供的一种权限控制架构图，该架构图采用图6、图7a、图7b所示的权限控制方法。

该权限控制架构包括权限管理服务200和运行管理服务300。其中，权限管理服务200负责权限检查(例如：组件的权限、应用的权限)；对组件以及目标组件，也即组件和首调者的映射关系进行维护，记录组件的权限授予(使用)记录。运行管理服务300主要负责调用链路的初始化，调用链路的维护以及识别目标组件。

如图9所示，以第一应用为APP1，第二应用为APP3，第一组件为组件2，第二组件为组件5为例，进行说明，运行管理服务300包括组件启动模块310、启动管理模块320调用链路维护模块330。权限管理服务200包括权限查询模块210以及权限登记模块220。

应理解，权限管理服务和运行管理服务以及相关的功能模块仅仅是一个名称。并不构成对模块功能的限定，上述各模块的功能可以通过一个模块实现，也可以通过多个模块实现，本申请实施例对此不作限定。

(1)组件2调用组件5，启动接口拉起组件5，也即调用组件5。在不存在组件5的实例的情况下，运行管理服务300的组件启动模块310创建组件5的实例。

需要说明的是，在存在组件5的实例的情况下，需要根据具体情况来判断是否还需要创建组件5的实例。示例性的，在采用单实例的情况下，如果已经存在组件5的实例，则不需要再创建组件5的实例；如果不存在，则需要创建。在采用多实例的情况下，如果已经存在组件2调用组件5的实例，则不需要再创建组件2调用组件5的实例；如果不存在组件2调用组件5的实例，则需要创建组件2调用组件5的实例。

在组件2调用组件5的实例存在之后，运行管理服务300中的启动管理模块320会检查调用方，也即组件2是否存在调用链路信息。

一种可能的设计中，组件2不存在调用链路信息，则可以确定当前调用方，也即组件2为调用组件5的目标组件，也即组件2为组件5的首调者。启动管理模块320生成第一标识信息，例如：token，作为目标组件的唯一身份标识，并初始化调用链路信息。

可选的，对于第一标识信息，不同的调用链路，同一个目标组件的第一标识信息可以是相同的。例如：对于调用链路1“{APP1：组件1}→{APP2：组件2}→{APP3：组件3}→{APP4：组件4}”，组件1是组件4的目标组件。调用链路2“{APP1：组件1}→{APP3：组件3}→{APP2：组件2}”，组件1是组件2的目标组件。在调用链路1和调用链路2中组件1的第一标识信息可以同一个token。

可选的，对于第一标识信息，不同的调用链路，不同目标组件的第一标识信息可以是不同的。例如：调用链路3“{APP2：组件2}→{APP3：组件3}→{APP4：组件4}”，组件2是组件4的目标组件。调用链路2“{APP1：组件1}→{APP3：组件3}→{APP2：组件2}”，组件1是组件2的目标组件。调用链路1中的组件2的第一标识信息与调用链路2中组件1的第一标识信息可以是不同的token。

示例性的，初始化的调用链路信息可以用“组件5：{init组件2}”表示，或者“组件2→组件5”表示，用于指示组件2调用组件5的一条调用链路。

另一种可能的设计中，组件2存在调用链路信息，则可以根据组件2的调用链路信息确定组件5的首调者。例如：组件2的调用链路信息包括调用链路“{APP1：组件1}→{APP3：组件4}→{APP2：组件2}”，则可以确定组件1为组件5的目标组件。

启动管理模块320会更新调用方的调用链路信息到被调方，也即纪录组件2的调用链路信息到组件5，并以此作为组件5的调用链路信息的一部分。示例性的，记录到组件5的调用链路信息可以包括“{APP1：组件1}→{APP3：组件4}→{APP2：组件2}→{APP5：组件5}”调用链路。

(2)组件5访问系统资源API，API要受到权限控制。启动管理模块320调用权限管理服务200对组件5进行鉴权，也即，检查组件5是否具备访问该系统资源的API权限。管理服务200的权限查询模块会检查组件5的目标组件，并在权限授予记录中查询该目标组件(或者目标组件所在的应用)是否具备该API权限。如果具备，则允许该组件5访问该系统资源API。如果不具备，则在组件5的界面弹出指示框，向用户请求授予该目标组件所在的应用该API权限。

与此同时，权限管理服务200的权限登记模块220会记录组件5的权限授予纪录。该权限授予记录可以如表三所示。

表三

	目标组件	授予权限集合
			组件5	组件1	P1、P2
组件5	组件2	P2、P3
			组件5	组件3	P1、P3
…	…	…

(3)当组件2或者组件5被卸载，也即二者所在的应用被卸载的情况下，运行管理服务300会更新调用链路信息，权限管理服务200会更新权限授予记录。关于该情况下的具体描述，请参见上述步骤S502，再次不再进行赘述。

(4)组件3调用组件5时，调用逻辑参见组件2调用组件5的调用逻辑，在此不再进行赘述。

如图10所示，图5中的步骤S102还可以具备实现为以下步骤：

S601、电子设备确定第二组件为后台组件，且第一应用具备API权限，则确定第二组件具备API权限。

其中，所述后台组件为无用户界面UI交互的组件。

如图10所示的实施例中，只有被调用的组件为后台组件时，才判断调用该组件的组件所在的应用是否具备该组件所需要的权限来控制该组件对电子设备资源的访问。

可选的，在被调用的组件为前台组件时，电子设备会判断被调用的组件所在的应用是否具备该组件所需要的权限来控制该组件对电子设备资源的访问。

基于该方案，实现了基于“调用者+被调者”的调用链路权限控制，前台组件单独授权，授权责任主体界面清晰，且系统不用记录调用链路信息，相对授权模式比较简单。后台组件被调用时由于自身无UI界面，用户无法感知，因此系统检查调用者的权限，后台组件临时拥有权限，调用结束之后该组件的权限被收回，对消费者来说易于理解。

可选的，在图10所示的实施例中，还可以包括以下步骤：

S602、若电子设备确定第二组件为后台组件，且第一应用不具备API权限，则向用户请求授予所述第一应用API权限。

示例性的，电子设备可以在第一应用的界面，通过弹出指示框的形式，向用户请求授予第一应用API权限。

基于该方案，使得只有在用户同意授予第一应用权限之后，该组件才有权限访问系统资源，增强了系统的安全保护能力。

示例性的，为了便于理解本申请实施例提供的权限控制方法，如图11所示，为本申请实施例提供的另一种权限控制逻辑示意图。该示意图采用图10所示的权限控制方法。

①组件1→组件4：意为组件1调用组件4，组件1为前台组件，组件4为前台组件。组件4已经在APP3的配置文件中声明需要的权限P1，此时电子设备会检查组件4所在的应用APP3是否具备P1权限。如果APP3已经具备P1权限，则电子设备不会向用户请求授权，如果APP3不具备P1权限，则电子设备可以在组件4的界面弹出指示框，向用户请求授予APP3P1权限。

②组件2→组件5：意为组件2调用组件5，组件2为前台组件，组件5为前台组件。组件5已经在APP3的配置文件中声明了需要的权限P1和P2。电子设备会检查组件5所在的应用APP3是否具备权限P1和P2。由于在步骤①中，APP3已经具备了P1权限，因此不用再向用户请求授予APP3 P1权限，组件5可以直接利用P1权限访问该权限所对应的接口。如果APP3具备P2权限，则电子设备不用向用户请求授予APP3 P2权限，如果APP3不具备P2权限，则电子设备在组件5界面弹出指示框，向用户请求授予APP3 P2权限。

③组件3→组件5：意为组件3调用组件5，组件3为前台组件，组件5为前台组件。组件5已经在APP3的配置文件中声明了需要的权限P1和P2。电子设备会检查组件5所在的应用APP3是否具备权限P1和P1，由于在步骤①和②中，APP3已经被授予了权限P1和P2，则组件5可以直接利用该权限访问对应的接口。

④组件4/组件5→组件6：意为组件4或5调用组件6，组件6已经在APP3的配置文件中声明了需要的权限P3。其中，在组件4调用组件6时，组件4为前台组件，组件6为后台组件，此时电子设备会检查组件4所在的应用APP3是否具备P3权限。如果APP3具备P3权限，则电子设备不用向用户请求授予APP3 P3权限，如果APP3不具备P3权限，则电子设备在组件4界面弹出指示框，向用户请求授予APP3 P3权限。

在组件5调用组件6时，组件5为前台组件，组件6为后台组件，此时电子设备会检查组件5所在的应用APP3是否具备P3权限。如果APP3具备P3权限，则电子设备不用向用户请求授予APP3 P3权限，如果APP3不具备P3权限，则电子设备在组件5界面弹出指示框，向用户请求授予APP3 P3权限。

⑤组件5→组件8：意为组件5调用组件8。组件8已经在APP5的配置文件中声明了需要的权限P4。组件5为前台组件，组件8为后台组件，此时电子设备会检查组件5所在的应用APP3是否具备P4权限。如果APP3具备P4权限，则电子设备不用向用户请求授予APP3P4权限，如果APP3不具备P4权限，则电子设备在组件5界面弹出指示框，向用户请求授予APP3 P4权限。

⑥组件4→组件7：意为组件4调用组件7。组件7已经在APP4的配置文件中声明了需要的权限P1。组件4为前台组件，组件7为前台组件，此时电子设备会检查组件7所在的应用APP4是否具备P1权限。如果APP4具备P1权限，则电子设备不用向用户请求授予APP4P1权限，如果APP4不具备P1权限，则电子设备在组件7界面弹出指示框，向用户请求授予APP4 P1权限。

应理解，对于跨应用间组件调用时，上述所提到的各组件是前台组件还是后台组件是由系统自身来识别的。示例性的，在andriod系统中，会把一个activity识别为前台组件，把一个service识别为后台组件。

需要说明的是，上述实施例是在第一组件调用第二组件的实例已经存在情况下进行说明的，在第二组件的实例不存在的情况下，需要先创建第二组件的实例。

因此，在如图5所示的步骤S102之前，本申请实施例提供的权限控制方法还包括以下步骤：

S701、若所述电子设备确定所述第二组件的实例不存在，则创建所述第二组件的实例。

需要说明的是，一个公共组件被多个应用调用时可以启动多个实例运行，每个实例分配不同的UID，应用之间的数据通过沙箱进行隔离。也可以启动单个实例，以节省内存损耗。

如图12a所示，为多个应用调用一个公共组件时，启动多个实例的系统框架。在该系统框架下，各应用以及公共组件都具有自己的沙箱，以实现数据的隔离。例如APP1的沙箱1、APP2的沙箱2、公共组件所在的应用的沙箱3和沙箱4。该公共组件被不同的应用调用时，启动的实例要用单独的沙箱进行隔离。

如图12b所示，为多个应用调用一个公共组件时，启动单个实例的系统框架。在该系统框架下，各应用具有自己的沙箱，但是该公共组件被不同的应用调用时，启动的是一个实例，用一个沙箱进行隔离。

在该公共组件被应用调用访问系统资源(例如：摄像头、日历、位置)时，系统级别的访问控制服务可以采用图5所示的方法会对该公共组件的权限进行管控。

基于该方案，使得只有存在第二组件的实例的情况下，第一组件才可以成功调用第二组件，保证了组件调用的成功率。

上述主要是从方法的角度对本申请实施例提供的方案进行了介绍。可以理解的是，电子设备(例如手机、平板电脑、可穿戴设备等)为了实现上述功能，其包含了执行各个功能相应的硬件结构和/或软件模块。结合本申请中所公开的实施例描述的各示例的单元及算法步骤，本申请实施例能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。本领域技术人员可以对每个特定的应用来使用不同的方法来实现所描述的功能，但是这种实现不应认为超过本申请实施例的技术方案的范围。

本申请是实施例可以根据上述方法示例对电子设备进行功能模块的划分，例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理单元中。上述集成的单元既可以采用硬件的形式，也可以采用软件功能模块的形式实现。需要说明的是，本申请实施例中对单元的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。

如图13所示，为本申请实施例提供一种电子设备，该电子设备包括处理单元1302和通信单元1303。可选的，通信单元1303还可以划分为发送单元(并未在图13中示出)和接收单元(并未在图13中示出)。其中，发送单元，用于支持电子设备向其他网元发送信息。接收单元，用于支持电子设备从其他网元接收信息。

可选的，电子设备还包括存储单元1301，用于存储电子设备的程序代码和数据，数据可以包括但不限于原始数据或者中间数据等。

处理单元1302，可以支持电子设备根据预设策略判定第二组件是否具备API权限，控制第二组件访问系统资源，和/或本文中所描述的方案的其他过程。

其中，处理单元1301可以是控制器或图4所示的处理器150，例如可以是中央处理器(central processing unit，CPU)，通用处理器，数字信号处理(digital signalprocessing，DSP)，应用专用集成电路(application specific integrated circuit，ASIC)，现场可编程门阵列(field－programmable gate array，FPGA)或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框，模块和电路。处理器也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，DSP和微处理器的组合等等。通信单元1303可以是图4所示的RF电路110、还可以是收发电路等。存储单元1301可以是图4所示的存储器120。

当处理单元1302为处理器，通信单元1303为通信接口，存储单元1301为存储器时，本申请实施例所涉及的电子设备可以为图14所示。

参阅图14所示，该电子设备包括：处理器1402、通信接口1403、存储器1401。可选的，电子设备还可以包括总线1404。其中，通信接口1403、处理器1402以及存储器1401可以通过总线1404相互连接；总线1404可以是外设部件互连标准(peripheral componentinterconnect，PCI)总线或扩展工业标准结构(extended industry standardarchitecture，EISA)总线等。所述总线204可以分为地址总线、数据总线、控制总线等。为便于表示，图14中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

可选的，本申请实施例还提供一种计算机可读存储介质，所述计算机可读存储介质存储计算机指令，当该计算机指令在计算机上运行时，使得计算机执行上述实施例所介绍的方法。

可选的，本申请实施例还提供一种携带计算机指令的计算机程序产品，当该计算机指令在计算机上运行时，使得计算机执行上述实施例所介绍的方法。

本申请实施例还提供一种芯片系统，如图15所示，该芯片系统包括至少一个处理器1501和至少一个接口电路1502。处理器1501和接口电路1502可通过线路互联。例如，接口电路1502可用于从其它装置接收信号。又例如，接口电路1502可用于向其它装置(例如处理器1501)发送信号。示例性的，接口电路1502可读取存储器中存储的指令，并将该指令发送给处理器1501。当所述指令被处理器1501执行时，可使得电子设备执行上述实施例所介绍方法中的各个步骤。当然，该芯片系统还可以包含其他分立器件，本申请实施例对此不作具体限定。

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

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

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

通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在可读取的存储介质中，如计算机的软盘，硬盘或光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述的方法。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，在本申请揭露的技术范围内的变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (23)

1.一种权限控制方法，其特征在于，所述方法应用于电子设备，所述电子设备包括多个应用，所述方法包括：

所述电子设备确定第一应用的第一组件调用第二应用的第二组件以访问所述电子设备的系统资源，所述第一应用以及所述第二应用属于所述多个应用；

所述电子设备根据预设策略确定所述第二组件具备第一应用程序接口API权限，允许所述第二组件访问所述系统资源，所述API权限为访问所述系统资源所需要的权限；

所述电子设备确定所述第二组件访问所述系统资源结束，撤回所述第二组件的API权限。

2.根据权利要求1所述的方法，其特征在于，所述电子设备根据预设策略确定所述第二组件具备API权限，包括：

若所述电子设备确定调用所述第二组件的目标组件所在的应用具备API权限，则确定所述第二组件具备API权限；

其中，所述目标组件为包括目标子调用链路的调用链路中的首个组件，所述目标子调用链路为所述第一组件调用所述第二组件的调用链路，所述调用链路是由多个组件之间链式调用构成的一条调用链路。

3.根据权利要求2所述的方法，其特征在于，在所述电子设备确定调用所述第二组件的目标组件所在的应用具备API权限，允许所述第二组件访问所述系统资源之前，所述方法还包括：

所述电子设备确定所述第一组件的调用链路信息不存在，所述第一组件的调用链路信息包括第三应用的第三组件调用所述第一组件的调用链路，所述第三应用属于所述多个应用；

所述电子设备确定所述第一组件为调用所述第二组件的目标组件。

4.根据权利要求3所述的方法，其特征在于，在所述电子设备确定所述第一组件为调用所述第二组件的目标组件之后，所述方法还包括：

所述电子设备生成第一标识信息、包括目标子调用链路的调用链路信息、以及所述第二组件的API权限授予记录，所述第一标识信息用于指示所述第一组件为目标组件。

5.根据权利要求2所述的方法，其特征在于，在所述电子设备确定调用所述第二组件的目标组件所在的应用具备API权限，允许所述第二组件访问所述系统资源之前，所述方法还包括：

所述电子设备确定所述第一组件的调用链路信息存在，所述第一组件的调用链路信息包括第三应用的第三组件调用所述第一组件的调用链路，所述第三应用属于所述多个应用；

所述电子设备根据所述第一组件的调用链路信息确定调用所述第二组件的目标组件。

6.根据权利要求2-5任一项所述的方法，其特征在于，所述方法还包括：

若所述电子设备确定调用所述第二组件的目标组件所在的应用不具备API权限，则向用户请求授予调用所述第二组件的目标组件所在的应用API权限。

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

所述电子设备确定所述第一应用和/或所述第二应用被卸载，则更新所述第二组件的调用链路信息，以及所述第二组件的API权限授予记录。

8.根据权利要求1所述的方法，其特征在于，所述电子设备根据预设策略确定所述第二组件具备API权限，包括：

所述电子设备确定所述第二组件为后台组件，且所述第一应用具备API权限，则确定所述第二组件具备API权限，所述后台组件为无用户界面UI交互的组件。

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

若所述电子设备确定所述第二组件为后台组件，且所述第一应用不具备API权限，则向用户请求授予所述第一应用API权限。

10.根据权利要求1-9任一项所述的方法，其特征在于，所述电子设备根据预设策略确定所述第二组件具备第一应用程序接口API权限，允许所述第二组件访问所述系统资源之前，所述方法还包括：

若所述电子设备确定所述第二组件的实例不存在，则创建所述第二组件的实例。

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

多个应用；

一个或多个处理器；

存储器；

显示屏；

以及一个或多个计算机程序，其中所述一个或多个计算机程序被存储在所述存储器中，所述一个或多个计算机程序包括指令；当所述指令被所述电子设备执行时，使得所述电子设备执行：

确定第一应用的第一组件调用第二应用的第二组件以访问所述电子设备的系统资源，所述第一应用以及所述第二应用属于所述多个应用；

根据预设策略确定所述第二组件具备API权限，允许所述第二组件访问所述系统资源，所述API权限为访问所述系统资源所需要的权限；

确定所述第二组件访问所述系统资源结束，撤回所述第二组件的API权限。

12.根据权利要求11所述的电子设备，其特征在于，当所述指令被电子设备执行时，使得所述电子设备执行：

若确定调用所述第二组件的目标组件所在的应用具备API权限，则确定所述第二组件具备API权限；

其中，所述目标组件为包括目标子调用链路的调用链路中的首个组件，所述目标子调用链路为所述第一组件调用所述第二组件的调用链路，所述调用链路是由多个组件之间链式调用构成的一条调用链路。

13.根据权利要求12所述的电子设备，其特征在于，当所述指令被电子设备执行时，使得所述电子设备执行：

确定所述第一组件的调用链路信息不存在，所述第一组件的调用链路信息包括第三应用的第三组件调用所述第一组件的调用链路，所述第三应用属于所述多个应用；

确定所述第一组件为调用所述第二组件的目标组件。

14.根据权利要求13所述的电子设备，其特征在于，当所述指令被电子设备执行时，使得所述电子设备执行：

生成第一标识信息、包括目标子调用链路的调用链路信息、以及所述第二组件的API权限授予记录，所述第一标识信息用于指示所述第一组件为目标组件。

15.根据权利要求12所述的电子设备，其特征在于，当所述指令被电子设备执行时，使得所述电子设备执行：

确定所述第一组件的调用链路信息存在，所述第一组件的调用链路信息包括第三应用的第三组件调用所述第一组件的调用链路，所述第三应用属于所述多个应用；

根据所述第一组件的调用链路信息确定调用所述第二组件的目标组件。

16.根据权利要求12-15任一项所述的电子设备，其特征在于，当所述指令被电子设备执行时，使得所述电子设备执行：

若确定调用所述第二组件的目标组件所在的应用不具备API权限，则向用户请求授予调用所述第二组件的目标组件所在的应用API权限。

17.根据权利要求12-16任一项所述的电子设备，其特征在于，当所述指令被电子设备执行时，使得所述电子设备执行：

确定所述第一应用和/或所述第二应用被卸载，则更新所述第二组件的调用链路信息，以及所述第二组件的API权限授予记录。

18.根据权利要求11所述的电子设备，其特征在于，当所述指令被电子设备执行时，使得所述电子设备执行：

确定所述第二组件为后台组件，且所述第一应用具备API权限，则确定所述第二组件具备API权限，所述后台组件为无用户界面UI交互的组件。

19.根据权利要求18所述的电子设备，其特征在于，当所述指令被电子设备执行时，使得所述电子设备执行：

若确定所述第二组件为后台组件，且所述第一应用不具备API权限，则向用户请求授予所述第一应用API权限。

20.根据权利要求11-19任一项所述的电子设备，其特征在于，当所述指令被电子设备执行时，使得所述电子设备执行：

若确定所述第二组件的实例不存在，则创建所述第二组件的实例。

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

22.一种计算机程序产品，其特征在于，当所述计算机程序产品在计算机上运行时，使得所述计算机执行如权利要求1-10中任一项所述的权限控制方法。

23.一种芯片系统，其特征在于，包括至少一个处理器和至少一个接口电路，所述至少一个接口电路用于执行收发功能，并将指令发送给所述至少一个处理器，当所述至少一个处理器执行所述指令时，所述至少一个处理器执行如权利要求1-10任一项所述的权限控制方法。

Images