很多人只知道开发完之后签名发布，签名就生成一个keystore文件就行，而不太清楚具体的签名流程，现在我就在这边简单过一遍流程。
本章节只讲流程，不会详细的去分析签名的源码，并且可能某些细节说得不对，但总体流程肯定就是那么一回事，如果有不对的地方还希望有大佬能够指点。
一.概念
开始之前我们先来简单了解几个重要的概念，有助于理解android的签名流程。
1.加密
数据加密的基本过程就是对原来为明文的文件或数据按某种算法进行处理，使其成为不可读的一段代码，通常称为"密文"，使其只能在输入相应的密钥之后才能显示出本来内容，通过这样的途径来达到保护数据不被非法人窃取、阅读的目的。
加密一般分为对称加密和非对称加密。
一般非对称加密更为安全，而一般非对称加密的操作是用公钥进行加密，接收端用私钥进行解密。
2.消息摘要
又称数字摘要或数字指纹。简单来说就是任意长度数据经过单向的HASH函数，生成一个固定长度的HASH值。也就是经过算法处理后的一个固定长度的数据。
3.数字签名
数字签名的作用就是保证信息传输的完整性、发送者的身份认证、防止交易中的抵赖发生。数字签名技术是将摘要信息用发送者的私钥加密，与原文一起传送给接收者。接收者只有用发送者的公钥才能解密被加密的摘要信息然后用HASH函数对收到的原文产生一个摘要信息，与解密的摘要信息对比。如果相同，则说明收到的信息是完整的，在传输过程中没有被修改，否则说明信息被修改过，因此数字签名能够验证信息的完整性。
和加密相比正好返过来，是用私钥加密，用公钥解密。
4.数字证书
数字证书就是互联网通讯中标志通讯各方身份信息的一串数字。简单来说就是能证明通信方的身份，能确定和我通信的是你，而不是某个假冒你的人。
假如你这边把应用用私钥签名，把签名后的文件和公钥都发给接收端。但是如果中间有人拦截，把文件换了，重新用自己的私钥签名，再换对应的公钥发给接收端。接收端依旧能正常校验成功，难道这就说明这个文件是正确的吗？所以才需要数字证书来证明这个公钥来自于真正的发送端。
二. 签名过程
单单这样讲这些概念，还是有点难以理解，我们就用签名的各个步骤来加深上面的每个概念。
1. android签名的工具
android有两种签名工具jarsigner和signapk。jarsigner在JDK里面，apksigner在build-tools里面，具体的路径可以自行百度，因为我不敢保证所有版本的路径是固定不变的。
jarsigner会生成keystore，也就是我们用AS的签名能生成keystore。signapk能生成pk8和pem。这两方也是可以转换的。
2. 签名和校验大概流程
按抽象来说（这是按我的理解，也行细节上有些差别），签名和校验的大概过程是，发送者把文件用算法生成摘要，再用私钥对摘要进行加密，把证书、文件、加密串、公钥发给接收端。接收端获取到之后，根据证书认真发送者身份，用公钥对加密串进行解密，再对文件也用算法生成摘要，对比解密之后的信息和摘要的信息是否相同。网上有张图挺形象的描述这个过程。
3. android签名生成的三个文件
对代码签名之后会生成三个文件：MANIFEST.MF、CERT.SF和CERT.RSA。
如果你解压apk或者反编译apk的话会看到一个META-INF文件夹，打开里面就包含这3个文件
这三个文件是在签名过程中生成的。
这里就抽象讲讲生成过程，不说源码，网上也很多讲这3个文件的生成代码。
（1）MANIFEST.MF
MANIFEST.MF的内容是所有文件进行SHA-1（这是一个Hash算法）之后再base64编码之后的值。去遍历所有文件，一个一个文件夹遍历，要是有文件，就SHA-1再base64。无论你每个文件长度怎样，每个文件都会生成一个固定长度的值，再把这些值一行一行记录下来（当然除了所有文件还有其他的属性，这个可以自行百度）。
可以看出这个过程就是一个获取摘要的过程，把不固定长度的文件生成固定长度的字符串。
（2）CERT.SF
其实就是将MANIFEST.MF文件按一定规则再进行SHA-1之后再base64。
SHA1-Digest-Manifest属性是对整个MANIFEST.MF文件做SHA1再base64生成的串。
之后的每个SHA1-Digest是对MANIFEST.MF的各个条目做SHA1再用base64。
所以这个过程还是一个获取摘要的过程。
（3）CERT.RSA
可以看出CERT.RSA不同于上边两个文件，是一个加密串。
CERT.RSA包含了很多东西。CERT.SF文件用私钥加密，然后把数字证书，公钥等一起组合在一起生成CERT.RSA。
可以看出这是一个用私钥加密的过程。
4. 签名验证的过程
安装的时候，会验证这三个文件，判断是否完整，这个其实很好理解。
我们一般会经历过这样的一种情况，我们手机已经安装过一个文件，如果用不同的签名就会安装出错，如果使用相同的签名就能覆盖安装。
安装时先会去查找是否已安装过相同的包名的应用，然后拿到证书指纹和要安装应用的证书指纹进行判断，相同的话说明是同一个应用。
至于指纹证书的原理我也不是很懂，在网上看到有人说是jks中X509证书的摘要信息，也有说是证书发行者对证书的数字签名。
而这些信息会存在CERT.RSA中，所以这个校验过程是在校验CERT.RSA的时候操作的。
大概的一个签名和验证的过程基本就是这样。
