安卓应用SHA1的获取与Unity打包发布

项目背景

项目中需要使用SHA1申请一个SDK的APPKey，在此记录一下SHA1相关知识。

SHA1介绍

SHA-1（英语：Secure Hash Algorithm 1，中文名：安全散列算法1）是一种密码散列函数，美国国家安全局设计，并由美国国家标准技术研究所（NIST）发布为联邦数据处理标准（FIPS）[2]。SHA-1可以生成一个被称为消息摘要的160位（20字节）散列值，散列值通常的呈现形式为40个十六进制数。[From Wiki]

每一个apk会对应有一个证书签名文件，这个签名文件中包含了MD5、SHA1、SHA256这三个证书指纹以及其他的一些信息。
在使用SHA1申请SDK APPKey的时候，碰到了两个概念：发布版SHA1和开发版SHA1。最初我很疑惑为什么会有两个SHA1呢？实际上，这并不是指这个apk有发布版SHA1和开发版SHA1两个SHA1，而是在调试的过程中我们可以使用开发版SHA1方便调试，在最后发布应用的时候要用到发布版SHA1。

为什么要有安卓签名文件呢？

以下参考Android的签名文件生成两种方法

1. 应用程序升级：如果你希望用户无缝升级到新的版本，那么你必须用同一个证书进行签名。这是由于只有以同一个证书签名，系统才会允许安装升级的应用程序。如果你采用了不同的证书，那么系统会要求你的应用程序采用不同的包名称，在这种情况下相当于安装了一个全新的应用程序。如果想升级应用程序，签名证书要相同，包名称要相同！
2. 应用程序模块化：Android系统可以允许同一个证书签名的多个应用程序在一个进程里运行，系统实际把他们作为一个单个的应用程序，此时就可以把我们的应用程序以模块的方式进行部署，而用户可以独立的升级其中的一个模块
3. 代码或者数据共享：Android提供了基于签名的权限机制，那么一个应用程序就可以为另一个以相同证书签名的应用程序公开自己的功能。以同一个证书对多个应用程序进行签名，利用基于签名的权限检查，你就可以在应用程序间以安全的方式共享代码和数据了。不同的应用程序之间，想共享数据，或者共享代码，那么要让他们运行在同一个进程中，而且要让他们用相同的证书签名。

SHA1的获取

1.开发版SHA1

通常开发版的sha1值我们使用的是默认安卓自带的签名，每个主机会有一个。
在C:\User\MMC.android路径下（MMC是我的用户名，这里注意替换），有一个debug.keystore

这就是默认自带的签名，如果你在打包apk时候没有进行额外的配置keystore签名的操作时，打包出来的apk对应的签名文件就是这个。

要查看这个签名中的SHA1，只需要在cmd中输入命令：keytool -list -v -keystore debug.keystore
注意：keytool是jdk下的工具，需要jdk配置完成后才能使用

2.发布版SHA1

发布版SHA1需要我们手动生成签名文件，手动生成签名文件的教程参考以下网址：
Android的签名文件生成两种方法

查看我们生成的签名方法与上述一致，打开cmd，进入刚才生成签名的路径下，输入命令keytool -list -v -keystore debug.keystore
将debug.keystore替换成刚刚生成的签名名称即可

3.查看apk的SHA1

1） 将apk修改后缀为 .rar文件后解压；

2） 进入解压后的META-INF目录，该目录下会存在文件CERT.RSA（注：也可能不叫CERT.RSA）


3） 在该目录下打开cmd，输入命令 ：keytool -printcert -file CERT.RSA（修改为路径下后缀为.RSA的文件名）
这里将会显示出MD5和SHA1签名。

SHA1的打包发布

unity打包Apk生成签名证书keystore

一个.keystore（密钥库）下可以有多个alias（别名）

使用不同的别名（来自同一个密钥库）签署一个APK会生成不同的APK signing signatures
用处：
如果您在一家拥有多个部门的大型公司中编写自己的应用程序，这将非常有用。所以Wilson的Widgets可能有一个wilsonwidgets.keystore的密钥库，可能有一个内部部门有一个“widgetmakers”密钥，一个部门有一个“widgetdelivery”密钥，另一个部门有一个“hrdepartment”密钥。每个部门都可以阻止其他部门更新他们的应用程序，但公司本身将所有密钥存储在一个密钥库中，可以备份到一个位置。

Android文档中对应用签名的解释

https://developer.android.com/studio/publish/app-signing#strategies