一种APP申请动态权限的管理方法、终端和系统

本发明涉及通信领域，具体为一种APP申请动态权限的管理方法、终端和系统。

目前安卓6.0以上版本，当应用App需要敏感权限时候，必须弹出对话框，让用户自行选择是否赋予权限。例如电话本、麦克风、摄像头、多媒体文件列表等。在隐私日益重视的时代，用户有迫切的需求，避免不良应用采集个人数据。但是面对繁多的应用，无法一一进行甄别。盲目的赋予权限，相当于动态权限管理无作用效果。

申请人肖戈林于2016年申报了一项发明专利CN201610796465.1，其公开了一种基于时间和应用白名单方式对移动设备使用权限进行管控的系统，包含云端、家长端和孩子端；云端包含应用分类模块，管控应用推荐模块，管控指令接收模块，管控指令存储模块，管控指令下发模块及数据库，数据库中存储应用识别数据，家长端及学生端的识别数据和管控策略内容；家长端和学生端均包含消息模块，该消息模块是管控指令的发起方，接收方和执行方，与云端的管控指令接收模块和管控指令下发模块配合完成管控指令的发起，传送及执行；家长端APP管控模块将管控指令发送至云端管控指令接收模块，并由云端管控指令下发模块发送至学生端APP管控模块执行相应的管控。

上述方案用于实现家长对于学生端的APP权限予以赋值，以达到管理学生APP的目的。

但是这种权限的赋予方式并不适用于互联网领域中各类的APP的权限管理。如何针对有隐私侵犯的APP进行权限管理，如何降低用户的操作流程复杂性，是本申请所需要解决的问题。

本发明的目的在于提供一种APP申请动态权限的管理方法、终端和系统。本方法基于后台的黑白名单的维护和管理，为终端的APP的权限管理提供相应的依据，使APP在终端安装过程中能够迅速的获取和识别APP的风险，并确定是否对该APP进行自动赋权操作、禁止赋权操作或弹出赋权窗口供用户手动赋权，使用户达到无感使用的目的。

同时，本发明还提供基于该方法的终端，和实现该方法的系统。

为实现上述目的，本发明提供如下技术方案：一种APP申请动态权限的管理方法，所述的方法涉及终端和后台服务器，所述的方法包括如下步骤：

步骤1：所述的终端在安装APP时，获取APP的包名；

步骤2：将所述的APP的包名发送至后台服务器，所述的后台服务器中存储有APP黑名单、APP白名单、APP灰名单，所述的后台服务器用于将APP的包名和APP黑名单、APP白名单、APP灰名单中APP的包名进行比对，并将比对结果发送至终端；

步骤3：接收比对结果，根据比对结果决定对该APP进行自动赋权操作、禁止赋权操作或弹出赋权窗口供用户手动赋权。

在上述的APP申请动态权限的管理方法中，所述的APP黑名单中储存有具有侵扰用户隐私风险的APP的包名；所述的APP白名单中存储有无用户隐私侵犯风险的APP包名；所述的灰名单中存储有不能确定是否有侵扰用户隐私风险的APP的包名。

在上述的APP申请动态权限的管理方法中，所述的后台服务器生成比对结果的方法为：

S1：后台服务器收到终端所发送的APP的包名后，将收到的APP的包名和APP黑名单、APP白名单、APP灰名单中的APP的包名进行比对；

S2：若APP黑名单中含有终端所发送的APP的包名，则生成第一比对结果并发送给终端；

S3：若APP白名单中含有终端所发送的APP的包名，则生成第二比对结果并发送给终端；

S4：若APP灰名单中含有终端所发送的APP的包名，则生成第三比对结果并发送给终端

所述的步骤3具体为：

接收后台服务器所发送的比对结果，若为第一比对结果，则对该APP进行禁止赋权操作；若为第二比对结果，则对该APP进行自动赋权操作；若为第二比对结果，则弹出赋权窗口供用户手动赋权。

在上述的APP申请动态权限的管理方法中，所述的终端中设有一个数据库，所述的数据库用于存储步骤3所接收到的比对结果和APP的历史安装记录；

所述的步骤1和步骤2之间还设有步骤4：将APP的包名和数据库中的APP的历史安装记录进行比对，判断该APP是否是第一次安装，若为第一次安装，则直接进行步骤2，若不是第一次安装，则查询数据库中所存储的该APP所对应的比对结果，并根据比对结果决定对该APP进行自动赋权操作、禁止赋权操作或弹出赋权窗口供用户手动赋权。

在上述的APP申请动态权限的管理方法中，所述方法还涉及云存储服务器；所述的终端将步骤3所接收到的比对结果和APP的历史安装记录存储到云存储服务器中；

当终端中的数据库清空或者用户使用新的终端时，将云存储服务器中所存储的比对结果和APP的历史安装记录同步到终端中的数据库中。

同时，本发明还公开了一种用于实现上述的方法的终端，所述的终端包含如下模块：

包名获取模块，用于在终端安装APP时，获取APP的包名；

包名发送模块，用于将包名获取模块所获取的APP的包名发送至后台服务器；所述的后台服务器中存储有APP黑名单、APP白名单、APP灰名单，所述的后台服务器用于将APP的包名和APP黑名单、APP白名单、APP灰名单中APP的包名进行比对，并将比对结果发送至终端；

权限确认模块：用于根据比对结果，决定对该APP进行自动赋权操作、禁止赋权操作或弹出赋权窗口供用户手动赋权。

在上述的终端中，所述的终端还包含：数据库、本地比对模块；

所述的数据库用于存储权限确认模块所接收到的比对结果和APP的历史安装记录；

所述的本地比对模块用于将包名获取模块所获取的APP的包名和数据库中的APP的历史安装记录进行比对，判断该APP是否是第一次安装，若为第一次安装，则控制包名发送模块运行，若不是第一次安装，则查询数据库中所存储的该APP所对应的比对结果，并将查询到的比对结果发送至权限确认模块。

此外，本发明还公开了一种APP申请动态权限的系统，包括至少一个后台服务器和若干终端，所述的终端如上所述；

所述的后台服务器中存储有APP黑名单、APP白名单、APP灰名单，所述的后台服务器用于将包名获取模块所发送的APP的包名和APP黑名单、APP白名单、APP灰名单中APP的包名进行比对，并将比对结果发送至终端的权限确认模块。

在上述的APP申请动态权限的系统中，还包括云存储服务器；

所述云存储服务器用于定期从终端的数据库中获得比对结果和APP的历史安装记录、用于根据终端的请求将比对结果和APP的历史安装记录同步到终端的数据库中。

在上述的APP申请动态权限的系统中，所述的后台服务器包括搭建基于SpringBoot的后台、MySql数据库和Vue前端；

所述的MySql数据库保存有APP黑名单、APP白名单、APP灰名单；

所述的Vue前端用于维护APP黑名单、APP白名单、APP灰名单；

所述的后台用于接收包名发送模块所发送的APP的包名，并调用MySql数据库，将包名发送模块所发送的APP的包名与APP黑名单、APP白名单、APP灰名单中的APP的包名进行比对，生成比对结果，并发送给权限确认模块。

在上述的APP申请动态权限的系统中，所Vue前端用于维护APP黑名单、APP白名单、APP灰名单的方法包括但不限于如下操作：

根据从各种渠道收集的信息，确定APP是列入APP黑名单、APP白名单或者APP灰名单；

一般来说，APP灰名单中存储的是新上架的APP或者是有少量用户投诉等情况的APP，这个时候运行APP运营商提出复议，根据复议结果和/或从各种渠道收集的信息来决定将APP灰名单中的APP是拉入APP黑名单还是APP白名单；

APP灰名单中的APP一般不会太多，经过人工处理、自动处理等方式需要定期进行确定是列入APP黑名单还是APP白名单。

上述从各种渠道收集的信息是指：

1、数据采集员，数据采集员从各大应用市场的评论，获取App是否有侵犯隐私的动作。

2、后台会自动收集用户取消授权的App名单，根据数据量来判断是否进行分析动作。

3、后台收集数据后，开发人员通过反编译App方式，获取代码。出各个权限最终做什么动作，来判断是否有收集用户隐私的可能。

4、各大主流App，自动加入白名单。如淘宝、、微博等。

与现有技术相比，本发明的有益效果是：

本方法基于后台的黑白灰名单的维护和管理，为终端的APP的权限管理提供相应的依据，使APP在终端安装过程中能够迅速的获取和识别APP的风险，并确定是否提示用户赋予权限，并且对于任一款用户隐私信息安全的APP，取消其赋权流程，使用户达到无感使用的目的。

这么做从另外一个角度来说，也可以相应提高用户对于赋权提示的警示，以改善现在的消费者对于赋权提示无视的现状。

对于目前应用市场上繁多的APP，用户不需要再关心哪些可以或不可以赋予权限的。系统帮助用户，筛选了可信APP并不弹出确认框，提升了用户体验性。对于不建议赋予权限APP即APP黑名单中的APP，直接禁止赋权，如果用户需要对其赋权以完成某种操作，则进入手机的系统设置页面进行手动选择。对于灰名单中的APP，则按照常规的流程，弹出赋权确认对话框，让用户自行选择。

安卓系统本身的设计，是没有黑白灰名单数据库，不能帮助用户判断。不管任何App，在申请动态权限时候，都会弹出确认框，让用户选择，同时把风险转嫁给用户。本设计则帮助用户进行筛选，通过后台数据库，而不是本地预置的数据库，可以及时同步黑白名单，适应市场上多变的App应用。

图1为本发明的实施例1的流程方框图；

图2为本发明的实施例2的流程方框图；

图3为本发明的实施例3和4的结构方框图；

图4为本发明的实施例4的结构方框图。

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

建议把下文中的各个英文代码翻译成中文语言。

实施例1

请参阅图1，一种APP申请动态权限的管理方法，所述的方法涉及终端和后台服务器，所述的方法包括如下步骤：

步骤1：所述的终端在安装APP时，获取APP的包名；

该过程产生于安卓系统FW(frameworks)层，具体来说，编写一个服务service，用于和后台服务器通信。

在frameworks/base/core/res/AndroidManifest.xml：增加App安装的广播接受android:name＝"android.intent.action.PACKAGE_ADDED”

这样我们的服务就可以在App安装成功后收到消息，然后service服务就可以开始获取安装App的包名：

PackageInfo packageInfo＝pm.getPackageInfo(packageName,PackageManager.GET_PERMISSIONS)；

步骤2：将所述的APP的包名发送至后台服务器，所述的后台服务器中存储有APP黑名单、APP白名单、APP灰名单，所述的APP黑名单中储存有具有侵扰用户隐私风险的APP的包名；所述的APP白名单中存储有无用户隐私侵犯风险的APP包名；所述的APP灰名单中存储有不能确定是否有侵扰用户隐私风险的APP的包名。

所述的后台服务器用于将APP的包名和APP黑名单、APP白名单、APP灰名单中APP的包名进行比对，并将比对结果发送至终端；

其具体操作为：

S1：后台服务器收到终端所发送的APP的包名后，将收到的APP的包名和APP黑名单和APP白名单中的APP的包名进行比对；

S2：若APP黑名单中含有终端所发送的APP的包名，则生成第一比对结果并发送给终端；

S3：若APP白名单中含有终端所发送的APP的包名，则生成第二比对结果并发送给终端；

S4：若APP灰名单中含有终端所发送的APP的包名，则生成第三比对结果并发送给终端；

步骤3：接收比对结果，根据比对结果决定对该APP进行自动赋权操作、禁止赋权操作或弹出赋权窗口供用户手动赋权；

更进一步的，步骤3具体为：接收后台服务器所发送的比对结果，若为第一比对结果，则对该APP进行禁止赋权操作；若为第二比对结果，则对该APP进行自动赋权操作；若为第二比对结果，则弹出赋权窗口供用户手动赋权。

本实施例基于后台的黑白灰名单的维护和管理，为终端的APP的权限管理提供相应的依据，使APP在终端安装过程中能够迅速的获取和识别APP的风险，并确定是否提示用户赋予权限，并且对于任一款用户隐私信息安全的APP，取消其赋权流程，使用户达到无感使用的目的。

这么做从另外一个角度来说，也可以相应提高用户对于赋权提示的警示，以改善现在的消费者对于赋权提示无视的现状。

实施例2

请参阅图2，与实施例1大体相同，不同的是，在步骤1和2之间具有步骤4。

所述的方法涉及终端和后台服务器；所述的终端中设有一个数据库，所述的数据库用于存储步骤3所接收到的比对结果和APP的历史安装记录；

本方法具体为：

步骤1：所述的终端在安装APP时，获取APP的包名；

所述的终端中设有一个数据库，所述的数据库用于存储步骤3所接收到的比对结果和APP的历史安装记录；

步骤4：将APP的包名和数据库中的APP的历史安装记录进行比对，判断该APP是否是第一次安装，若为第一次安装，则直接进行步骤2，若不是第一次安装，则查询数据库中所存储的该APP所对应的比对结果，并根据比对结果决定对该APP进行自动赋权操作、禁止赋权操作或弹出赋权窗口供用户手动赋权；

步骤2：将所述的APP的包名发送至后台服务器，所述的后台服务器中存储有APP黑名单、APP白名单、APP灰名单，所述的后台服务器用于将APP的包名和APP黑名单、APP白名单、APP灰名单中APP的包名进行比对，并将比对结果发送至终端；

步骤3：接收比对结果，根据比对结果决定对该APP进行自动赋权操作、禁止赋权操作或弹出赋权窗口供用户手动赋权。

本实施例增设了步骤4，可以进一步提高响应速度，利于删除过的APP再次安装。

实施例3

请参阅图3，一种用于实现实施例2的方法的终端A，所述的终端A包含如下模块：

包名获取模块11，用于在终端A安装APP时，获取APP的包名；

包名发送模块12，用于将包名获取模块11所获取的APP的包名发送至后台服务器B；所述的后台服务器B中存储有APP黑名单、APP白名单、APP灰名单，所述的后台服务器B用于将APP的包名和APP黑名单、APP白名单、APP灰名单中APP的包名进行比对，并将比对结果发送至权限确认模块13；

所述的APP黑名单中储存有具有侵扰用户隐私风险的APP的包名；

所述的APP白名单中存储有无用户隐私侵犯风险的APP包名；

所述的灰名单中存储有不能确定是否有侵扰用户隐私风险的APP的包名，在此需要说明的是，“不能确定是否有侵扰用户隐私风险”一般是指新上架的APP或者有少量用户投诉但是没有确定证据证实该投诉等情况的APP。

权限确认模块13：用于根据比对结果，决定对该APP进行自动赋权操作、禁止赋权操作或弹出赋权窗口供用户手动赋权；

比如，在手机终端中，如果比对结果表示该APP无用户隐私侵犯风险，则显示界面上在APP安装后直接运行，不会弹出提示用于权限赋予的对话框；

如果比对结果表示该APP有用户隐私侵犯风险，则同样不会弹出提示用于权限赋予的对话框，直接在该APP安装后在终端后台禁止赋权操作；

如果比对结果表示该APP是属于APP灰名单，则弹出提示用于权限赋予的对话框。

数据库14：用于存储权限确认模块13所接收到的比对结果和APP的历史安装记录；

本地比对模块15：用于将包名获取模块11所获取的APP的包名和数据库14中的APP的历史安装记录进行比对，判断该APP是否是第一次安装，若为第一次安装，则控制包名发送模块12运行，若不是第一次安装，则查询数据库14中所存储的该APP所对应的比对结果，并将查询到的比对结果发送至权限确认模块13，让权限确认模块13根据比对结果来决定对该APP进行自动赋权操作、禁止赋权操作或弹出赋权窗口供用户手动赋权。

实施例4

请参阅图3和4，一种APP申请动态权限的系统，包括至少一个后台服务器B、一个云存储服务器C和若干终端A；所述的后台服务器B和若干终端A之间通信连接；所述云存储服务器C同样和若干终端A之间通信连接；

具体来说，终端A如实施例3所示；

后台服务器B包含：搭建基于SpringBoot的后台21、MySql数据库14和Vue前端23；

所述的MySql数据库14保存有APP黑名单、APP白名单；

所述的Vue前端23用于维护APP黑名单、APP白名单，添加、删除一个新的App的包名到APP黑名单或APP白名单中；

所述的后台21用于接收包名发送模块12所发送的APP的包名，并调用MySql数据库14，将包名发送模块12所发送的APP的包名与APP黑名单、APP白名单中的APP的包名进行比对，生成比对结果，并发送给权限确认模块13。

云存储服务器C用于定期从终端的数据库14中获得比对结果和APP的历史安装记录、用于根据终端的请求将比对结果和APP的历史安装记录同步到终端的数据库14中

本实施例的系统的优点在于：

对于目前应用市场上繁多的App，用户不需要再关心那些可以或不可以赋予权限的。系统帮助用户，筛选了可信App并不弹出确认框，提升了用户体验性。对于不建议赋予权限App，用户马上能感知到此App是有一定风险，并能手动禁止其权限申请。

安卓系统本身的设计，是没有黑白名单数据库14，不能帮助用户判断。不管任何App，在申请动态权限时候，都会弹出确认框，让用户选择，同时把风险转嫁给用户。本设计则帮助用户进行筛选。

通过后台21数据库14，而不是本地预置的数据库14，可以及时同步黑白名单，适应市场上多变的App应用。

同时，本系统中，在终端A还设置了数据库14，以便App删除后再次安装时使用。

需要说明的是，在本实施例1-4中，终端A包括但不限于：移动终端A、非移动终端A，比如手机、平板电脑、服务器等。

本实施例1-4中，后台服务器B包括但不限于：云服务器、远程服务器等。

对于本领域技术人员而言，显然本发明不限于上述示范性实施例的细节，而且在不背离本发明的精神或基本特征的情况下，能够以其他的具体形式实现本发明。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本发明的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化囊括在本发明内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。