一、Android APK打包流程
** 资源预编译 **
为每一个非assert资源生成一个ID并保存在一个R文件中。
** Java文件编译 **
把手动编写的Java文件和前面步骤生成的Java文件一起编译成.class文件
** Dex文件生成 **
把前面生成的class文件和第三方库的class文件一起整合成.dex文件，相当于所有.class文件的索引表，可以通过这个文件找到每一个.class文件
** 资源文件打包 **
对资源进行大小进行优化，并把所有有ID的资源对应的配置信息收录生成resource.arsc文件中，相当于资源的索引表。
** APK文件生成 **
把之前生成的.dex文件和resource.arsc文件以及资源文件（res文件，里面包含一些已编译成二进制的文件如布局文件等和一些未编译成二进制的文件如图片等）和未分配ID的文件（assert文件）等整合成一个APk文件（特殊的.zip文件）。
** 对生成的APK进行签名 **
添加唯一标识，从而保证能够正常安装和覆盖安装，不会被恶意覆盖，以及说明APK的来源和拥有者。
** 对齐处理 **
对APK中一些资源的二进制上的位置进行调整，从而加快APk运行时的速度。
二、签名校验流程
将某一Apk进行解压查看，我们可以观察到META-INF目录。而且，在apk升级、覆盖安装的时候除了校验包名是否正确，还包括对签名信息的校验。其中校验流程主要是对META-INF目录下面的文件三个文件进行验证。
（1）校验apK中所有文件的数字编码，然后和MANIFEST.MF文件中的数字编码对比是否一致
（2）验证CERT.SF文件的签名信息和CERT.RSA中的内容是否一致(CERT.SF进行私钥签名后的信息和公钥信息存储在CERT.R)
（3）最后验证MANIFEST.MF，base64签名后的信息与CERT.SF头部（SHA1-Digest-Manifest）是否匹配
三、签名原理分析
（1） ** MANIFEST.MF **
首先观察下 ** MANIFEST.MF **下的内容
这里是表示在打包apk中的文件中，每个文件对应的数字编码，每个文件斗殴一个唯一的SHA1值，这是后完成了第一个签名文件生成。
（2） ** CERT.SF **
首先观察 CERT.SF 内容
内容是不是跟MANIFEST.MF文件有点相似，虽然MANIFEST.MF能够记录下每个文件的唯一编码值，虽然保证了MANIFEST记录的文件安全，但是无法保证自身安全，别人依然可以进行篡改。
所以需要CERT.SF对MANIFEST.MF进行加固。首先依然将每个文件在进行一次数字编码，并且存储在CERT.SF中。然后对MANIFEST.MF进行base64进行编码后存储在CERT.SF文件头部（SHA1-Digest-Manifest）
（3）** CERT.RSA **
由二进制内容组成。生成CERT.SF后，我们会将私钥对CERT.SF进行加密得出签名。将得到的签名和公钥的数字证书信息保存在CERT.RSA中，整个签名过程结束。
开发记录 2017.02.22
