CN109815682B - 一种对权限进行追踪管理的方法、装置和计算机记录介质 - Google Patents

Abstract

本公开涉及一种对权限进行追踪管理的方法、装置和计算机记录介质。该方法由计算机实现，且包括：建立第一配置文件和第二配置文件，所述第一配置文件用于存储常规权限，所述第二配置文件用于存储与权限的引入相关的信息；在应用的编译过程中执行如下步骤：获取所有声明的权限；判定各个声明的权限是否在第一配置文件和第二配置文件中的任一个中；在判定结果为否的情况下，提供相应的提醒。上述的对权限进行追踪管理的方法、装置和计算机记录介质能够在编译过程中完成对风险权限的监控，在提交代码之前就能完成高效改正，改正的成本低，且不会延误发版。

Description

一种对权限进行追踪管理的方法、装置和计算机记录介质

技术领域

本公开涉及一种对权限进行追踪管理的方法、装置和计算机记录介质。

背景技术

目前在安卓(Android)操作系统或者苹果(iOs)操作系统上各种应用(App)中许多功能的使用都需要先声明权限，但是权限不能随意申请，如果申请过多的权限，会产生对APP的不利影响。例如，安装器会列出所有申请的权限，申请过多权限，则这些权限中可能有些涉及到隐私，从而可能导致用户取消安装。又例如，各种安全类软件可能针对某些权限设定，从而在申请某些权限时弹出警告，从而也可能导致用户取消安装。进一步地，如果App存在漏洞，则权限申请越多可能造成的风险也越大。因此需要对权限进行追踪和管理，但目前通常在App发版前扫描所有使用的权限，然后和该App之前的版本就使用的权限进行对比。这种方式对于问题的发现滞后(在提交代码之后)，改动成本大，可能会导致延误发版；并且不能方便且针对性地对权限的引入进行追踪管理，导致开发者纠正问题的效率较低。

发明内容

因此，需要一种对权限进行追踪管理的方法、装置和计算机记录介质来解决上述问题。需要一种对权限进行追踪管理的方法、装置和计算机记录介质，其能够方便、准确且早期发现权限的变动，从而指导开发者高效且早期地纠正权限相关的问题。

根据本公开的第一方案，提供一种对权限进行追踪管理的方法，其由计算机实现，且其特征在于，所述方法包括：建立第一配置文件和第二配置文件，所述第一配置文件用于存储常规权限，所述第二配置文件用于存储与权限的引入相关的信息；在应用的编译过程中执行如下步骤：获取所有声明的权限；判定各个声明的权限是否在第一配置文件和第二配置文件中的任一个中；在判定结果为否的情况下，提供相应的提醒。

在一些实施例中，通过如下方式中的至少一种提供相应的提醒：终止所述编译过程；发出提示信息；以及将相应的提醒信息写入提示文件中以供开发者查看。

在一些实施例中，所述方法还包括：在判定结果为是的情况下，核实所述第二配置文件中与权限的引入相关的信息是否与相应模块的权限声明一致，如果不一致，则终止所述编译过程。

在一些实施例中，如果所述第二配置文件中与权限的引入相关的信息与相应模块的权限声明不一致，则更新与权限的引入相关的信息，使之与相应模块的权限声明一致。

在一些实施例中，与权限的引入相关的信息包括相应权限的引入来源和引入原因。

在一些实施例中，所述第二配置文件采用xml格式，且包括：与权限对应设置的xml节点，其列出使用相应权限的模块；以及模块节点，其包含模块的包名以及引入相应权限的原因。

在一些实施例中，获取所有声明的权限的步骤包括：从处理清单文件的任务的输出获取合并后的全清单文件，并从所述全清单文件中解析出所有声明的权限。

在一些实施例中，获取所有声明的权限的步骤包括：从处理清单文件的任务的输入获取各个模块的清单文件；对各个模块的清单文件进行解析，以得到相应各个模块所声明的权限；以及在当前模块的清单文件中有针对下一级模块的权限的删除指令的情况下，删除相应权限，使用剩余的权限作为所述所有声明的权限。

根据本公开的第二方案，提供一种对权限进行追踪管理的装置，所述装置包括存储有计算机可执行指令的存储器和处理器，其特征在于，所述处理器执行所述计算机可执行指令时，实现如下步骤：建立第一配置文件和第二配置文件，所述第一配置文件用于存储常规权限，所述第二配置文件用于存储与权限的引入相关的信息；在应用的编译过程中执行如下步骤：获取所有声明的权限；判定各个声明的权限是否在第一配置文件和第二配置文件中的任一个中；在判定结果为否的情况下，提供相应的提醒。

根据本公开的第三方案，提供一种非暂时性的计算机记录介质，其上存储有计算机可执行指令，所述计算机可执行指令被处理器执行时实现如下步骤：建立第一配置文件和第二配置文件，所述第一配置文件用于存储常规权限，所述第二配置文件用于存储与权限的引入相关的信息；在应用的编译过程中执行如下步骤：获取所有声明的权限；判定各个声明的权限是否在第一配置文件和第二配置文件中的任一个中；在判定结果为否的情况下，终止所述编译过程。

上述的对权限进行追踪管理的方法、装置和计算机记录介质能够在编译过程中完成对风险权限的监控和提醒，在提交代码之前就能够引导开发者完成高效的改正，改正的成本低，且不会延误发版。

附图说明

在不一定按比例绘制的附图中，相同的附图标记可以描述不同视图中的类似部件。具有字母后缀或不同字母后缀的相同数字可表示类似部件的不同实例。附图通常通过示例而非通过限制的方式示出了各种实施例，并且与说明书以及权利要求书一起用于对所公开的实施例进行说明。在适当的时候，在所有附图中使用相同的附图标记指代同一或相似的部分。这样的实施例是例证性的，而并非旨在作为本方法、装置、或其上存储有用于实现该方法的指令的非暂时性计算机可读介质的穷尽或排他实施例。下面将参照附图描述本发明的示例性实施例的特征、优点以及技术和工业重要性，附图中相同的数字表示相同的元件，并且其中：

图1示出根据本公开第一实施例的一种对权限进行追踪管理的方法的流程图；

图2示出根据本公开第二实施例的一种对权限进行追踪管理的方法的流程图；以及

图3示出根据本公开第三实施例的一种对权限进行追踪管理的装置的框图。

具体实施方式

在下文中，技术术语“模块”表示各种操作系统中运行的app的开发进程中各种阶段的软件模块。操作系统例如可以包括苹果公司的iOS操作系统或者Google公司开发的Android操作系统，但不限于此。以Android操作系统为例，所述模块诸如可以包括在各种开发环境(例如但不限于Android Studio集成开发环境)下由开发者自己开发的尚未打包的模块，对模块打包后所得到的打包模块(例如后缀为aar的打包模块)，开发者使用的来自第三方的sdk模块(例如地图导航sdk模块)等等。本文中技术术语“清单文件”在Android操作系统下指各个App的根目录下的AndroidManifest.xml文件(也简称为Manifest文件或者清单文件)，清单文件向Android系统提供应用的必要信息，例如，为应用的软件包名、描述应用的各个组件、声明应用必须具备哪些权限才能访问API中受保护的部分并与其他应用交互、声明其他应用与该应用组件交互所需具备的权限等，系统必须具有这些信息才可运行应用的任何代码。在iOS操作系统中info.plist文件起到所述“清单文件”的作用，在此不赘述。

图1示出根据本公开第一实施例的一种对权限进行追踪管理的方法的流程图。如图1所示，所述对权限进行追踪管理的方法的流程100始于步骤101，建立第一配置文件和第二配置文件，所述第一配置文件用于存储常规权限，所述第二配置文件用于存储与权限的引入相关的信息。在本文中，常规权限表示常用且用户不敏感的权限，比如联网的权限等；与权限的引入相关的信息可以体现各个权限的引入来源(例如由哪些模块、打包模块或者SDK模块引入的)以及具体的引入原因。在一些实施例中，所述第一配置文件和第二配置文件可以采用各种在不同操作系统下通用的格式，例如，第一配置文件可以采用纯文本(txt)格式以节省存储空间，而第二配置文件可以采用xml或者json之类的通用格式。接着，在编译过程中基于所建立的第一和第二配置文件完成权限的追踪和管理，具体说来，在步骤102，获取所有声明的权限，注意，本文中“所有声明的权限”与整个App打包后形成的apk文件的所有声明的权限相同，也就是对各个独立的模块的模块清单文件进行合并(merge)操作后所得到的剩余的所有声明的权限。在步骤103，判定各个声明的权限是否包含在第一配置文件和第二配置文件中的任一个中，在此，第一配置文件和第二配置文件共同形成声明的权限的“白名单”，认为没有落在“白名单”中的声明的权限是新增的且有风险的。如果步骤103的判定结果为否，则认为该声明的权限有风险，提供相应的提醒(步骤104)。在一些实施例中，可以通过如下方式中的至少一种提供相应的提醒：终止所述编译过程；发出提示信息；以及将相应的提醒信息写入提示文件中以供开发者查看。由此开发者在编译过程中即可得知哪些声明的权限有风险，并按照需求进行代码的修改。在一些实施例中，可以以编译错误的形式终止编译，并向开发者给出对应的错误提示信息，提醒开发者检查新增的风险权限，从而在提交代码之前就能完成高效且针对性的改正，改正的成本低，且不会延误发版。如果步骤103的判定结果为是，则流程进行到步骤105，在步骤105视权限的追踪精度采取不同步骤。在一些实施例中，可以认为落在“白名单”中的声明的权限是合理且安全的，则在步骤105，权限的追踪管理流程100结束，继续后续的编译过程。在一些实施例中，在步骤105，可以对落在“白名单”中的声明的权限进行进一步的核查。例如，可以核实所述第二配置文件中与权限的引入相关的信息与相应模块的权限声明是否一致，也就是说，第二配置文件中对于权限的配置(什么权限、由什么模块引入以及什么原因引入等)准确地反映了各个模块中声明的权限，不多配置也不少配置，如果不一致，则终止所述编译过程。在一些实施例中，可以为每个声明的权限核查该声明的权限的配置(所对应的模块及具体引入原因)与第二配置文件中对应的权限节点下的配置(所对应的模块及具体引入原因)是否一致，如果核查结果一致，则认为该声明的权限是安全且合理的，如果不一致，则发现了新增的且没有为其正确配置对应模块和引入原因的权限，如此，开发者除了知晓新增的权限之外，还能具体知道哪个模块引入了该权限以及因为什么原因引入该权限，从而进一步提高改正代码的针对性和效率。

下面以在Android操作系统中运行的App的编译过程为例，对根据本公开第二实施例的一种对权限进行追踪管理的方法的流程200进行说明。需要知道，基于下面的说明，本领域技术人员也可以利用在iOS操作系统下运行的App的编译过程实现相应的追踪管理的方法，具体实现过程在此不赘述。须知，不管App是在什么操作系统中运行，其可以在通用的开发机上进行开发和编译，在此不赘述。

如图2所示，根据本公开第二实施例的一种对权限进行追踪管理的方法的流程200始于步骤201，建立第一和第二配置文件，第一配置文件例如acceptable-permissions.txt，用于保存常规的权限，比如联网的权限android.permission.INTERNET，第二配置文件例如permission-track.xml，用于存储与权限的引入相关的信息，用于配置各个权限是因为哪些模块引入的以及引入的原因。第二配置文件可以采用各种格式，例如xml格式，且可以包括：与权限对应设置的xml节点，例如为每个权限设立相应的一个xml节点，其列出使用相应权限的模块；以及模块节点，其包含模块的包名以及引入(依赖)相应权限的原因。

接着，可以在编译过程中增加一个任务以实现对权限的追踪和管理。在一些实施例中，该权限的追踪和管理任务始于获取所有声明的权限。例如，可以获取所有模块中的清单文件，例如AndroidManifest.xml文件，并对这些AndroidManifest.xml文件(本文中可称为模块清单文件)进行诸如合并(融合)的复合处理，来获取与打包得到的apk相同的所有声明的权限。这种复合处理可以采用各种方式来实现。在一些实施例中，可以由开发者自行编写复合任务，用于对各个模块清单文件进行解析以得出每个模块所声明的权限，然后对所得到的每个模块各自所声明的权限进行诸如合并融合的复合处理。在一些实施例中，所述复合处理例如可以包括：如果当前AndroidManifest.xml文件或者它的上一级模块中的AndroidManifest.xml中有针对某个权限的tools:node＝"remove"，则对某个权限做相应的移除处理(简称为移除处理)，使用剩余的权限作为所述所有声明的权限；和/或，如果存在Manifest Placeholder定义，则根据Manifest Placeholder中的映射值处理(简称为映射处理)上一步中的权限声明以得到最终的权限声明。在一些实施例中，可以直接利用Android编译框架中现成的处理Manifest文件(清单文件)的任务(processDebugManifest/processReleaseManifest)，从该processDebugManifest/processReleaseManifest任务的输入可以获取到所有模块中的模块清单原件，从该任务的输出可以获取到诸如合并融合的复合处理之后的AndroidManifest.xml文件(称之为全清单文件)。例如，如图2所示，可以先执行处理清单文件的任务(步骤202)，然后从处理清单文件的任务的输出获取合并后的全清单文件，并从所述全清单文件中解析出所有声明的权限(步骤203)，解析所得的就是当前apk所有声明的权限，和上一次编译输出的对比，就能得出本次声明的权限的增减状况。在一些实施例中，也可以从处理清单文件的任务的输入获取各个模块的模块清单文件；对各个模块的模块清单文件进行解析，以得到相应各个模块所声明的权限；然后，对各个模块的声明权限进行根据本公开各个实施例的复合处理，例如移除处理和映射处理，复合处理后的声明的权限就是当前apk所有声明的权限。

依据上一步的结果，按module维度遍历(步骤209和步骤207)它们所有声明的权限，并判定当前编号的模块的所有声明的权限是否包含在第一配置文件acceptable-permissions.txt中(步骤204)。如果是，则认为该模块的声明的权限是安全合理的，递减模块编号，继而对下一模块的所有声明的权限进行核查。如果步骤204的判定结果为否，则判定当前编号的模块的所有声明的权限是否包含在第二配置文件permission-track.xml中(步骤205)，如果是，则继续判定当前编号的模块的所有声明的权限与第二配置文件permission-track.xml中相应权限的引入相关信息是否严格一致(步骤206)，例如，判定第二配置文件permission-track.xml中相应权限节点下有否当前模块的配置。如果步骤206的判定结果为是，则认为该模块的声明的权限是安全合理的，递减模块编号，继而对下一模块的所有声明的权限进行核查。如果当前编号的模块的所有声明的权限既没有包含在第一配置文件acceptable-permissions.txt中，也没有包含在permission-track.xml中，或者permission-track.xml中该权限节点下没有当前模块的配置，则认为发现了新增的并且没有配置引入模块和原因的权限，提供相应的提醒(步骤208)，在一些实施例中，可以通过如下方式中的至少一种提供相应的提醒：终止所述编译过程；发出提示信息；以及将相应的提醒信息写入提示文件中以供开发者查看。由此开发者在编译过程中即可得知哪些声明的权限有风险，并按照需求进行代码的修改。例如，可以以编译错误的形式终止编译，并给出错误提示信息。

在一些实施例中，可以将新增的并且没有配置引入模块和原因的权限其加入到new_permission_set集合中，如果new_permission_set集合不为空，那么以编译错误的形式终止编译，并给出错误提示信息，开发者可以根据错误提示信息对代码进行修改后再重新进行编译。如果对所有模块遍历后new_permission_set集合依然为空，则认为没有发现新增的且没有配置的权限，从而可以认为没有出错并继续进行后续的编译。

在一些实施例中，在步骤206中或之后，可以引入附加的校验步骤(未图示)，在校验步骤中，核实所述第二配置文件permission-track.xml中与权限的引入相关的信息是否与相应模块的权限声明一致，也就是核实permission-track.xml中的所有声明是否确实有效。如果所述第二配置文件中与权限的引入相关的信息与相应模块的权限声明不一致(也就是发现无效的配置)，则可以以各种方式提供相应的提醒，例如可以编译错误的形式抛出并终止编译过程。在一些实施例中，如果所述第二配置文件中与权限的引入相关的信息与相应模块的权限声明不一致，可以更新与权限的引入相关的信息，使之与相应模块的权限声明一致。如此使得开发者能够同步维护permission-track.xml配置文件，从而保证permission-track.xml中配置的权限都精确的反应了各个模块中声明的权限，不少配置，也不多配置；便利把握App开发过程中同一个权限可能多次的引入和移除的变动情况以及每次变动的原因，从而避免遗漏权限的不合理或原因敏感特殊的变动。

利用根据本公开各种实施例的对权限进行追踪管理的流程200，可以在编译过程中及时发现并定位变动的权限，且开发者能明确知道权限的变动是由哪个模块因为什么原因引入，从而提高追踪管理的效率，并在提交代码(打包)之前就能改正所有风险权限的配置，从而降低开发成本并缩短开发周期。

图3示出根据本公开第三实施例的一种对权限进行追踪管理的装置的框图。如图3所示，所述对权限进行追踪管理的装置300包括存储有计算机可执行指令的存储器301和处理器302，所述处理器302执行所述计算机可执行指令时，实现如下步骤：建立第一配置文件和第二配置文件，所述第一配置文件用于存储常规权限，所述第二配置文件用于存储与权限的引入相关的信息；在应用的编译过程中执行如下步骤：获取所有声明的权限；判定各个声明的权限是否包含在第一配置文件和第二配置文件中的任一个中；在判定结果为否的情况下，提供相应的提醒。在一些实施例中，可以通过如下方式中的至少一种提供相应的提醒：终止所述编译过程；发出提示信息；以及将相应的提醒信息写入提示文件中以供开发者查看。由此开发者在编译过程中即可得知哪些声明的权限有风险，并按照需求进行代码的修改。

在一些实施例中，处理器302可以是包括一个或多个通用处理装置的处理装置，诸如微处理器、中央处理单元(CPU)、图形处理单元(GPU)等。更具体地，处理器302可以是复杂指令集计算(CISC)微处理器、精简指令集计算(RISC)微处理器、超长指令字(VLIW)微处理器、运行其他指令集的处理器或者运行指令集的组合的处理器。另外，术语“处理器”或“图像处理器”可以包括一个以上的处理器，例如，多核设计或多个处理器，每个处理器具有多核设计。处理器302可以通信地耦合到存储器301并且被配置为执行存储在其中的计算机可执行指令，以执行根据本公开各种实施例的操作、过程和方法。

在一些实施例中，存储器301可以包括只读存储器(ROM)、闪存、随机存取存储器(RAM)、诸如同步DRAM(SDRAM)或Rambus DRAM的动态随机存取存储器(DRAM)、静态存储器(例如，闪存、静态随机存取存储器)等，计算机可执行指令以任何格式存储在其上。计算机程序指令可以由处理器302访问，从ROM或者任何其他合适的存储器位置读取，并且加载在RAM中以供处理器302执行。例如，存储器301可以存储一个或多个软件应用程序。存储在存储器301中的软件应用程序可以包括，例如，用于普通计算机系统的操作系统(未示出)以及用于软控制装置的操作系统，例如安卓操作系统；或者针对软件的各种常见的开发系统。

本文描述了各种操作或功能，其可以实现为软件代码或指令或者定义为软件代码或指令。这样的内容可以是可以直接执行(“对象”或“可执行”形式)的源代码或差分代码(“delta”或“patch”代码)。软件代码或指令可以存储在计算机可读存储介质中，并且当被执行时，可以使机器执行所描述的功能或操作，并且包括用于以机器(例如，计算装置，电子系统等)可访问的形式存储信息的任何机构，例如可记录或不可记录介质(例如，只读存储器(ROM)、随机存取存储器(RAM)、磁盘存储介质、光存储介质、闪存装置等)。在一些实施例中，根据本公开的各个实施例的步骤可以实现为在存储器301上的各个软件模块，例如，如图3所示，可以包括：建立模块303，配置为建立第一配置文件和第二配置文件，所述第一配置文件用于存储常规权限，所述第二配置文件用于存储与权限的引入相关的信息；包括在编译模块(未图示)中的获取模块304、判定模块305和终止模块306，其中，获取模块304配置为在应用的编译过程中获取所有声明的权限，判定模块305配置为判定各个声明的权限是否包含在第一配置文件和第二配置文件中的任一个中，所述终止模块306配置为在判定结果为否的情况下终止所述编译过程。该终止模块306仅仅作为示例，在一些实施例，代替终止模块306，该装置300可以包括提醒模块306，其配置为在判定结果为否的情况下以除了终止所述编译过程以外的方式来提供相应的提醒。如此，开发者能够自主判定是否终止编译过程，从而避免在低风险的权限变化下不必要的编译终止。

已经出于说明的目的呈现了前面的描述。它并非穷尽的，并且不限于所公开的精确形式或实施例。考虑到所公开实施例的说明书和实践，实施例的修改和改编将是显而易见的。

在本文中，此外，在随附权利要求中，术语“包括”是开放式的。也就是说，术语“包括”，与“包括”、“包含”或“其特征在于”同义，是包容性或开放式的，并不排除另外、未陈述的要素或方法步骤。“包括”是权利要求语言中使用的专用术语，其意味着所称的要素是必要的，但其他要素可以被添加而依然形成权利要求的范围内的构想。包括除了那些在权利要求中在该术语后列出的要素以外的要素的设备、系统、装置、制品、组成、配方或过程，也被视为落入该权利要求的保护范围内。此外，在下面的权利要求中，术语“第一”、“第二”和“第三”等仅被用作标签，并不旨在对其对象施加数值上的要求。

这里描述的示例性方法可以至少部分地是机器或计算机实现的。一些示例可以包括用指令编码的计算机可读介质或机器可读介质，所述指令可操作以配置电子装置执行如以上示例中所述的方法。这种方法的实现可以包括软件代码，诸如微代码、汇编语言代码、更高级的语言代码等。各种程序或程序模块可以使用各种软件编程技术来创建。例如，可以使用Java、Python、C、C++、汇编语言或任何已知的编程语言来设计程序段或程序模块。一个或多个这样的软件部分或模块可以被集成到计算机系统和/或计算机可读介质中。这种软件代码可以包括用于执行各种方法的计算机可读指令。软件代码可以形成计算机程序产品或计算机程序模块的一部分。此外，在一个示例中，软件代码可以诸如在执行期间或其他时间有形地存储在一个或多个易失性、非暂时性或非易失性有形计算机可读介质上。这些有形的计算机可读介质的示例可以包括但不限于硬盘、可移动磁盘、可移动光盘(例如，光盘和数字视频盘)、磁带盒、存储卡或棒、随机存取存储器(RAM)，只读存储器(ROM)等。

以上描述旨在是说明性的而不是限制性的。例如，上述示例(或其一个或多个方案)可以彼此组合使用。本领域普通技术人员在查看以上描述时可以使用其他实施例。而且，在上面的详细描述中，各种特征可以被组合在一起以简化本公开。这不应被解释成意图让不要求保护的公开特征对于任何权利要求而言都是必不可少的。而是，发明主题可以在于比一个公开的实施例的所有特征少的特征组合。因此，以下权利要求由此作为示例或实施例并入到具体实施方式中，其中每个权利要求独立作为单独的实施例，并且可以构想的是，这些实施例可以以各种组合或置换来相互组合。本发明的范围应该参考所附权利要求以及赋予这些权利要求的等同物的全部范围来确定。

Claims (9)

1.一种对权限进行追踪管理的方法，其由计算机实现，且其特征在于，所述方法包括：

建立第一配置文件和第二配置文件，所述第一配置文件用于存储常规权限，所述第二配置文件用于存储与权限的引入相关的信息，其中，与权限的引入相关的信息包括相应权限的引入来源和引入原因；

在应用的编译过程中执行如下步骤：

获取所有声明的权限；

判定各个声明的权限是否在第一配置文件和第二配置文件中的任一个中；

在判定结果为否的情况下，提供相应的提醒。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：在判定结果为是的情况下，核实所述第二配置文件中与权限的引入相关的信息是否与相应模块的权限声明一致，如果不一致，则提供相应的提醒。

3.根据权利要求1或2所述的方法，其特征在于，通过如下方式中的至少一种提供相应的提醒：

终止所述编译过程；

发出提示信息；以及

将相应的提醒信息写入提示文件中以供开发者查看。

4.根据权利要求3所述的方法，其特征在于，如果所述第二配置文件中与权限的引入相关的信息与相应模块的权限声明不一致，则更新与权限的引入相关的信息，使之与相应模块的权限声明一致。

5.根据权利要求1所述的方法，其特征在于，所述第二配置文件采用xml格式，且包括：

与权限对应设置的xml节点，其列出使用相应权限的模块；以及

模块节点，其包含所述模块的包名以及引入相应权限的原因。

6.根据权利要求1所述的方法，其特征在于，获取所有声明的权限的步骤包括：从处理清单文件的任务的输出获取合并后的全清单文件，并从所述全清单文件中解析出所有声明的权限。

7.根据权利要求1所述的方法，其特征在于，获取所有声明的权限的步骤包括：

从处理清单文件的任务的输入获取各个模块的清单文件；

对各个模块的清单文件进行解析，以得到相应各个模块所声明的权限；以及

在当前模块的清单文件中有针对下一级模块的权限的删除指令的情况下，删除相应权限，使用剩余的权限作为所述所有声明的权限。

8.一种对权限进行追踪管理的装置，所述装置包括存储有计算机可执行指令的存储器和处理器，其特征在于，所述处理器执行所述计算机可执行指令时，实现如下步骤：

建立第一配置文件和第二配置文件，所述第一配置文件用于存储常规权限，所述第二配置文件用于存储与权限的引入相关的信息，其中，与权限的引入相关的信息包括相应权限的引入来源和引入原因；

在应用的编译过程中执行如下步骤：

获取所有声明的权限；

判定各个声明的权限是否在第一配置文件和第二配置文件中的任一个中；

在判定结果为否的情况下，提供相应的提醒。

9.一种非暂时性的计算机记录介质，其上存储有计算机可执行指令，所述计算机可执行指令被处理器执行时实现如下步骤：

建立第一配置文件和第二配置文件，所述第一配置文件用于存储常规权限，所述第二配置文件用于存储与权限的引入相关的信息，其中，与权限的引入相关的信息包括相应权限的引入来源和引入原因；

在应用的编译过程中执行如下步骤：

获取所有声明的权限；

判定各个声明的权限是否在第一配置文件和第二配置文件中的任一个中；

在判定结果为否的情况下，提供相应的提醒。

Images