跨平台应用开发进阶(二十二) ：uni-app Android APP上线准备工作汇总

一、为什么要做安全加固？

应用uni-app开发完成APP应用后，上线前进行安全检测，发现APP Android版存在反编译高危漏洞，iOS版并没有爆出此类问题。

当我们开发的 App 准备做上架应用市场时，应用市场会要求上架的 App 做加固处理，这是为什么呢 ？

首先，来看下腾讯开放平台官方的解释说明。

• 若应用不做任何安全防护，极易被病毒植入、广告替换、支付渠道篡改、钓鱼、信息劫持等，严重侵害开发者的利益。
• App 加固后，可以对应用进行安全防护，防止应用分发后，被反编译、调试、盗版、破解、二次打包等威胁，维护开发者的利益。

当然，除了应用加固外，还有其它的安全解决方案如：安全检测（漏洞扫描）、**渠道监控（正盗版分发情况监控）和安全 SDK（专业场景下的安全解决方案）**等。

简单来说就是，如果你不希望自己参与开发的 App 出现以下问题，是免费为别人写的，那就加固吧。

• 应用程序被破解
• 核心代码被窃取
• 恶意代码注入
• 核心数据泄露
• 安全检测未合规

二、如何为 App 应用加固？

目前市面上主流的加固方式有 360 加固保，腾讯云乐固，梆梆加固、网易易顿、顶象等等…这些加固平台工作流程基本都是APK加固、APP签名。

网易易顿加固截图信息：

顶象加固截图信息：

腾讯云加固截图信息（果然白嫖的不香～）：


加固后效果如下：

三、APP签名

通过对 Apk 进行签名，开发者可以证明对 Apk 的所有权和控制权，可用于安装和更新其应用。而在 Android 设备上的安装 Apk ，如果是一个没有被签名的 Apk，则会被拒绝安装。

在安装 Apk 的时候，软件包管理器也会验证 Apk 是否已经被正确签名，并且通过签名证书和数据摘要验证是否合法没有被篡改。只有确认安全无篡改的情况下，才允许安装在设备上。

简单来说，APK 的签名主要作用有两个：

• 证明 APK 的所有者。
• 允许 Android 市场和设备校验 APK 的正确性。

签名的话，一般使用通用签名工具ApkSigner。

ApkSigner是jar包形式的签名工具，较传统工具签名快很多，适用于Win/Mac/Linux环境。

点击下载

3.1 使用说明

1. 解压下载包

2. 命令行执行（需要jdk环境）

    java -jar ApkSigner.jar [-appname test] -keystore keystorePath -alias alias [-pswd password] [-aliaspswd aliasPassword] apkPath(or directory)
   1

注意⚠️：签名之后，如果需要进行对齐操作，请调用命令: zipalign -f 4 in.apk out.apk， zipalign 这个程序在 android sdk 有提供。

（可选）android7.0及之后的apk，可以采用v2签名，提高apk安装速度。但是为了兼容android7.0之前的系统，也需要进行v1签名，且需要先进行v1签名，apk字节对齐（可选），再进行v2签名。具体步骤命令如下：

1. java -jar ApkSigner.jar [-appname test] -keystore keystorePath -alias alias [-pswd password] [-aliaspswd aliasPassword] -v1 true -v2 false in.apk
2. zipalign -c -f [alignmentSize] in.apk out.apk (可选)
3. java -jar ApkSigner.jar [-appname test] -keystore keystorePath -alias alias [-pswd password] [-aliaspswd aliasPassword] -v1 false -v2 true out.apk

其中，option参数说明：

• appname 待签名的应用程序名，可选，但建议不同的APP填上对应的app名（可以为中文），有助于【加速】；
• keystore 后跟.keystore签名文件；
• alias 后跟签名别名；
• pswd 后跟对应签名的密码，例如这里是：android 可选，如果不填，则签名的时候需要手动输入；
• aliaspswd 对应别名 alias 的密码，如果没有则默认使用 keystorePassword，最后跟待签名的APK路径或者目录路径 ，如果跟的是目录则是批量签名；
• v1 true（默认）表示使用v1签名模式，false表示不使用；
• v2 true表示使用v2签名模式，false(默认)表示不适用；

3.2 V1、V2、V3、V4签名方案

Android 目前支持以下四种应用签名方案：

• v1 方案：基于 JAR 签名。
• v2 方案：APK 签名方案 v2（在 Android 7.0 中引入）
• v3 方案：APK 签名方案 v3（在 Android 9 中引入）
• v4 方案：APK 签名方案 v4（在 Android 11 中引入）

其中，v1 到 v2 是颠覆性的，为了解决 JAR 签名方案的安全性问题，而到了 v3 方案，其实结构上并没有太大的调整，可以理解为 v2 签名方案的升级版，有一些资料也把它称之为 v2+ 方案。

3.2.1 v1 签名

在 Android 7.0 (即 Android N，Android Api 24) 以下的版本，只能使用旧签名方案，也就是 v1 签名。

v1 签名使用 JDK 的 jarsigner 工具，对 zip 压缩包的每个文件进行验证，签名后仍可对压缩包进行修改、移动、重新压缩文件。

V1 签名的机制主要就在 META-INF 目录下的三个文件，MANIFEST.MF，CERT.SF，CERT.RSA，他们都是 V1 签名的产物。

在 V1 签名方案中，并不会保护 APK 内的所有文件，会存在一些例外部分，即便被修改也不会导致签名失效。

例如：ZIP 元数据。同时，v1 方案对 APK 内部被保护的原始文件，是单独进行计算数据摘要的，所以在验证时，需要先解压再验证，导致安装时会花费更多的时间，消耗更多的内存。例如 v1 方案中签渠道的方式就是利用了此特性，将渠道信息写入 META-INF 文件中，这不会破坏 v1 签名。

缺点是：不安全、速度慢。

为了解决这些问题，Android 7.0 中引入了 APK 签名方案 v2。

3.2.2 v2 签名

自 Android 7.0 开始，Google 新增了 v2 签名方案。

v2 签名使用 Google 自带的 apksigner 工具，对 zip 压缩包的整个文件进行验证，签名后不能修改压缩包，包括 zipalgin 。

如果你对 v2 签名的 apk 解压，没有发现签名文件，重新压缩后 v2 签名失效，这说明 v2 签名是对整个 Apk 进行签名验证。

v2 签名是一种全文件签名方案，该方案能够发现对 APK 的受保护部分进行的所有更改，从而有助于加快验证速度并增强完整性保证。

使用 APK 签名方案 v2 进行签名时，会在 APK 文件中插入一个 APK 签名分块，该分块位于「ZIP 中央目录」部分之前并紧邻该部分。在「APK 签名分块」内，v2 签名和签名者身份信息会存储在 APK 签名方案 v2 分块 中。

上图是签名前后，APK 文件结构的对比。可以看到在 v2 已签名的 APK 中，包含了 4 个部分：

• ZIP 条目的内容
• APK 签名分块（APK Signing Block）
• ZIP 中央目录
• ZIP 中央目录结尾

在验证期间，v2+ 方案会将 APK 文件视为 blob，并对整个文件进行签名检查。对 APK 进行的任何修改（包括对 ZIP 元数据进行的修改）都会使 APK 签名作废。这种形式的 APK 验证不仅速度要快得多，而且能够发现更多种未经授权的修改。

新的签名格式向后兼容，因此，使用这种新格式签名的 APK 可在更低版本的 Android 设备上进行安装（会直接忽略添加到 APK 的额外数据），但前提是这些 APK 还带有 v1 签名。

从安全的角度 v2 会比 v1 更安全，v2 签名是验证整个打包后的 APK 文件，所以对其 APK 文件做「任何」改动都会破坏签名。注意这里的任何是带引号的，V2签名的签名块其实是一个 K-V 的结构，可以向其中插入一些简单的数据而不破坏 v2 签名，这就是 v2 方案下，多渠道的方案思路。

缺点是：无法解决签名过期更换签名的问题。

3.2.3 v2 签名相对 v1 签名的优点

• 因为不能修改压缩包，所以 v2 签名会更安全。
• v2 签名是对整个 Apk 进行签名验证，不需要解压验证，所以签名验证的时间会更短。

3.2.4 v3 签名

v2 方案解决了安全问题以及安装时验证的效率问题，但是它并没有解决更换签名问题。

Android 9.0 中引入了新的签名方式，它的格式大体和 v2 类似，在 v2 插入的签名块（Apk Signature Block v2）中，又添加了一个新快（Attr块）。

在这个新块中，会记录之前的签名信息以及新的签名信息，以密钥转轮的方案，来做签名的替换和升级。这意味着，只要旧签名证书在手，就可以通过它在新的 APK 文件中，更改签名。

V3 签名新增的新块（attr）存储了所有的签名信息，由更小的 Level 块，以链表的形式存储。

其中每个节点都包含用于为之前版本的应用签名的签名证书，最旧的签名证书对应根节点，系统会让每个节点中的证书为列表中下一个证书签名，从而为每个新密钥提供证据来证明它应该像旧密钥一样可信。

这个过程有点类似 CA 证书的证明过程，已安装的 App 的旧签名，确保覆盖安装的 APK 的新签名正确，将信任传递下去。

3.2.5 v4 签名

在传统的应用安装方案中，开发者通过 ADB（Android Debug Bridge）以有线或无线的方式与终端用户连接，或者用户从软件商店直接下载，然而该方案需要用户等待完整的安装包传输结束后才能启动安装，在这期间产生了不良的用户体验。

增量安装技术是一种流式安装方案：一旦安装包的核心文件传输完成便可启动应用。流式安装意味着允许优先传输核心数据以启动应用，并在后台流式传输剩余数据。

在Android 11中，Google在内核中实现了增量文件系统用于对增量安装的支持。

这使得 Android os 可以通过 ADB 流式传输 APK。同时，Android 11 为了适应增量安装，添加了新的 v4签名方案。

此方案不改变前代签名方案而是创建一种新的签名：基于 APK 所有字节数据计算出 Merkle 哈希树，并将Merkle 树的根哈希、盐值作为签名数据进行包完整性验证。新的签名数据保存在 .idsig 文件中并且在进行增量安装前必须为APK创建对应的 v4 签名文件。

官方文档：v4签名

3.2.6 总结

• v1 签名实际上就是 JAR 签名的方案，它不会保护 APK 内的所有问题，存在安全和效率问题；
• v2 签名是一种全文件签名方案，增加了 APK 签名块（APK Signing Block），但仍无法解决更换签名的问题；
• v3 签名是 v2 的升级版，也被称为 v2+。在 V2 插入的签名块（Apk Signature Block V2）中，又添加了一个新快（Attr 块），它使用链表存储了所有的签名信息，验证时就像 CA 证书的证明过程。
• v4 签名是为了增量安装技术而产生的一种新的签名方案。

3.3 jarsigner 与 apksigner

3.3.1 jarsigner

jarsigner 是 JDK 提供的针对 jar 包签名的工具，如果你本地已经安装了 Java 环境，会自带 jarsigner ，

比如我的 jarsigner 工具的位置在

/Library/Java/JavaVirtualMachines/jdk1.8.0_211.jdk/Contents/Home/bin/jarsigner
1

效果图如下：

3.3.2 apksigner

apksigner 是 Google 官方提供的针对 Android Apk 签名和验证的专用工具，位于 Android SDK / build-tools / SDK 版本 / apksigner 。

以我本地的 Android SDK 30.0.2 版本为例， apksigner 工具的位置在
/Users/suxing/Library/Android/sdk/build-tools/30.0.2/apksigner 。

效果图如下：

如果你用的是 Android Studio 或者 IDEA ，安装这两个编辑器时会自动下载 Android SDK ，所以 apksigner 工具也不需要另外安装。

不过，无论是 apk 包还是 jar 包，其本质都是 zip 格式的压缩包，如果只针对 v1 签名的话，两者的签名过程其实差不多。

apksigner 工具默认同时使用 v1 和 v2 签名，以兼容 Android 7 以下的系统版本。

签名后如果包能正确安装到手机（无需运行）则没有问题，如果安装失败请用命令安装：adb install apkfile 查看出错信息。

3.3.3 签名文件jks与keystore格式

• .jks是在android studio里面生成的签名证书。
• .keystore是eclipse里面生成的签名证书。

两者在使用方式上没有什么区别,但是在算法上有一点区别。

3.3.3.1 jks 转 keystore

在应用apksigner 签名工具进行APK签名时，发现只支持.keystore格式的签名文件，需要把.jks签名格式转化为.keystore格式。

直接用命令行转换，先生成.p12文件，用.p12生成.keystore。

keytool -importkeystore -srckeystore test.jks -srcstoretype JKS -deststoretype PKCS12 -destkeystore test.p12
1

keytool -v -importkeystore -srckeystore test.p12 -srcstoretype PKCS12 -destkeystore test.keystore -deststoretype JKS
1

转换后，会看到如下提示信息。可以通过提示的命令行

keytool -importkeystore -srckeystore cicc-keystore.keystore -destkeystore cicc-keystore.keystore deststoretype pkcs12
1

按照指定行业标准格式进行转换。

Warning: JKS 密钥库使用专用格式。建议使用 “keytool -importkeystore -srckeystore
cicc-keystore.keystore -destkeystore cicc-keystore.keystore
-deststoretype pkcs12” 迁移到行业标准格式 PKCS12。

现在test.keystore的签名应该与test.jks的签名信息是一样的了。

可以通过以下命令来验证:

keytool -v -list -keystore test.keystore
1

3.3.3.1 keystore 转 jks

同理，.keystore也可以转.jks，转换命令如下：

keytool -importkeystore -srckeystore test.keystore -srcstoretype JKS -deststoretype PKCS12 -destkeystore test.p12
1

keytool -v -importkeystore -srckeystore test.p12 -srcstoretype PKCS12 -destkeystore test.jks -deststoretype JKS
1

四、延伸阅读 CPU类型配置

Android平台配置CPU类型针对的是为了提高运行效率，使用C/C++语言开发生成的so库，需要为各cpu类型平台单独编译生成对应指令的so库。Java语言开发的代码运行在虚拟机中，基于虚拟机跨平台特性，由虚拟机适配CPU类型，不涉及到此问题。

HBuilder/HBuilderX中使用so库的功能（模块）如下：

• Audio（录音）：支持mp3格式；
• Geolocation（定位）：百度；
• LivePush（直播推流）；
• Maps（地图）：高德、百度；
• OAuth（登录鉴权）：新浪微博；
• Push（消息推送）：个推、UniPush；
• Share（分享）：新浪微博；
• Speech（语音输入）：百度，注意：讯飞不支持64位；
• Weex（原生渲染）：uni-app（自定义组件模式、nvue页面）， 注意：HBuilderX2.1.5及以上版本支持；

注意⚠️：

• HBuilderX2.7.0+ 调整 云端打包默认不再包含 x86 CPU类型库，减少apk包体积详情；
• HBuilderX2.1.5+ 开始支持Android平台的新增适配64位CPU类型，云端打包支持配置App支持的CPU类型，满足Google Play从2019年8月1日起上传的App必需支持64位CPU的要求。

4.1 CPU类型

HBulderX已适配支持以下主流CPU类型：

• armeabi-v7a 第7代及以上的ARM处理器（ARM32位），市面上大多数手机使用此CPU类型。
• arm64-v8a 第8代、64位ARM处理器（ARM64位），最近两年新发的设备使用此CPU类型，可以兼容使用armeabi-v7a的so库。

x86 少部分平板使用x86，AS模拟器中选了intel x86时使用x86处理器，以及其它常用三方模拟器通常使用x86。

注意⚠️：不勾选x86在模拟器上可能无法正常运行，以下是常见模拟器是否需要包含x86的情况：

• 雷电模拟器： 3.x必须包含x86，否则无法正常运行；4.x无需包含x86；
• 夜神模拟器： 必须包含x86，否则无法正常运行；
• MuMu模拟器： 无需包含x86；
• 逍遥模拟器： 无需包含x86；
• BlueStacks（蓝叠模拟器）： 无需包含x86；
• 腾讯模拟器（手游助手）： 必须包含x86，否则无法正常运行；
• 其它模拟器： 未测试验证，建议包含x86，确保在模拟器正常运行；

4.2 配置支持的CPU类型

4.2.1 可视化界面配置

打开项目的manifest.json文件，在 “App常用其它设置” -> “Android设置” -> “支持CPU类型” 项中勾选需要支持的CPU类型：

4.2.2 源码视图配置

打开项目的manifest.json文件，切换到“源码视图”，根据项目类型进行配置。

4.2.2.1 uni-app项目

在 "app-plus"->"distribute"->"android" 节点的 abiFilters 属性配置支持的CPU类型，示例如下：

  "app-plus": {
    "distribute": {
      "android": {
        "abiFilters": [
          "armeabi-v7a",
          "arm64-v8a"
        ]
        //...
      },
      //...
    },
    //...
  },
  //..
1
2
3
4
5
6
7
8
9
10
11
12
13
14

4.2.2.2 离线打包配置

使用Android studio打开Android原生项目，打开对应项目的build.gradle文件。 在Android -> defaultConfig下添加支持的CPU类型，如下示例：

defaultConfig{
	ndk {
            abiFilters 'arm64-v8a','armeabi-v7a'
        }
}
1
2
3
4
5

注意：离线打包仅支持arm64-v8a、armeabi-v7a、x86三种类型，建议根据自己需求选择打包的

4.3 CPU类型

4.3.1 CPU类型选择建议

ARM64位（arm64-v8a）CPU可以兼容ARM32的指令，也就是说只选择armeabi-v7a类型的so库也可以在64位手机上运行，只是没有完全发挥CPU的性能。 选择支持的CPU类型时请参考以下建议：

• 如果不在意apk大小，三种CPU类型都勾选;
• 如果在意apk大小，选择ARM32位即可（几乎在所有ARM指令的所有设备上都可正常运行）;
• 如果要兼容一些平板和模拟器，选择ARM32位和X86 不是所有模拟都仅支持x86指令，如雷电（4.x）、MuMu等模拟器也是支持ARM指令。

4.3.2 查看apk支持的CPU类型

使用解压工具打开apk，在lib目录下可以查看到支持的CPU类型，如下图所示：

4.3.3 常见问题

提交Google Play时要求支持64位，建议选择"armeabi-v7a"和"arm64-v8a"两个即可，也可以只选择"arm64-v8a"。

注意⚠️：不要勾选"x86"！

如果打包选择的CPU类型与设备不兼容，会导致无法正常安装。 通过adb命令安装通常会提示如下错误：

Performing Streamed Install
adb: failed to install android_debug.apk: Failure [INSTALL_FAILED_NO_MATCHING_ABIS: Failed to extract native libraries, res=-113]
1
2

使用Android Studio自带的x86模拟器，将不包含x86 cpu类型的apk拖到模拟器安装时会弹出如下提示框：

目前市面上常见的手机都是使用ARM处理器，很少有设备使用x86处理器，因此从HBuilderX2.7.0开始云端打包调整为默认不再包含x86的CPU类型，减少apk包大小：

• uni-app项目基础功能apk减少5M+，使用的三方SDK及uni原生插件越多，减少的包尺寸越大，具体值取决于其包含的x86类型的so库大小；
• 5+App、Wap2App项目 基础功能apk减少100K+，如果使用的三方SDK中存在so库则减少的尺寸较大，具体值取决于其包含的x86类型的so库大小

注意⚠️：大多数模拟器（如夜神）必须包含x86，否则应用启动时可能会白屏，请进行配置！

五、拓展阅读

• Android APK安全加固