CN117473556A - Sdk的管理方法、设备及存储介质 - Google Patents

Abstract

本申请公开了一种SDK的管理方法、设备及存储介质，属于终端技术领域。所述方法包括：电子设备的操作系统设置有SDK沙盒，SDK沙盒若监听到第一应用集成的第一SDK调用第一系统接口的调用指令，则在第一系统接口不是第一SDK声明的权限所涉及的系统接口的情况下，对调用指令进行阻塞处理；SDK沙盒在第一系统接口是第一SDK声明的权限涉及的系统接口的情况下，对调用指令进行放行。如此，可以控制第一SDK无法成功调用未声明的权限所涉及的系统接口，进而无法通过未声明的权限获取用户隐私数据，提高了用户隐私数据的安全性。而且，该方案对原有SDK集成框架的兼容性较高。

Description

SDK的管理方法、设备及存储介质

技术领域

本申请涉及终端技术领域，特别涉及一种SDK的管理方法、设备及存储介质。

背景技术

随着终端技术的发展，终端可以安装多种多样的应用以供用户使用。很多应用都集成了第三方软件开发工具包（softwaredevelopmentkit，SDK），以通过集成的第三方SDK实现特定的业务需求，比如通过集成的地图SDK获取地图信息等。但是，目前很多第三方SDK有越权收集用户隐私数据的行为，比如在应用具有获取敏感数据权限的情况下，其集成的第三方SDK可以在未声明该权限的情况下直接继承应用的权限完成收集用户隐私数据的行为。

为了避免第三方SDK越权收集用户隐私数据，目前提出了一种对应用和SDK进行独立上架的解决方案。该解决方案中，由SDK开发人员通过SDK上传界面将SDK单独发布到应用商店，并由应用开发人员通过应用上传界面将应用单独发布到应用商店，然后由应用商店对应用及其相关SDK进行分发。其中，独立上架的APP集成的是SDK服务接口，而非SDK本身。在终端侧的应用安装完成后，在应用进程运行过程中，应用进程可以调用SDK服务接口，SDK服务接口被调用后可以跨越进程边界进入SDK管理进程，通过SDK管理进程调用SDK本身。这样，可以使得SDK作为一个独立的进程与应用进程分隔开来，以避免SDK通过继承应用的相关权限完成收集用户隐私数据的行为。

由于上述解决方案需要对SDK单独上架，因此将导致SDK的分发和管理更加复杂，而且不利于兼容原有SDK集成框架。

发明内容

本申请提供了一种SDK的管理、设备及存储介质，可以降低第三方SDK越权收集用户隐私数据的概率的基础上，且对原有SDK使用框架的兼容性较高。所述技术方案如下：

第一方面，提供了一种SDK的管理方法，该方法应用于电子设备中，电子设备的操作系统包括第一应用和SDK沙盒，第一应用集成有第一SDK，方法包括：

SDK沙盒若监听到第一SDK调用第一系统接口的调用指令，则在第一系统接口不是第一SDK声明的权限所涉及的系统接口的情况下，对调用指令进行阻塞处理；在第一系统接口是第一SDK声明的权限涉及的系统接口的情况下，对调用指令进行放行。

本申请实施例中，在操作系统中设置有SDK沙盒，可以通过SDK沙盒对应用中集成的第三方SDK调用系统接口的行为进行监控和管理。通过在第一系统接口不是第一SDK声明的权限所涉及的系统接口的情况下，对该调用指令进行阻塞处理，即不对该调用指令进行放行，可以使得第一SDK无法成功调用未声明的权限所涉及的系统接口，进而无法通过未声明的权限获取用户隐私数据，大大降低了第三方SDK越权收集用户隐私数据的可能性，提高了用户隐私数据的安全性。另外，通过在第一系统接口是第一SDK声明的权限所涉及的系统接口的情况下，对该调用指令进行放行，可以使得第一SDK可以正常调用声明的权限所涉及的系统接口，进而可以正常通过声明的权限获取所需数据，保障了SDK的正常运行。

相较于相关技术中提出的对APP和SDK独立上架的解决方案，本申请实施例提出的解决方案是在原有SDK集成框架实现的，仅需在电子设备的操作系统中额外设置具有对SDK调用系统接口的行为进行监控功能的SDK沙盒即可，无需对SDK单独上架，降低了SDK的分发和管理的复杂化，对原有SDK集成框架的兼容性较高。

在一些实施例中，在对调用指令进行阻塞处理之前，SDK沙盒可以先触发电子设备显示提示信息，该提示信息用于询问用户是否允许第一SDK调用第一系统接口。响应于用户的拒绝操作，SDK沙盒执行对调用指令进行阻塞处理的步骤。响应于用户的允许操作，SDK沙盒对调用指令进行放行。如此，可以进一步提高隐私保护的灵活性。

比如，在对该调用指令进行阻塞处理之前，可以先触发终端设备显示提示窗口，该提示窗口包括提示信息“第一应用集成的第一SDK正在调用第一系统接口，是否允许？”，以及同意选项和拒绝选项。用户可以通过点击同意选项允许第一SDK调用第一系统接口，通过点击拒绝选项不允许第一SDK调用第一系统接口。示例地，该提示窗口可以为弹窗等形式。

在一些实施例中，SDK沙盒可以维护接口权限信息，该接口权限信息用于指示与第一SDK声明的权限有关的系统接口和/或与第一SDK声明的权限有关的系统接口，即用于指示哪些系统接口与第一SDK声明的权限有关和/或哪些系统接口与第一SDK声明的权限无关。以便SDK沙盒可以在监听到第一SDK调用第一系统接口的调用指令时，根据该接口权限信息快速判断所调用的第一系统接口是否为第一SDK声明的权限涉及的系统接口，进而根据判断结果对该调用指令进行放行或阻塞处理。

通过针对待监控的SDK维护接口权限信息，便于根据接口权限信息快速和准确地判断所调用系统接口是否为待监控的SDK声明的权限所涉及的系统接口，提高了SDK的管理效率和准确性。

在一些实施例中，接口权限信息可以包括操作系统的多个系统接口的接口标识以及各个系统接口对应的标记信息，该标记信息用于指示对应系统接口是否为与第一SDK声明的权限相关的系统接口，这多个系统接口包括第一系统接口。比如，标记信息包括第一标记和第二标记，第一标记用于指示对应系统接口是与第一SDK声明的权限相关的系统接口，第二标记用于指示对应系统接口是与第一SDK声明的权限无关的系统接口。

这种情况下，根据该接口权限信息判断所调用的第一系统接口是否为第一SDK声明的权限涉及的系统接口可以包括：从接口权限信息中查找第一系统接口对应的标记信息（flag）；若第一系统接口对应的标记信息为第一标记，则确定第一系统接口是第一SDK声明的权限所涉及的系统接口；若第一系统接口对应的标记信息为第二标记，则确定第一系统接口不是第一SDK声明的权限所涉及的系统接口。

也即是，在对待监控的SDK进行监控的过程中，若监听到该SDK调用第一系统接口的调用指令，则根据第一系统接口查找接口权限信息，若第一系统接口对应的标记信息为第一标记，则对该调用指令进行放行，若第一系统接口对应的标记信息为第二标记，则对该调用指令进行阻塞处理。

作为一个示例，第一标识为true，第二标识为false。当然，第一标记和第二标记也可以为其他形式的标记信息，本申请实施例对此不做限定。

作为一个示例，接口权限信息可以通过对初始接口权限信息进行打标得到。初始接口权限信息包括多个系统接口的接口标识以及各个系统接口对应的初始标记信息（即默认标记信息），初始标记信息为第一标记。本申请实施例中，可以通过将这多个系统接口中与第一SDK声明的权限无关的系统接口的接口标记从默认的第一标记修改为第二标识的方式，来对这些系统接口进行打标，从而得到打标好的接口权限信息。

作为一个示例，该接口权限信息可以为列表形式，该接口权限信息还可以称为全局接口打标表，该全局接口打标表包括多个系统接口的接口标识以及各个系统接口对应的flag，flag=true或false，flag=true表示对应的系统接口是与第一SDK声明的权限相关的系统接口，flag=false表示对应的系统接口不是与第一SDK声明的权限相关的系统接口。

在一些实施例中，接口权限信息包括若干个第一接口的接口标识，这若干个第一接口为操作系统的多个系统接口中与第一SDK声明的权限相关的系统接口。

这种情况下，根据该接口权限信息判断所调用的第一系统接口是否为第一SDK声明的权限涉及的系统接口可以包括：根据第一系统接口查找该接口权限信息，如果接口权限信息包括的若干个第一接口中存在第一系统接口，则确定第一系统接口是第一SDK声明的权限所涉及的系统接口；如果接口权限信息包括的若干个第一接口中不存在第一系统接口，则确定第一系统接口不是第一SDK声明的权限所涉及的系统接口。

也即是，在对待监控的SDK进行监控的过程中，若监听到该SDK调用第一系统接口的调用指令，则根据第一系统接口查找接口权限信息，若接口权限信息中存在第一系统接口，则对该调用指令进行放行，若接口权限信息中不存在第一系统接口，则对该调用指令进行阻塞处理。

在一些实施例中，接口权限信息包括若干个第二接口的接口标识，若干个第二接口为操作系统的多个系统接口中与第一SDK声明的权限无关的系统接口。

这种情况下，根据该接口权限信息判断所调用的第一系统接口是否为第一SDK声明的权限涉及的系统接口可以包括：根据第一系统接口查找该接口权限信息，如果接口权限信息包括的若干个第二接口中存在第一系统接口，则确定第一系统接口不是第一SDK声明的权限所涉及的系统接口；如果接口权限信息包括的若干个第二接口中不存在第一系统接口，则确定第一系统接口是第一SDK声明的权限所涉及的系统接口。

也即是，在对待监控的SDK进行监控的过程中，若监听到该SDK调用第一系统接口的调用指令，则根据第一系统接口查找接口权限信息，若接口权限信息中不存在第一系统接口，则对该调用指令进行放行，若接口权限信息中存在第一系统接口，则对该调用指令进行阻塞处理。

在一些实施例中，操作系统的多个系统接口可以为操作系统的全部或部分系统接口，比如为多种权限涉及的系统接口。这多种权限可以为预设权限，比如预设权限为敏感权限（用于获取敏感数据的权限）。

在一些实施例中，SDK沙盒可以预先对第一应用的应用文件进行解析，根据解析结果来维护该接口权限信息。比如，预先对第一应用的应用文件进行解析，以确定第一SDK声明的权限，以及第一SDK涉及调用的系统接口；根据第一SDK声明的权限和第一SDK涉及调用的系统接口，确定与第一SDK声明的权限相关的系统接口和/或与第一SDK声明的权限无关的系统接口，根据确定结果来生成该接口权限信息。

其中，应用文件可以应用程序包，如安卓应用程序包（Android applicationpackage，APK）。

作为一个示例，若用户开启针对多个APP的SDK沙盒监控功能，则SDK沙盒可以排队扫描这多个APP的应用文件，每扫描到一个APP的应用文件，对扫描到的应用文件进行解析，根据解析结果维护APP集成的各个SDK对应的接口权限信息，以便根据各个SDK对应的接口权限信息对该SDK调用系统接口的行为进行监测和管理。

在一个实施例中，可以由应用开发人员在发布第一应用前，在第一应用的应用文件中额外添加权限配置信息，使得第一应用的应用文件包括权限配置信息、以及第一应用集成的各个SDK的可执行文件。应理解，第一应用的应用文件还可以包括其他所需信息。

其中，权限配置信息包括第一应用集成的各个SDK声明的权限。SDK声明的权限是指向用户告知的该SDK将会使用的权限。比如，权限配置信息包括第一应用集成的各个SDK的SDK标识以及声明的权限。在一个实施例中，应用开发者服务平台可以为应用开发人员提供权限配置信息的配置模板，以便开发人员按照该配置模板在开发的第一应用中添加权限配置信息。

需要说明的是，传统的应用文件并不包括权限配置信息，本申请实施例通过额外配置在应用文件中添加权限配置信息的规则，便于SDK的开发商通过权限配置信息向公众声明其开发的SDK所涉及的权限，进而便于SDK沙盒能够准确确定应用中集成的SDK声明的权限。

作为一个示例，在第一应用的应用文件包括权限配置信息以及集成的各个SDK的可执行文件的情况下，SDK沙盒可以从权限配置信息中确定第一SDK声明的权限，从第一SDK的可执行文件中解析出第一SDK涉及调用的系统接口。然后根据第一SDK声明的权限和第一SDK涉及调用的系统接口，从终端设备的多个系统接口中确定与第一SDK声明的权限无关的系统接口。比如，先从第一SDK涉及调用的系统接口中确定与第一SDK声明的权限有关的系统接口，将多个系统接口中除已确定的系统接口之外的其他接口确定为与第一SDK声明的权限无关的系统接口。之后，可以根据确定的与第一SDK声明的权限有关的和/或无关的系统接口，生成与第一SDK对应的接口权限信息。

比如，可以根据确定的第一SDK声明的权限无关的系统接口，在初始全局接口打标表中将这些系统接口对应的标记信息从默认的第一标记修改为第二标记，以得到全局接口打标表。初始全局接口打标表包括多个系统接口的接口标识和各个系统接口对应的默认标记信息，默认标记信息为第一标记。

其中，SDK的可执行文件包括SDK的全部操作指令以及运行时数据。SDK沙盒可以通过可执行文件解析工具对SDK的可执行文件进行解析。比如，以安卓操作系统为例，SDK的可执行文件为dex文件。SDK沙盒可以通过dex文件解析工具对SDK的dex文件进行解析。

在一些实施例中，对第一应用的应用文件进行解析，以确定第一SDK声明的权限，以及第一SDK涉及调用的系统接口可以包括：从第一应用的应用文件中确定权限配置信息，权限配置信息包括第一应用集成的各个SDK声明的权限；根据权限配置信息，确定第一SDK声明的权限；从第一应用的应用文件中确定第一SDK的可执行文件；根据可执行文件，确定第一SDK涉及调用的系统接口。

在一些实施例中，根据可执行文件，确定第一SDK涉及调用的系统接口可以包括：对可执行文件进行反编译，得到可执行文件的源文件；确定源文件中的代码项，代码项包括字节码；从字节码中解析出第一SDK涉及调用的系统接口。

在一些实施例中，SDK沙盒可以预先在操作系统启动的过程中，对操作系统的多个系统接口进行封装，得到封装后的多个系统接口；其中，每个封装后的系统接口均用于在调用信息为第一指示信息的情况下调用对应的原生系统接口，在调用信息为第二指示信息的情况下返回接口调用失败的指示信息。

作为一个示例，SDK沙盒可以预先通过hook机制对操作系统的多个系统接口中的各个系统接口进行封装，使得应用中集成的SDK在调用这些系统接口时，触发调用封装后的系统接口。封装后的系统接口的执行逻辑可以为：若调用信息为第一指示信息，则对调用该系统接口（封装前的原生系统接口）的调用指令进行放行，即允许调用该系统接口；若调用信息为第二指示信息，则对调用该系统接口的调用指令进行阻塞处理，比如返回接口调用失败的指示信息。

其中，第一指示信息用于指示该系统接口满足调用条件。第二指示信息用于指示该系统接口不满足调用条件。比如，在某个系统接口被应用中集成的SDK调用，且该SDK为待监控的SDK的情况下，该调用条件可以为该系统接口是该SDK声明的权限所涉及的系统接口。示例地，第一指示信息为第一标记，第二指示信息为第二标记。

在一些实施例中，SDK沙盒在第一系统接口不是第一SDK声明的权限所涉及的系统接口的情况下，可以根据第二指示信息调用封装后的第一系统接口，通过封装后的第一系统接口对调用指令进行阻塞处理；在第一系统接口是第一SDK声明的权限所涉及的系统接口的情况下，根据第一指示信息调用封装后的第一系统接口，通过封装后的第一系统接口对调用指令进行放行。其中，封装后的第一系统接口用于在调用信息为第一指示信息的情况下调用第一系统接口，在调用信息为第二指示信息的情况下返回接口调用失败的指示信息。

在一些实施例中，为了便于用户对SDK进行管理，电子设备可以为用户提供相关设置入口，以便用户通过相关设置入口开启或关闭SDK沙盒监控功能，SDK沙盒监控功能用于触发SDK沙盒按照本申请实施例提供的SDK的管理方法对应用中集成的SDK调用系统接口的行为进行检测和管理。

比如，相关设置入口可以为用户提供SDK沙盒监控选项以供用户选择，SDK沙盒监控选项可以用于开启针对批量APP、特定APP、或特定SDK的SDK沙盒监控功能，即用于触发SDK沙盒按照本申请实施例提供的SDK的管理方法对批量APP中集成的SDK、特定APP中集成的SDK、或特定SDK调用系统接口的行为进行监测和管理。

作为一个示例，电子设备还包括显示屏，显示屏显示第一界面，第一界面包括SDK沙盒监控选项；响应于用户对SDK沙盒监控选项的点击操作，显示屏显示第二界面，第二界面包括多个应用的应用标识以及每个应用标识对应的开关控件，多个应用包括第一应用；响应于用户对第一应用的应用标识对应的开关控件的开启操作，SDK沙盒执行该SDK管理方法。

第二方面，提供了一种SDK的管理装置，SDK的管理装置具有实现上述第一方面中SDK的管理方法行为的功能。SDK的管理装置包括至少一个模块，至少一个模块用于实现上述第一方面所提供的SDK的管理方法。

第三方面，提供了一种SDK的管理装置，SDK的管理装置的结构中包括处理器和存储器，存储器用于存储支持SDK的管理装置执行上述第一方面所提供的SDK的管理方法的程序，以及存储用于实现上述第一方面的SDK的管理方法所涉及的数据。处理器被配置为用于执行存储器中存储的程序。SDK的管理装置还可以包括通信总线，通信总线用于在处理器与存储器之间建立连接。

第四方面，提供了一种计算机可读存储介质，计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述第一方面的SDK的管理方法。

第五方面，提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述第一方面的SDK的管理方法。

上述第二方面、第三方面、第四方面和第五方面所获得的技术效果与上述第一方面中对应的技术手段获得的技术效果近似，在这里不再赘述。

附图说明

图1是作为一示例性实施例示出的一种第三方SDK越权收集用户隐私数据的示意图；

图2是作为一示例性实施例示出的一种对APP和SDK进行独立上架的示意图；

图3是作为一示例性实施例示出的两种APP调用SDK逻辑的对比示意图；

图4是作为一示例性实施例示出的一种终端的结构示意图；

图5是作为一示例性实施例示出的一种终端的软件系统的框图；

图6是作为一示例性实施例示出的一组图形用户界面的示例图；

图7是作为一示例性实施例示出的一个图形用户界面的示例图；

图8是作为一示例性实施例示出的一种SDK沙盒通过解析应用文件维护全局接口打标表的流程示意图；

图9是作为一示例性实施例示出的一种对APK进行解析的流程示意图；

图10是作为一示例性实施例示出的一种对SDK的源文件中类和方法的逻辑结构示意图；

图11是作为一示例性实施例示出的一种查找SDK的源文件中的字节码的查找路径的示意图；

图12是作为一示例性实施例示出的一种SDK沙盒的hook机制的逻辑示意图；

图13是作为一示例性实施例示出的一种SDK沙盒的监控逻辑的示意图；

图14是作为一示例性实施例示出的一种SDK管理方法的流程图。

具体实施方式

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

应当理解的是，本申请提及的“多个”是指两个或两个以上。在本申请的描述中，除非另有说明，“/”表示或的意思，比如，A/B可以表示A或B；本文中的“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，比如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，为了便于清楚描述本申请的技术方案，采用了“第一”、“第二”等字样对功能和作用基本相同的相同项或相似项进行区分。本领域技术人员可以理解“第一”、“第二”等字样并不对数量和执行次序进行限定，并且“第一”、“第二”等字样也并不限定一定不同。

第三方SDK是指在应用开发过程中，根据业务需要集成在应用中的软件开发工具包。目前，市面上的很多应用（Application，APP）都集成了第三方SDK，如地图SDK、浏览器SDK等。应用可以通过集成的地图SDK获取地图信息，通过集成的浏览器SDK访问浏览器。但是，很多第三方SDK有越权收集用户隐私数据的行为。

接下来，对应用集成的SDK越权收集用户隐私数据的场景进行举例说明。

在一些场景中，对于电子设备的预装应用来说，很多预装应用具有预授权权限，即很多预装应用已被预先授予一些权限，如获取位置信息权限、读取联系人信息权限等获取敏感数据的权限。这种情况下，有些第三方SDK的厂商可能会针对预装应用进行定制化重构，使得集成在预装应用中的第三方SDK可以在未声明相关权限的情况下，直接继承预装应用的预授权权限完成越权收集用户隐私数据的行为。也即是，在未告知用户的情况下通过继承预装应用的预授权权限偷偷收集用户隐私数据。

比如，请参考图1，图1是作为一示例性实施例示出的一种第三方SDK越权收集用户隐私数据的示意图。如图1所示，电子设备中的预装应用10集成第三方SDK20，第三方SDK20云端的远程配置中心30可以通过第三方SDK20探测电子设备的操作系统版本或设备型号等信息，并根据探测信息向第三方SDK20下发攻击脚本。这些攻击脚本可以探测并继承预装应用10的预授权权限，根据预授权权限越权收集用户隐私数据。比如，在第三方SDK20未声明读取联系人权限的情况下，第三方SDK20可以利用远程配置中心30下发的攻击脚本直接继承预装应用10预授权的读取联系人信息权限，进而越权读取用户的联系人信息。另外，这些攻击脚本还可能会攻击电子设备中的系统应用和其他应用，以越权获取系统应用和其他应用的应用数据，或者通过继承系统应用和其他应用的相关权限来越权收集用户隐私数据。

在另一些应用场景中，电子设备中的应用还可以根据用户的授权操作获取相关权限。在应用被用户授权敏感数据获取权限后，应用中集成的第三方SDK即可在未声明相关权限的情况下，私下通过继承应用的权敏感数据获取权限完成越权收集用户隐私数据的行为。

比如，假设某个应用集成了地图SDK，且该应用已被用户授予了获取位置信息权限、获取蓝牙位置权限和获取无线保真（Wireless Fidelity，WIFI）信息权限等。这种情况下，地图SDK不仅可以根据声明获取位置信息权限来获取电子设备的全球定位系统（globalpositioning system，GPS）坐标，还可以通过继承该应用的其他权限来获取其他可能的位置数据，如蓝牙位置信息、测量WIFI信息或电信塔数据等，并将获取的数据上报至地图SDK的云端服务器。这样，地图SDK即可在声明的权限之外偷偷越权收集用户隐私数据，导致用户隐私数据泄露。

目前的SDK集成框架中，在APP中集成第三方SDK，由应用开发人员通过应用上传界面将集成有第三方SDK的应用发布到应用商店。为了避免第三方SDK越权收集用户隐私数据，目前提出了一种对APP和SDK独立上架的解决方案。在该解决方案中，独立上架的APP集成的是SDK服务接口，而非SDK本身。其中，SDK服务接口用于调用SDK。

请参考图2，图2是作为一示例性实施例示出的一种对APP和SDK进行独立上架的示意图。如图2所示，一方面，SDK开发人员可以使用SDK上传界面将开发的SDK单独发布到应用商店。另一方面，APP开发人员可以使用APP上传界面将开发的APP单独发布到应用商店，且发布的APP集成有SDK服务接口，SDK服务接口可以指示待调用的SDK。之后，应用商店对APP及其相关SDK进行分发，以将APP及其相关SDK发布到最终的电子设备。

请参考图3，图3是作为一示例性实施例示出的两种APP调用SDK逻辑的对比示意图。如图3中的（a）图所示，在原有SDK使用框架中，APP中集成有SDK调用代码（SDK callingcode）和第三方SDK，这种情况下，电子设备启动APP进程后，APP对SDK的调用位于APP进程内。比如，在APP进程内通过SDK调用代码调用SDK A或SDK B。如图3中的（b）图所示，在上述对APP和SDK独立上架的解决方案中，APP中集成有SDK调用代码和SDK服务接口，这种情况下，电子设备在对应用商店发布的APP及其相关SDK安装完成后，电子设备可以分别启动APP进程和SDK运行时进程，SDK运行时进程为运行SDK的进程。在APP进程内可以通过SDK调用代码与SDK服务接口进行通信，SDK服务接口可以跨越进程边界进入SDK运行时进程，以调用SDK本身。比如，在APP进程内通过SDK A服务接口跨进程调用SDK A，通过SDK B服务接口跨进程调用SDK B。也即是，在对APP和SDK独立上架的解决方案中，可以使得SDK作为一个独立的进程与应用进程分隔开来，以避免SDK通过继承应用的相关权限完成收集用户隐私数据的行为。

但是，上述对APP和SDK独立上架的解决方案中，由于需要在APP之外对SDK单独上架，因此额外增加了SDK的分发和管理负担，导致SDK的分发和管理更加复杂，而且不利于兼容原有SDK集成框架。

本申请实施例中，为了在解决第三方SDK越权收集用户隐私数据的问题的基础上，最大限度地集成和兼容现有SDK使用框架，减轻SDK的分发和管理的复杂化，提出了一种SDK管理方法。在该方法中，可以在电子设备的操作系统中设置SDK沙盒，通过SDK沙盒对应用中集成的SDK调用系统接口的行为进行监控。

比如，若SDK沙盒监听到第一应用集成的第一SDK调用第一系统接口的调用指令，则在第一系统接口不是第一SDK声明的权限所涉及的系统接口的情况下，SDK沙盒可以对该调用指令进行阻塞处理（block），即不对该调用指令进行放行。如此，可以使得第一SDK无法成功调用未声明的权限所涉及的系统接口，进而无法通过未声明的权限获取用户隐私数据，大大降低了第三方SDK越权收集用户隐私数据的可能性，提高了用户隐私数据的安全性。另外，在SDK沙盒监听到第一应用集成的第一SDK调用第一系统接口的调用指令后，在第一系统接口是第一SDK声明的权限所涉及的系统接口的情况下，SDK沙盒还可以对该调用指令进行放行，使得第一SDK可以正常调用声明的权限所涉及的系统接口，进而可以正常通过声明的权限获取所需数据，保障了SDK的正常运行。

相较于相关技术中提出的对APP和SDK独立上架的解决方案，本申请实施例提出的解决方案是在原有SDK集成框架实现的，仅需在电子设备的操作系统中额外设置具有对SDK调用系统接口的行为进行监控功能的SDK沙盒即可，无需对SDK单独上架，降低了SDK的分发和管理的复杂化，对原有SDK集成框架的兼容性较高。

其中，第一应用可以为终端安装的任一应用，第一SDK为第一应用集成的任一SDK，第一系统接口为操作系统的任一系统接口。第一SDK声明的权限是指第一SDK告知公众的需要使用的权限。第一SDK声明的权限涉及的系统接口是指第一SDK声明的权限将会调用的系统接口。比如，假设第一SDK声明的权限为联系人权限，则联系人权限涉及的接口可以为读取联系人信息接口、写入联系人信息接口和访问账户列表接口中的一种或多种。

也即是，本申请实施例中，可以通过SDK沙盒对应用中集成的SDK调用系统接口的调用指令进行拦截，在所调用的系统接口不是该SDK声明权限所涉及的系统接口的情况下，通过SDK沙盒对该调用指令进行阻塞处理；在所调用的系统接口是该SDK声明权限所涉及的系统接口的情况下，通过SDK沙盒对该调用指令进行放行。

第三方SDK通过某个权限获取数据时，需要调用该权限所涉及的系统接口来获取。操作系统是指终端设备的操作系统提供给应用程序调用使用的代码，比如是应用程序框架层中的一些预先定义的函数，用来实现相关实例功能。比如，系统接口为应用程序编程接口（application programming interface，API）。

通过对第三方SDK调用未声明权限所涉及的系统接口的调用指令进行阻塞处理，可以阻止该第三方SDK成功调用未声明权限所涉及的系统接口，进而无法通过未声明权限成功获取用户隐私数据。另外，通过对第三方SDK调用声明权限所涉及的系统接口的调用指令进行放行，可以使得第三方SDK能够正常调用声明的权限所涉及的系统接口，进而可以正常通过声明的权限获取所需数据。通过这种监测和管理方式，可以在一定程度上控制第一SDK仅在所声明的权限内获取数据，从而大大降低了第三方SDK越权收集用户隐私数据的可能性，提高了用户隐私数据的安全性。

本申请实施例提供的SDK管理方法可以应用于可以安装和运行集成有SDK的应用的电子设备中，该电子设备可以为终端或服务器，终端可以为手机、平板电脑、计算机设备、智能可穿戴设备（如智能手表）等，本申请实施例对电子设备的具体设备类型不做限定。

接下来，以终端为例对本申请实施例涉及的电子设备进行详细说明。

图4是作为一示例性实施例示出的一种终端的结构示意图。参见图4，终端100可以包括处理器110，外部存储器接口120，内部存储器121，通用串行总线（universal serialbus，USB）接口130，充电管理模块140，电源管理模块141，电池142，天线1，天线2，移动通信模块150，无线通信模块160，音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，传感器模块180，按键190，马达191，指示器192，摄像头193，显示屏194，以及用户标识模块（subscriber identification module，SIM）卡接口195等。其中，传感器模块180可以包括压力传感器180A，陀螺仪传感器180B，气压传感器180C，磁传感器180D，加速度传感器180E，距离传感器180F，接近光传感器180G，指纹传感器180H，温度传感器180J，触摸传感器180K，环境光传感器180L，骨传导传感器180M等。

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

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

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

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

在一些实施例中，处理器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的无线通信功能可以通过天线1，天线2，移动通信模块150，无线通信模块160，调制解调处理器以及基带处理器等实现。

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

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

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

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

在一些实施例中，终端100的天线1和移动通信模块150耦合，天线2和无线通信模块160耦合，使得终端100可以通过无线通信技术与网络以及其他设备通信。

终端100通过GPU，显示屏194，以及应用处理器等实现显示功能。GPU为图像处理的微处理器，连接显示屏194和应用处理器。GPU用于执行数学和几何计算，用于图形渲染。处理器110可包括一个或多个GPU，其执行程序指令以生成或改变显示信息。

显示屏194用于显示图像，视频等。显示屏194包括显示面板。显示面板可以采用液晶显示屏（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个显示屏194，N为大于1的整数。

终端100可以通过ISP，摄像头193，视频编解码器，GPU，显示屏194以及应用处理器等实现拍摄功能。

ISP 用于处理摄像头193反馈的数据。比如，拍照时，打开快门，光线通过镜头被传递到摄像头感光元件上，光信号转换为电信号，摄像头感光元件将电信号传递给ISP处理，转化为肉眼可见的图像。ISP还可以对图像的噪点，亮度，肤色进行算法优化。ISP还可以对拍摄场景的曝光，色温等参数优化。在一些实施例中，ISP可以设置在摄像头193中。

摄像头193用于捕获静态图像或视频。物体通过镜头生成光学图像投射到感光元件。感光元件可以是电荷耦合器件（charge coupled device，CCD）或互补金属氧化物半导体（complementary metal-oxide-semiconductor，CMOS）光电晶体管。感光元件把光信号转换成电信号，之后将电信号传递给ISP转换成数字图像信号。ISP将数字图像信号输出到DSP加工处理。DSP将数字图像信号转换成标准的RGB，YUV等格式的图像信号。在一些实施例中，终端100可以包括1个或N个摄像头193，N为大于1的整数。

数字信号处理器用于处理数字信号，除了可以处理数字图像信号，还可以处理其他数字信号。比如，当终端100在频点选择时，数字信号处理器用于对频点能量进行傅里叶变换等。

视频编解码器用于对数字视频压缩或解压缩。终端100可以支持一种或多种视频编解码器。这样，终端100可以播放或录制多种编码格式的视频，比如：动态图像专家组（moving picture experts group，MPEG）1，MPEG2，MPEG3，MPEG4等。

NPU为神经网络（neural-network，NN）计算处理器，通过借鉴生物神经网络结构，比如借鉴人脑神经元之间传递模式，对输入信息快速处理，还可以不断的自学习。通过NPU可以实现终端100的智能认知等应用，比如：图像识别，人脸识别，语音识别，文本理解等。

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

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

终端100可以通过音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D以及应用处理器等实现音频功能，比如音乐播放，录音等。

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

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

接下来对终端100的软件系统予以说明。

终端100的软件系统可以采用分层架构，事件驱动架构，微核架构，微服务架构，或云架构。本申请实施例以分层架构的安卓（Android）系统为例，对终端100的软件系统进行示例性说明。

图5是作为一示例性实施例示出的一种终端100的软件系统的框图。参见图5，分层架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中，将Android系统分为四层，从上至下分别为应用程序层，应用程序框架层，安卓运行时（Android runtime）和系统层，以及内核层。

应用程序层可以包括一系列应用程序包，这一系列应用程序包中的部分应用可以集成SDK。如图5所示，应用程序包可以包括APP 1、APP 2和APP 3等应用。其中，APP 1集成SDK 1，APP 2集成SDK 2，APP 3集成SDK 3。这些应用可以为相机，图库，日历，通话，地图，导航，WLAN，蓝牙，音乐，视频，短信息等应用，当然也可以为其他应用，本申请实施例对此不做限定。如图5所示，应用程序包还包括设置应用，用户可以通过设置应用开启或关闭“SDK沙盒监控选项”，通过开启或关闭“SDK沙盒监控选项”来开启或关闭“SDK沙盒监控功能”，SDK沙盒监控功能用于对应用中集成的SDK调用系统接口的行为进行监控。在一个实施例中，用户可以通过设置应用开启特定应用对应的“SDK沙盒监控选项”，来开启特定应用的SDK沙盒监控功能，以对特定应用中集成的SDK调用系统接口的行为进行监控。进一步地，用户还可以通过设置应用开启特定SDK对应的“SDK沙盒监控选项”，来开启特定SDK的SDK沙盒监控功能，以对特定SDK调用系统接口的行为进行监控。其中，SDK沙盒监控功能可以通过下述系统层的SDK沙盒实现。

应用程序框架层为应用程序层的应用程序提供应用编程接口（applicationprogramming interface，API）和编程框架。应用程序框架层包括一些预先定义的函数。如图5所示，应用程序框架层可以包括各种系统接口、窗口管理器，内容提供器，视图系统，电话管理器和资源管理器等。这些系统接口可以为终端的各种权限涉及的系统接口，如位置权限涉及的系统接口、蓝牙权限涉及的系统接口、WIFI权限涉及的系统接口、摄像头权限涉及的系统接口、以及联系人权限涉及的系统接口等。窗口管理器用于管理窗口程序。窗口管理器可以获取显示屏大小，判断是否有状态栏，锁定屏幕，截取屏幕等。内容提供器用来存放和获取数据，并使这些数据可以被应用程序访问，这些数据可以包括视频，图像，音频，拨打和接听的电话，浏览历史和书签，电话簿等。视图系统包括可视控件，比如显示文字的控件，显示图片的控件等。视图系统可用于构建应用程序的显示界面，显示界面可以由一个或多个视图组成，比如，包括显示短信通知图标的视图，包括显示文字的视图，以及包括显示图片的视图。电话管理器用于提供终端100的通信功能，比如通话状态的管理（包括接通，挂断等）。资源管理器为应用程序提供各种资源，比如本地化字符串，图标，图片，布局文件，视频文件等。通知管理器使应用程序可以在状态栏中显示通知信息，可以用于传达告知类型的消息，可以短暂停留后自动消失，无需用户交互。比如，通知管理器被用于告知下载完成，消息提醒等。通知管理器还可以是以图表或滚动条文本形式出现在系统顶部状态栏的通知，比如后台运行的应用程序的通知。另外，应用程序框架层还可以包括通知管理器还可以是以对话窗口形式出现在屏幕上的通知，比如在状态栏提示文本信息，发出提示音，电子设备振动，指示灯闪烁等。

系统层位于应用程序框架层和内核层之间。本申请实施例中，可以在系统层配置SDK沙盒（sandbox），以通过SDK沙盒对应用中集成的SDK调用系统接口的行为进行监控。沙盒又叫沙箱或沙盘等，是一个虚拟系统程序，是在现有的操作系统下隔离一个环境。沙盒相当于一个安全软件，可以用于测试不受信任的文件或应用程序等行为。而且，沙盒中的所有改动对操作系统不会造成任何损失。如图5所示，系统层包括SDK沙盒，该SDK沙盒包括可执行文件读取模块（图5中以dex文件读取模块为例）、接口监听配置模块（图5中以API 监听配置模块为例）和沙盒监控模块。

其中，可执行文件读取模块用于读取待监测的第一应用集成的SDK的可执行文件，以根据该SDK的可执行文件确定与该SDK声明的权限相关或无关的系统接口（即该SDK声明的权限涉及调用或未涉及调用的系统接口）。比如，可执行文件读取模块可以对第一应用的应用文件中的第一SDK的可执行文件进行解析，以确定第一SDK涉及调用的系统接口，根据第一SDK涉及调用的系统接口，确定与该SDK声明的权限无关的系统接口。其中，SDK的可执行文件包括SDK的全部操作指令以及运行时数据。示例地，SDK的可执行文件可以为dex文件（Android系统的可执行文件）。在一个实施例中，可执行文件读取模块可以在第一应用的SDK沙盒监控功能被开启后，读取第一应用集成的SDK的可执行文件。另外，可执行文件读取模块还用于从第一应用的应用文件中读取权限配置信息，该权限配置信息包括第一应用集成的各个SDK声明的权限；从该权限配置信息中确定第一SDK声明的权限。

接口监听配置模块用于对操作系统的多个系统接口进行监听配置，以便SDK沙盒具有对这些系统接口的被调用行为进行监听的能力。这多个系统接口可以为终端的全部或部分系统接口，比如为多种权限涉及的系统接口。这多种权限可以为预设权限，比如预设权限为敏感权限（用于获取敏感数据的权限）。请参考图5，这多个系统接口可以为位置权限涉及的系统接口、蓝牙权限涉及的系统接口、WIFI权限涉及的系统接口、摄像头权限涉及的系统接口、以及联系人权限涉及的系统接口等，当然也可以包括其他权限涉及的系统接口。在一个实施例中，接口监听配置模块可以通过hook（钩子）进制对这多个系统接口进行监听配置，hook机制可以为Frida、Xposed或Lsposed等hook框架。这些hook框架可以在不修改APK的情况下改变系统和APK的行为。在一个实施例中，接口监听配置模块可以通过hook机制对多个系统接口进行封装，以使待监测的SDK在调用这些系统接口时触发调用封装后的系统接口。

其中，沙盒监控模块用于对终端的多种权限涉及的系统接口进行监测，以监测这些系统接口是否被调用，当任一系统接口被调用时，采用本申请实施例提供的SDK管理方法进行管理。比如，当监听到任一系统接口被第一应用集成的第一SDK调用时，则在该系统接口不是第一SDK声明的权限所涉及的系统接口的情况下，对该调用行为进行阻塞处理，在该系统接口是第一SDK声明的权限所涉及的系统接口的情况下，对该调用行为进行放行处理。请参考图5，这些系统接口可以包括位置权限涉及的系统接口、蓝牙权限涉及的系统接口、WIFI权限涉及的系统接口、摄像头权限涉及的系统接口、以及联系人权限涉及的系统接口等。作为一个示例，沙盒监控模块可以通过hook进制对多种权限涉及的系统接口进行监测。在一些实施例中，沙盒监控模块还可以针对第一SDK维护接口权限信息，该接口权限信息用于指示哪些系统接口与第一SDK声明的权限有关，和/或，哪些系统接口与第一SDK声明的权限无关。以便沙盒监控模块根据该接口权限信息对第一SDK调用系统接口的行为进行监测和管理。作为一个示例，沙盒监控模块可以针对第一SDK维护全局接口打标表，该全局接口打标表包括操作系统的多个系统接口的接口标识以及各个系统接口对应的标记信息，标记信息用于指示对应系统接口是否为与第一SDK声明的权限相关的系统接口。以便沙盒监控模块根据该全局接口打标表，判断第一SDK调用的系统接口是否为第一SDK声明的权限所涉及的系统接口，进而根据该判断结果对该调用行为进行放行或阻塞处理。接口标识可以为系统接口的名称或身份标识号（identity document，ID）等，本申请实施例对此不做限定。

内核层是硬件和软件之间的层。内核层至少包含显示驱动，摄像头驱动，音频驱动，传感器驱动。

接下来，对本申请实施例提供的SDK的管理方法进行详细介绍。

本申请实施例中，为了便于用户对SDK进行管理，终端设备可以为用户提供相关设置入口，以便用户通过相关设置入口开启或关闭SDK沙盒监控功能，SDK沙盒监控功能用于触发SDK沙盒按照本申请实施例提供的方法对应用中集成的SDK调用系统接口的行为进行监控，即进行检测和管理。

比如，相关设置入口可以为用户提供SDK沙盒监控选项以供用户选择，SDK沙盒监控选项可以用于开启针对批量APP、特定APP、或特定SDK的SDK沙盒监控功能，即用于触发SDK沙盒按照本申请实施例提供的SDK的管理方法对批量APP中集成的SDK、特定APP中集成的SDK、或特定SDK调用系统接口的行为进行监测和管理。

作为一个示例，终端设备可以提供相关设置入口，以便用户针对特定应用开启SDK沙盒监控功能。比如，终端设备可以显示设置界面，该设置界面包括多个应用标识以及各个应用标识对应的SDK沙盒监控开关。若接收到用户对第一应用标识对应的SDK沙盒监控开关的开启操作，则触发SDK沙盒对第一应用中集成的SDK调用系统接口的行为进行监控。其中，第一应用标识可以为多个应用标识中的任一个。应用标识可以为应用名称、应用ID、应用包名或应用图标等，本申请实施例对此不做限定。

请参考图6，图6是作为一示例性实施例示出的一组图形用户界面（graphicaluser interface，GUI）的示例图。在一种应用场景中，如图6中的（a）图所示，终端设备的桌面中显示有设置应用的应用图标，当用户想要开启SDK沙盒监控功能时，可以点击设置应用的应用图标。响应于用户对该图标的点击操作，终端设备显示如图6中的（b）图所示的设置界面，该设置界面包括“隐私保护”选项，以及WLAN、蓝牙等其他选项。应理解，该设置界面还可以包括其他选项。用户可以点击“隐私保护”选项，响应于用户对“隐私保护”选项的点击操作，终端设备显示如图6中的（c）图所示的设置界面，该设置界面包括“SDK沙盒监控”选项，以及权限管理、定位服务等其他选项。应理解，该设置界面还可以包括其他选项。用户可以点击“SDK沙盒监控”选项，响应于用户对“SDK沙盒监控”选项的点击操作，终端设备显示如图6中的（d）图所示的设置界面，该设置界面包括多个应用的应用标识以及每个应用对应的开关控件（即SDK沙盒监控开关），每个应用对应的开关控件用于开启或关闭该应用的SDK沙盒监控功能，以触发SDK沙盒对该应用集成的SDK调用系统接口的行为进行监控。比如，若用户想要开启应用1的SDK沙盒监控功能，则用户可以点击应用1对应的开关控件，响应于用户对该开关控件的点击操作，终端设备将该开关控件从关闭状态切换至开启状态，并开启应用1的SDK沙盒监控功能，即触发SDK沙盒对应用1中集成的SDK调用系统接口的行为进行监控。

应理解，图6仅是以SDK沙盒的相关设置入口设置于设置应用为例进行举例说明，在其他实施例中，终端设备还可以在其他界面中显示用于开启或关闭SDK沙盒监控功能的设置入口，该设置入口还可以为其他展示形式，本申请实施例对用于开启或关闭SDK沙盒监控功能的设置入口的展示位置和展示形式不做限定。

在另一实施例中，终端设备可以提供相关设置入口，以便用户针对批量应用开启SDK沙盒监控功能。比如，终端设备可以显示第二设置界面，第二设置界面包括SDK沙盒监控功能的总SDK沙盒监控开关。若接收到用户对该总SDK沙盒监控开关的开启操作，则触发SDK沙盒对批量应用（如全部应用或已选应用）集成的SDK的调用系统接口的行为进行监控。其中，已选应用可以为用户通过选择操作选择的应用，或者为已允许通过SDK沙盒进行监控的应用。

在另一实施例中，终端设备可以提供相关设置入口，以便用户针对特定SDK开启SDK沙盒监控功能。比如，终端设备可以显示第三设置界面，第三设置界面包括多个SDK标识以及各个SDK标识对应的SDK沙盒监控开关。若接收到对目标SDK标识对应的SDK沙盒监控开关的开启操作，则触发SDK沙盒对目标SDK调用系统接口的行为进行监控，比如对所有应用或已选应用中集成的目标SDK调用系统接口的行为进行监控。其中，目标SDK标识为多个SDK标识中的任一SDK标识。通过这种方式，可以在SDK粒度上启动SDK沙盒监控功能。

在另一实施例中，终端设备可以提供相关设置入口，以便用户针对特定应用的特定SDK开启SDK沙盒监控功能。比如，终端设备可以显示第四设置界面，第四设置界面包括特定应用集成的至少一个SDK标识以及各个SDK标识对应的SDK沙盒监控开关。若接收到对第二SDK标识对应的SDK沙盒监控开关的开启操作，则触发SDK沙盒对该特定应用集成的第二SDK调用系统接口的行为进行监控。其中，第二SDK标识为该至少一个SDK标识中的任一个。例如，用户可以点击上述图6中的（d）图所示的应用1，响应于用户对应用1的点击操作，终端设备还可以显示第四设置界面，第四设置界面包括应用1集成的各个SDK的标识以及各个SDK对应的SDK沙盒监控开关。若用户想要针对应用1集成的SDK 1开启SDK沙盒监控功能，可以点击SDK 1对应的SDK沙盒监控开关，响应于用户的点击操作，即可触发SDK沙盒对应用1集成的SDK 1调用系统接口的行为进行监控。

本申请实施例中，在SDK沙盒监控功能开启后，SDK沙盒可以对待监控的SDK调用系统接口的行为进行监测和管理。比如，SDK沙盒若监测到待监控的第一SDK调用第一系统接口的调用指令，则在第一系统接口是第一SDK声明的权限涉及的系统接口的情况下，对该调用指令进行放行；在第一系统接口不是第一SDK声明的权限涉及的系统接口的情况下，对该调用指令进行阻塞处理。

为了进一步提高隐私保护的灵活性，在对该调用指令进行阻塞处理之前，还可以先触发终端设备显示提示信息，该提示信息用于询问用户是否允许第一SDK调用第一系统接口。比如，该提示信息用于提示用户第一SDK正在调用第一系统接口，以及询问用户是否允许其调用。用户可以基于该提示信息执行允许操作或拒绝操作。在接收到用户的拒绝操作（即不允许操作）的情况下，则执行对该调用指令进行阻塞处理的步骤。在接收到用户的允许操作的情况下，则对该调用指令进行放行。

比如，在对该调用指令进行阻塞处理之前，可以先触发终端设备显示提示窗口，该提示窗口包括提示信息“第一应用集成的第一SDK正在调用第一系统接口，是否允许？”，以及同意选项和拒绝选项。用户可以通过点击同意选项允许第一SDK调用第一系统接口，通过点击拒绝选项不允许第一SDK调用第一系统接口。

作为一个示例，该提示窗口可以为弹窗等形式。请参考图7，对于待监控的应用A，假设应用A集成的地图SDK正在偷偷调用读取联系人信息接口以读取联系人信息，则SDK沙盒在监测到地图SDK对联系人接口的调用指令后，在确定联系人接口不是地图SDK所声明的权限涉及的系统接口的情况下，可以先触发终端设备显示如图7所示的消息弹窗，该消息弹窗包括提示信息“应用A集成的地图SDK正在读取联系人信息，是否允许？”，以及“同意选项”和“拒绝选项”。若用户不允许地图SDK读取联系人信息，则可以点击“拒绝选项”。响应于用户点击“拒绝选项”的操作，SDK沙盒即可对该调用指令进行阻塞处理，以使地图SDK无法成功调用读取联系人信息接口，进而无法成功读取联系人信息。另外，若用户允许地图SDK读取联系人信息，还可以点击“同意选项”。响应于用户的操作，SDK沙盒即可对该调用指令进行放行，以使地图SDK能成功调用读取联系人信息接口，进而成功读取联系人信息。

在一种可能的实现方式中，SDK沙盒可以维护接口权限信息，该接口权限信息用于指示与第一SDK声明的权限有关的系统接口和/或与第一SDK声明的权限有关的系统接口，即用于指示哪些系统接口与第一SDK声明的权限有关和/或哪些系统接口与第一SDK声明的权限无关。以便SDK沙盒可以在监听到第一SDK调用第一系统接口的调用指令时，可以根据该接口权限信息快速判断所调用的第一系统接口是否为第一SDK声明的权限涉及的系统接口，进而根据判断结果对该调用指令进行放行或阻塞处理。

通过针对待监控的SDK维护接口权限信息，便于根据接口权限信息快速和准确地判断所调用系统接口是否为待监控的SDK声明的权限所涉及的系统接口，提高了SDK的管理效率和准确性。

作为一个示例，接口权限信息可以包括如下几种实现方式：

1）接口权限信息包括操作系统的多个系统接口的接口标识以及各个系统接口对应的标记信息，该标记信息用于指示对应系统接口是否为与第一SDK声明的权限相关的系统接口，这多个系统接口包括第一系统接口。比如，标记信息包括第一标记和第二标记，第一标记用于指示对应系统接口是与第一SDK声明的权限相关的系统接口，第二标记用于指示对应系统接口是与第一SDK声明的权限无关的系统接口。

这种情况下，根据该接口权限信息判断所调用的第一系统接口是否为第一SDK声明的权限涉及的系统接口可以包括：从接口权限信息中查找第一系统接口对应的标记信息（flag）；若第一系统接口对应的标记信息为第一标记，则确定第一系统接口是第一SDK声明的权限所涉及的系统接口；若第一系统接口对应的标记信息为第二标记，则确定第一系统接口不是第一SDK声明的权限所涉及的系统接口。

也即是，在对待监控的SDK进行监控的过程中，若监听到该SDK调用第一系统接口的调用指令，则根据第一系统接口查找接口权限信息，若第一系统接口对应的标记信息为第一标记，则对该调用指令进行放行，若第一系统接口对应的标记信息为第二标记，则对该调用指令进行阻塞处理。

作为一个示例，第一标识为true，第二标识为false。当然，第一标记和第二标记也可以为其他形式的标记信息，本申请实施例对此不做限定。

作为一个示例，接口权限信息可以通过对初始接口权限信息进行打标得到。初始接口权限信息包括多个系统接口的接口标识以及各个系统接口对应的初始标记信息（即默认标记信息），初始标记信息为第一标记。本申请实施例中，可以通过将这多个系统接口中与第一SDK声明的权限无关的系统接口的接口标记从默认的第一标记修改为第二标识的方式，来对这些系统接口进行打标，从而得到打标好的接口权限信息。

作为一个示例，该接口权限信息可以为列表形式，该接口权限信息还可以称为全局接口打标表，该全局接口打标表包括多个系统接口的接口标识以及各个系统接口对应的flag，flag=true或false，flag=true表示对应的系统接口是与第一SDK声明的权限相关的系统接口，flag=false表示对应的系统接口不是与第一SDK声明的权限相关的系统接口。

作为一个示例，接口权限信息中的多个系统接口可以包括如下表1所示的系统接口：

表1

应理解，上述表1并不构成对接口权限信息中的多个系统接口的限定，这多个系统接口还可以包括其他系统接口。

在一个示例中，假设接口权限信息为全局接口打标表的形式，全局接口打标表可以如下表2所示：

表2

应理解，表2并不构成对全局接口打标表的限定，全局接口打标表还可以包括其他内容。

2）接口权限信息包括若干个第一接口的接口标识，若干个第一接口为操作系统的多个系统接口中与第一SDK声明的权限相关的系统接口。

这种情况下，根据该接口权限信息判断所调用的第一系统接口是否为第一SDK声明的权限涉及的系统接口可以包括：根据第一系统接口查找该接口权限信息，如果接口权限信息包括的若干个第一接口中存在第一系统接口，则确定第一系统接口是第一SDK声明的权限所涉及的系统接口；如果接口权限信息包括的若干个第一接口中不存在第一系统接口，则确定第一系统接口不是第一SDK声明的权限所涉及的系统接口。

也即是，在对待监控的SDK进行监控的过程中，若监听到该SDK调用第一系统接口的调用指令，则根据第一系统接口查找接口权限信息，若接口权限信息中存在第一系统接口，则对该调用指令进行放行，若接口权限信息中不存在第一系统接口，则对该调用指令进行阻塞处理。

3）接口权限信息包括若干个第二接口的接口标识，若干个第二接口为操作系统的多个系统接口中与第一SDK声明的权限无关的系统接口。

这种情况下，根据该接口权限信息判断所调用的第一系统接口是否为第一SDK声明的权限涉及的系统接口可以包括：根据第一系统接口查找该接口权限信息，如果接口权限信息包括的若干个第二接口中存在第一系统接口，则确定第一系统接口不是第一SDK声明的权限所涉及的系统接口；如果接口权限信息包括的若干个第二接口中不存在第一系统接口，则确定第一系统接口是第一SDK声明的权限所涉及的系统接口。

也即是，在对待监控的SDK进行监控的过程中，若监听到该SDK调用第一系统接口的调用指令，则根据第一系统接口查找接口权限信息，若接口权限信息中不存在第一系统接口，则对该调用指令进行放行，若接口权限信息中存在第一系统接口，则对该调用指令进行阻塞处理。

在一种可能的实现方式中，SDK沙盒可以预先对第一应用的应用文件进行解析，根据解析结果来维护该接口权限信息。比如，预先对第一应用的应用文件进行解析，以确定第一SDK声明的权限，以及第一SDK涉及调用的系统接口；根据第一SDK声明的权限和第一SDK涉及调用的系统接口，确定与第一SDK声明的权限相关的系统接口和/或与第一SDK声明的权限无关的系统接口，根据确定结果来生成该接口权限信息。

其中，应用文件可以应用程序包，如安卓应用程序包（Android applicationpackage，APK）。

作为一个示例，若用户开启针对多个APP的SDK沙盒监控功能，则SDK沙盒可以排队扫描这多个APP的应用文件，每扫描到一个APP的应用文件，对扫描到的应用文件进行解析，根据解析结果维护APP集成的各个SDK对应的接口权限信息，以便根据各个SDK对应的接口权限信息对该SDK调用系统接口的行为进行监测和管理。

在一个实施例中，可以由应用开发人员在发布第一应用前，在第一应用的应用文件中额外添加权限配置信息（permission config），使得第一应用的应用文件包括权限配置信息、以及第一应用集成的各个SDK的可执行文件。应理解，第一应用的应用文件还可以包括其他所需信息。

其中，权限配置信息包括第一应用集成的各个SDK声明的权限。SDK声明的权限是指向用户告知的该SDK将会使用的权限。比如，权限配置信息包括第一应用集成的各个SDK的SDK标识以及声明的权限。SDK标识可以为SDK的包名（packagename）、 ID、或版本号等。在一个实施例中，应用开发者服务平台可以为应用开发人员提供权限配置信息的配置模板，以便开发人员按照该配置模板在开发的第一应用中添加权限配置信息。

示例地，第一应用的权限配置信息可以包括如下内容：

SDK A packagename：[1.访问摄像头权限；2.音频录制权限]；

SDK B packagename：[1.访问位置权限；2.读取联系人信息权限]。

需要说明的是，传统的应用文件并不包括权限配置信息，本申请实施例通过额外配置在应用文件中添加权限配置信息的规则，便于SDK的开发商通过权限配置信息向公众声明其开发的SDK所涉及的权限，进而便于SDK沙盒能够准确确定应用中集成的SDK声明的权限。

作为一个示例，在第一应用的应用文件包括权限配置信息以及集成的各个SDK的可执行文件的情况下，SDK沙盒可以从权限配置信息中确定第一SDK声明的权限，从第一SDK的可执行文件中解析出第一SDK涉及调用的系统接口。然后根据第一SDK声明的权限和第一SDK涉及调用的系统接口，从终端设备的多个系统接口中确定与第一SDK声明的权限无关的系统接口。比如，先从第一SDK涉及调用的系统接口中确定与第一SDK声明的权限有关的系统接口，将多个系统接口中除已确定的系统接口之外的其他接口确定为与第一SDK声明的权限无关的系统接口。之后，可以根据确定的与第一SDK声明的权限有关的和/或无关的系统接口，生成与第一SDK对应的接口权限信息。

比如，可以根据确定的第一SDK声明的权限无关的系统接口，在初始全局接口打标表中将这些系统接口对应的标记信息从默认的第一标记修改为第二标记，以得到全局接口打标表。初始全局接口打标表包括多个系统接口的接口标识和各个系统接口对应的默认标记信息，默认标记信息为第一标记。

为了便于说明，接下来将以接口权限信息为全局接口打标表为例进行说明。

其中，SDK的可执行文件包括SDK的全部操作指令以及运行时数据。SDK沙盒可以通过可执行文件解析工具对SDK的可执行文件进行解析。比如，以安卓操作系统为例，SDK的可执行文件为dex文件。SDK沙盒可以通过dex文件解析工具对SDK的dex文件进行解析。

作为一个示例，请参考图8，图8是作为一示例性实施例示出的一种SDK沙盒通过解析应用文件维护全局接口打标表的流程示意图。如图8所示，APP A集成有SDK A和SDK B。SDK沙盒可以从APP A的应用文件中读取权限配置信息，从权限配置信息中读取APP A集成的SDK A的包名以及SDK A声明的权限。然后，根据SDK A的包名从APP A的应用文件中提取SDK A的dex文件，从SDK A的dex文件中解析出SDK A涉及调用的API，从SDK A涉及调用的API中确定与SDK A声明的权限有关的API，将全局接口打标表中的其他API进行打标，即将这些API对应的默认标记信息从第一标记更新为第二标记，比如将这些API对应的flag=true更新为flag=false。比如，请参考图8，全局接口打标表包括相机1API、相机2API、读取联系人信息API、获取精确位置API、获取模糊位置API、音频录制API和读取短信API等。假设SDK A为地图SDK，其声明了位置权限，其涉及调用的API中与位置权限相关的API为获取模糊位置API。则可以将全局接口打标表中除模糊位置API之外的其他API进行打标，即将模糊位置API之外的其他API对应的flag=true修改为flag=false。

作为一个示例，请参考图9，图9是作为一示例性实施例示出的一种对APK进行解析的流程示意图。如图9所示，对APK进行解压，得到权限配置信息、各个SDK的dex文件以及其他文件。从权限配置信息中可以提取各个SDK声明的权限。对于每个SDK的dex文件，可以从dex文件中提取代码项（code item），对代码项进行解析，可以解析出该SDK涉及调用的系统接口。

作为一个示例，可以对第一SDK的可执行文件进行反编译，得到可执行文件的源文件；确定源文件中的代码项；从代码项包括的字节码中解析出第一SDK涉及调用的系统接口。

通过对第一SDK的可执行文件进行反编译，可以将可执行文件反编译为源文件。比如，将第一SDK的dex文件反编译为java包。SDK对系统接口的调用通常通过一些类和方法来实现，相应地，代码项可以为实例方法的代码项，字节码为实例方法的字节码。实例方法通常可以包括一些调用系统接口的实现方法，因此可以通过解析实例方法的字节码中包括的调用系统接口的实现方法的字节码，确定第一SDK涉及调用的系统接口。如图10所示，SDK的源文件可以包括一些类，类可以包含实例方法、静态方法和对象（object）等信息，实例方法可以包括一些调用系统接口的实现方法。因此，可以从这些实现方法的字节码中解析出SDK涉及调用的系统接口。

作为一个示例，确定源文件中的代码项的过程可以包括：从源文件中查找代码的偏移量（code offset），根据代码的偏移量从源文件中查找代码项。比如，从源文件中查找代码项的查找路径可以包括：从源文件中查找类定义信息的偏移量，根据类定义信息的偏移量查找源文件中的类定义项（class def item）；根据类定义项中的类数据的偏移量，查找源文件中的类数据项（class deta item）；从类数据项中查找方法信息的代码的偏移量；根据方法信息的代码的偏移量，从源文件中查找方法信息的代码项。之后，即可确定方法信息的代码项中的字节码，从字节码中解析出第一SDK涉及调用的系统接口。比如，字节码可以为dex字节码（dex byte code）。

请参考图11，图11是作为一示例性实施例示出的一种查找SDK的源文件中的字节码的查找路径的示意图。如图11所示，SDK的源文件可以包括：文件尺寸（file size）、文件头尺寸（header size）、字符串的偏移量（string IDs offset）、类型信息的偏移量（typeIDs offset）、方法声明的偏移量（proto IDs offset）、字段信息的偏移量（field IDsoffset）、方法信息的偏移量（method IDs offset）、类信息的偏移量（class IDs offset）和数据区的偏移量（date offset）等内容。其中，字符串、类型信息、方法声明、字段信息、方法信息和类信息均存储在数据区内，可以通过对应的偏移量从数据区中查找。在对SDK的源文件进行解析时，可以先查找SDK的源文件中的类信息的偏移量，根据类信息的偏移量从数据区中查找类定义项（classdef item）。classdef item包括：类的索引（class_idx）、访问标识（access_flags）、超级类的索引（superclass_idx）、接口的偏移量（interfaces_off）、资源文件的索引（source_file_idx）、注释的偏移量（annotations_off）、类数据的偏移量（class_data_off）和静态值的偏移量（static_values）等内容。之后，从类定义项中查找class_data_off，根据class_data_off从数据区中查找类数据项（class data item）。class data item包括静态字段（# of static fields）、实例字段（# of instancefields）、直接方法（# of direct methods）、虚拟方法（# of virtual methods）、字段索引（field idx）和对应的访问标识、方法索引（method idx）以及对应的访问标识和代码的偏移量（code offset）。之后，从class deta item中查找method idx对应的code offset，根据code offset从数据区中查找代码项（code item）。code item包括代码项使用的寄存器（#of registers used by code item）、在参数中使用的单词（#of words used by inparameters）和实际的字节码（actua byte code）等内容。之后，即可从code item中查找到actua byte code。

应理解，图11中字节码的查找路径仅是示例性的，其并不构成对字节码的查找路径的限定，也可以采用查找路径查找源文件中的字节码。另外，也可以从源文件中的其他信息中解析出SDK涉及调用的系统接口，本申请实施例对此不做限定。

作为一个示例，在终端设备已开启针对第一应用的SDK沙盒监控功能的情况下，SDK沙盒可以对第一应用的应用文件进行解析，根据解析结果生成第一应用集成的所有SDK中的各个SDK对应的全局接口打标表。然后，根据每个SDK对应的全局接口打标表，对每个SDK调用系统接口的行为进行监测和管理。其中，每个SDK对应的全局接口打标表均可以按照上述维护第一SDK对应的全局接口打标表的方式进行。

作为另一个示例，SDK沙盒可以在第一应用安装完成后，或者在用户开启针对第一应用的目标SDK的SDK沙盒监控功能后，对第一应用的应用文件进行解析，根据解析结果生成目标SDK对应的全局接口打标表。之后，在针对第一应用的目标SDK的SDK沙盒监控功能已开启的情况下，SDK沙盒即可根据目标SDK对应的全局接口打标表，对目标SDK调用系统接口的行为进行监测和管理。其中，目标SDK可以为第一应用的任一SDK或特定SDK，比如为用户从第一应用集成的全部SDK中选择的部分SDK。

在一种可能的实现方式中，SDK沙盒可以通过hook（钩子）机制对各个系统接口进行监测和管理。比如，SDK沙盒可以预先通过hook机制对应用程序框架层的多个系统接口中的各个系统接口进行封装，使得应用层的应用中集成的SDK在调用这些系统接口时，触发调用封装后的系统接口。封装后的系统接口的执行逻辑可以为：若调用信息为第一指示信息，则对调用该系统接口（封装前的原生系统接口）的调用指令进行放行，即允许调用该系统接口；若调用信息为第二指示信息，则对调用该系统接口的调用指令进行阻塞处理，比如返回接口调用失败的指示信息。

其中，hook机制可以为Frida、Xposed或Lsposed等hook框架。这些hook框架可以在不修改APK 的情况下改变系统和APK的行为。

其中，第一指示信息用于指示该系统接口满足调用条件。第二指示信息用于指示该系统接口不满足调用条件。比如，在某个系统接口被应用中集成的SDK调用，且该SDK为待监控的SDK的情况下，该调用条件可以为该系统接口是该SDK声明的权限所涉及的系统接口。示例地，第一指示信息为第一标记，第二指示信息为第二标记。

作为一个示例，SDK沙盒可以在终端设备开机后、操作系统启动的过程中，通过hook框架对系统框架层中的系统接口进行封装。比如，在操作系统启动的过程中，在系统框架层的孵化器（zygote）进程启动后，zygote进程可以孵化（fork）应用程序进程（APP_process）。APP_process可以加载虚拟机，通过java虚拟机（java virtual machine，JVM）加载类和方法、以及系统资源等，这些类和方法包括系统接口对应的类和方法。本申请实施例中，SDK沙盒可以在zygote进程启动后，通过重写APP_process对系统接口进行封装。

请参考图12，图12是作为一示例性实施例示出的一种SDK沙盒的hook机制的逻辑示意图。如图12所示，SDK沙盒可以在zygote进程启动后，重写zygote进程所孵化的APP_process，通过重写APP_process向JVM注入hook函数，通过注入的hook函数对虚拟机加载的系统接口进行封装，得到封装后的系统接口。这样，若应用中集成的SDK需要调用系统接口，即可通过SDK沙盒调用封装后的系统接口。应理解，图12仅是一种示例性举例，其并不构成对系统接口进行监测和管理的实现方式的限定，在其他实施例中，还可以采用其他方式对系统接口进行监测和管理。

也即是，本申请实施例中，SDK沙盒可以提前通过hook机制对系统接口进行封装。对于待监控的APP，SDK沙盒监听到该APP集成的第一SDK调用第一系统接口的调用指令，可以根据第一SDK对应的全局接口打标表确定第一系统接口对应的标记信息。若第一系统接口对应的标记信息为第一标记，则根据第一标记调用封装后的第一系统接口，通过封装后的第一系统接口对该调用指令进行放行。若第一系统接口对应的标记信息为第二标记，则根据第二标记调用封装后的第一系统接口，通过封装后的第一系统接口对该调用指令进行阻塞处理。其中，封装后的第一系统接口是由SDK沙盒预先通过hook机制对第一系统接口进行封装得到，封装后的第一系统接口用于若调用信息为第一标记，则对该调用指令进行放行，即允许调用第一系统接口，若调用信息为第二标记，则对该调用指令进行阻塞处理，即不允许调用第一系统接口，比如返回接口调用失败的指示信息。其中，该指示信息可以为空值或错误信息等。

请参考图13，图13是作为一示例性实施例示出的一种SDK沙盒的监控逻辑的示意图。如图13所示，假设终端设备安装的APP A集成SDK A和SDK B，SDK声明相机权限，SDK声明位置权限。在用户开启针对APP A的SDK沙盒监控功能后，SDK沙盒可以执行如下步骤：

1、扫描APP A的应用文件，对扫描到的应用文件中的权限配置信息进行解析，解析出APP A中集成的各个SDK声明的权限。

2、对应用文件中的各个SDK的dex文件进行解析，解析出各个SDK涉及调用的系统接口。比如，SDK A涉及调用相机API和位置信息API。

3、根据各个SDK声明的权限，从各个SDK涉及调用的系统接口中筛选出与各个SDK声明的权限相关的系统接口。比如，SDK 声明相机权限，则与SDK A声明的相机权限的系统接口为相机API。

4、在初始全局接口打标表中对与各个SDK声明的权限无关的系统接口进行打标，以维护与各个SDK对应的全局接口打标表。比如，与SDK A对应的初始全局接口打标表包括操作系统的多个API以及各个API对应的默认flag=true，可以在该初始全局接口打标表中将相机API之外的API对应的flag=true更新为flag=false。

5、SDK A或SDK B通过SDK沙盒调用封装后的API。

封装后的API用于在flag=true的情况下对调用指令进行放行，在flag=false的情况下对调用指令进行阻塞处理。比如，若SDK A触发调用相机API的调用指令，则可以通过SDK沙盒调用相机API’（即封装后的相机API），由于根据全局接口打标表可以确定相机API’对应的flag=true，因此通过相机API’可以成功调用相机API。再比如，若SDK A触发调用位置信息API的调用指令，则可以通过SDK沙盒调用位置信息API’（封装后的位置信息API），由于根据全局接口打标表可以确定位置信息API’对应的flag=false，因此通过位置信息API’无法成功调用位置信息API。

接下来，结合上述图5和图13，以电子设备为手机，手机的操作系统为安卓操作系统，手机安装有APP A且APP A中集成SDK A为例，对本申请实施例提供的SDK管理方法进行详细说明。

请参考图14，图14是作为一示例性实施例示出的一种SDK管理方法的流程图。如图13所示，该方法包括如下步骤：

步骤101：API 监听配置模块在手机的操作系统启动的过程中，通过hook机制对操作系统的多个系统接口进行封装，得到封装后的API。

其中，这多个系统接口可以为操作系统的全部或部分接口，比如可以为与预设权限相关的系统接口。预设权限可以为用于能够敏感数据的敏感权限，比如位置权限、读取联系人信息权限、读取短信权限等。

其中，封装后的各个系统接口可以在调用信息为第一指示信息的情况下调用对应的原生系统接口，即对调用指令进行放行；在调用信息为第二指示信息的情况下返回接口调用失败的指示信息，即对调用指令进行阻塞处理。比如，第一指示信息为第一标记，第二指示信息为第二标记。

通过hook机制对操作系统的多个系统接口进行封装的具体实现方式可以参考上述实施例中的相关描述，本申请实施例在此不再赘述。

作为一个示例，API 监听配置模块可以在手机开机后、操作系统首次启动的过程中，通过hook机制对操作系统的多个系统接口进行封装。或者，在操作系统重启的过程中，通过hook机制对操作系统的多个系统接口进行封装。

步骤102：用户通过设置应用开启APP A的SDK沙盒监控开关。

本申请实施例中，SDK沙盒为用户提供了相关设置入口，以供用户自主选择针对哪些APP或APP中的哪些SDK开启SDK沙盒监控功能。

请参考图6，用户可以点击图6中的（a）图中的设置应用的图标，进入图6中的（b）图所示的设置界面。然后该设置界面中的“隐私保护”选项，进入图6中的（c）图中的隐私保护设置界面。然后，点击隐私保护设置界面中的“SDK沙盒监控”选项，进入图6中的（d）图所示的SDK沙盒监控设置界面，SDK沙盒监控设置界面包括多个应用的标识以及各个应用对应的SDK沙盒监控控件，若用户想要开启针对某个应用的SDK沙盒监控功能，则可以点击该应用对应的SDK沙盒监控控件。比如，假设这多个应用包括APP A，若用户想要开启APP A的SDK沙盒监控功能，则可以点击APP A对应的SDK沙盒监控开关，以开启对应的SDK沙盒监控开关。

步骤103：响应于用户的开启操作，设置应用向SDK沙盒中的dex文件读取模块和沙盒监控模块发送监控开启指令，该监控开启指令携带APP A的标识。

该监控开启指令用于指示APP A的SDK沙盒监控开关已开启，可以开始对APP A集成的各个SDK调用API的行为进行监测和管理。APP A的标识可以为APP A的名称、ID或包名等，本申请实施例对此不做限定。

步骤104：dex文件读取模块根据APP A的标识，扫描APP A的应用文件。

dex文件读取模块可以根据APP A的标识，查找APP A的应用文件，并对APP A的应用文件进行扫描。

作为一个示例，SDK沙盒进程可以为常驻后台进程，在接收到针对任意APP或任意SDK的监控开启指令后，即可对对应APP的应用文件进行扫描和解析，以根据解析结果维护全局接口打标表，根据全局接口打标表对待监控SDK调用API的行为进行监测和管理。

需要说明的是，在针对APP A的SDK沙盒监控开关首次开启时，dex文件读取模块可以对APP A的应用文件和解析，以根据解析结果维护全局接口打标表。之后，若APP A的SDK沙盒监控开关在关闭后又重新开启，则无需再对APP A的应用文件和解析，直接根据维护的全局接口打标表对APP A集成的SDK调用API的行为进行监测和管理即可。

步骤105：dex文件读取模块对扫描到的APP A的应用文件进行解压，得到权限配置信息、dex文件集合和其他文件。

其中，权限配置信息包括APP A集成的所有SDK中各个SDK的包名和声明的权限信息。dex文件集合包括APP A集成的所有SDK中各个SDK的dex文件。

步骤106：dex文件读取模块从权限配置信息中读取SDK A的包名和声明的权限信息。

示例地，APP A的权限配置信息可以包括如下内容：

SDK A packagename：[1.相机权限；]

SDK B packagename：[1.位置信息权限；]

根据权限配置信息可以确定SDK A声明了相机权限。

应理解，APP A还可以集成其他SDK，dex文件读取模块从权限配置信息中读取其他SDK的包名和声明的权限信息，比如可以读取SDK B的包名和声明的权限信息。

步骤107：dex文件读取模块根据SDK A的包名，从dex文件集合中确定SDK A的dex文件，对SDK A的dex文件进行解析，以确定SDK A涉及调用的API。

作为一个示例，可以采用dex文件解析工具对SDK A的dex文件进行解析。

作为一个示例，可以先对SDK A的dex文件进行反编译，得到可dex文件的源文件。然后，确定源文件中的代码项，从代码项包括的字节码中解析出第一SDK涉及调用的系统接口。

需要说明的是，确定源文件中的代码项，从代码项包括的字节码中解析出第一SDK涉及调用的系统接口的实现方式可以参考上述相关描述，本申请实施例在此不再赘述。

步骤108：dex文件读取模块根据SDK A 声明的权限，从SDK A涉及调用的API中确定与SDK A所声明的权限相关的API。

比如，SDK A声明了相机权限，SDK A涉及调用的API包括相机API和位置信息API。则，是与SDK A所声明的相机权限相关的API为相机API。

步骤109：dex文件读取模块向沙盒监控模块发送与SDK A所声明的权限相关的API的标识。

比如，向沙盒监控模块发送相机API的标识。

步骤110：沙盒监控模块对初始全局接口打标表中除与SDK A声明的权限相关的API之外的其他API对应的标记信息更新为第二标记，以得到SDK A对应的全局接口打标表。

初始全局接口打标表包括操作系统的多个API的标识以及对应的初始标记信息，初始标记信息为第一标记。通过对初始全局接口打标表进行打标，可以将与SDK A声明的权限无关的API的标记信息修改为第二标记，以便沙盒监控模块后续可以根据全局接口打标表中各个API对应的标记信息快速判断SDK A调用的API是否为SDK A声明权限涉及的API，即是否是其声明的权限允许调用的API。

应理解，本申请实施例仅是以dex文件读取模块将与SDK A声明的权限相关的API的标识发送给沙盒监控模块，由沙盒监控模块根据与SDK A声明的权限相关的API的标识构建全局接口打标表为例，在其他实施例中，还可以由dex文件读取模块根据与SDK A声明的权限相关的API维护全局接口打标表构建全局接口打标表，再将全局接口打标表发送给沙盒监控模块。

需要说明的是，APP A还可以集成其他SDK，dex文件读取模块还可以对其他SDK的dex文件进行解析，根据解析结果与沙盒监控模块一起维护其他SDK对应的全局接口打标表，以便沙盒监控模块根据其他SDK对应的全局接口打标表，对其他SDK调用API的行为进行监测和管理。

步骤111：APP A中的SDK A触发调用第一API的调用指令1。

其中，调用指令1可以携带SDK A的标识以及第一API的标识。第一API可以为操作系统的任一API，本申请实施例对此不做限定。

步骤112：沙盒监控模块监听到该调用指令1。

步骤113：沙盒监控模块在监听到该调用指令1后，根据第一API从全局接口打标表中查找第一API对应的标记信息。

步骤114：在第一API对应的标记信息为第二标记的情况下，沙盒监控模块根据第二标记调用封装后的第一API。

若第一API对应的标记信息为第二标记，则说明第一API不是SDK A声明的权限涉及的API，即不是SDK A声明的权限允许调用的API，这种情况下，可以根据第二标记调用封装后的第一API，以通过封装后的第一API对调用第一API的调用指令1进行阻塞处理。

比如，假设第二标记为flag=false，则沙盒监控模块可以根据flag=false调用封装后的第一API。示例地，沙盒监控模块可以向封装后的第一API发送携带第二标记的调用指令2，来调用封装后的第一API。

步骤115：封装后的第一API在调用信息为第二标记的情况下，通过沙盒监控模块向SDKA发送接口调用失败的指示信息。

其中，接口调用失败的指示信息用于指示对第一API调用失败。比如，该指示信息可以为空值或错误信息等。本申请实施例中，可以通过在调用信息为第二标记的情况下返回接口调用失败的指示信息，实现对调用第一API的调用指令1的阻塞处理。

比如，封装后的第一API在调用信息为第二标记的情况下，向沙盒监控模块发送接口调用失败的指示信息，由沙盒监控模块将接口调用失败的指示信息转发给SDKA。

为了进一步提高隐私保护的灵活性，封装后的第一API在调用信息为第二标记的情况下，还可以先触发手机显示提示信息，以询问用户是否允许SDK A调用第一API。比如，触发手机显示消息弹窗，该消息弹窗包括提示信息“APP A集成的SDK A正在调用第一API，是否允许？”，以及“同意选项”和“拒绝选项”。若用户不允许SDK A调用第一API，则可以点击“拒绝选项”。响应于用户点击“拒绝选项”的操作，封装后的第一API通过沙盒监控模块向SDKA发送接口调用失败的指示信息，以对调用指令1进行阻塞处理。

另外，若用户允许SDK A调用第一API，还可以点击“同意选项”。响应于用户点击“同意选项”的操作，封装后的第一API还可以调用API，以对调用指令1进行放行。

步骤116：在第一API对应的标记信息为第一标记的情况下，沙盒监控模块根据第一标记调用封装后的第一API。

若第一API对应的标记信息为第一标记，则说明第一API是SDK A声明的权限涉及的API，即是SDK A声明的权限允许调用的API，这种情况下，可以根据第一标记调用封装后的第一API，以通过封装后的第一API对调用第一API的调用指令1进行放行。

比如，假设第一标记为flag=true，则沙盒监控模块可以根据flag=true调用封装后的第一API。示例地，沙盒监控模块可以向封装后的第一API发送携带第一标记的调用指令3，来调用封装后的第一API。

步骤117：封装后的第一API在调用信息为第一标记的情况下，调用第一API。

封装后的第一API在调用信息为第一标记的情况下，对调用第一API的调用指令1进行放行，即允许调用第一API。比如，封装后的第一API可以将调用指令1发送给第一API。

步骤118：第一API通过沙盒监控模块向SDK A向发送第一API获取的相关数据。

第一API在被调用后，可以获取相关数据，并返回获取的相关数据。

比如，第一API可以将获取的相关数据经封装后的API发送给沙盒监控模块，再由沙盒监控模块转发给SDK A。

本申请实施例中，在终端设备的操作系统中设置了SDK沙盒，可以通过SDK沙盒对应用中集成的SDK调用API的行为进行监控。其监控逻辑为：若SDK沙盒监听到APP A集成的SDK A调用第一API的调用指令，则在第一API不是SDK A声明的权限所涉及的系统接口的情况下，对该调用指令进行阻塞处理，即不对该调用指令进行放行，从而不允许调用第一API。在第一API是SDK A声明的权限所涉及的系统接口的情况下，对该调用指令进行放行，即允许调用第一API。如此，可以保障SDK A可以正常调用声明的权限所涉及的系统接口，但无法成功调用未声明的权限所涉及的系统接口，进而无法通过未声明的权限获取用户隐私数据，大大降低了第三方SDK越权收集用户隐私数据的可能性，提高了用户隐私数据的安全性。而且，这种解决方案是在原有SDK集成框架实现的，仅需在电子设备的操作系统中额外设置具有对SDK调用系统接口的行为进行监控功能的SDK沙盒即可，无需对SDK单独上架，降低了SDK的分发和管理的复杂化，对原有SDK集成框架的兼容性较高。

本文中描述的各个实施例可以为独立的方案，也可以根据内在逻辑进行组合，这些方案都落入本申请的保护范围中。

可以理解的是，上述各个方法实施例中由电子设备实现的方法和操作，也可以由可用于电子设备的部件（例如芯片或者电路）实现。

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

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

本申请还提供一种芯片，该芯片与存储器耦合，该芯片用于读取并执行存储器中存储的计算机程序或指令，以执行上述各实施例中的方法。

本申请还提供一种电子设备，该电子设备包括芯片，该芯片用于读取并执行存储器存储的计算机程序或指令，使得各实施例中的方法被执行。

本实施例还提供一种计算机可读存储介质，该计算机可读存储介质中存储有计算机指令，当该计算机指令在电子设备上运行时，使得电子设备执行上述相关方法步骤实现上述实施例中的SDK的管理方法。

本实施例还提供了一种计算机程序产品，该计算机可读存储介质存储有程序代码，当该计算机程序产品在计算机上运行时，使得计算机执行上述相关步骤，以实现上述实施例中的SDK的管理方法。

另外，本申请的实施例还提供一种装置，这个装置具体可以是芯片，组件或模块，该装置可包括相连的处理器和存储器；其中，存储器用于存储计算机执行指令，当装置运行时，处理器可执行存储器存储的计算机执行指令，以使芯片执行上述各方法实施例中的SDK的管理方法。

其中，本实施例提供的电子设备、计算机可读存储介质、计算机程序产品或芯片均用于执行上文所提供的对应的方法，因此，其所能达到的有益效果可参考上文所提供的对应的方法中的有益效果，此处不再赘述。

本申请实施例并未对本申请实施例提供的方法的执行主体的具体结构进行特别限定，只要能够通过运行记录有本申请实施例提供的方法的代码的程序，以根据本申请实施例提供的方法进行视频处理即可。例如，本申请实施例提供的方法的执行主体可以是电子设备，或者，是电子设备中能够调用程序并执行程序的功能模块。

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

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

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

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

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (20)

1.一种SDK的管理方法，其特征在于，应用于电子设备中，所述电子设备的操作系统包括第一应用和软件开发工具包SDK沙盒，所述第一应用集成有第一SDK，所述方法包括：

所述SDK沙盒若监听到所述第一SDK调用第一系统接口的调用指令，则在所述第一系统接口不是所述第一SDK声明的权限所涉及的系统接口的情况下，对所述调用指令进行阻塞处理；

所述SDK沙盒在所述第一系统接口是所述第一SDK声明的权限涉及的系统接口的情况下，对所述调用指令进行放行。

2.如权利要求1所述的方法，其特征在于，所述对所述调用指令进行阻塞处理之前，还包括：

所述SDK沙盒触发所述电子设备显示提示信息，所述提示信息用于询问用户是否允许所述第一SDK调用所述第一系统接口；

所述SDK沙盒响应于用户的拒绝操作，执行对所述调用指令进行阻塞处理的步骤。

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

所述SDK沙盒响应于用户的允许操作，对所述调用指令进行放行。

4.如权利要求1所述方法，其特征在于，所述监听到所述第一SDK调用第一系统接口的调用指令之后，还包括：

所述SDK沙盒根据所述第一SDK对应的接口权限信息，确定所述第一系统接口是否为所述第一SDK声明的权限涉及的系统接口；

其中，所述接口权限信息存储有以下内容中的任一种：

所述操作系统的多个系统接口的接口标识以及各个系统接口对应的标记信息，所述标记信息用于指示对应系统接口是否为与所述第一SDK声明的权限相关的系统接口，所述多个系统接口包括所述第一系统接口；

若干个第一接口的接口标识，所述若干个第一接口为所述多个系统接口中与所述第一SDK声明的权限相关的系统接口；

若干个第二接口的接口标识，所述若干个第二接口为所述多个系统接口中与所述第一SDK声明的权限无关的系统接口。

5.如权利要求4所述的方法，其特征在于，所述多个系统接口为所述操作系统的系统接口中与预设权限相关的系统接口。

6.如权利要求4所述的方法，其特征在于，所述接口权限信息包括所述多个系统接口的接口标识以及各个系统接口对应的标记信息，所述标记信息包括第一标记和第二标记，所述第一标记用于指示对应系统接口是与所述第一SDK声明的权限相关的系统接口，所述第二标记用于指示对应系统接口是与所述第一SDK声明的权限无关的系统接口；

所述根据所述第一SDK对应的接口权限信息，确定所述第一系统接口是否为所述第一SDK声明的权限涉及的系统接口，包括：

从所述接口权限信息中查找所述第一系统接口对应的标记信息；

若所述第一系统接口对应的标记信息为所述第一标记，则确定所述第一系统接口是所述第一SDK声明的权限所涉及的系统接口；

若所述第一系统接口对应的标记信息为所述第二标记，则确定所述第一系统接口不是所述第一SDK声明的权限所涉及的系统接口。

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

在接收到用户的允许操作后，将所述接口权限信息中的所述第一系统接口对应的标记信息更新为所述第一标记，所述允许操作用于指示允许所述第一SDK调用所述第一系统接口。

8.如权利要求6所述的方法，其特征在于，所述从所述接口权限信息中查找所述第一系统接口对应的标记信息之前，还包括：

获取初始接口权限信息，所述初始接口权限信息包括所述多个系统接口的接口标识以及各个系统接口对应的初始标记信息，所述初始标记信息为所述第一标记；

将所述初始接口权限信息中与所述第一SDK声明的权限无关的系统接口对应的标记信息更新为所述第二标记，以得到所述接口权限信息。

9.如权利要求4所述的方法，其特征在于，所述接口权限信息包括所述若干个第一接口的接口标识，所述根据所述第一SDK对应的接口权限信息，确定所述第一系统接口是否为所述第一SDK声明的权限涉及的系统接口，包括：

若所述若干个第一接口中存在所述第一系统接口，则确定所述第一系统接口是所述第一SDK声明的权限所涉及的系统接口；

若所述若干个第一接口中不存在所述第一系统接口的接口标识，则确定所述第一系统接口不是所述第一SDK声明的权限所涉及的系统接口。

10.如权利要求4所述的方法，其特征在于，所述接口权限信息包括所述若干个第二接口的接口标识，所述根据所述第一SDK对应的接口权限信息，确定所述第一系统接口是否为所述第一SDK声明的权限涉及的系统接口，包括：

若所述若干个第二接口中存在所述第一系统接口，则确定所述第一系统接口不是所述第一SDK声明的权限所涉及的系统接口；

若所述若干个第二接口中存在所述第一系统接口的接口标识，则确定所述第一系统接口是所述第一SDK声明的权限所涉及的系统接口。

11.如权利要求4所述的方法，其特征在于，所述根据所述第一SDK对应的接口权限信息，确定所述第一系统接口是否为所述第一SDK声明的权限涉及的系统接口之前，还包括：

对所述第一应用的应用文件进行解析，以确定第一SDK声明的权限，以及所述第一SDK涉及调用的系统接口；

根据所述第一SDK声明的权限，从所述第一SDK涉及调用的系统接口中确定与所述第一SDK声明的权限相关的系统接口；

根据确定的系统接口，生成所述接口权限信息。

12.如权利要求11所述的方法，其特征在于，所述根据确定的系统接口，生成所述接口权限信息，包括：

将所述多个系统接口中除确定的系统接口之外的其他接口，确定为与所述第一SDK声明的权限无关的系统接口；

根据确定的与所述第一SDK声明的权限相关的系统接口和/或与所述第一SDK声明的权限无关的系统接口，生成所述接口权限信息。

13.如权利要求11所述的方法，其特征在于，所述对所述第一应用的应用文件进行解析，以确定第一SDK声明的权限，以及所述第一SDK涉及调用的系统接口，包括：

从所述第一应用的应用文件中确定权限配置信息，所述权限配置信息包括所述第一应用集成的各个SDK声明的权限；

根据所述权限配置信息，确定所述第一SDK声明的权限；

从所述第一应用的应用文件中确定所述第一SDK的可执行文件；

根据所述可执行文件，确定所述第一SDK涉及调用的系统接口。

14.如权利要求13所述的方法，其特征在于，所述根据所述可执行文件，确定所述第一SDK涉及调用的系统接口，包括：

对所述可执行文件进行反编译，得到所述可执行文件的源文件；

确定所述源文件中的代码项，所述代码项包括字节码；

从所述字节码中解析出所述第一SDK涉及调用的系统接口。

15.如权利要求1所述的方法，其特征在于，所述SDK沙盒在所述第一系统接口不是所述第一SDK声明的权限所涉及的系统接口的情况下，对所述调用指令进行阻塞处理，包括：

所述SDK沙盒在所述第一系统接口不是所述第一SDK声明的权限所涉及的系统接口的情况下，根据第二指示信息调用封装后的第一系统接口，通过所述封装后的第一系统接口对所述调用指令进行阻塞处理；

其中，所述封装后的第一系统接口用于在调用信息为第一指示信息的情况下调用所述第一系统接口，在调用信息为所述第二指示信息的情况下返回接口调用失败的指示信息。

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

所述SDK沙盒在所述第一系统接口是所述第一SDK声明的权限所涉及的系统接口的情况下，根据所述第一指示信息调用所述封装后的第一系统接口，通过所述封装后的第一系统接口对所述调用指令进行放行。

17.如权利要求15所述的方法，其特征在于，所述根据第二指示信息调用封装后的第一系统接口之前，还包括：

所述SDK沙盒在所述操作系统启动的过程中，对所述操作系统的多个系统接口进行封装，得到封装后的多个系统接口；

其中，每个封装后的系统接口均用于在调用信息为所述第一指示信息的情况下调用对应的原生系统接口，在调用信息为所述第二指示信息的情况下返回接口调用失败的指示信息。

18.如权利要求1-17任一所述的方法，其特征在于，所述电子设备还包括显示屏，所述方法还包括：

所述显示屏显示第一界面，所述第一界面包括SDK沙盒监控选项；

响应于用户对所述SDK沙盒监控选项的点击操作，所述显示屏显示第二界面，所述第二界面包括多个应用的应用标识以及每个应用标识对应的开关控件，所述多个应用包括所述第一应用；

响应于用户对所述第一应用的应用标识对应的开关控件的开启操作，所述SDK沙盒执行所述SDK的管理方法。

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

20.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行如权利要求1-18任意一项所述的方法。