本文目录
- Android 创建自己的pk8, x509.pem并给app签名
- Android怎么签名和加密
- 如何用Android 源码生成APK签名文件
- android 生成签名证书
- Android签名机制之签名文件和数字证书的作用
- Android如何生成签名文件
- Android Studio 之签名
- Android基础『V1V2V3签名』
- 如何发布android应用程序,app增加签名证书(安卓签名证书)
- 如何对Android的APP进行签名(手机什么app可以签名文件)
Android 创建自己的pk8, x509.pem并给app签名
***隐藏网址*** 1, 生成key 这个命令会生成带组织/个人信息的key，并存放在app.keystore文件中 2, 转换key的格式 3, 将PKCS12格式的key dump为可直接阅读的文本 dump过程中也会提示输入密码，正确输入之后可阅读的token会存储在tmp.rsa.pem中 4, 提取 这一段（包含这两个tag）的文本复制出来，新建为文件my.x509.pem （签名时用到的公钥） 5, 转换，生成pk8格式的私钥 这个生成的my_private.pk8就是签名时用到的私钥 6, 对apk签名
Android怎么签名和加密
前言：
当我们编写完我们的app之后，我们还需要做两件事：签名和加密
签名：
1》为什么要签名？
主要是为了确保应用的安全，为什么这么说呢？那么，我们首先假设android没有签名这个概念，
在这个前提下，下面来举个实例说明签名的重要性，比如，我写了一个myApp，然后装在了我的手机上，
与此同时，我又装了一个yourApp，在装yourApp的时候，突然发现myApp被覆盖了，为什么？因为yourApp
的包名和myApp的包名相同，那么，这样对于开发人员写的app的安全性是没有保障的，也就是说，随便一个
包名相同的app就可以将另一个app覆盖掉了，而我们知道获取一个应用的包名是很容易的事，所以此时签名的
概念也就随之而来了，主要是为了保证app的安全性，因为签名只有开发人员才知道，就算其他人知道这个应用
的包名，但是不知道这个应用的签名，依旧是没法覆盖的，所以这就是android中的签名的作用，与此同时，
在这里也需要提醒一下我们的开发人员，一旦app上市，那么这个app的签名一定要保存好，不然再次升级时，
是没办法做到覆盖的，最好是将签名再复制一份给上司；
2》如何签名？
在androidstudio中，选择Build-----》GenerateSignedAPK...
填写完相应的选项(注：若没有keystore,可自行新建一个)-----》Next-----》
在这个对话框中，BuildType选择Finish即可完成签名；
注：（签名apk生成目录）
我们签名之后的apk文件，可以在上边这幅图中可以看到，不要找错签名的应用了，
在本示例中，其目录就是：C:UsersDAIDesktop
加密：
1》为什么要进行加密？
简而言之，就是为了让我们的apk不被其他人所破解；
2》如何加密？
参考了一下网上的做法，就是：通过“爱加密”来达到对我们所写APK的一种加密
注：在爱加密上加密了我们的APK之后，其官网也有明确注释，就是还需要再进行签名一次，否则，APK无法运行，
其签名工具，在“爱加密”官网上已给出；
这样当我们在对我们的已经加密的APK破解时，可以发现，其已无法直接获取得到源码了！！！
阅读全文
如何用Android 源码生成APK签名文件
我们很多应用需要用到系统签名，可以通过生成系统签名文件，在生成apk时使用这个签名，然后可以安装到机器中，不需要放在源码里编译，重新刷系统。
先附上 50和 20机器人通用的debugkey(图已经省略)
在Linux环境中，以Android源码目录为根目录。
其中的platform.pk8是制作系统签名需要的文件。
1、在这个目录下，执行
生成临时文件platform.pem
2、接着执行以下命令，将在目录下生成platform.p12文件，它本质上应该就是一个数字证书
3、然后再执行以下命令出现以下信息，表示成功生成platform.jks
这个名字可以改成debug.keystore. 它的后缀本身是没有关系，eclipse和AS都识别 platform.jks
4、然后在打包 apk 的时候选择platform.jks文件，就可以直接用adb命令安装apk到机器中了。
xxxx表示需要安装的apk路径 5、签名的 Key store password和Key password都是android
android 生成签名证书
使用keytool -genkey命令生成证书：
回车后会提示：
以上命令运行完成后就会生成证书，路径为“D:\test.keystore”。
注意：上述信息填写要规范，乱填有可能会影响应用上架应用市场。
可以使用以下命令查看：
会输出以下格式信息：
其中证书指纹信息（Certificate fingerprints）：
MD5 证书的MD5指纹信息（安全码MD5） SHA1 证书的SHA1指纹信息（安全码SHA1） SHA256 证书的SHA256指纹信息（安全码SHA245）
***隐藏网址*** 注意事项 云端打包默认会添加V1/V2签名，已知V1签名不支持2048位的DSA算法，使用2048-bit DSA key云端打包可能失败，提示以下错误：
解决方法
查看证书算法的方法 使用“keytool -list -v”查看证书信息，看“Subject Public Key Algorithm: ”项的信息，如下表示使用DSA算法：
***隐藏网址***
Android签名机制之签名文件和数字证书的作用
Android签名机制目的是确保app的可靠通信，其一，要确定消息的来源确实是其申明 的那个人；其二，要保证信息在传递的过程中不被第三方篡改，即使被篡改了，也可以 发觉出来。 所谓数字签名，就是为了解决这两个问题而产生的，它是对非对称加密技术与数字摘要 技术的一个具体的应用。 对于消息的发送者来说，先要生成一对公私钥对，将公钥给消息的接收者。 如果消息的发送者有一天想给消息接收者发消息，在发送的信息中，除了要包含原始的 消息外，还要加上另外一段消息。这段消息通过如下两步生成： 1）对要发送的原始消息提取消息摘要； 2）对提取的信息摘要用自己的私钥加密。 通过这两步得出的消息，就是所谓的原始信息的数字签名。 而对于信息的接收者来说，他所收到的信息，将包含两个部分，一是原始的消息内容， 二是附加的那段数字签名。他将通过以下三步来验证消息的真伪： 1）对原始消息部分提取消息摘要，注意这里使用的消息摘要算法要和发送方使用的一致； 2）对附加上的那段数字签名，使用预先得到的公钥解密； 3）比较前两步所得到的两段消息是否一致。如果一致，则表明消息确实是期望的发送者 发的，且内容没有被篡改过；相反，如果不一致，则表明传送的过程中一定出了问题， 消息不可信。 通过这种所谓的数字签名技术，确实可以有效解决可靠通信的问题。如果原始消息在传 送的过程中被篡改了，那么在消息接收者那里，对被篡改的消息提取的摘要肯定和原始 的不一样。并且，由于篡改者没有消息发送方的私钥，即使他可以重新算出被篡改消息 的摘要，也不能伪造出数字签名。 那么数字签名呢？ 综上所述，数字签名其实就是只有信息的发送者才能产生的别人无法伪造的一段数字 串，这段数字串同时也是对信息的发送者发送信息真实性的一个有效证明。 不知道大家有没有注意，前面讲的这种数字签名方法，有一个前提，就是消息的接收者 必须要事先得到正确的公钥。如果一开始公钥就被别人篡改了，那坏人就会被你当成好 人，而真正的消息发送者给你发的消息会被你视作无效的。而且，很多时候根本就不具 备事先沟通公钥的信息通道。那么如何保证公钥的安全可信呢？这就要靠数字证书来解 决了。 所谓数字证书，一般包含以下一些内容： 证书的发布机构（Issuer） 证书的有效期（Validity） 消息发送方的公钥 证书所有者（Subject） 数字签名所使用的算法 数字签名 可以看出，数字证书其实也用到了数字签名技术。只不过要签名的内容是消息发送方的 公钥，以及一些其它信息。但与普通数字签名不同的是，数字证书中签名者不是随随便 便一个普通的机构，而是要有一定公信力的机构。这就好像你的大学毕业证书上签名的 一般都是德高望重的校长一样。一般来说，这些有公信力机构的根证书已经在设备出厂 前预先安装到了你的设备上了。所以，数字证书可以保证数字证书里的公钥确实是这个 证书的所有者的，或者证书可以用来确认对方的身份。数字证书主要是用来解决公钥的 安全发放问题。 综上所述，总结一下，数字签名和签名验证的大体流程如下图所示： ***隐藏网址***
Android如何生成签名文件
一、首先工具栏中 Build 》 GenerateSignedBundle/APK... 二、选择Apk 》 Next 三、选择 生成的 Module 点Create new , 文件设置文件生成路径 和 访问文件密码，设置文件名和签名密码 保存的年份 默认25年 ，设置国家城市信息。 四、路径的 名字 和 密码 一定要保存好！ 选择 记住密码 Remember passwords 五、选择release 选中 v1 v2 Finish！ 六、最后在Project 目录下 release 文件夹下 可以看到你的 apk 签名文件
Android Studio 之签名
通过签名可以确保数据来源的可靠性和数据的不可篡改性
对 Apk 进行签名，也就是在 Apk 中写入一个指纹，写入指纹后，Apk 中有任何修改，都会导致这个指纹无效，Android 系统在安装 Apk 进行签名校验时就会不通过，进而无法安装该 Apk
如上图：
通常的签名验签过程中，接收方收到消息后，会先向 CA 机构验证证书的合法性，再进行签名校验。但 Apk 的证书通常由开发者自己制作，没有向 CA 机构申请，Android 系统在安装 Apk 时也并没有校验证书本身的合法性，只是从证书中提取公钥和加密算法，因此，如果对第三方 Apk 重新签名，也能安装到没有安装过这个 Apk 的系统中
keystore 文件包含私钥、公钥和数字证书，分为很多种，Android 使用的是 Java 标准 keystore 格式 JKS(Java Key Storage)
Android App Bundle：用于通过 Google Play 发布的应用，需要升级到AS 3.2 以上版本才支持App Bundle 格式； APK：用于创建可部署到设备上的签名 APK
点击 Finish 就会生成签名文件与签名后的 Apk
当我们需要升级 Apk 版本的时候，需要再次对 Apk 文件进行签名，可以通过配置 build.gradle 让其自动生成签名后的 Apk
如果你的项目是开源的，需要把你的签名信息写在 local.properties 中，然后在 .gitignore 配置文件中加入 local.properties ，这样 local.properties 就不会提交到开源项目中，签名信息也就不会被人获取
local.properties：
app/build.gradle:
有时候我们的 apk 中某些功能需要系统签名，例如静默安装。测试系统签名的 apk，需要 root 权限，而带 Google APIs 的模拟器不能 root，因此要注意不能选择带 Google APIs 的模拟器
下面执行的操作都是在 Linux 中，如果 apk 是 window 中生成的，需要拷贝到 linux 操作，再将生成的系统签名过得 apk 再拷贝到 window，比较麻烦，可以考虑后面的自动系统签名，还是需要在 linux 操作一次，不过之后就可以只在 window 操作了
这两个文件在目录 aosp/build/target/product/security 下，如下图
在目录 aosp/prebuilts/sdk/tools/lib 下，如下图
将前面获取的 platform.pk8 、 platform.x509.pem 和 signapk.jar 文件放到需要签名的 apk 同一个目录，执行以下命令
如果出现上面的错误：Failed to load any of the given libraries:
解决方法：
到目录 aosp/prebuilts/sdk/tools/linux/lib64 下，复制 libconscrypt_openjdk_jni.so 文件到需要签名 apk 的同一个目录，并将命令改为
自动进行系统签名的原理是：先生成一个 system.jks 文件，使用 keytool-importkeypair 对 system.jks 文件进行系统签名，再 build.gradle 和 local.properties 进行配置，直接使用带有系统签名的 system.jks 对 apk 进行签名，这样编译生成的apk文件就自带系统签名了
按照前面的方法，生成一个 system.jks 文件，此时是在 window 系统中操作的
进入 keytool-importkeypair 目录，将 system.jks、platform.pk8、platform.x509.pem 文件拷贝进来，拷贝之后的目录结构为
使用 linux 中修改过的带有系统签名的 system.jks 文件将 window 中最开始生成的 system.jks 覆盖掉，再像前面的自动签名部分一样，修改 build.gradle 和 local.properties 的配置，之后生成的 apk 就是系统签名过的了
测试方法是，在 AndroidManifest.xml 中添加 android:sharedUserId="android.uid.system" 后安装到 非 Google APIs 的模拟器上 ， Google APIs 的模拟器不能 root，无法安装
会发现只有使用 system.jks 文件签名后才能安装，否则安装失败，会报以下的错误：
Android基础『V1V2V3签名』
基础概念 签名：在 APK 中写入一个「指纹」。指纹写入以后，APK 中有任何修改，都会导致这个指纹无效，Android 系统在安装 APK 进行签名校验时就会不通过，从而保证了安全性。 摘要算法： 使用一段简单的看上去随机的不可逆向的固定长度的字符串来表示一个文件的唯一性。 常见的摘要算法如MD5(128个比特位)、SHA-1算法(160/192/256个比特位)。 公钥密码体制：也称非对称算法，特点是 公钥是公开的 ，私钥是保密的。常见的如：RSA。 展开讨论一下RSA：
Android中的签名方案 V1 ：基于jarsigner(JDK自带工具，使用keystore文件进行签名) 或 apksigner(Android专门提供的，使用pk8、x509.pem进行签名)。keystore和pk8/x509.pem可以相互转换。 签名原理：首先keystore文件包含一个MD5和一个SHA1摘要。 这也是很多开放平台需要我们上传的摘要数据 。 签名APK后会在META-INF文件夹下生产CERT.RSA、CERT.SF、MANIFEST.MF三个文件。
在apk中，/META-INF文件夹中保存着apk的签名信息，一般至少包含三个文件，.SF和MANIFEIST.MF文件。这三个文件就是对apk的签名信息。 MANIFEST.MF中包含对apk中除了/META-INF文件夹外所有文件的签名值，签名方法是先SHA1()(或其他hash方法)在base64()。存储形式是：Name加-Digest。 .SF是对MANIFEST.MF文件整体签名以及其中各个条目的签名。一般地，如果是使用工具签名，还多包括一项。就是对MANIFEST.MF头部信息的签名，关于这一点前面源码分析中已经提到。 .SF的签名以及包含公钥信息的数字证书。 是否存在签名伪造可能： 修改(含增删改)了apk中的文件，则：校验时计算出的文件的摘要值与MANIFEST.MF文件中的条目不匹配，失败。 修改apk中的文件+MANIFEST.MF,则：MANIFEST.MF修改过的条目的摘要与.SF对应的条目不匹配，失败。 修改apk中的文件+MANIFEST.MF+.RSA中记录的签名值不匹配，失败。 修改apk中的文件+MANIFEST.MF+.RSA无法伪造。
V2 ：7.0新增的 签名后的包会被分为四部分 1. Contents of ZIP entries（from offset 0 until the start of APK Signing Block） 2. APK Signing Block 3. ZIP Central Directory 4. ZIP End of Central Directory 新应用签名方案的签名信息会被保存在区块2（APK Signing Block） 中， 而区块1（ Contents of ZIP entries ）、区块3（ ZIP Central Directory ）、区块4（ ZIP End of Central Directory ）是受保护的， 在签名后任何对区块1、3、4的修改都逃不过新的应用签名方案的检查 。
V3 ：9.0新增的 格式大体和 v2 类似，在 v2 插入的签名块（Apk Signature Block v2）中，又添加了一个新快（Attr块） 。 在这个新块中，会记录我们之前的签名信息以及新的签名信息，以 密钥转轮的方案，来做签名的替换和升级。这意味着，只要旧签名证书在手，我们就可以通过它在新的 APK 文件中，更改签名 。 v3 签名新增的新块（attr）存储了所有的签名信息，由更小的 Level 块，以 链表 的形式存储。 其中每个节点都包含用于为之前版本的应用签名的签名证书，最旧的签名证书对应根节点，系统会让每个节点中的证书为列表中下一个证书签名，从而为每个新密钥提供证据来证明它应该像旧密钥一样可信。 这个过程有点类似 CA 证书的证明过程，已安装的 App 的旧签名，确保覆盖安装的 APK 的新签名正确，将信任传递下去。 注意： 签名方式只支持升级不支持降级，如安装了V2的包，不能覆盖替换为V1的包。
参考 Android App签名(证书)校验过程源码分析 新一代开源Android渠道包生成工具Walle Android 签名机制 v1、v2、v3
如何发布android应用程序,app增加签名证书(安卓签名证书)
Android系统要求，所有的程序经过数字签名后才能安装。Android系统使用这个证书来识别应用程序的作者，并且建立程序间的信任关系。证书不是用于用户控制哪些程序可以安装。证书不需要授权中心来签名：Android应用程序上使用自己签名的证书是完全允许且普遍的。
理解Android应用程序签名有以下几个重要点：
·所有的应用程序都必须签名。系统不会安装任何一个不签名的程序。
·你可以使用自己的证书来签名。不需要任何授权中心。
·当你要为最终用户发布你的应用程序的时候，你必须签入一个合适的密钥。你不可以发布程序的时候还使用SDK工具签入的DebugKey。
·系统只在安装应用程序的时候检测证书的有效期。如果应用程序在安装之后证书失效了，那么，应用程序还是可以正常工作。
·你可以使用标准工具——Keytool和Jarsigner——生成Key并签名apk文件。
·一旦你为应用程序签名了，一定要使用zipalign工具来优化最终的APK包。
Android系统不会安装和运行没有正确签名的应用程序。这条规则适用于任何运行Android系统的地方，不管是真机还是模拟器。正是由于这个原因，你必须在模拟器或真机上运行/调试程序之前对程序进行签名。
当你调试应用程序时，AndroidSDK工具替你对应用程序进行了签名。Eclipse的ADT插件和Ant编译工具都提供了两种签名模式——Debug模式和Release模式。
·当开发和测试时，你可以使用Debug模式。在Debug模式下，编译工具使用内嵌在JDK中的Keytool工具来创建一个keystore和一个key(包含公认的名字和密码)。在每次编译的时候，使用这个DebugKey来为apk文件签名。由于密码是公认的，在每次编译的时候，也不需要提示你输入keystore和key密码。
·当你的程序准备发布时，你必须在Release模式下，使用密钥来为apk文件签名。有以下两种方式可以做到：
1.命令行中使用Keytool和Jarsigner。在这个方法中，首先需要编译出一个未签名的apk。然后使用Jarsigner(或相似的工具)，用你的密钥为apk手动签名。如果你没有合适的密钥，你可以运行Keytool来手动生成自己的keystore/key。
2.使用ADT导出向导。如果你使用Eclipse/ADT插件进行开发，你可以使用导出向导来编译程序，生成密钥(如果需要)，并为apk签名，所有这些操作都在导出向导中。一旦你的程序签名了，别忘了运行zipalign来为apk进行额外的优化。
签名策略
应用程序签名的某些方面可能会影响应用程序的开发，特别是你打算一起发布多个应用程序的时候。一般来说，推荐的策略是在整个应用程序寿命内，所有的程序签上相同的证书。
以下有几个应该这么做的原因：
·应用程序升级——当你对应用程序进行升级时，如果你想用户平稳的升级，那么，你就需要签上相同的证书。当系统安装一个升级应用程序时，如果新版本的证书与老版本的证书有匹配的话，那么，系统才会允许进行升级。如果你没有为版本签上合适的证书，当你安装时，你需要给应用程序指定一个新的包名——在这种情况下，用户安装的新版本，被当作是一个全新的应用程序。
·应用程序模块化——如果应用程序请求的话，Android系统允许签有相同证书的应用程序运行在相同的进程里，这样，系统就会把它们看作是一个单一的应用程序。用这种方法配置应用程序，用户可以选择更新每个独立的模块。
·代码/数据权限共享——Android系统提供了基于签名的权限检查，因此，如果应用程序间签有特定的证书，那么，它们之间可以共享功能。通过多个程序签有相同的证书并且使用基于签名的权限检查，你的程序可以以一种安全的方式共享代码和数据。还有一个决定签名策略的重要因素是：如何设定key的有效期。
·如果你计划支持单个应用程序的升级，你需要确保你的key拥有一个超过期望的应用程序生命周期的有效期。推荐使用25年或更多的有效期。当你的key过期了，用户也就不能平稳的更新到新版本了。
·如果你想给多个无关的应用程序签上相同的key，那么，你必须确保key的有效期超过所有应用程序所有版本的生命周期，包括将来有可能添加到这一阵营的程序。
·如果你想在上发布你的程序，key的有效期必须在2033.10.22以后。Market服务器强制这一要求，目前是保证用户可以平稳的更新他们的程序。
当你设计应用程序时，一定要把这些点记在脑子里，并且使用一个合适的证书来为应用程序签名。
签名的基本设定
在你开始之前，你必须保证Keytool对SDK编译工具来说是可利用的。多数情况下，你可以通过设置JAVA_HOME环境变量来告诉SDK编译工具如何找到Keytool。另外，你还可以添加JDK中Keytool的路径到PATH的变量里。
如果你在Linux上开发，并且使用GNU编译器来编译Java，那么，请确保系统是使用JDK中的Keytool，而不是gcj。如果Keytool已经在你的PATH中，它有可能是对/usr/bin/keytool的符号链接。在这种情况下，检查符号链接的目标，确保它是指向JDK中的Keytool。如果你打算对公众释放你的应用程序，你还需要Jarsigner工具。Jarsigner和Keytool都包含在JDK中。
Debug模式下签名
Android编译工具提供了Debug签名模式，使得开发和调试应用程序更加容易，而且还满足Android系统的签名要求。当使用Debug模式编译你的app时，SDK工具会调用Keytool工具自动创建一个Debug的keystore和key。然后，这个Debugkey会自动用于apk的签名，这样，你不需要使用你自己的key来为应用程序包签名。
SDK工具使用预先定义好的名字/密码来创建/key：
·Keystore名字：“debug.keysotre”
·Keystore密码：“android”
·Key别名：“”
·Key密码：“android”
·CN：“CN=,O=Android,C=US”
如果需要的话，你可以改变/key的位置和名字，或者提供一个自定义的/key。然而，任何自定义的/key必须使用和默认Debugkey(上面描述的)相同的名字和密码。(在Eclipse/ADT中，操作Windows》Preferences》Android》Build实现。)
注意：你不能将签有Debug证书的应用程序发布给公众。
Eclipse用户
如果你在Eclipse/ADT下开发(并且已经按照上面描述的“签名的基本设定”配置了Keytool)，Debug模式下签名默认是开启的。当你运行或是调试应用程序时，ADT会使用Debug证书进行签名，并运行zipalign，然后安装到选择的模拟器或是连接上的设备。整个过程不需要你参与，前提是ADT能访问Keytool。
Ant用户
如果你使用Ant来编译你的apk文件，需要在ant命令中添加debug选项来开启Debug签名模式(假设你正在使用由android工具生成build.xml文件)。当你运行antdebug来编译你的程序时，编译脚本会生成一个keystore/key，并为apk进行签名。然后脚本会使用zipalign工具对apk进行对齐处理。整个过程不需要你参与。阅读“其它IDE下开发：Debug模式编译”来了解更多的信息。
Debug证书过期
Debug模式下签名用的证书(默认是Eclipse/ADT和Ant编译)自从它创建之日起，1年后就会失效。
当证书失效时，你会得到一个编译错误，在Ant编译上，错误如下：
debug:
/samples-debug.apk,...
/4/083:43PM
在Eclipse/ADT中，Android控制台上你将会看到一个相似的错误。
为了解决这个问题，只需要删掉debug.keystore文件即可。AVD默认存储的位置在：~/.android/avd(OSX和Linux)，C:\.android(WindowsXP)，C:Users\.android()。
当下一次编译的时候，编译工具会重新生成一个新的keystore和Debugkey。
Release模式下签名
当你的程序准备好释放给其它用户时，你必须：
1.获取一个合适的密钥
2.在Release模式下编译程序
3.使用密钥签名程序
4.对齐APK包
如果你是使用Eclipse/ADT插件开发，你可以使用导出向导来完成编译、签名和对齐等操作。在整个过程中，导出向导甚至还可以生成一个新的keystore和密钥。因此，如果你使用Eclipse，你可以直接跳到“使用EclipseADT编译和签名”。
获取一个合适的密钥为了进行程序的签名，首先，你必须有一个合适的密钥。密钥指：
·个人持有。
·代表个人、公司或组织实体的身份。
·拥有一个有效期。有效期推荐超过25年。
如果你在上发布你的程序，需要注意一点的是：程序的有效期需要在2033.10.22之后。你不能上传一个应用程序，而它的key的有效期是在这个日期之前。
·不是由AndroidSDK工具生成的Debugkey。
如果你没有一个合适的key，你一定要使用Keytool来生成一个。如“基本设定”中描述的，确保Keytool可用。
为了用Keytool生成一个key，使用keytool命令并传入一些可选参数，如下表所示。
警告:确保密钥的安全。一定要阅读“安全储存你的密钥”中讨论如何确保你的密钥的安全以及这对你和用户为何如此重要。尤其是，当你生成你的密钥时，一定要为keystore和key使用强密码。
如何对Android的APP进行签名(手机什么app可以签名文件)
app签名意义：为了保证每个应用程序开发商合法ID，防止部分开放商可能通过使用相同的PackageName来混淆替换已经安装的程序，需要对发布的APK文件进行唯一签名，保证每次发布的版本的一致性(如自动更新不会因为版本不一致而无法安装)。
