为什么需要手动通过命令去签名：
这里做个笔记，今天刚好遇到，使用360加固保加固apk之后需要重新签名，由于项目比较老，使用的签名文件不是jks的格式，360加固保无法在正常情况下对其进行加固后再次签名，这时，就需要我们自己手动签名。
签名的机制有v1,v2,v3：
v1:基于 JAR 签名。
v2:基于Android 7.0 引入。
v3:基于Android 9.0引入。
v1到v2的签名机制是为了解决jar签名机制存在一定的安全性问题，v3的机制，会记录我们之前的签名信息以及新的签名信息，以密钥转轮的方案，来做签名的替换和升级。
大概了解了相应的问题和需求之后，我们开始实践，如何进行命令打包。
V1签名：
jarsigner -verbose -keystore (签名地址) -signedjar (签名后的apk地址) (待签名apk地址) (别名)
注释：签名后的apk地址
例如：user/apkFinder/v1.apk,其中这个v1.apk不要掉了，这个名字你自己随便取，就是不能掉了。不然会创建不成功。
就这么一句命令，然后会弹出一句输入密码：
输入密码就开始签名，然后等待一会
那就表示已经签名成功。
V2，V3签名（执行以下命令V2和V3是同时签名的）
1）找到你的Android SDK的路径。切换到对应的路径下执行命令：
例如我的/Users/zyh/Library/Android/sdk/build-tools/29.0.0/lib
使用命令进入到cd /Users/zyh/Library/Android/sdk/build-tools/29.0.0/lib目录下
（使用29是因为安卓9.0之后才有V3，后面我就直接叫版本号）
切换到对应的目录下之后要执行Zip对齐
2）执行ZipAlign（zipAlign.exe在你的/Users/zyh/Library/Android/sdk/build-tools/版本号/zipAlign.exe）
zip对齐，因为APK包的本质是一个zip压缩文档，经过边界对齐方式优化能使包内未压缩的数据有序的排列，从而减少应用程序运行时的内存消耗 ，通过空间换时间的方式提高执行效率（zipalign后的apk包体积增大了100KB左右）。
执行命令：/Users/zyh/Library/Android/sdk/build-tools/版本号/zipAlign.exe -v -p 4 input.apk(刚刚进行v1签名的那个apk) output.apk（重新创建的一个新的输出路径，会生成一个新的apk，）
注释：这里output.apk一定要加上，不能只写一个文件夹。
执行好之后会出现这个情况
3）最后给apk进行v2签名
执行命令：java -jar apksigner.jar sign --ks (你自己的签名文件） --out （输出APK的路径） （传入刚刚对齐的apk文件）
注释：还是在lib目录下执行。输出APK的路径一定要写apk文件，不要是一个空文件夹，例如：应该是use/apk/output.apk不能是use/apk
如果执行成功会要求你输入密码，输入密码运行完成之后，看不到执行的命令，命令直接回到了根目录。
打开输出apk的文件夹，会发现已经有一个已经签好名的apk了。这里要注意执行命令的空格什么的，很容易出错。
检测APK是否完成签名
输入命令（还是在lib目录下）：java -jar apksigner.jar verify -v my.apk
注释：其中my.apk是你刚签名好的apk
查看是否成功，成功的状态是：
这里可以看到V1 V2 V3都是为true。如果使用Android studio打包签名的时候勾选V1 V2，这个命令去验证，V3就不是true。
