开发笔记-应用签名
开发笔记主要是记录开发中遇到的一些问题和解决方案，以及引发的一些思考，不会太深入地记录问题，但是会尽可能广泛地记录涉及到的内容，方便之后整理归纳和查阅
No.1 一些细碎的问题
- build.gradle 里面的 signingConfigs 里的 keyAlias 要与你新建 Key Store 时填写的 Alias 保持一致，否则会报错：No key with alias ‘xxxx’ found in keystore E:\workspace\xxxx\xxxx，如果不小心忘记了，可以用指令：
keytool -changealias -keystore test.keystore -alias key_name -destalias new_key_name来处理，参考文章：修改 alias 方法 - 发现未签名的 apk 打包出来后，文件名里面带有 unsigned，签了名的就没有了，这个应该是可以配置的
- 生成签名文件和查看签名文件
script 1
2
3
4
5如何生成 .keystore
keytool -genkey -v -keystore myApp.keystore -alias myApp.keystore -keyalg RSA -validity 30000
如何查看 .keystore
keytool -list -v -keystore keystore文件路径 -storepass keystore密码
No.2 关于系统签名
近来接触了一下车机项目，因为需要系统级权限，探索了一下系统签名，这里简单记录一下，后续如果还有进行更多关于系统签名的学习的话，可以再继续完善
首先我们手上的是一个普通 apk，能够直接 adb install 到手机、车机等 Android 设备上，这时候我们想要打包一个系统级别的 apk，我做了如下步骤：
- AndroidManifest.xml 里面 Application 层级声明了
android:sharedUserId="android.uid.system"1
2
3
4
5
6
7
8<manifest xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools"
package="com.hoshi.test"
android:sharedUserId="android.uid.system"
android:versionCode="1"
android:versionName="1.0.0">
...
</manifest> - 然后将客户提供的 platform.jks 文件放到项目根目录下
- 修改 build.gradle 里面的 signingConfigs
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22signingConfigs {
systemKey {
keyAlias "e02"
keyPassword "123456"
storeFile file("../platform.jks")
storePassword "123456"
}
...
}
buildTypes {
release {
minifyEnabled true
shrinkResources true
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-project.txt'
signingConfig signingConfigs.systemKey
}
debug {
minifyEnabled false
signingConfig signingConfigs.debugkey
}
} - 然后把代码提交，Jenkins 进行打包，得到 apk
- 使用
keytool -list -v -keystore指令查看 jks 的 SHA1 码，然后把 apk 上传到客户的应用市场
上面步骤走完，整个处理就结束了，大体流程非常简单，但是里面的细节可以讲很多，下面稍微展开讲讲
第 1 步
我们声明了一个 android:sharedUserId="android.uid.system"，声明之后，就无法通过 AS 直接运行我们的 apk 了，如果要本地运行，调试应用，还需要把这个注释掉
默认情况下，Android 会为每个应用分配其唯一用户 ID。如果两个或多个应用将此属性设置为相同的值，则这些应用都将共享相同的 ID，前提是这些应用的签名完全相同。具有相同用户 ID 的应用可以访问彼此的数据，如果需要的话，还可以在同一进程中运行。所以我们设置了这个 sharedUserId 后，又签了同一个应用的签名，除了都获得了系统级权限之外，彼此之间应该也都可以共享数据了
要注意，android:sharedUserId 在 Android 29 上已经被弃用了，所以高版本还需要找下替代，同时，由于现有应用无法移除此值，这类应用应添加 android:sharedUserMaxSdkVersion="32" ，以免在新用户安装时使用共享用户 ID。因为我这次开发针对的车机 Android 版本比较老，所以不怎么需要管这个
第 2 步
第 2 步这个 platform.jks 文件，应该是客户进入到 AOSP 的 build 目录（或者什么别的目录）下，运行 keytool 相关指令生成的，因为用户有车机系统的源码，所以他可以生成一个车机系统的签名文件出来，具体细节我不太了解，这里简单提一下大概原理即可
第 5 步
因为上传到用户的应用市场需要填入 SHA1 码，所以调用 keytool 指令去获取，这里记录一下方便以后有类似场景时查阅，如果不需要的话就不要管这个了
最后
我们得到的这个 apk，是无法正常 adb install 的，只能获得 root 权限后，通过 adb push 到 system/app/ 这种目录下，然后重启系统让其自行安装，具体的执行方法视乎具体系统而定。安装好后，这个应用拥有系统级权限，且无法通过常规手段卸载