如何用Android 源码生成APK签名文件

我们很多应用需要用到系统签名，可以通过生成系统签名文件，在生成apk时使用这个签名，然后可以安装到机器中，不需要放在源码里编译，重新刷系统。

先附上 50和 20机器人通用的debugkey(图已经省略)

在Linux环境中，以Android源码目录为根目录。

其中的platformpk8是制作系统签名需要的文件。

1、在这个目录下，执行

生成临时文件platformpem

2、接着执行以下命令，将在目录下生成platformp12文件，它本质上应该就是一个数字证书

3、然后再执行以下命令出现以下信息，表示成功生成platformjks

这个名字可以改成debugkeystore 它的后缀本身是没有关系，eclipse和AS都识别 platformjks

4、然后在打包 apk 的时候选择platformjks文件，就可以直接用adb命令安装apk到机器中了。

xxxx表示需要安装的apk路径

5、签名的 Key store password和Key password都是android

## 使用自动签名的方法

1 创建或者修改 ~/gradle/gradleproperties

2 在gradleproperties 文件中增加下面的内容(具体内容需要根据实际来更改)

STORE_PASSWORD=xysys

KEY_ALIAS=xxsasd

KEY_PASSWORD=988asdf

3 这样每次build的时候，总是用keystore来签名，不会用生成的debug来签名了

## 使用命令行来构建APK

进入项目最高层目录,找到 gradlew 执行下面的命令来构建所有类型的APK，自动使用官方签名

## 验证签名是官方签名

1 使用keytool 获取apk包的指纹

例如：

2 查看keystore的指纹

apk的签名指纹跟keystore中的指纹一致表明该包是用keystore来签名的。

注意：若java版本是7之前的，需要先把apk解压，

来看包的指纹。

给apk签名。

用已有的jks文件给apk签名。

先打开jdk文件夹，例如E:\Program Files\Java\jdk180_201\bin。

然后打开cmd输入以下命令

其中alias就是当初创建签名文件时所设定的，不能随便写。

在签名之前应当删除apk中META-INF中的文件，以免签名冲突。

2021年8月4日

查看应用签名的MD5、SHA1、SHA256值及签名算法。

查看keystore文件签名信息，前提要有keystore文件和密钥，才能够获取keystore文件的签名信息。

方法一：（适用于 AS）

1)打开 AS工具窗口栏右边的 Gradle -> Project -> app -> Tasks -> android -> signingReport,双击运行 signingReport;

在没有keystore文件和密钥的情况下,要想查看我们所需应用的签名信息,就需要借助 keytool 工具来完成。

首先解压要查看的apk包,通过数据证书管理工具 keytool 查看apk的签名信息。具体步骤如下：

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

2）进入解压后的 META-INF 目录，找到该目录下的 xxxRSA 文件；

3）通过命令 cmd 打开DOS窗口，输入命令 ： keytool -printcert -file [RSA文件路径]

在查看应用签名信息过程中，可能会遇到以下几个问题：

定位 keytoolexe 工具所在的目录，使用相关 *** 作命令查看签名信息；

JKS(Java KeyStore) ：是 Java 的 keytools 证书工具支持的证书私钥格式。jks 包含了公钥和私钥，可以通过 keytool 工具来将公钥和私钥导出。因为包含了私钥，所以 jks 文件通常通过一个密码来加以保护。一般用于 Java 或者 Tomcat 服务器。

PKCS #12 ：定义了一种存档文件格式，用于实现存储许多加密对象在一个单独的文件中。通常用它来打包一个私钥及有关的 X509 证书，或者打包信任链的全部项目。

定位 keytoolexe 工具所在的目录，使用 *** 作命令转换证书格式；

对apk进行反编译并修改后，需要对重新打包的apk进行签名。

秘钥生成工具——keytool

路径：jdk/bin/keytoolexe

生成秘钥： keytool -genkeypair -keystore testkeystore -alias test -validity 10 -keyalg RSA

其中-validity指定有效期天数，-keyalg指定算法

查看秘钥信息： keytool -list -v -keystore testkeystore

JDK签名工具——jarsigner

仅支持V1签名

路径：jdk/bin/jarsignerexe

命令： jarsigner -keystore testkeystore testapk testkey

apk签名工具——apksigner

默认开启V1和V2签名

路径：AndroidSDK/build-tools/2800/apksignerbat

命令： apksigner sign --ks xxkeystore --ks-key-alias testkey testapk

Android中许多函数只能是系统程序或者有root权限的程序才可以调用，否则会有"Permission denied"异常。所以如果开发时要调用此类函数，必须授予程序root权限。下面是两种具体的实现方法

注：两种方法都不一定适用于所有android系统。

方法一：需要在Android系统源码的环境下用make来编译：

在应用程序的 AndroidManifestxml 中的 manifest 节点中加入 android:sharedUserId="androiduidsystem" 这个属性

修改Androidmk文件，加入LOCAL_CERTIFICATE := platform这一行

使用mm命令来编译，生成的apk就有修改系统时间的权限了。

方法二：

同上，加入android:sharedUserId="androiduidsystem"这个属性。

使用eclipse编译出apk文件，但是这个apk文件是不能用的。

用压缩软件打开apk文件，删掉META-INF目录下的CERTSF和CERTRSA两个文件。 （这一步我跳过了（原本是无意的，后来发现下面也有提到），结果一样可以）

使

用目标系统的platform密钥来重新给apk文件签名。这步比较麻烦，首先找到密钥文件，在Android源码目录中的位置

是"build\target\product\security"，下面的platformpk8和platformx509pem两个文件。然

后用Android提供的Signapk工具来签名，signapk的源代码是在"build\tools\signapk"下，用法为"signapk

platformx509pem platformpk8 inputapk

outputapk"，文件名最好使用绝对路径防止找不到，也可以修改源代码直接使用。

解释一下原理，首先加入

android:sharedUserId="androiduidsystem"这个属性。通过Shared User id,拥有同一个User

id的多个APK可以配置成运行在同一个进程中。那么把程序的UID配成androiduidsystem，也就是要让程序运行在系统进程中，这样就

有权限来调用那些需要系统权限的函数了。 只是加入UID还不够，如果这时候安装APK的话发现无法安装，提示签名不符，原因是程序想要运行在系统进程中

还要有目标系统的platform

key，就是上面第二个方法提到的platformpk8和platformx509pem两个文件。用这两个key签名后apk才真正可以放入系

统进程中。第一个方法中加入LOCAL_CERTIFICATE := platform其实就是用这两个key来签名。

有一个问题，就是这样生成的程序只有在原始的Android系统或者是自己编译的系统中才可以用，因为这样的系统才可以拿到

platformpk8

和platformx509pem两个文件。要是别家公司做的Android上连安装都安装不了。试试原始的Android中的key

来签名，程序在模拟器上运行OK，不过放到G3上安装直接提示"Package has no signatures that match

those in shared user androiduidsystem"，这样也是保护了系统的安全。

最后说一下，这个android:sharedUserId属性不只可以把apk放到系统进程中，也可以配置多个APK运行在一个进程中，这样可以共享数据，应该会很有用的。

因工作需要对系统的wifi和以太网进行配置，需要获取到系统权限以后才能进行 *** 作，因此研究了下对apk 进行系统签名以获取系统权限，其实本来打算如果root可以的话直接通过root的方式（设备已经root），后来找了半天发现没有api进行修改，无奈只能进行系统签名了，有童鞋知道root方式修改不妨告诉我一下。

这些文件可以问系统厂商获取，如果是原生系统可以到系统源码目录下获取。

如果报以下的错误 ,这时候就用到准备的libconscrypt_openjdk_jniso 文件

为了检测我们的应用是否已经签名成功 可以获取系统权限，看看能否获取到。

结果:

在上一种方式中，我们成功对我们的apk进行了系统签名，并且能使用系统权限，但是必须每次打包出apk再进行签名 对调试很不方便，下面我们可以生成带有系统签名的签名文件，在项目中使用，就不需要每次手动进行签名。

bubble可以替换为自己喜欢的名称,这一步要输入密码，我尝试输入其他不行，只能输入android。

bubble 可替换为自己喜欢的password和alias

到这里 两种对app进行系统签名的方式完成，如有不足，欢迎指出

通过前一篇 Apk签名机制之——JAR签名机制详解 的分析我们知道，JAR签名需要对apk内所有文件进行hash校验，当资源较多时签名验证速度较慢。为了加快验证速度并加强完整性保证，Andorid在70引入一种全文件签名方案V2。下面来看V2方案的具体设计原理。

在了解V2签名结构前，先来了解下 zip（apk）文件的结构 。

zip文件分为3部分：

通过中央目录起始偏移量和size即可定位到中央目录，再遍历中央目录条目，根据本地文件头的起始偏移量即可在数据区中找到相应的压缩数据。

在 Apk签名机制之——JAR签名机制详解 中我们已经知道，JAR签名是在apk文件中添加META-INF目录，即需要修改 数据区 、 中央目录 ，因为添加文件后会导致中央目录大小和偏移量发生变化，还需要修改 中央目录结尾记录 。V2方案为加强数据完整性保证，不在 数据区 和 中央目录 中插入数据，选择在 数据区 和 中央目录 之间 插入一个 APK签名分块 ，从而保证了原始zip（apk）数据的完整性。具体如下所示：

v2 签名块负责保护第 1、3、4 部分的完整性，以及第 2 部分包含的 APK 签名方案 v2分块 中的 signed data 分块的完整性。

APK签名分块包含了4部分：分块长度、ID-VALUE序列、分块长度、固定magic值。其中 APK 签名方案 v2分块 存放在ID为0x7109871a的键值对中。在进行签名校验时，先找到zip 中央目录结尾记录 ，从该记录中找到 中央目录起始偏移量 ，再通过magic值即可确定前方可能是 APK签名分块 ，再通过前后两个分块长度字段，即可确定 APK签名分块 的位置，最后通过ID（0x7109871a）定位 APK 签名方案 v2分块 位置。

APK 签名方案 v2分块 是一个签名序列，说明可以使用多个签名者对同一个APK进行签名。每个签名信息中均包含了三个部分的内容：

前面说了v2 签名块负责保护第 1、3、4 部分的完整性，以及第 2 部分包含的 APK 签名方案 v2分块 中的 signed data 分块的完整性。第1、3、4部分的完整性是通过内容摘要来保护的，这些摘要保存在 signed data 分块中，而 signed data 分块的完整性是通过签名来保证的。下面来看摘要的计算过程：

第 1、3 和 4 部分的摘要采用以下计算方式，类似于两级 Merkle 树 。

因为V2签名机制是在Android 70中引入的，为了使APK可在Android 70以下版本中安装，应先用JAR签名对APK进行签名，再用V2方案进行签名。要注意顺序一定是先JAR签名再V2签名，因为JAR签名需要修改zip 数据区 和 中央目录 的内容，先使用V2签名再JAR签名会破坏V2签名的完整性。

实际上我们在编译APK时并不需要关心这个过程，在Android Plugin for Gradle 22中，gradle默认会同时使用JAR签名和V2方案对APK进行签名，如果想要关闭JAR签名或V2签名，可以在buildgradle中进行配置：

在 Android 70 中，会优先以 v2方案验证 APK，在Android 70以下版本中，系统会忽略 v2 签名，仅验证 v1 签名。Android 70+的校验过程如下：

因为在经过V2签名的APK中同时带有JAR签名，攻击者可能将APK的V2签名删除，使得Android系统只校验JAR签名。为防范此类攻击，V2方案规定：

攻击者还可能试图删除 APK 签名方案 v2 分块 中安全系数较高的签名，从而使系统验证安全系数较低的签名。为防范此类攻击：

通过 Apk签名机制之——JAR签名机制详解 和本篇文章的分析，我们知道了：

JAR签名的劣势

V2签名的优势

现在我们可以解答 Apk签名的基本概念和用法 前言中提出的问题了：

APK签名是为了保证APK的完整性和来源的真实性，分为JAR签名和V2签名两种方案。核心思想均是计算APK内容的hash，再使用签名算法对hash进行签名。校验时通过签名者公钥解密签名，再与校验者计算的APK内容hash进行比对，一致则校验通过。

签名证书的指纹，在申请第三方SDK时，需填入APK包名和证书指纹，SDK开发者后台会根据这两个值生成一个key。第三方SDK在初始化时，会从系统中获取当前APK的包名、签名证书指纹以及key，然后将此指纹上传到其服务器，然后校验包名、签名证书指纹是否与此key绑定，校验通过后才进行授权。

在V2方案出现之前，快速批量打包方案有3类：

在V2方案出现之后，因同时保证了 数据区 、 中央目录 和 中央目录结尾记录 的完整性，故方案2、3均不适用了。那是不是就没有快速批量打包的可能了呢？当然不是，可以从 APK签名分块 中着手。再回过头来看一下 APK签名分块 的结构：

APK签名分块 中有一个ID-VALUE序列， 签名信息（ APK 签名方案 v2 分块 ）只存储在ID 为 0x7109871a的ID-VALUE中，通过分析签名校验源码可以发现，其它ID-VALUE数据是未被解析的，也就是说除 APK 签名方案 v2 分块 外，其余ID-VALUE是不影响签名校验的。故可以定义一个新的ID-VALUE，将渠道信息写入 APK签名分块 中。因为V2方案只保证了第1、3、4部分和第 2 部分（ APK签名分块 ）包含的 APK 签名方案 v2分块 中的 signed data 分块的完整性。新写入的ID-VALUE不受保护，所以此方案可行。实际上美团新一代渠道包生成工具 Walle 就是以这个方案实现的。

好了，到这里APK签名机制的全部内部就分析完了，相信大家看完这三篇文章之后，对JAR签名和V2签名机制都有了大致的了解，有兴趣的同学可以阅读签名和校验的源码进一步分析。

以上就是关于如何用Android 源码生成APK签名文件全部的内容，包括:如何用Android 源码生成APK签名文件、安卓 自动签名 以及如何验证一个apk包是用你的签名文件签名的、用命令给apk签名等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！