安卓签名有什么好处
① Android签名机制之签名文件和数字证书的作用
Android签名机制目的是确保app的可靠通信，其一，要确定消息的来源确实是其申明
的那个人；其二，要保证信息在传递的过程中不被第三方篡改，即使被篡改了，也可以
发觉出来。
所谓数字签名，就是为了解决这两个问题而产生的，它是对非对称加密技术与数字摘要
技术的一个具体的应用。
对于消息的发送者来说，先要生成一对公私钥对，将公钥给消息的接收者。
如果消息的发送者有一天想给消息接收者发消息，在发送的信息中，除了要包含原始的
消息外，还要加上另外一段消息。这段消息通过如下两步生成：
1）对要发送的原始消息提取消息摘要；
2）对提取的信息摘要用自己的私钥加密。
通过这两步得出的消息，就是所谓的原始信息的数字签名。
而对于信息的接收者来说，他所收到的信息，将包含两个部分，一是原始的消息内容，
二是附加的那段数字签名。他将通过以下三步来验证消息的真伪：
1）对原始消息部分提取消息摘要，注意这里使用的消息摘要算法要和发送方使用的一致；
2）对附加上的那段数字签名，使用预先得到的公钥解密；
3）比较前两步所得到的两段消息是否一致。如果一致，则表明消息确实是期望的发送者
发的，且内容没有被篡改过；相反，如果不一致，则表明传送的过程中一定出了问题，
消息不可信。
通过这种所谓的数字签名技术，确实可以有效解决可靠通信的问题。如果原始消息在传
送的过程中被篡改了，那么在消息接收者那里，对被篡改的消息提取的摘要肯定和原始
的不一样。并且，由于篡改者没有消息发送方的私钥，即使他可以重新算出被篡改消息
的摘要，也不能伪造出数字签名。
那么数字签名呢？
综上所述，数字签名其实就是只有信息的发送者才能产生的别人无法伪造的一段数字
串，这段数字串同时也是对信息的发送者发送信息真实性的一个有效证明。
不知道大家有没有注意，前面讲的这种数字签名方法，有一个前提，就是消息的接收者
必须要事先得到正确的公钥。如果一开始公钥就被别人篡改了，那坏人就会被你当成好
人，而真正的消息发送者给你发的消息会被你视作无效的。而且，很多时候根本就不具
备事先沟通公钥的信息通道。那么如何保证公钥的安全可信呢？这就要靠数字证书来解
决了。
所谓数字证书，一般包含以下一些内容：
证书的发布机构（Issuer）
证书的有效期（Validity）
消息发送方的公钥
证书所有者（Subject）
数字签名所使用的算法
数字签名
可以看出，数字证书其实也用到了数字签名技术。只不过要签名的内容是消息发送方的
公钥，以及一些其它信息。但与普通数字签名不同的是，数字证书中签名者不是随随便
便一个普通的机构，而是要有一定公信力的机构。这就好像你的大学毕业证书上签名的
一般都是德高望重的校长一样。一般来说，这些有公信力机构的根证书已经在设备出厂
前预先安装到了你的设备上了。所以，数字证书可以保证数字证书里的公钥确实是这个
证书的所有者的，或者证书可以用来确认对方的身份。数字证书主要是用来解决公钥的
安全发放问题。
综上所述，总结一下，数字签名和签名验证的大体流程如下图所示：
引用链接： https://www.cnblogs.com/dacainiao/p/5842987.html
② android包名修改了，还能用以前的签名吗
android包名修改了，仍然可用以前的签名，用什么签名与包名无关。
同一个开发者的多个程序尽可能使用同一个数字证书 ，这可以带来以下好处：
1、有利于程序升级，当新版程序和旧版程序的数字证书相同时，Android系统才会认为这两个程序是同一个程序的不同版本。如果新版程序和旧版程序的数字证书不相同，则Android系统认为他们是不同的程序，并产生冲突，会要求新程序更改包名；
2、有利于程序的模块化设计和开发。Android系统允许拥有同一个数字签名的程序运行在一个进程中，Android程序会将他们视为同一个程序。所以开发者可以将自己的程序分模块开发，而用户只需要在需要的时候下载适当的模块；
3、 可以通过权限(permission)的方式在多个程序间共享数据和代码。Android提供了基于数字证书的权限赋予机制，应用程序可以和其他的程序共 享概功能或者数据给那那些与自己拥有相同数字证书的程序。如果某个权限(permission)的protectionLevel是signature， 则这个权限就只能授予那些跟该权限所在的包拥有同一个数字证书的程序。
③ apk签名是什么意思
apk签名相当于程序的身份识别代码。
是Android application package英文缩写。
它是为了确保消息来源的真实性，同时确保消息不会被第三方篡改。于是就产生了apk签名。
在apk中写入一个“指纹”。指纹写入以后，Apk中有任何修改，都会导致这个指纹无效，Android系统在安装Apk进行签名校验时就会不通过，从而保证了安全性。
(3)安卓签名有什么好处扩展阅读：
作用
1、apk签名用于程序编译打包之后，手机在运行程序之前会先去验证程序的签名（可以看作类似于我们电脑上常说的md5）是否合法，只有通过了验证的文件才会被运行，所以签名软件的作用的让文件通过手机的验证为合法，不同的手机、系统是对应不同的签名的。
2、可以用签名工具来更改。比如手机签名工具ZipSigner 2，可以对手机上的文件进行直接签名，支持apk、zip及jar格式，方便刷机或汉化的朋友。有些爱好修改安卓apk软件的用户有时候需要对apk文件进行修改。
但是如果在电脑上操作的话，打包签名是十分复杂的，还必须安装java环境，可以说打包一个包是十分麻烦的，这款签名工具可以解决上述遇到的问题。
3、应用程序模块化：Android 系统可以允许同一个证书签名的多个应用程序在一个进程里运行，系统实际把他们作为一个单个的应用程序，此时就可以把我们的应用程序以模块的方式进行部署，而用户可以独立的升级其中的一个模块。
④ Android V1及V2签名原理简析
Android为了保证系统及应用的安全性，在安装APK的时候需要校验包的完整性，同时，对于覆盖安装的场景还要校验新旧是否匹配，这两者都是通过Android签名机制来进行保证的，本文就简单看下Android的签名与校验原理，分一下几个部分分析下：
签名是摘要与非对称密钥加密相相结合的产物，摘要就像内容的一个指纹信息，一旦内容被篡改，摘要就会改变，签名是摘要的加密结果，摘要改变，签名也会失效。Android APK签名也是这个道理，如果APK签名跟内容对应不起来，Android系统就认为APK内容被篡改了，从而拒绝安装，以保证系统的安全性。目前Android有三种签名V1、V2（N）、V3（P），本文只看前两种V1跟V2，对于V3的轮密先不考虑。先看下只有V1签名后APK的样式：
再看下只有V2签名的APK包样式：
同时具有V1 V2签名：
可以看到，如果只有V2签名，那么APK包内容几乎是没有改动的，META_INF中不会有新增文件，按Google官方文档：在使用v2签名方案进行签名时，会在APK文件中插入一个APK签名分块，该分块位于zip中央目录部分之前并紧邻该部分。在APK签名分块内， 签名和签名者身份信息会存储在APK签名方案v2分块中，保证整个APK文件不可修改 ，如下图：
而V1签名是通过META-INF中的三个文件保证签名及信息的完整性：
V1签名是如何保证信息的完整性呢？V1签名主要包含三部分内容，如果狭义上说签名跟公钥的话，仅仅在.rsa文件中，V1签名的三个文件其实是一套机制，不能单单拿一个来说事，
如果对APK中的资源文件进行了替换，那么该资源的摘要必定发生改变，如果没有修改MANIFEST.MF中的信息，那么在安装时候V1校验就会失败，无法安装，不过如果篡改文件的同时，也修改其MANIFEST.MF中的摘要值，那么MANIFEST.MF校验就可以绕过。
CERT.SF个人觉得有点像冗余，更像对文件完整性的二次保证，同绕过MANIFEST.MF一样，.SF校验也很容易被绕过。
CERT.RSA与CERT.SF是相互对应的，两者名字前缀必须一致，不知道算不算一个无聊的标准。看下CERT.RSA文件内容：
CERT.RSA文件里面存储了证书公钥、过期日期、发行人、加密算法等信息，根据公钥及加密算法，Android系统就能计算出CERT.SF的摘要信息，其严格的格式如下：
从CERT.RSA中，我们能获的证书的指纹信息，在微信分享、第三方SDK申请的时候经常用到，其实就是公钥+开发者信息的一个签名：
除了CERT.RSA文件，其余两个签名文件其实跟keystore没什么关系，主要是文件自身的摘要及二次摘要，用不同的keystore进行签名，生成的MANIFEST.MF与CERT.SF都是一样的，不同的只有CERT.RSA签名文件。也就是说前两者主要保证各个文件的完整性，CERT.RSA从整体上保证APK的来源及完整性，不过META_INF中的文件不在校验范围中，这也是V1的一个缺点。V2签名又是如何保证信息的完整性呢？
前面说过V1签名中文件的完整性很容易被绕过，可以理解 单个文件完整性校验的意义并不是很大 ，安装的时候反而耗时，不如采用更加简单的便捷的校验方式。V2签名就不针对单个文件校验了，而是 针对APK进行校验 ，将APK分成1M的块，对每个块计算值摘要，之后针对所有摘要进行摘要，再利用摘要进行签名。
也就是说，V2摘要签名分两级，第一级是对APK文件的1、3 、4 部分进行摘要，第二级是对第一级的摘要集合进行摘要，然后利用秘钥进行签名。安装的时候，块摘要可以并行处理，这样可以提高校验速度。
APK是先摘要，再签名，先看下摘要的定义：Message Digest：摘要是对消息数据执行一个单向Hash，从而生成一个固定长度的Hash值，这个值就是消息摘要，至于常听到的MD5、SHA1都是摘要算法的一种。理论上说，摘要一定会有碰撞，但只要保证有限长度内碰撞率很低就可以，这样就能利用摘要来保证消息的完整性，只要消息被篡改，摘要一定会发生改变。但是，如果消息跟摘要同时被修改，那就无从得知了。
而数字签名是什么呢（公钥数字签名），利用非对称加密技术，通过私钥对摘要进行加密，产生一个字符串，这个字符串+公钥证书就可以看做消息的数字签名，如RSA就是常用的非对称加密算法。在没有私钥的前提下，非对称加密算法能确保别人无法伪造签名，因此数字签名也是对发送者信息真实性的一个有效证明。不过由于Android的keystore证书是自签名的，没有第三方权威机构认证，用户可以自行生成keystore，Android签名方案无法保证APK不被二次签名。
知道了摘要跟签名的概念后，再来看看Android的签名文件怎么来的？如何影响原来APK包？通过sdk中的apksign来对一个APK进行签名的命令如下：
其主要实现在 android/platform/tools/apksig 文件夹中，主体是ApkSigner.java的sign函数，函数比较长，分几步分析
先来看这一步，ApkUtils.findZipSections，这个函数主要是解析APK文件，获得ZIP格式的一些简单信息，并返回一个ZipSections，
ZipSections包含了ZIP文件格式的一些信息，比如中央目录信息、中央目录结尾信息等，对比到zip文件格式如下：
获取到 ZipSections之后，就可以进一步解析APK这个ZIP包，继续走后面的签名流程，
可以看到先进行了一个V2签名的检验，这里是用来签名，为什么先检验了一次？第一次签名的时候会直接走这个异常逻辑分支，重复签名的时候才能获到取之前的V2签名，怀疑这里获取V2签名的目的应该是为了排除V2签名，并获取V2签名以外的数据块，因为签名本身不能被算入到签名中，之后会解析中央目录区，构建一个DefaultApkSignerEngine用于签名
先解析中央目录区，获取AndroidManifest文件，获取minSdkVersion(影响签名算法)，并构建DefaultApkSignerEngine，默认情况下V1 V2签名都是打开的。
第五步与第六步的主要工作是：apk的预处理，包括目录的一些排序之类的工作，应该是为了更高效处理签名，预处理结束后，就开始签名流程，首先做的是V1签名（默认存在，除非主动关闭）：
步骤7、8、9都可以看做是V1签名的处理逻辑，主要在V1SchemeSigner中处理，其中包括创建META-INFO文件夹下的一些签名文件，更新中央目录、更新中央目录结尾等，流程不复杂，不在赘述，简单流程就是：
这里特殊提一下重复签名的问题： 对一个已经V1签名的APK再次V1签名不会有任何问题 ，原理就是：再次签名的时候，会排除之前的签名文件。
可以看到目录、META-INF文件夹下的文件、sf、rsa等结尾的文件都不会被V1签名进行处理，所以这里不用担心多次签名的问题。接下来就是处理V2签名。
V2SchemeSigner处理V2签名，逻辑比较清晰，直接对V1签名过的APK进行分块摘要，再集合签名，V2签名不会改变之前V1签名后的任何信息，签名后，在中央目录前添加V2签名块，并更新中央目录结尾信息，因为V2签名后，中央目录的偏移会再次改变：
签名校验的过程可以看做签名的逆向，只不过覆盖安装可能还要校验公钥及证书信息一致，否则覆盖安装会失败。签名校验的入口在PackageManagerService的install里，安装官方文档，7.0以上的手机优先检测V2签名，如果V2签名不存在，再校验V1签名，对于7.0以下的手机，不存在V2签名校验机制，只会校验V1，所以，如果你的App的miniSdkVersion<24(N)，那么你的签名方式必须内含V1签名：
校验流程就是签名的逆向，了解签名流程即可，本文不求甚解，有兴趣自己去分析，只是额外提下覆盖安装，覆盖安装除了检验APK自己的完整性以外，还要校验证书是否一致只有证书一致（同一个keystore签名），才有可能覆盖升级。覆盖安装同全新安装相比较多了几个校验
这里只关心证书部分：
Android V1及V2签名签名原理简析
仅供参考，欢迎指正
⑤ 安卓ROM签名有什么用请高手解答下，我把别人的ROM精简了也加了自己喜欢的，但是没签名也照样刷机成功了
签名工具就相当于给ROM发一个身份证（额，这么比喻不知道合不合适~），就是系统会任何你这个是合法的，就可以运行，如果不签名的话，就是黑户~不合法的，系统不认可。我以前改rom的时候都会最后用签名工具处理下，你说的没签名也能刷，这个情况我倒不是很清楚，不过我还是建议刷之前签名下，以免以后系统不稳定或有什么其他问题。