安卓数字签名指的是对apk包做文件摘要并加密，在安装apk包时做解密和验证以保证包体不被篡改。这里先普及下签名和验证流程。签名文件保存在apk包里META-INF目录下，包含3个文件：
1、后缀为MF的是摘要文件。首先遍历apk包，将除META-INF目录外其他所有文件用SHA1生成摘要信息并用base64编码。如果你手动改变了apk包中的文件，那么在apk包安装验证时，改后的文件摘要信息与原MF文件中的不一致，会导致安装失败。
2、后缀为SF还是摘要文件。对上面生成的MF文件做两步处理，首先读取全量摘要文件使用SHA1生成摘要并用base64编码，然后再次读取各文件子项再次做一样的摘要操作。
3、后缀为RSA的是签名文件。数字证书一般存放在钥匙库中，从数字证书中取出私钥，对SF文件使用SHA1-RSA算法进行非对称加密得到RSA文件。在安装时从钥匙库取出数字证书的公钥并解密，再与未加密前的摘要信息进行对比，相符则说明apk包未被篡改。
问题场景是原来签名正常的apk包突然出现闪退现象。经定位发现该签名包体原来已经签过名，重复签名导致问题发生。排查代码发现，在生成MF文件时调用addDigestsToMainfest方法时没有去掉以上三个文件，导致重复签名时重复计算摘要，安装验证时拿计算后的摘要比较计算前的，必然会出现验证失败。
举例，首次签名时包里是不存在这三个文件的，所以首次签名会正常生成wlf. MF、wlf.SF和wlf.RSA；第二次签名会把这三个文件也计算进wlf.MF里去，接着按上面逻辑生成另外两个文件，再替换掉原来三个同名文件。而且这时wlf.MF已经改变了，同样其他两个文件也跟着变。那么在验证时拿新的摘要去比对包体里老的摘要，发现这三个文件被替换了，验证也就失败了。第三次重复签名的话这三个文件还会被替换成新的，因为计算后文件又被替换了，以此类推。举个例子，好比你拿着刚办好的二代身份证给人家看，但人家系统里只有你的一代身份证，虽然名字一样，样貌衣着却变了，人家一核对就怀疑你了。而篡改的人就是你自己，这就叫监守自盗了。所以做摘要必须要去掉那三个文件。