开发笔记-应用签名

开发笔记主要是记录开发中遇到的一些问题和解决方案，以及引发的一些思考，不会太深入地记录问题，但是会尽可能广泛地记录涉及到的内容，方便之后整理归纳和查阅

No.1 一些细碎的问题

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 方法
2. 发现未签名的 apk 打包出来后，文件名里面带有 unsigned，签了名的就没有了，这个应该是可以配置的
3. 生成签名文件和查看签名文件

   script

   如何生成 .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，我做了如下步骤：

1. AndroidManifest.xml 里面 Application 层级声明了 android:sharedUserId="android.uid.system"

   <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>

2. 然后将客户提供的 platform.jks 文件放到项目根目录下
3. 修改 build.gradle 里面的 signingConfigs

   signingConfigs {
       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
       }
   }

4. 然后把代码提交，Jenkins 进行打包，得到 apk
5. 使用 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/ 这种目录下，然后重启系统让其自行安装，具体的执行方法视乎具体系统而定。安装好后，这个应用拥有系统级权限，且无法通过常规手段卸载

No.3 APK 迁移 AAB

首先用我自己的理解简单说说什么是 AAB，AAB 全称是 Android App Bundle，在用户进行下载时，它会根据用户所在地区、语言、手机分辨率等差异进行分发，以达到精简应用大小的效果，更正式的说明可以自行搜索文档或其他文章

从 2021 年 8 月起，新应用上架 Google 市场就需要以 AAB 的格式上传，老应用可以继续用 APK。公司的应用逐渐臃肿，已经超过 APK 的大小限制 —— 100 MB 了。因为之前已经进行过精简，所以再压缩会比较困难，而 AAB 的大小限制是 150 MB，所以刚好趁这次机会直接将 APK 升级为 AAB 格式

需要做的非常简单，只需要修改 Jenkins 打包脚本，将 gradlew assebleRelease 改为 gradlew bundleRelease，就可以将产物从 .apk 变为 .aab，至于签名密钥文件，可以沿用 .keystore，也可以将 .keystore 转换成 .jks，这两种都是一样的，转换指令为：keytool -importkeystore -srckeystore your-keystore.keystore -srcstoretype JKS -destkeystore your-keystore.jks -deststoretype JKS

.keystore 和 .jks 文件本质上是 Java 密钥库的不同命名格式，网上很多文章说 .keystore 是 Eclipse、keytool 生成的，而 .jks 是 Android Studio 生成的，它们本质是一样的，具体还没怎么研究，相关文章也少，暂时按这样理解，后续由新的认知可以再补充下

另外还有个语言分包问题，如果 app 做了应用内多语言切换的话，用 AAB 格式，会由于根据语言分发的特性而导致部分语言实效，所以还要加上如下配置，这里记录一下

android {

    ...

    bundle {
        language {
            // Specifies that the app bundle should not support
            // configuration APKs for language resources. These
            // resources are instead packaged with each base and
            // feature APK.
            enableSplit = false
        }
    }
}