网上有很多文章讲这个，但是我觉得讲的不够体系，希望我的总结能够让大家快速理解安卓签名到底是个什么。
首先，任何一个名词或者事务的出现一定是要来解决什么问题的，那么安卓签名解决什么问题呢？
场景1：
假设腾讯开发了个应用叫微信，包名（包名就是一个应用在安卓系统的ID）叫做com.wechat
那么现在有个盗版fake公司，开发了一个fake wechat，包名也叫com.wechat
当用户安装盗版fake公司的face wechat的时候，会把腾讯的wechat覆盖掉，这对于用户是不可接受的。
场景2：
腾讯的微信里面的代码被fake修改了，修改后的微信会偷偷扣费，可以呗用户安装和更新，用户安装了以后，就会一直扣钱。这对用户也是不能接受。
为了解决这个问题，安卓系统规定，一个app需要有签名，才能安装。必须签名一致，才能覆盖更新。
那么签名到底是什么？它到底如何解决上面的问题？
带着疑问，我们继续来看，先直观的感受下一个apk的结构
里面有一个叫META-INF的文件夹
META-INF文件夹里面有三个关键文件xx.MF、xx.RSA、xx.SF，这三个玩意儿是签名后产生的。也就是说，这三个文件是签名的关键。
看完结构后，回到我们刚才的问题，微信如何能保证自己不被别人覆盖或者修改，那么微信他可能先要有一个类似于指纹的东西来保证这就是我，这就是签名，其次这个签名如何能保证，数据被修改后，能够知道被改了。
思路：第一个问题简单，就是私钥和公钥，用户用我给的公钥，能解开我，那就是真的我（这里先不考虑你的私钥丢了，或者公钥私钥都是假的情况，后面会说明如何保证）。第二个问题的思路是，把所有文件都参与hash计算，并用私钥加密，如果公钥解开了，并且对所有文件hash的结果一样，那么就是没被修改。（当然这是马后炮，因为这个方案不是我发明的）
先介绍一下一些关键的名词
数据：就是除刚才说的那三个文件之外，所有的文件
数据摘要：就是x.MF文件，对数据里的每个文件进行hash，具体长这样：
.SF文件：是对MF文件里的数据进行私钥加密，具体长这样
证书：主要是放公钥的地方，和一些其他的信息，比如作者的名字，证书的有效期等等
整个过程如上图所示，最终能保证数据的正确性和完整性。我们可以举一些反例来证明，这套方案是靠谱安全的
假如你没有私钥，你修改了文件，打了MF（这一步不讨论，没啥意义），因为你没有私钥，你也没有办法打SF，到客户端那边用公钥解开SF，但是校验文件的时候，会对不上，所以验签失败
假如你自己伪造了一把私钥，修改了文件，打了MF，并重新打了SF，但是客户端那边，用证书里面的公钥是解不开的，验签失败
假如你自己伪造了一把私钥，修改了文件，打了MF，并重新打了SF，并且伪造了证书，到客户的那边，按道理就可以解开，并且校验通过。但是这时候有个叫CA的证书，会校验你那个装公钥的证书，发现是假的。于是验签失败
那么CA证书又是个什么？
其实又是一个循环，开发者会把自己的公钥给CA，让CA用CA私钥（注意这里的CA私钥和上面的应用私钥用途不一样，不是同一个）加密生成证书，并公示于众，然后用户用CA公钥解开签名，拿到应用公钥...
那么这个CA证书如果也被伪造呢？不就无解了吗？这就是一个社会学问题了，这就好比你信任银行一样，银行是靠谱的，没人能破解它，银行自己也不会瞎搞。
那这个CA证书如何保证像银行一样的存在呢？你的手机有个地方存放根证书，只有经过CA认证的证书才会放进去，除非你自己同意装一些未经过认证的证书（这个动作很危险），当然这块里面还有很多细节，但是主要是为了做这个事。
安全都是相对的，这个案例告诉大家，不要乱同意装证书
到目前为止，就可以保证应用是安全的，完整的，不被修改的。
fake公司它没有办法覆盖wechat，因为他没有wechat的私钥，没法生成真正的签名
fake也没有办法修改wechat，因为验签过不了
最后说一个知识点，这里面签名出现了好多个地方，那我们平时说的应用签名到底是什么呢？实际上就是最上面那个大图证书里面的那个签名 = md5(私钥（公钥+一些信息）)，这些都是常量，所以签名是固定的
有错误，欢迎指正