对于一个待保护的Android应用程 序，首先需要将其进行解压缩，然后获取到其中的可执行文件。本发明中，应用程序的可执 行文件指的是运行在Android Dalvik虚拟机上的可执行文件，即dex文件。
[0045] 步骤2,从待保护的Android应用程序中提取共享库文件、资源文件以及配置信 息；具体步骤包括：
[0046] 步骤2. 1，从解压缩后的Android应用程序包中提取出所有的共享库文件；
[0047] 步骤2. 2,资源文件包括应用程序的图片文件、布局文件等，布局文件是经过编译 后打包到应用程序包中的，因此，首先需要利用反编译工具Apktool将应用程序进行反编 译，然后再从其中提取这些资源文件；
[0048] 步骤2. 3,本发明中的应用程序配置信息指的是Manifest文件中的配置信息， 同样的，从反编译后的应用程序包中获取到Manifest文件，提取出Application类的类 名（若该应用程序有用户自定义的Application类）、各组件（包括Activity、Service、 Broadcast receiver、Content Provider)的声明信息、应用程序的权限声明列表。
[0049] 步骤3,根据步骤1提取出的可执行文件的结构，对可执行文件进行代码分片，然 后将各代码片分别进行加密；
[0050] 步骤3. 1，分析待保护可执行文件的文件结构，确定出分片方案，即根据可执行文 件的不同构成部分，将其分为不同的代码片段。如图2给出的一种示例中，将其中的Dex Header、String Table、Type Table^Proto Table、Field Table、Method Table、Class Def Table、Data Section这八个部分分离开来；
[0051] 步骤3. 2,确定要分离的各部分代码片的文件偏移，过程为：解析Dex header结 构，读取出后面7个部分的文件偏移值，记为String_Off、Type_Off、Proto_Off、Field_ Off、Method_Off、Class_Off、Data_Off，则Dex Header部分的内容就是该文件中偏移值O 到String_Off之间的部分，String Table部分的内容就是该文件中偏移值String_Off到 Type_0ff之间的部分，Type Table部分的内容就是该文件中偏移值Type_0ff到Proto_ Off之间的部分，Proto Table部分的内容就是该文件中偏移值Proto_0ff到Field_0ff之 间的部分，Field Table部分的内容就是该文件中偏移值Field_0ff到Method_0ff之间的 部分，Method Table部分的内容就是该文件中偏移值Method_0ff到Class_0ff之间的部 分，Class Def Table部分的内容就是该文件中偏移值Class_0ff到Data_0ff之间的部分， Data Section部分的内容就是该文件中偏移值Data_0ff到文件尾之间的部分；
[0052] 步骤3. 3,将各部分的代码片内容分别读取到独立的文件中；如本示例中，将各 个部分的内容分别读取到8个独立文件中，记为Header_File、String_File、Type_File、 Proto_File、Field_File、Method_File、Class_File、Data_File ;
[0053] 步骤3. 4,依据低性能消耗原则，使用对称加密算法对各代码片内容进行加密。在 本示例中，设定8个不同的秘钥，使用对称加密算法AES加密算法分别对以上8个文件的 内容进行加密，输出加密后的文件，记为Header_File_enc、String_File_enc、Type_File_ enc、Proto_File_enc、Field_File_enc、Method_File_enc、Class_File_enc、Data_File_ enc〇
[0054] 步骤4,为待保护的应用程序建立新的应用程序包，作为最终保护后应用的程序 包；将加密后的各代码片以及步骤2中提取的共享库文件、资源文件导入到该新的应用程 序包中，并在其配置文件中添加提取的配置信息；具体过程如下：
[0055] -个Android应用程序在经过本发明保护前后，其包结构组成变化如图3所示。经 过本发明保护后，其原始dex文件会以加密、碎片化的形式存在，该dex的执行是靠一个外 壳dex文件来引导的，为保证该应用在保护过后的功能完整性及一致性，共享库文件、资源 文件需要完整地存在于保护后的应用程序包中，而Manifest文件中则需要包含外壳dex以 及原始dex的所有配置信息：
[0056] 步骤4. 1，为待保护的应用程序建立新的应用程序包：新建一个Android工程，记 为protected，作为保护后的应用程序；将加密后的各代码段拷贝到新的应用程序包中的 assets目录下；
[0057] 若应用程序中包含本地库，则将提取到的所有的库文件直接作为保护后应用的库 文件处理，即将其置于protected的libs/armeabi目录下；
[0058] 步骤4. 2,将步骤2中提取的资源文件，如各种布局文件、图片文件等合并至新的 应用程序包中；
[0059] 步骤4. 3,将步骤2提取出的原始应用的配置信息，包括Application类名、各组件 的声明信息、权限声明在保护后应用程序的配置文件中进行添加；其中，Application类名 以Meta-data的形式进行保存；各组件的配置信息以及权限声明作为保护后应用的组件以 及权限直接在保护后应用的配置文件中进行配置和声明。
[0060] 对于Application的声明，由于该类在Android应用程序中的特殊地位--应用 入口，不能直接作为protected的Application类进行配置，而需要对其进行后续的特殊处 理，在此，只需要将其类名保存起来即可，因此，以Meta-data的形式在Manifest文件中进 行保存；各组件可作为protected的组件，直接在Manifest文件中进行声明，因此，只需要 将提取出的各声明信息按照组件声明格式拷贝到protected的Manifest文件中即可；同样 的，权限声明也可直接作为protected的权限声明信息，以相同方式拷贝即可。
[0061] 步骤5,对加密后的各代码片进行解密并分别映射到相互独立的内存空间中，具体 为：
[0062] 步骤5. 1，根据加密后各代码片对应的文件大小确定出各代码片所需的空间大小， 本例中分别记为 Header_Size、String_Size、Type_Size、P;roto_Size、Field_Size、Method_ Size、Class_Size、Data-Size ;
[0063] 步骤5. 2,根据各代码片大小分别为其分配相应的内存空间，所分配的每一个内存 空间都是一个独立的Virtual Memory Area (VMA)，记录每一个代码片所在VMA的首地址， 记为 Header_0ff_vma，String_0ff_vma、Type_0ff_vma、Proto_0ff_vma、Field_0ff_vma、 Method_0ff_vma、Class_0ff_vma、Data_0ff_vma ;
[0064] 步骤5. 3,解密各代码片，并将解密后的数据分别直接映射到所述的内存空间VM 中。
[0065] 步骤6,对解密映射到内存区域中的各代码片进行修复，使这些代码片重组为可执 行文件；内存中的可执行文件目前是以碎片化形式存在的，因此要进行修