CN105577720A - 移动应用打包的方法及系统 - Google Patents

Abstract

本发明公开了一种移动应用打包的系统，该系统包括：用户管理模块，用于设置用户访问目标APK文件的权限；移动应用管理模块，用于上传和下载壳文件、初始APK文件以及目标APK文件；打包构建模块，用于将初始APK文件和壳文件打包构建成目标APK文件；日志管理模块，用于记录用户的操作信息，并生成操作日志；存储模块，用于接收和存储壳文件、初始APK文件以及目标APK文件。本发明还公开了一种移动应用打包的方法。本发明通过对移动应用程序打包、建立用户操作日志和设置用户权限等方式来增加移动应用的安全。

Description

移动应用打包的方法及系统

技术领域

本发明涉及移动办公领域，尤其涉及移动应用打包的方法及系统。

背景技术

随着社会的发展，企业移动信息化得到快速发展，使得移动应用管理越来越重要。随着移动终端的普及，使得越来越多的职能终端涌入企业，使得移动办公的安全性成为一个显著的问题，如：员工使用个人终端设备，登录企业IT，随意访问重要资源；员工使用个人终端设备，占用公司资源却做一些和公司无关的事情等等。由于企业以前主要采用PC办公，而在PC上使用的各类安全策略、准入控制、权限管理不能直接搬用到移动终端上使用，使得在PC上使用的各类安全措施不能用在移动应用的管理上。另外，目前各大解决安全问题的供应商所提供的BYOD(BringYourOwnDevice指携带自己的设备办公)安全方案，都是比较庞大的一个全新系统，如需要云服务器，需要WEB服务器，需要注册终端，甚至有些需要和第三方软件合作修改。并且对于企业部署新系统改造老系统建设周期长，投资昂贵，后期维护的代价越来越高。因此，目前来说，没有一种能够简便、低成本的解决企业移动办公安全问题的方法。

上述内容仅用于辅助理解本发明的技术方案，并不代表承认上述内容是现有技术。

发明内容

本发明的主要目的在于解决保障移动办公的安全性的技术问题。

为实现上述目的，本发明提供的一种移动应用打包的系统，所述移动应用打包的系统包括：

用户管理模块，用于设置用户访问目标APK文件的权限；

移动应用管理模块，用于上传和下载壳文件、所述初始APK文件以及所述目标APK文件；

打包构建模块，用于将所述初始APK文件和所述壳文件打包构建成所述目标APK文件；

日志管理模块，用于记录用户的操作信息，并生成操作日志；

存储模块，用于接收和存储所述壳文件、所述初始APK文件以及所述目标APK文件。

优选地，所述用户管理模块包括：

分级单元，用于根据预置指令对登录系统的用户进行分级；

设置单元，用于根据用户的级别设置用户可以访问的目标APK文件的类别。x

优选地，所述日志管理模块包括：

记录单元，用于根据用户名，记录用户在系统内的操作；

生成单元，用于根据记录的所述操作，生成与所述用户名对应的操作日志。

优选地，所述打包构建模块包括：

获取单元，用于获取初始APK文件和壳文件；

反编译单元，用于对所述初始APK文件进行反编译处理；

提取单元，用于从反编译处理后的文件中提取与所述壳文件中的文件类型相同的目标文件；

合并单元，用于将所述目标文件和所述壳文件进行合并处理；

打包构建单元，用于将合并处理后的文件和所述初始APK文件存贮至预置文件夹，并打包构建所述预置文件夹为目标APK文件。

优选地，所述打包构建模块包括：

第一判断单元，用于获取所述初始APK文件的文件类型，判断所述APK文件的类型是否为APK类型；

第二判断单元，用于若所述初始APK文件的类型为APK类型，获取所述初始APK文件的xml文件，判断所述xml文件内是否存在预置的标记信息；

所述第二判断模块还用于，当所述xml文件内不存在预置的标记信息时，提取单元从反编译处理后的文件中提取与所述壳文件的文件类型相同的目标文件。

此外，为实现上述目的，本发明还提供一种移动应用打包的方法，所述移动应用打包的方法包括以下步骤：

当接收到用户上传的初始APK文件时，根据所述初始APK文件的类别获取对应的功能壳文件；

将所述初始APK文件和所述功能壳文件打包构建成目标APK文件并存储至目标文件夹；

设置用户访问目标APK文件的权限；

记录用户的操作信息，并生成操作日志。

优选地，所述设置用户访问目标APK文件的权限包括：

根据预置指令对登录系统的用户进行分级；

根据用户的级别设置用户可以访问的目标APK文件的类别。

优选地，所述记录用户的操作信息，并生成操作日志的步骤包括：

根据用户名，记录用户在系统内的操作；

根据记录的所述操作，生成与所述用户名对应的操作日志。

优选地，所述将所述初始APK文件和所述功能壳文件打包构建成目标APK文件并存储至目标文件夹的步骤包括：

获取初始APK文件和壳文件；

对所述初始APK文件进行反编译处理；

从反编译处理后的文件中提取与所述壳文件中的文件类型相同的目标文件；

将所述目标文件和所述壳文件进行合并处理；

将合并处理后的文件和所述初始APK文件存贮至预置文件夹，并打包构建所述预置文件夹为目标APK文件。

优选地，所述对初始APK文件进行反编译处理的步骤之后还包括：

获取所述初始APK文件的文件类型，判断所述APK文件的类型是否为APK类型；

若所述初始APK文件的类型为APK类型，获取所述初始APK文件的xml文件，判断所述xml文件内是否存在预置的标记信息；

当所述xml文件内不存在预置的标记信息时，提取单元从反编译处理后的文件中提取与所述壳文件的文件类型相同的目标文件。

本实施例，通过对用户分级，设置各级用户的访问权限，从而使得部分目标APK文件的访问受到账户的限制，从而达到禁止权限不够的用户访问机密目标APK文件，进而有效地增加了机密APK文件的安全性能，有效的提高了移动办公的安全性；通过生成用户的操作日志，有利于系统对用户的管控，有利于用户根据操作日志对操作用户的管理，有利于提高移动应用的安全；对初始APK文件进行分类，然后根据初始APK文件的类别获取相应的一个或者多个功能壳，并将所获取的功能壳逐一的与初始APK文件进行打包构建；目标APK文件由系统提供的功能壳和初始APK文件打包构建生成，保证目标APK文件能稳定可靠的按照系统的要求在系统上运行，从而不会威胁到系统的安全；通过功能壳的打包构建，使得目标APK文件本身就具有限制用户访问和使用的功能，从而减少非必要的用户访问目标APK文件，从而有利于保障移动办公的安全；另外，通过打包构建目标APK文件的方式来增加移动办公的安全性，具有易部署、易维护、易弹性扩展性，并且它无需修改原有的IT系统，也无需移动应用改造，从而有效的控制了移动应用打包所耗费的成本。

附图说明

图1为本发明移动应用打包的系统第一实施例的功能模块示意图；

图2为本发明移动应用打包的系统用户管理模块的细化功能模块示意图；

图3为本发明移动应用打包的系统打包构建模块一实施例的细化功能模块示意图；

图4为本发明移动应用打包的系统打包构建模块另一实施例的细化功能模块示意图；

图5为本发明移动应用打包的系统日志管理模块的细化功能模块示意图；

图6为本发明移动应用打包的方法的流程示意图；

图7为本发明移动应用打包的方法第二步一实施例的步骤细化流程示意图；

图8为本发明移动应用打包的方法第二步另一实施例的步骤细化流程示意图；

图9为本发明移动应用打包的方法第三步的步骤细化流程示意图；

图10为本发明移动应用打包的方法第四步的步骤细化流程示意图。

本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。

具体实施方式

应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

本发明提供一种移动应用打包的系统，参照图1至图5，在一实施例中，移动应用打包的系统包括：

用户管理模块10，用于设置用户访问目标APK文件的权限，用户管理模块10具体包括：

分级单元11，用于根据预置指令对登录系统的用户进行分级；

设置单元12，用于根据用户的级别设置用户可以访问的目标APK文件的类别。

本实施例中，管理员通过默认账号进入系统，然后对系统发送建立用户的指令，系统根据指令创建用户，然后对所创建的用户设置权限。具体地，系统根据管理员指令创建高级用户和普通用户，将普通用户的访问权限设置成仅可以下载系统内的部分目标APK文件和将目标APK文件上传至系统；而把高级用户的权限设置成，除可以上传和下载所有目标APK文件以外，还可以上传初始APK文件和功能壳，并在系统内对初始APK文件和功能壳打包构建成目标APK文件。例如，加有VPN功能壳的目标APK文件，可以供普通用户和高级用户同时下载，而加有有效期功能壳的目标APK文件就只允许高级用户下载，普通用户不能下载。不论是普通用户还是高级用户，上传的目标APK文件都可以通过web进行下载，但如果想要在系统内运行，就必须经过系统的检测，是否符合本系统运行的规则。当然，在其他实施例中，可以将用户的等级分得更细，每个等级的用户可访问权限也不相同。

本实施例中，通过对目标APK文件设置用户的访问权限，使得部分目标APK文件的访问受到账户的限制，从而达到禁止权限不够的用户访问机密目标APK文件，进而有效地增加了机密APK文件的安全性能，有效的提高了移动办公的安全性。

移动应用管理模块20，用于上传和下载壳文件、初始APK文件以及目标APK文件；

本实施例中，移动应用管理模块20包括上传单元21和下载单元22。上传单元21用于供用户上传初始APK文件、功能壳文件以及打包构建后的目标APK文件，下载单元22用于供用户下载打包构建后的目标APK文件。当然，移动应用管理模块20与用户管理模块10对应，不同等级的用户可以下载和上传的APK文件类型的范围不同，如高级用户可以通过上传单元21上传管理类的初始APK文件，而普通用户则不能。其中，上传打包构建后的目标APK文件，主要用于，当用户在使用第一次打包后的目标APK文件时，发现第一次打包后的目标APK文件还不能满足用户的需求，需要进行第二次打包。当系统内第一次打包后的目标APK文件被清理时，用户需要上传第一次打包后的目标APK文件，作为第二次打包的初始APK文件。

日志管理模块30，用于记录用户的操作信息，并生成操作日志，日志管理模块30具体包括；

记录单元31，用于根据用户名，记录用户在系统内的操作；

生成单元32，用于根据记录的操作，生成与用户名对应的操作日志。

本实施例中，根据管理员指令创立的用户，不论是高级用户还是普通用户，其所有的操作都被系统记录在操作日志内，以达到系统对所有用户的一个操作管理。具体地，系统对每一位登录系统的用户都建立一个操作日志，操作日志记录该用户的所有操作，包括上传或下载目标APK文件的时间、目标APK文件的名称等，或者是在系统上运行某目标APK文件的时间，甚至用户在打包构建目标APK时设置的密码也会被记录。以高级用户给初始APK文件加VPN的功能壳为例，日志内会记录该高级用户上传初始APK文件的文件名称和时间；上传功能壳文件的文件名称和时间；以及打包构建时设置的VPN的密码和打包构建的时间；以及目标APK存贮的目录。系统根据各用户预置的权限，来查询用户的操作日志，当发现操作日志内记录有超出该用户预置权限的内容时，冻结该账号，并给管理员发出警报信息。通过生成用户的操作日志，有利于系统对用户的管控，有利于用户根据操作日志对操作用户的管理，有利于提高移动应用的安全。

存储模块40，用于接收和存储壳文件、初始APK文件以及目标APK文件。

存储模块包括用于存储初始APK文件和壳文件的初始存储单元，用于打包过程中的中间存储单元，以及用于存储打包构建后的目标APK文件的目标存储单元。初始存储单元用于接收用户上传的初始APK文件和功能壳文件，并将接收后的文件存储。中间存储单元用于接收和存储打包过程中解析后的初始APK文件和壳文件。目标存储单元除了存储在系统内打包构建的目标APK文件外，也用于存储用户上传的目标APK文件。存储模块40与用户管理模块10相对应，存储模块内的内容，需要相应等级的用户才能读取和写入。如管理类的初始APK文件和目标APK文件，只有高级用户可以读取，而普通用户则不能。

打包构建模块50，用于将初始APK文件和壳文件打包构建成目标APK文件，打包构建模块50具体包括：

获取单元51，用于获取初始APK文件和壳文件；

接收用户准备加壳的初始APK文件，接收用户选择壳文件的指令，根据用户的选择指令，从壳文件库中提取所需的壳文件。

反编译单元52，用于对初始APK文件进行反编译处理；

提取单元53，用于从反编译处理后的文件中提取与壳文件中的文件类型相同的目标文件；

反编译也称计算机软件还原工程，是指通过对他人软件的目标程序(可执行程序)进行“逆向分析、研究”工作。本实施例中，反编译初始APK文件，只是得到可读的第一AndroidManifest.xml文件和第一资源文件，没有反编译java代码，初始APK文件中的dex文件也不进行反编译，在后续的步骤中可以知道，不需要对初始APK文件的代码进行编译就可以实现为初始APK文件增加功能。第一AndroidManifest.xml文件和第一资源文件和壳文件中的第二AndroidManifest.xml文件和第二资源文件相对应。在反编译的过程中利用了初始APKtool(APKTool是GOOGLE提供的APK编译工具，能够反编译及回编译apk)提供的文件。通过反编译初始APK文件，为打包构建新的APK文件提供必要的基本文件。

本实施例中，壳文件以SSLVPN为例，SSLVPN是解决远程用户访问敏感公司数据最简单最安全的解决技术。其中，SSL(安全套接层)协议是一种在internet上保证发送信息安全的通用协议，采用B/S结构(Browser/Server，浏览器/服务器模式)；VPN的英文全称是“VirtualPrivateNetwork”，就是“虚拟专用网络”。对已知的SSLVPN壳进行解析，并得到壳的第二AndroidManifest.xml文件和第二资源文件。当然，在其它实施例中，壳文件不仅仅限于SSLVPN。通过解析SSLVPN壳，为打包构建新的初始APK文件提供必要的基本文件。

合并单元54，用于将目标文件和壳文件进行合并处理；

目标文件包括初始APK文件的第一xml文件和第一资源文件，壳文件包括第二xml文件和第二资源文件；

将目标文件和壳文件进行合并处理具体包括：

解析第一xml文件和第二xml文件；

本实施例中，第一xml文件为第一AndroidManifest.xml文件，第二xml文件为第二AndroidManifest.xml文件；解析第一AndroidManifest.xml文件后可获取初始APK文件的第一MainActivity信息、第一Application信息，以及第一AndroidManifest.xml文件的其它信息，其中还包括初始APK文件的包名；解析第二AndroidManifest.xml文件后，可获取SSLVPN壳的第二MainActivity信息、第二Application信息，以及第二AndroidManifest.xml文件的其它信息。

将第一xml文件和第二xml文件中节点类型相同的内容进行合并，并将第一资源文件和第二资源文件中子文件的文件类型相同的文件进行合并；

将初始APK文件的第一MainActivity信息和SSLVPN壳的第二MainActivity信息合并在一起，在合并的过程中，对第一MainActivity信息和第二MainActivity进行排序，为了先执行SSLVPN的壳程序，将第二MainActivity排列在第一MainActivity的前面，并其将设置为启动activity，即设置“android.intent.action.MAIN”和“android.intent.category.LAUNCHER”，使得在执行初始APK文件前先执行SSLVPN；将初始APK文件的第一Application信息和SSLVPN壳的第二Application信息中其它的activity节点合并在一起，在合并的过程中，将android:name指定为壳工程继承android.app.Application的完整类名。

本实施例中，第一资源文件包括第一strings.xml文件，第二资源文件包括第二strings.xml文件，将第一strings.xml文件和第二strings.xml文件进行合并，并将合并后的文件存贮至预置文件夹中。合并后的文件，不仅包含了第一strings.xml文件和第二strings.xml文件全部内容，还记录了原始apk文件的包名，以及启动activity等信息。

打包构建单元55，用于将合并处理后的文件和初始APK文件存贮至预置文件夹，并打包构建预置文件夹为目标APK文件。

将合并处理后的文件存贮至预置文件夹包括：

将第一xml文件和第二xml文件中节点类型相同的内容进行合并处理得到的文件存贮至预置文件夹中；将第一资源文件和第二资源文件中子文件的文件类型相同的文件进行合并处理得到的文件与未进行合并处理的文件均存贮至预置文件夹中。

将第一资源文件中未合并的内容存贮至预置文件夹。本实施例中，将第一资源文件中除第一strings.xml文件以外的文件，拷贝到第二资源文件中对应的目录下保存，再将合在一起的第一资源文件和第二资源文件存贮到预置文件夹中。

合并第一xml文件和第二xml文件中未合并的项。将解析第一AndroidManifest.xml文件后获取的第一AndroidManifest.xml文件中的其它信息和解析第二AndroidManifest.xml文件后获取的第二AndroidManifest.xml文件中的其它信息合在一起，并将合在一起后的文件存贮至预置文件夹中。通过将初始APK文件的目标文件和SSLVPN壳文件合并在一起，为打包构建新的目标APK文件提供重要的组成部分，为新的目标APK启动提供驱动。

在将初始APK文件的目标文件和SSLVPN壳文件合并在一起，并存贮至预置文件夹以后，还需要将初始APK文件拷贝到预置文件夹下。初始APK文件为目标APK文件提供初始APK文件本来拥有的功能。在打包预置文件夹的过程中，需要调用apktool和使用ant(Ant是一种基于Java的build工具)。

上述为给一个移动应用初始APK文件加一个壳的过程，当初始APK文件需要增加其它功能的壳时，将目标APK文件作为原始文件，选择其它的壳文件，然后按照上述的方法和步骤进行即可。

在系统生成目标APK文件后，才会向用户提供下载，才会允许用户在系统内运行此目标APK文件。用户可以通过web下载目标APK文件，当web服务器开放外网时，在外工作的员工就可以通过Internet访问服务器，下载需要的目标APK文件。

下面举一个高级用户使用系统的过程，用户先打开浏览器，输入网址，进入登录界面，输入正确的用户名和密码后进入系统。选择需要打包的APK文件进行上传，在将APK文件上传后，用户可根据需要在系统内选择需要打包的功能壳，如VPN加密壳，也可自行上传功能壳。选择好功能壳后就可以给系统发送打包命令，让系统对所选的初始APK文件和功能壳进行打包。

本实施例通过先对初始APK文件进行反编译获取第一xml文件和第一资源文件，然后对第一xml文件和待加壳的第二xml文件进行合并等处理、对第一资源文件和第二资源文件进行合并等处理并将处理后的文件存贮到预置文件夹，最后将预置文件夹打包构建成目标APK文件，以实现将待加壳的功能附加到初始APK文件上的目的，在此过程中不需要改变初始APK文件的源码、也不需要修改dex的文件结构，使得给现有的移动应用增加新的功能时灵活方便，简单易行，有利于企业更加简便快捷的定制和改造原有的企业移动应用。

在上述实施例的基础上，打包构建模块还包括：

第一判断单元56，用于获取初始APK文件的文件类型，判断APK文件的类型是否为APK类型；

第二判断单元57，用于若初始APK文件的类型为APK类型，获取初始APK文件的xml文件，判断xml文件内是否存在预置的标记信息；第二判断单元57还用于当xml文件内不存在预置的标记信息时，提取单元从反编译处理后的文件中提取与壳文件的文件类型相同的目标文件。

本实施例中，xml文件优选为AndroidManifest.xml文件，在对初始APK文件进行反编译之前，还需要对初始APK文件进行检测，以判断欲反编译的初始APK文件是否符合反编译的要求。具体地，判断初始APK文件是否符合反编译要求包括以下几个方面：

首先，判断此文件是否为真的初始APK文件，一个文件是否为合格的初始APK文件，不能只从后缀名来判断，其它文件将后缀名改成初始APK后，此文件也将显示为初始APK文件。例如，将word文档的后缀名doc修改成初始APK后，word文档的形式上就成为了初始APK文件。这一部分的判断是先获取初始APK文件的文件类型，然后判断APK文件的类型是否为APK类型，如果是APK类型，则继续下面的判断，如果不是APK类型，则退出加壳程序。当然，判断APK文件是否为真的APK文件也可以通过反编译来进行，通过将不是APK文件的后缀名改为.apk，反编译工具可以给出相关提示。

然后，判断欲加壳的初始APK文件内是否包含壳文件的功能，本实施例中是通过检测初始APK文件内是否包含壳文件对应的标识信息来完成判断的。一个初始APK文件是否符合加壳要求，除了确定此文件为真初始APK文件外，还需判断此初始APK文件是否需要增加壳文件的功能，如果检测出初始APK文件已经具备壳文件的功能，则不再需要对同一初始APK文件增加同样的壳文件，如果没有检测到壳文件的标识信息，则对初始APK文件进行加壳处理。具体地，首先获取APK文件的AndroidManifest.xml文件，然后判断AndroidManifest.xml文件中是否包含与壳文件对应的预置标识信息，如果存在，则不再对初始APK文件进行加壳，如果不存在，则对初始APK文件进行提取。

通过在提取反编译后的初始APK文件前，对初始APK文件的合法性进行判断，有效的去除了非APK类型的文件，避免了对非APK类型的文件进行多余的处理；对初始APK文件加壳的必要性进行判断，有效的杜绝了对初始APK文件进行重加壳的操作，提高了对移动应用加壳的效率。

本实施例，通过对用户分级，设置各级用户的访问权限，从而使得部分目标APK文件的访问受到账户的限制，从而达到禁止权限不够的用户访问机密目标APK文件，进而有效地增加了机密APK文件的安全性能，有效的提高了移动办公的安全性；通过生成用户的操作日志，有利于系统对用户的管控，有利于用户根据操作日志对操作用户的管理，有利于提高移动应用的安全；对初始APK文件进行分类，然后根据初始APK文件的类别获取相应的一个或者多个功能壳，并将所获取的功能壳逐一的与初始APK文件进行打包构建；目标APK文件由系统提供的功能壳和初始APK文件打包构建生成，保证目标APK文件能稳定可靠的按照系统的要求在系统上运行，从而不会威胁到系统的安全；通过功能壳的打包构建，使得目标APK文件本身就具有限制用户访问和使用的功能，从而减少非必要的用户访问目标APK文件，从而有利于保障移动办公的安全；另外，通过打包构建目标APK文件的方式来增加移动办公的安全性，具有易部署、易维护、易弹性扩展性，并且它无需修改原有的IT系统，也无需移动应用改造，从而有效的控制了移动应用打包所耗费的成本。

本发明进一步提供一种移动应用打包的方法。

参照图6至图10，在一实施例中，移动应用打包的方法包括：

步骤S10：当接收到用户上传的初始APK文件时，根据初始APK文件的类别获取对应的功能壳文件；

步骤S20：将初始APK文件和功能壳文件打包构建成目标APK文件并存储至目标文件夹，具体包括：

步骤S21：获取初始APK文件和壳文件；

接收用户准备加壳的初始APK文件，接收用户选择壳文件的指令，根据用户的选择指令，从壳文件库中提取所需的壳文件。

步骤S22：对初始APK文件进行反编译处理；

步骤S23：从反编译处理后的文件中提取与壳文件中的文件类型相同的目标文件；

反编译也称计算机软件还原工程，是指通过对他人软件的目标程序(可执行程序)进行“逆向分析、研究”工作。本实施例中，反编译初始APK文件，只是得到可读的第一AndroidManifest.xml文件和第一资源文件，没有反编译java代码，初始APK文件中的dex文件也不进行反编译，在后续的步骤中可以知道，不需要对初始APK文件的代码进行编译就可以实现为初始APK文件增加功能。第一AndroidManifest.xml文件和第一资源文件和壳文件中的第二AndroidManifest.xml文件和第二资源文件相对应。在反编译的过程中利用了初始APKtool(APKTool是GOOGLE提供的APK编译工具，能够反编译及回编译apk)提供的文件。通过反编译初始APK文件，为打包构建新的APK文件提供必要的基本文件。

本实施例中，壳文件以SSLVPN为例，SSLVPN是解决远程用户访问敏感公司数据最简单最安全的解决技术。其中，SSL(安全套接层)协议是一种在internet上保证发送信息安全的通用协议，采用B/S结构(Browser/Server，浏览器/服务器模式)；VPN的英文全称是“VirtualPrivateNetwork”，就是“虚拟专用网络”。对待加已知的SSLVPN壳进行解析，并得到壳的第二AndroidManifest.xml文件和第二资源文件。当然，在其它实施例中，壳文件不仅仅限于SSLVPN。通过解析SSLVPN壳，为打包构建新的初始APK文件提供必要的基本文件。

步骤S24：将目标文件和壳文件进行合并处理；

目标文件包括初始APK文件的第一xml文件和第一资源文件，壳文件包括第二xml文件和第二资源文件；

将目标文件和壳文件进行合并处理具体包括：

解析第一xml文件和第二xml文件；

本实施例中，第一xml文件为第一AndroidManifest.xml文件，第二xml文件为第二AndroidManifest.xml文件；解析第一AndroidManifest.xml文件后可获取初始APK文件的第一MainActivity信息、第一Application信息，以及第一AndroidManifest.xml文件的其它信息，其中还包括初始APK文件的包名；解析第二AndroidManifest.xml文件后，可获取SSLVPN壳的第二MainActivity信息、第二Application信息，以及第二AndroidManifest.xml文件的其它信息。

将第一xml文件和第二xml文件中节点类型相同的内容进行合并，并将第一资源文件和第二资源文件中子文件的文件类型相同的文件进行合并；

将初始APK文件的第一MainActivity信息和SSLVPN壳的第二MainActivity信息合并在一起，在合并的过程中，对第一MainActivity信息和第二MainActivity进行排序，为了先执行SSLVPN的壳程序，将第二MainActivity排列在第一MainActivity的前面，并其将设置为启动activity，即设置“android.intent.action.MAIN”和“android.intent.category.LAUNCHER”，使得在执行初始APK文件前先执行SSLVPN；将初始APK文件的第一Application信息和SSLVPN壳的第二Application信息中其它的activity节点合并在一起，在合并的过程中，将android:name指定为壳工程继承android.app.Application的完整类名。

本实施例中，第一资源文件包括第一strings.xml文件，第二资源文件包括第二strings.xml文件，将第一strings.xml文件和第二strings.xml文件进行合并，并将合并后的文件存贮至预置文件夹中。合并后的文件，不仅包含了第一strings.xml文件和第二strings.xml文件全部内容，还记录了原始apk文件的包名，以及启动activity等信息。

步骤S25：将合并处理后的文件和初始APK文件存贮至预置文件夹，并打包构建预置文件夹为目标APK文件。

将合并处理后的文件存贮至预置文件夹包括：

将第一xml文件和第二xml文件中节点类型相同的内容进行合并处理得到的文件存贮至预置文件夹中；将第一资源文件和第二资源文件中子文件的文件类型相同的文件进行合并处理得到的文件与未进行合并处理的文件均存贮至预置文件夹中。

将第一资源文件中未合并的内容存贮至预置文件夹。本实施例中，将第一资源文件中除第一strings.xml文件以外的文件，拷贝到第二资源文件中对应的目录下保存，再将合在一起的第一资源文件和第二资源文件存贮到预置文件夹中。

合并第一xml文件和第二xml文件中未合并的项。将解析第一AndroidManifest.xml文件后获取的第一AndroidManifest.xml文件中的其它信息和解析第二AndroidManifest.xml文件后获取的第二AndroidManifest.xml文件中的其它信息合在一起，并将合在一起后的文件存贮至预置文件夹中。通过将初始APK文件的目标文件和SSLVPN壳文件合并在一起，为打包构建新的目标APK文件提供重要的组成部分，为新的目标APK启动提供驱动。

在将初始APK文件的目标文件和SSLVPN壳文件合并在一起，并存贮至预置文件夹以后，还需要将初始APK文件拷贝到预置文件夹下。初始APK文件为目标APK文件提供初始APK文件本来拥有的功能。在打包预置文件夹的过程中，需要调用apktool和使用ant(Ant是一种基于Java的build工具)。

上述为给一个移动应用初始APK文件加一个壳的过程，当初始APK文件需要增加其它功能的壳时，将目标APK文件作为原始文件，选择其它的壳文件，然后按照上述的方法和步骤进行即可。

在系统生成目标APK文件后，才会向用户提供下载，才会允许用户在系统内运行此目标APK文件。用户可以通过web下载目标APK文件，当web服务器开放外网时，在外工作的员工就可以通过Internet访问服务器，下载需要的目标APK文件。

下面举一个高级用户使用系统的过程，用户先打开浏览器，输入网址，进入登录界面，输入正确的用户名和密码后进入系统。选择需要打包的APK文件进行上传，在将APK文件上传后，用户可根据需要在系统内选择需要打包的功能壳，如VPN加密壳，也可自行上传功能壳。选择好功能壳后就可以给系统发送打包命令，让系统对所选的初始APK文件和功能壳进行打包。

本实施例通过先对初始APK文件进行反编译获取第一xml文件和第一资源文件，然后对第一xml文件和待加壳的第二xml文件进行合并等处理、对第一资源文件和第二资源文件进行合并等处理并将处理后的文件存贮到预置文件夹，最后将预置文件夹打包构建成目标APK文件，以实现将待加壳的功能附加到初始APK文件上的目的，在此过程中不需要改变初始APK文件的源码、也不需要修改dex的文件结构，使得给现有的移动应用增加新的功能时灵活方便，简单易行，有利于企业更加简便快捷的定制和改造原有的企业移动应用。

在上述实施例的基础上，在步骤S22之后还包括：

步骤S26：获取初始APK文件的文件类型，判断APK文件的类型是否为APK类型；

步骤S27：若初始APK文件的类型为APK类型，获取初始APK文件的xml文件，判断xml文件内是否存在预置的标记信息；第二判断单元57还用于当xml文件内不存在预置的标记信息时，提取单元从反编译处理后的文件中提取与壳文件的文件类型相同的目标文件。

本实施例中，xml文件优选为AndroidManifest.xml文件，在对初始APK文件进行反编译之前，还需要对初始APK文件进行检测，以判断欲反编译的初始APK文件是否符合反编译的要求。具体地，判断初始APK文件是否符合反编译要求包括以下几个方面：

首先，判断此文件是否为真的初始APK文件，一个文件是否为合格的初始APK文件，不能只从后缀名来判断，其它文件将后缀名改成初始APK后，此文件也将显示为初始APK文件。例如，将word文档的后缀名doc修改成初始APK后，word文档的形式上就成为了初始APK文件。这一部分的判断是先获取初始APK文件的文件类型，然后判断APK文件的类型是否为APK类型，如果是APK类型，则继续下面的判断，如果不是APK类型，则退出加壳程序。当然，判断APK文件是否为真的APK文件也可以通过反编译来进行，通过将不是APK文件的后缀名改为.apk，反编译工具可以给出相关提示。

然后，判断欲加壳的初始APK文件内是否包含壳文件的功能，本实施例中是通过检测初始APK文件内是否包含壳文件对应的标识信息来完成判断的。一个初始APK文件是否符合加壳要求，除了确定此文件为真初始APK文件外，还需判断此初始APK文件是否需要增加壳文件的功能，如果检测出初始APK文件已经具备壳文件的功能，则不再需要对同一初始APK文件增加同样的壳文件，如果没有检测到壳文件的标识信息，则对初始APK文件进行加壳处理。具体地，首先获取APK文件的AndroidManifest.xml文件，然后判断AndroidManifest.xml文件中是否包含与壳文件对应的预置标识信息，如果存在，则不再对初始APK文件进行加壳，如果不存在，则对初始APK文件进行提取。

通过在提取反编译后的初始APK文件前，对初始APK文件的合法性进行判断，有效的去除了非APK类型的文件，避免了对非APK类型的文件进行多余的处理；对初始APK文件加壳的必要性进行判断，有效的杜绝了对初始APK文件进行重加壳的操作，提高了对移动应用加壳的效率。

步骤S30：设置用户访问目标APK文件的权限；具体包括：

步骤S31：，根据预置指令对登录系统的用户进行分级；

步骤S32：根据用户的级别设置用户可以访问的目标APK文件的类别。

本实施例中，管理员通过默认账号进入系统，然后对系统发送建立用户的指令，系统根据指令创建用户，然后对所创建的用户设置权限。具体地，系统根据管理员指令创建高级用户和普通用户，将普通用户的访问权限设置成仅可以下载系统内的部分目标APK文件和将目标APK文件上传至系统；而把高级用户的权限设置成，除可以上传和下载所有目标APK文件以外，还可以上传初始APK文件和功能壳，并在系统内对初始APK文件和功能壳打包构建成目标APK文件。例如，加有VPN功能壳的目标APK文件，可以供普通用户和高级用户同时下载，而加有有效期功能壳的目标APK文件就只允许高级用户下载，普通用户不能下载。不论是普通用户还是高级用户，上传的目标APK文件都可以通过web进行下载，但如果想要在系统内运行，就必须经过系统的检测，是否符合本系统运行的规则。当然，在其他实施例中，可以将用户的等级分得更细，每个等级的用户可访问权限也不相同。

本实施例中，通过对目标APK文件设置用户的访问权限，使得部分目标APK文件的访问受到账户的限制，从而达到禁止权限不够的用户访问机密目标APK文件，进而有效地增加了机密APK文件的安全性能，有效的提高了移动办公的安全性。

步骤S40：记录用户的操作信息，并生成操作日志，具体包括：

步骤S41：根据用户名，记录用户在系统内的操作；

步骤S42：根据记录的操作，生成与用户名对应的操作日志。

本实施例中，根据管理员指令创立的用户，不论是高级用户还是普通用户，其所有的操作都被系统记录在操作日志内，以达到系统对所有用户的一个操作管理。具体地，系统对每一位登录的用户都建立一个操作日志，操作日志记录该用户的所有操作，包括上传或下载目标APK文件的时间、目标APK文件的名称等，或者是在系统上运行某目标APK文件的时间，甚至用户在打包构建目标APK时设置的密码也会被记录。以高级用户给初始APK文件加VPN的功能壳为例，日志内会记录该高级用户上传初始APK文件的文件名称和时间；上传功能壳文件的文件名称和时间；以及打包构建时设置的VPN的密码和打包构建的时间；以及目标APK存贮的目录。系统根据各用户预置的权限，来查询用户的操作日志，当发现操作日志内记录有超出该用户预置权限的内容时，冻结该账号，并给管理员发出警报信息。通过生成用户的操作日志，有利于系统对用户的管控，有利于用户根据操作日志对操作用户的管理，有利于提高移动应用的安全。

在实现上述的方法步骤中，需要使用到以下模块：

移动应用管理模块20，用于上传和下载壳文件、初始APK文件以及目标APK文件；

本实施例中，移动应用管理模块20包括上传单元21和下载单元22。上传单元21用于供用户上传初始APK文件、功能壳文件以及打包构建后的目标APK文件，下载单元22用于供用户下载打包构建后的目标APK文件。当然，移动应用管理模块20与用户管理模块10对应，不同等级的用户可以下载和上传的APK文件类型的范围不同，如高级用户可以通过上传单元21上传管理类的初始APK文件，而普通用户则不能。

存储模块40，用于接收和存储壳文件、初始APK文件以及目标APK文件。

存储模块包括用于存储初始APK文件和壳文件的初始存储单元，用于打包过程中的中间存储单元，以及用于存储打包构建后的目标APK文件的目标存储单元。初始存储单元用于接收用户上传的初始APK文件和功能壳文件，并将接收后的文件存储。中间存储单元用于接收和存储打包过程中解析后的初始APK文件和壳文件。目标存储单元除了存储在系统内打包构建的目标APK文件外，也用于存储用户上传的目标APK文件。存储模块40与用户管理模块10相对应，存储模块内的内容，需要相应等级的用户才能读取和写入。如管理类的初始APK文件和目标APK文件，只有高级用户可以读取，而普通用户则不能。

本实施例，通过对用户分级，设置各级用户的访问权限，从而使得部分目标APK文件的访问受到账户的限制，从而达到禁止权限不够的用户访问机密目标APK文件，进而有效地增加了机密APK文件的安全性能，有效的提高了移动办公的安全性；通过生成用户的操作日志，有利于系统对用户的管控，有利于用户根据操作日志对操作用户的管理，有利于提高移动应用的安全；对初始APK文件进行分类，然后根据初始APK文件的类别获取相应的一个或者多个功能壳，并将所获取的功能壳逐一的与初始APK文件进行打包构建；目标APK文件由系统提供的功能壳和初始APK文件打包构建生成，保证目标APK文件能稳定可靠的按照系统的要求在系统上运行，从而不会威胁到系统的安全；通过功能壳的打包构建，使得目标APK文件本身就具有限制用户访问和使用的功能，从而减少非必要的用户访问目标APK文件，从而有利于保障移动办公的安全；另外，通过打包构建目标APK文件的方式来增加移动办公的安全性，具有易部署、易维护、易弹性扩展性，并且它无需修改原有的IT系统，也无需移动应用改造，从而有效的控制了移动应用打包所耗费的成本。

以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。

Claims (10)

1.一种移动应用打包的系统，其特征在于，所述移动应用打包的系统包括：

用户管理模块，用于设置用户访问目标APK文件的权限；

移动应用管理模块，用于上传和下载壳文件、所述初始APK文件以及所述目标APK文件；

打包构建模块，用于将所述初始APK文件和所述壳文件打包构建成所述目标APK文件；

日志管理模块，用于记录用户的操作信息，并生成操作日志；

存储模块，用于接收和存储所述壳文件、所述初始APK文件以及所述目标APK文件。

2.如权利要求1所述的移动应用打包的系统，其特征在于，所述用户管理模块包括：

分级单元，用于根据预置指令对登录系统的用户进行分级；

设置单元，用于根据用户的级别设置用户可以访问的目标APK文件的类别。

3.如权利要求1所述的移动应用打包的系统，其特征在于，所述日志管理模块包括：

记录单元，用于根据用户名，记录用户在系统内的操作；

生成单元，用于根据记录的所述操作，生成与所述用户名对应的操作日志。

4.如权利要求1所述的移动应用打包的系统，其特征在于，所述打包构建模块包括：

获取单元，用于获取初始APK文件和壳文件；

反编译单元，用于对所述初始APK文件进行反编译处理；

提取单元，用于从反编译处理后的文件中提取与所述壳文件中的文件类型相同的目标文件；

合并单元，用于将所述目标文件和所述壳文件进行合并处理；

打包构建单元，用于将合并处理后的文件和所述初始APK文件存贮至预置文件夹，并打包构建所述预置文件夹为目标APK文件。

5.如权利要求4所述的移动应用打包的系统，其特征在于，所述打包构建模块包括：

第一判断单元，用于获取所述初始APK文件的文件类型，判断所述APK文件的类型是否为APK类型；

第二判断单元，用于若所述初始APK文件的类型为APK类型，获取所述初始APK文件的xml文件，判断所述xml文件内是否存在预置的标记信息；

所述第二判断模块还用于，当所述xml文件内不存在预置的标记信息时，提取单元从反编译处理后的文件中提取与所述壳文件的文件类型相同的目标文件。

6.一种移动应用打包的方法，其特征在于，所述移动应用打包的方法包括以下步骤：

当接收到用户上传的初始APK文件时，根据所述初始APK文件的类别获取对应的功能壳文件；

将所述初始APK文件和所述功能壳文件打包构建成目标APK文件并存储至目标文件夹；

设置用户访问目标APK文件的权限；

记录用户的操作信息，并生成操作日志。

7.如权利要求6所述的移动应用打包的方法，其特征在于，所述设置用户访问目标APK文件的权限包括：

根据预置指令对登录系统的用户进行分级；

根据用户的级别设置用户可以访问的目标APK文件的类别。

8.如权利要求6所述的移动应用打包的方法，其特征在于，所述记录用户的操作信息，并生成操作日志的步骤包括：

根据用户名，记录用户在系统内的操作；

根据记录的所述操作，生成与所述用户名对应的操作日志。

9.如权利要求6所述的移动应用打包的方法，其特征在于，所述将所述初始APK文件和所述功能壳文件打包构建成目标APK文件并存储至目标文件夹的步骤包括：

获取初始APK文件和壳文件；

对所述初始APK文件进行反编译处理；

从反编译处理后的文件中提取与所述壳文件中的文件类型相同的目标文件；

将所述目标文件和所述壳文件进行合并处理；

将合并处理后的文件和所述初始APK文件存贮至预置文件夹，并打包构建所述预置文件夹为目标APK文件。

10.如权利要求9所述的移动应用打包的方法，其特征在于，所述对初始APK文件进行反编译处理的步骤之后还包括：

获取所述初始APK文件的文件类型，判断所述APK文件的类型是否为APK类型；

若所述初始APK文件的类型为APK类型，获取所述初始APK文件的xml文件，判断所述xml文件内是否存在预置的标记信息；

当所述xml文件内不存在预置的标记信息时，提取单元从反编译处理后的文件中提取与所述壳文件的文件类型相同的目标文件。