android中用的到加密：
Https编程 :应该是使用带安全的网络协议处理。除非你本地需要加密
2.数据签名：混淆代码和防二次打包的APK加密技术
3.对称加密：可以先将数据通过某种加密方式加密发送到服务器端，然后服务器端再解密 ，项目中除了登陆，支付等接口采用rsa非对称加密，之外的采用aes对称加密
4.非对称加密====支付宝
数字摘要是指通过算法将长数据变为短数据，通常用来标识数据的唯一性，是否被修改，常用的加密算法有md5和sha1两种，如Android的App签名也是用的这两种算法。
由于以上两种生成数字摘要的算法都是不可逆的，对于可逆的加密算法中，按照密钥的数量和加密规则一半分为对称加密和非对称加密两类：
对称加密：
密钥可以自己指定，只有一把密钥，如果密钥泄漏数据就会暴漏；
常用的对称加密算法有DES和AES两种；
特点是加密速度快，但是缺点是安全性低，因为只要密钥暴漏，数据就可以被解密。
非对称加密的特点：
常见的非对称加密算法是RSA；
他有两把密钥，且是由程序生成的，不能自己指定；
特点是加密速度比较慢，但是安全性比较高；
加密和解密的规则是：公钥加密只能私钥解密，私钥加密只能公钥解密；
㈡ 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签名签名原理简析
仅供参考，欢迎指正
㈢ APK签名机制原理详解
众所周知，Android系统在安装Apk的过程中，会对Apk进行签名校验，校验通过后才能安装成功。那你知道签名校验的机制是什么？具体校验的是什么内容吗？申请第三方SDK（如微信支付）时填入的SAH1值是什绝颂高么？目前众多的快速批量打包方案又是如何绕过签名检验的？
我将通过一系列的文章来解开这些疑惑：
这篇文章先来介绍Apk签名相关的基本知识。
要知道签名是什么，先来看为什么需要签名 。大家都知道，在消息通信时，必须至少解决两个问题：一是确保消息来源的真实性，二是确保消息不会被第三方篡改。在安装Apk时，同样需要确保Apk来源的真实性，以及Apk没有被第三方篡改。如何解决这两个问题呢？方法就是开发者对Apk进行签名：在Apk中写入一个“指纹”。指纹写入以后，Apk中有任何修改，都会导致这个指纹无效，Android系统在安装Apk进行签名校验时就会不通过，从而保证了安全性。
要了解如何实现签名，需要了解两个基本概念：数字摘要和数字证书。
简单来说，就是对一个任意长度的数据，通过一个Hash算法计算后，都可以得到一个固定长度的二进制数据，这个数据就称为“摘要”。摘要具有下面的几个特征：
前面已经说到，可以通过签名来确保数据来源的可靠性和数据的不可篡改性。签名就是在摘要的基础上再进行一次加密，对摘要加密后的数据就可以当作数字签名，在安装Apk需要对签名进行验证，验证通过才能继续安装。
这里有两个过程：签名过程 和 校验过程。
先来说 签名过程：
再来看 校验过程：
这里有一个前提：接收方必须要知道发送方的公钥和所使用的算法。如果数字签名和公钥一起被篡改，接收方无法得知，还是会校验通过。如何保证公钥的可靠性呢？答案是数字证书，数字证书是身份认证机构（Certificate Authority）颁发的，包含了以下信息：
接收方收到消息后，先向CA验证证书的合法性（根据证书的签名、绑定的域名等信息。CA机构是权威的，可以保证这个过程的可靠性。）再进行签名校验。
需要注意的是，Apk的证书通常的自签名的，也就是由开发者自己制作，没有向CA机构申请。Android在安装Apk时并没有校验证书本身的合法性，只是从证书中提取公钥和加密算法，这也正是对第三方Apk重新签名后，还能够继续在没有安装这个Apk的系统中继续安装的原因。
我们在对Apk签名时并没有直接指定私钥、公钥和数字证书，而是使用keystore文件，这些信息都包含在了keystore文件中。根据编码不同，keystore文件分为很多种，Android使用的是Java标准keystore格式JKS(Java Key Storage)，所以通过Android Studio导出的keystore文件是以.jks结尾的。
keystore使用的证书标准是X.509，X.509标准也有多种编码格式，常用的有两种：pem（Privacy Enhanced Mail）和der（Distinguished Encoding Rules）。jks使用的是der格式，Android也支持直接使用pem格式的证书进行签名，我们下面会介绍。
两种证书编码格式的区别：
X.509证书格式：
Android提供了两种对Apk的签名方式，一种是基于JAR的签名方式，另一种是基于Apk的签名方式，它们的主要区别在于使用的签名文件不一样：jarsigner使用keystore文件进行签名；apksigner除了并尺支持使用keystore文件进行签名外，还支持直接指定pem证书文件和私钥进行签名。
不知道大家有没有注意一个问题，我们通过樱御keytool或者AS生成一个keystore的时候（ 签署您的应用 ），除了要输入keystore的密码外，还要输入一个alias和key的密码。在签名时，除了要指定keystore文件和密码外，也要指定alias和key的密码，这是为什么呢？
原因是keystore是一个密钥库，也就是说它可以存储多对密钥和证书，keystore的密码是用于保护keystore本身的，一对密钥和证书是通过alias来区分的。从这里可以看出jarsigner是支持使用多个证书对Apk进行签名的。apksigner也同样支持，关于apksigner的使用介绍可以参考官方文档 apksigner 。
ok，签名的基本概念和校验过程就介绍到这里，关于JAR签名和V2签名机制的详细介绍，参考下面两篇文章：
㈣ 一文弄懂关于证书，签名，ssl，android包签名机制。
所有的概念都基于一个非常重要的基础：
rsa 非对称加密算法 ：
先感受下几个概念
PKI。
PKI是公钥基础设施（Public Key Infrastructure) 包括PKI策略、软硬件系统、证书机构CA、注册机构RA、证书发布系统和PKI应用等。
我们关注就俩东西： PKCS 证书机构CA 。前者是定义加密算法，签名，证书相关的各种事情采用的协议。后者可以为我们颁发权威的证书。
PKCS ：
PKCS（The Public-Key Cryptography Standards ）是由美国RSA数据安全公司及其合作伙伴制定的一组公钥密码学标准，其中包括证书申请、证书更新、证书作废表发布、扩展证书内容以及数字签名、数字信封的格式等方面的一系列相关协议。RSA算法可以做加密、解密、签名、验证，还有RSA的密钥对存储。这些都需要标准来规范，如何输入，如何输出，如何存储等。
PKCS。全称是公钥密码学标准， 目前共发布过 15 个标准，这些标准都是协议。总结一下 就是对加密算法，签名，证书协议的描述。下面列举一些常用的协议，这些协议在本文都会对应上。
这些协议具体的实现就体现在openssl等工具中， 以及jdk工具keytool jdk java第三方库bouncycastle。
比如用openssl 如何生成公/私钥(PKCS#1)、签名(PKCS#1 )、签名请求文件（KCS#10）、 带口令的私钥（PKCS#8）。 含私钥的证书（PKCS#12）、证书库（PKCS#12）
其中涉及到算法的基础协议PKCS#1等，由于涉及到密码学原理所以我们并不需要深究它，只要知道怎么做就可以了。
现实中我们要解决这样一种情况:
客户端和服务器之间的数据要进行加密。需要两个达成同一个对称秘钥加密才行，那么这个秘钥如何生成，并在两边都能拿到，并保证传输过程中不被泄露。 这就用到非对称加密了。 后续的传输，就能用这个 对称秘钥来加密和解密了。
还有这样一个问题：
就是客户端如何判断服务端是否是合法的服务端。这就需要服务端有个id来证明它，而这个id 就是证书，而且必须是权威机构颁发的才能算是合法的。
因为客户端即浏览器，认定证书合法的规则必须通过第三方来确认 即ca颁发的证书。否则就我可能进了一个假网站。
而这两个问题 都是ssl协议要解决的内容。
所以ssl协议做了两件事情，一是验证身份，二是协商对称秘钥，并安全的传输。 而实现这个过程的关键数据模型就是证书， 通过证书中的ca对证书的签名，实现了身份验证，通过证书中的公钥，实现对对称秘钥加密，从而实现数据保密。 其实还顺手做了一件事情就是通过解密签名比对hash，保证了数据完整性。
明白ssl协议 首先明白几个重要的概念：
证书： 顾名思义就是提供了一种在Internet上验证通信实体身份的方式，数字证书不是数字身份证，由权威公正的第三方机构，即CA（例如中国各地方的CA公司）中心签发的证书， 就是可以认定是合法身份的。客户端不需要证书。 证书是用来验证服务端的。
一般的证书都是x509格式证书，这是一种标准的证书，可以和其他证书类型互相转换。完整来说证书包含，证书的内容，包括 版本号， 证书序列号， hash算法， 发行者名称，有效期， 公钥算法，公钥，签名（证书原文以及原文hash一起签名）而这个内容以及格式 都是标准化的，即x509格式 是一种标准的格式。
签名: 就用私钥对一段数据进行加密，得到的密文。 这一段数据在证书的应用上就是 对证书原文+原文hash进行签名。
谁签的名，就是用谁的私钥进行加密。就像身份证一样， 合法的身份证我们都依据是政府签的，才不是假证， 那就是浏览器会有政府的公钥，通过校验（解密）签名，如果能够解密，就可以确定这个就是政府的签名。就对了。
hash算法 ：对原始数据进行某种形式的信息提取，被提取出的信息就被称作原始数据的消息摘要。比如，MD5和SHA-1及其大量的变体。 hash算法具有不可逆性，无法从摘要中恢复出任何的原始消息。长度总是固定的。MD5算法摘要的消息有128个比特位，SHA-1算法摘要的消息最终有160比特位的输出。
ca机构： 权威证书颁发机构，浏览器存有ca的公钥，浏览器以此公钥来验证服务端证书的合法性。
证书的获取： 生成证书申请文件.csr（涉及到PKCS#10定义的规范）后向ca机构申请。 或者自己直接通过生成私钥就可以一步到位生成自签名证书。 自签名证书就是用自己的私钥来签名证书。
那么为了体现到 证书身份认证、数据完整、保密性三大特性 ，证书的简化模型可以认为包含以下两个要素：服务器公钥，ca的签名（被ca私钥加密过的证书原文+原文hash），
身份认证：
浏览器存有ca公钥，用ca公钥解密网站发给你的证书中的签名。如果能解密，说明该证书由ca颁发，证书合法。 否则浏览器就会报警告，问你是否信任这个证书，也就是这个网站。这时候的证书可以是任何人签发的，可以自己签发的。 但是中间人攻击。 完全伪造新的证书， 这就没有办法了。 所以还是信任证书的时候要谨慎。
数据完整：
如果你信任该证书的话，这时候就会用证书中的公钥去解密签名，如果是ca签发的证书，那么之前就已经通过ca的公钥去解密签名了。 然后得到证书hash，然后在浏览器重新对证书做hash，两者比对一致的话，说明证书数据没有被篡改。
保密性：
使用证书的公钥对对称秘钥加密保证传输安全，对称秘钥生成后，后续的传输会通过对称秘钥来在服务端和客户端的加解密。
那么ssl协议的具体过程就是：
4.网站接收浏览器发来的数据之后 使用自己的私钥校验签名，并对原文进行hash 与解密出的hash 做比对检查完整性。然后发送编码改变通知，服务器握手结束通知（所有内容做hash ）。 发送给客户端校验。
5 客户端校验，校验成功后，之后就用 对称秘钥进行通信了。
总共的过程是 c-s-c- s-c 四次握手。
四次握手简单来说分别是：
1.请求获取证书
2.服务端返回证书，客户端验证了证书的合法性和完整性，同时生成了对称秘钥。
3.客户端把加密的 对称秘钥发给服务器。服务器检查真实性和完整性。
4.服务端返回握手结束通知，客户端再检查一次真实性和完整性。
前两次握手是明文， 后两次握手是密文。 所以都要检查身份真实性和数据完整性。
ca的作用：
ca起到一个权威中间人的角色，如果脱离了ca， 那么证书还是证书，还能加密，保证数据完整性。 但是无法应用在客户端去认定服务器身份合法这个场景下。
下面就详细说下 脱离了ca签发的证书的应用：
自签名证书：
证书如果没有权威机构的签名，就是没有权威机构给你签发身份证。 那么这时候身份认证的场景变了。
这时候的认证场景就变成了，不再是某个官方权威说了算，而是假设第一次碰到这个证书，会认为，这个证书与之捆绑的实体之间是合法的并做记录。如果当这个实体下次捆绑了另一个证书，那么就是非法的。
这种情况常用于android中安装和校验app的时候，会先假设第一次安装的是合法的应用，认定这个app证书中的公钥是合法的公钥。然后通过自签名的证书，校验签名，就能实现后续安装是否合法以及完整性。
android中的如何对app进行身份认定和不被篡改：
android系统在安装app时候会进行校验applicationId，applicationId 不同会认定为不同应用。相同应用，第二次安装会校验证书是否和之前app的证书相同，如果相同则两个包很可能来自同一个身份。 如果证书不同，也就是该包被另一个身份用自己的私钥重新签名过，就会拒绝安装。 然后通过公钥来解密签名，如果能解密，说明身份是ok的。否则拒绝安装。比对解密签名后的hash 与apk包内的cert.sf文件(该文件是apk内所有文件生成的hash文件)是否一致，如果相同则认定为没有被篡改。
android在提交应用商店的问题：
应用商店也会校验 后续的上传和第一次上传时的证书，以及类似上述的后续的一系列校验。防止合法的开发者平台被盗后，上传非法应用。
android在接入第三方sdk的问题：
接入第三方sdk 会提交applicationId 和 sha1 值。 这个sha1值就是对 证书原文的签名后的sha1，也就是证书指纹。这个证书是证书库里最初的那个证书（x509格式），而不是对apk签名后生成的证书(PKCS#7)。一般的证书签名的主体是证书原文本身，而对apk签名还额外会对apk所有文件生成的hash值文件（cert.sf）进行一次签名。
第三方平台会记录 applicationId 与sha1 的对应关系。 当有假冒app试图接入时候，由于会对app内的PKCS#7证书转换为原始的x509格式证书，重新生成sha1值，与用户提交sha1 比对， 如果相同则说明证书很可能是ok的。 因为sha1就是证书的指纹。 之后就会通过证书中的公钥来校验签名，从而最终确认身份合法性以及信息完整性。
第三方平台之所以需要用户去提交证书指纹sha1值，多了这一步，就意味着你的证书是可以更换的，一旦更换了证书，就必须提交新的指纹给我，然后我来做匹配。而应用商店没有这个功能， 一旦你的证书的私钥丢了， 那就必须重新建一个新的app。
总结来看证书的身份认定机制：
在ssl协议下，这种场景是 浏览器用于认定合法的服务器身份。 在自签名证书下，需要用户选择是否信任该证书。
在android app采用自签名证书的场景下， 证书起到了 假设第一次的证书合法，公钥合法，后续如果证书不一致或不能够完成签名校验，就是非法。
证书库：
证书库应该满足PKCS#12协议。 但是jdk提供了制作证书的工具keytool 可以生成keystore类型的证书库，后缀为jks。 keystore pk12可以通过keytool命令互相转换。
证书库是个证书的容器， 可以用来创建数字证书。 在keystore证书库中，所有的数字证书是以一条一条(采用别名alias区别)的形式存入证书库的。证书库中的证书格式为pk12，即包含私钥。 如果导出证书的话， 可以导出为x509不包含私钥的格式 或者pk12包含私钥的证书。 也可以也可以用-import参数加一个证书或证书链到信任证书。
android中一般都采用读取证书库的方式，通过证书库来创建一个证书，通过alias来区分。 所以在签名的时候，一个alias是一个证书，不同的alias是不同的证书，不要搞错了。
几个关系：
证书和非对称加密算法的关系：
证书代表一个身份的主体，包含了非对称秘钥体系中的公钥，以及用私钥对证书签名。这种组织结构，把非对称加密算法从加密的功能，拓宽到了用于身份认证，信息完整性上。这体现在了证书的作用。 本质还是利用了非对称加密算法的特性。
ssl协议和证书的关系。
因为证书解决了客户端对服务器的身份认证（自签名证书除外），同时也解决了加密，和信息完整性，所以ssl协议基于证书来实现。
㈤ Android中APK签名工具之jarsigner和apksigner详解
转自 https://www.cnblogs.com/slysky/p/9780015.html
一.工具介绍
jarsigner是JDK提供的针对jar包签名的通用工具,
位于JDK/bin/jarsigner.exe
apksigner是Google官方提供的针对Android apk签名及验证的专用工具,
位于Android SDK/build-tools/SDK版本/apksigner.bat
不管是apk包,还是jar包,本质都是zip格式的压缩包,所以它们的签名过程都差不多(仅限V1签名),
以上两个工具都可以对Android apk包进行签名.
1.V1和V2签名的区别
在Android Studio中点击菜单 Build->Generate signed apk... 打包签名有两种签名选项 V1(Jar Signature) V2(Full APK Signature),
从Android 7.0开始, 谷歌增加新签名方案 V2 Scheme (APK Signature);
但Android 7.0以下版本, 只能用旧签名方案 V1 scheme (JAR signing)
V1签名:
V2签名:
V2签名优点很明显:
注意: apksigner工具默认同时使用V1和V2签名,以兼容Android 7.0以下版本
2.zipalign和V2签名
位于Android SDK/build-tools/SDK版本/zipalign.exe
zipalign 是对zip包对齐的工具,使APK包内未压缩的数据有序排列对齐,从而减少APP运行时内存消耗
zipalign -v 4 in.apk out.apk //4字节对齐优化
zipalign -c -v 4 in.apk //检查APK是否对齐
zipalign可以在V1签名后执行
但zipalign不能在V2签名后执行,只能在V2签名之前执行！！！
二.签名步骤
1.生成密钥对(已有密钥库,可忽略)
Android Studio在Debug时,对App签名都会使用一个默认的密钥库:
1.生成密钥对
进入JDK/bin, 输入命令
参数:
提示: 可重复使用此条命令,在同一密钥库中创建多条密钥对
例如: 在debug.keystore中新增一对密钥,别名是release
keytool -genkeypair -keystore debug.keystore -alias release -validity 30000
2.查看密钥库
进入JDK/bin, 输入命令
keytool -list -v -keystore 密钥库名
参数:
例如:
keytool -list -v -keystore debug.keystore
现在debug.keystore密钥库中有两对密钥, 别名分别是androiddebugkey release
2.签名
1.方法一(jarsigner,只支持V1签名)
进入JDK/bin, 输入命令
从JDK7开始, jarsigner默认算法是SHA256, 但Android 4.2以下不支持该算法,
所以需要修改算法, 添加参数 -digestalg SHA1 -sigalg SHA1withRSA
参数:
例如:
用JDK7及以上jarsigner签名,不支持Android 4.2 以下
jarsigner -keystore debug.keystore MyApp.apk androiddebugkey
用JDK7及以上jarsigner签名,兼容Android 4.2 以下
jarsigner -keystore debug.keystore -digestalg SHA1 -sigalg SHA1withRSA MyApp.apk androiddebugkey
2.方法二(apksigner,默认同时使用V1和V2签名)
进入Android SDK/build-tools/SDK版本, 输入命令
若密钥库中有多个密钥对,则必须指定密钥别名
禁用V2签名
apksigner sign --v2-signing-enabled false --ks 密钥库名 xxx.apk
参数:
例如:
在debug.keystore密钥库只有一个密钥对
apksigner sign --ks debug.keystore MyApp.apk
在debug.keystore密钥库中有多个密钥对,所以必须指定密钥别名
apksigner sign --ks debug.keystore --ks-key-alias androiddebugkey MyApp.apk
3.签名验证
1.方法一(keytool,只支持V1签名校验)
进入JDK/bin, 输入命令
keytool -printcert -jarfile MyApp.apk (显示签名证书信息)
参数:
2.方法二(apksigner,支持V1和V2签名校验)
进入Android SDK/build-tools/SDK版本, 输入命令
apksigner verify -v --print-certs xxx.apk
参数:
例如:
apksigner verify -v MyApp.apk
㈥ Android | 他山之石，可以攻玉！一篇文章看懂 v1/v2/v3 签名机制
这篇文章的内容会涉及以下前置 / 相关知识，贴心的我都帮你准备好了，请享用~
数字签名（Digital Signature）也叫作数字指纹（Digital Fingerprint），它是消息摘要算法和非对称加密算法的结合体，能够验证数据的完整性，并且认证数据的来源 。
数据签名算法的模型分为两个主要阶段：
需要注意的是，Android 目前不对应用证书进行 CA 认证，应用可以由第三方（OEM、运营商、其他应用市场）签名，也可以自行签名。
应用 APK 其实是一种特殊的 Zip 压缩包，无法避免恶意破解者解压 / 反编译修改内容，针对这个问题有何解决方案呢？他山之石，可以攻玉 ——数字签名算法。应用签名正是数字签名算法的应用场景之一，与其他应用场景类似，目的无非是：
Android 平台上运行的每个应用都必须有开发者的签名。在慧唤安装应用时，软件包管理器会验证 APK 是否已经过适当签名，安装程序会拒绝没有获得签名就尝试安装的应用。
软件包管理器在安装应用前会验证应用摘要，如果破解者修改了 apk 里的内容，那么摘要就不再匹配，验证失败（验证流程见下文方案）。
截止至 Android 11，Android 支持以下三种应用签名方案：
为了提高兼容性，必须按照 v1、v2、v3 的先后顺序采用签名方案，低版本平台会忽略高版本的签名方案在 APK 中添加的额外数据。
v1 签名方案是基于 Jar 的签名。
首先，我们先来分析其签名产物。 v1 签名后会增加 META-INF 文件夹 ，其中会有如下三个文件。考虑到使用不同的证书和签名方式，得到的文件名可能不同，因此你只要留意文件的后缀即可：
v1 签名流程如下：
MANIFEST.MF（Message Digest File，摘要文件）
*.SF（Signature File，签名文件）
验证流程可以分为验证签名和验证完整性两个步骤：
验证签名步骤：
如果上述签名验证结果正确，才会验证完整性：
以上任何步骤验证失败，则整个 APK 验证失败。
为了解决这些问题，Android 7.0 中引入了 APK 签名方案 v2。
v2 签名方案是一种 全文件签名方案 ，该方案能够发现对 APK 的受保护部分进行的所有更改，相对于 v1 签名方案验证速度更快，完整性覆盖范围更广。
在分析 v2 签名方案之前，我们先简单了解一下 Zip 文件格式：
首先，我们先来分析其签名产物。v2 签名后会在 “条目内容区”和“中央目录区”之间插入“APK 签名分块（APK Signing Block）” 。
从左到右边，我们定义为区块 1~4。
相对与 v1 签名方案，v2 签名方案不再以文件为单位计算摘要了，而敬坦是以 1 MB 为单位将文件拆分为多个连续的块（chunk），每个分区的最后一个块可能会小于 1 MB。
v2 签亮碧桐名流程如下：
验证流程可以分为验证签名和验证完整性两个步骤：
签名方案 v3 支持密钥轮换，应用能够在 APK 更新过程中更改其签名密钥。
【累了，后面先不写了...】
这一节，我们介绍基于 Android 应用签名机制的衍生应用场景。
在 v1 方案中， MANIFEST.MF 和 *.SF 这两个文件会记录大量的文件名和文件摘要。如果 apk 中文件数很多，而且文件名很长，那么这两个文件会变得很大。使用 AndResGuard 工具，可以将文件名转换为短路径文件名，从而减少这两个文件的大小。
在实际生产中，往往需要生成多个渠道的 APK 包，传统的方法是使用 APKTool 逆向工具、Flavor + BuildType 等方案，这一类多渠道打包方案的缺点是耗时严重。随着 Android 应用签名方案的演进，演变出了不同的多渠道打包方案：
在 v1 方案中，我们提到了完整性校验不覆盖到 META-INF 文件夹的问题。有些多渠道打包方案就是利用了这个问题，在 META-INF 文件夹下添加空文件， 用空文件的名称来作为渠道的唯一标识 ，就可以节省打包的时间，提高打渠道包的速度。
除了添加空文件的方法，还可以向 APK 添加 Zip Comment 来生成多渠道包（APK 本身就是特殊的 Zip 包）。
在 v2 签名方案中，几乎整个 APK 都纳入保护范围，如果向 APK 添加空文件或 Zip Comment 的话，在安装时会报以下错误：
新背景下的多渠道打包方案，则是利用了 APK 签名分块（区块 2）不受保护 & 字段可扩展的特点 ，向区块中添加多渠道信息（ID-Value），例如 美团多渠道打包方案 Walle 。