小编在之前给大家介绍过很多android项目打包的经验，本篇内容我们通过一个项目实例来给大家讲解android每一步打包和签名的过程。 [b]android打包[/b] 以下是原理图： [img]http://files.jb51.net/file_images/article/201712/2017120715151461.png[/img] 由android的项目经过编译和打包，形成了: [b].dex 文件[/b] [b]resources.arsc[/b] [b]uncompiled resources[/b] [b]AndroidManifest.xml[/b] 解压了一个普通的apk文件，解压出来的文件如下： [img]http://files.jb51.net/file_images/article/201712/2017120715151462.png[/img] classes.dex 是.dex文件。resources.arsc是resources resources文件。AndroidManifest.xml是AndroidManifest.xml文件。res是uncompiled resources。META-INF是签名文件夹。 其中resources.arsc相等于是资源文件的索引，方便查找资源文件 具体打包流程图： [img]http://files.jb51.net/file_images/article/201712/2017120715151463.png[/img] [b]android签名[/b] android签名后文件中多了个META-INF其中有三个文件： [img]http://files.jb51.net/file_images/article/201712/2017120715151564.png[/img] 下面分析一下3个文件的具体如何生成的apksinger： [b]1、MANIFEST.MF[/b] 逐一遍历里面的所有条目，如果是目录或者三个文件(MANIFEST.MF,CERT.RSA,CERT.SF)就跳过，如果是一个文件，就用SHA1（或者SHA256）消息摘要算法提取出该文件的摘要然后进行BASE64编码后，作为“SHA1-Digest”属性的值写入到MANIFEST.MF文件中的一个块中。该块有一个“Name”属性，其值就是该文件在apk包中的路径。 [b]2、CERT.SF：[/b] 1》计算这个MANIFEST.MF文件的整体SHA1值，再经过BASE64编码后，记录在CERT.SF主属性块（在文件头上）的“SHA1-Digest-Manifest”属性值值下 2》逐条计算MANIFEST.MF文件中每一个块的SHA1，并经过BASE64编码后，记录在CERT.SF中的同名块中，属性的名字是“SHA1-Digest [b]3、CERT.RSA[/b] 这里会把之前生成的 CERT.SF文件， 用私钥计算出签名, 然后将签名以及包含公钥信息的数字证书一同写入 CERT.RSA 中保存。CERT.RSA是一个满足PKCS7格式的文件。 [b]为何要这么来签名[/b] 上面我们就介绍了签名apk之后的三个文件的详细内容，那么下面来总结一下，Android中为何要用这种方式进行加密签名，这种方加密是不是最安全的呢？下面我们来分析一下，如果apk文件被篡改后会发生什么。 首先，如果你改变了apk包中的任何文件，那么在apk安装校验时，改变后的文件摘要信息与MANIFEST.MF的检验信息不同，于是验证失败，程序就不能成功安装。 其次，如果你对更改的过的文件相应的算出新的摘要值，然后更改MANIFEST.MF文件里面对应的属性值，那么必定与CERT.SF文件中算出的摘要值不一样，照样验证失败。 最后，如果你还不死心，继续计算MANIFEST.MF的摘要值，相应的更改CERT.SF里面的值，那么数字签名值必定与CERT.RSA文件中记录的不一样，还是失败。 那么能不能继续伪造数字签名呢？不可能，因为没有数字证书对应的私钥。 所以，如果要重新打包后的应用程序能再Android设备上安装，必须对其进行重签名。 从上面的分析可以得出，只要修改了Apk中的任何内容，就必须重新签名，不然会提示安装失败，当然这里不会分析，后面一篇文章会注重分析为何会提示安装失败。