跨平台应用开发进阶(二十二) ：Android 应用安全机制实现方案

No Silver Bullet

已于 2023-05-26 09:31:33 修改

阅读量2.8k

点赞数 2

分类专栏： Cross-platform APP 文章标签： android

于 2022-06-17 15:30:56 首次发布

本文链接：https://blog.csdn.net/sunhuaqiang1/article/details/125300253

版权

Cross-platform APP 专栏收录该内容

74 篇文章 46 订阅

订阅专栏

文章目录

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

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

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

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

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

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

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

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

二、如何为 App 应用加固？

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

网易易顿加固截图信息：
在这里插入图片描述
顶象加固截图信息：

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

加固后效果如下：

三、APP签名

3.1 Android 签名机制

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

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

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

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

给APK签名可以带来以下好处：

应用程序升级
如果想无缝升级一个应用，Android系统要求应用程序的新版本与老版本具有相同的签名与包名。若包名相同而签名不同，系统会拒绝安装新版应用。
应用程序模块化
Android系统可以允许同一个证书签名的多个应用程序在一个进程里运行，系统实际把他们作为一个单个的应用程序。此时就可以把我们的应用程序以模块的方式进行部署，而用户可以独立的升级其中的一个模块。
代码或数据共享
Android提供了基于签名的权限机制，一个应用程序可以为另一个以相同证书签名的应用程序公开自己的功能与数据，同时其它具有不同签名的应用程序不可访问相应的功能与数据。
应用程序的可认定性
签名信息中包含有开发者信息，在一定程度上可以防止应用被伪造。例如网易云加密对Android APK加壳保护中使用的“校验签名（防二次打包）”功能就是利用了这一点。

3.2 Android 签名原理

对一个APK文件签名之后，APK文件根目录下会增加META-INF目录，该目录下增加三个文件：

在这里插入图片描述

MANIFEST.MF
NETEASE.SF
NETEASE.RSA

3.2.1 MANIFEST.MF

MANIFEST.MF 为摘要文件。

MANIFEST.MF中保存了APK里所有文件的SHA1校验值的BASE64编码，程序遍历Apk包中的所有文件(entry)，对非文件夹非签名文件的文件，逐个用SHA1生成摘要信息，再用Base64进行编码，格式如下（一个文件对应一条记录）：

Name: res/anim/abc_fade_in.xml
SHA1-Digest: ohPEA4mboaFUu9LZMUwk7FmjbPI=
Name: res/anim/abc_fade_out.xml
SHA1-Digest: MTJWZc22b5LNeBboqBhxcQh5xHQ=

如果你改变了apk包中的文件，那么在apk安装校验时，改变后的文件摘要信息与MANIFEST.MF的检验信息不同，于是程序就不能成功安装。

如果攻击者修改了程序的内容，又重新生成了新的摘要，那么就不可以通过验证，所以这是一个非常简单的验证。

3.2.2 CERT.SF

CERT.SF 是对摘要的签名文件。

SF文件里保存了MANIFEST.MF文件的SHA1校验值的BASE64编码，同时还保存了MANIFEST.MF中每一条记录的SHA1检验值BASE64编码，格式如下：

SHA1-Digest-Manifest: ZRhh1HuaoEKMn6o21W1as0sMlaU=
Name: res/anim/abc_fade_in.xml
SHA1-Digest: wE1QEZhFkLBWMw4TRtxPdsiMRtA=
Name: res/anim/abc_fade_out.xml
SHA1-Digest: MfCV1efdxSKtesRMF81I08Zyvvo=

对前一步生成的MANIFEST.MF，使用SHA1-RSA算法，用开发者的私钥进行签名。在安装时只能使用公钥才能解密它。解密之后，将它与未加密的摘要信息（即，MANIFEST.MF文件）进行对比，如果相符，则表明内容没有被异常修改。

在这一步，即使开发者修改了程序内容，并生成了新的摘要文件，但是攻击者没有开发者的私钥，所以不能生成正确的签名文件（CERT.SF）。系统在对程序进行验证的时候，用开发者公钥对不正确的签名文件进行解密，得到的结果和摘要文件（MANIFEST.MF）对应不起来，所以不能通过检验，不能成功安装文件。

3.2.3 CERT.RSA

CERT.RSA 文件是一个X.509格式证书。

.RSA文件还可能是.DSA文件，RSA与SF文件的文件名可以更改，但是它们的命名必须一样。

RSA文件则包含了签名公钥、签名所有者等信息，还保存了用SHA1withRSA签名算法对CERT.SF文件的签名结果信息。

使用 openssl pkcs7 -inform DER -in CERT.RSA -noout -print_certs -text 命令查看证书CERT.RSA内容:

在这里插入图片描述

由上图可知，在CERT.RSA文件中有两个签名信息，一个是证书的签名信息，另一个是证书附加信息中CERT.SF的签名信息。

系统对CERT.SF文件进行签名校验，所需要的公钥就是从证书里取出来的，由于证书中包含了证书签名信息，我们可以在代码中预埋证书签名信息，校验证书中的签名是否一致，防止第三方使用他的私钥重新签名apk。

证书自身的签名信息可以用于校验apk是否被第三方重新打包，当第三方使用自己的私钥签名apk时，其生成的证书的签名值与我们生成的证书签名值不同，因此可以在此处进行校验。

附加信息中的CERT.SF的签名信息在apk安装时，安装器会重新CERT.SF的签名内容与附加信息中的CERT.SF的签名信息进行对比判断apk是否被篡改。

通常我们所说的签名是指证书的签名信息。

Android系统就是根据这三个文件的内容对APK文件进行签名检验的。

为什么要签名呢？是不是最安全的呢？如果apk文件被篡改后会发生什么？

首先，如果你改变了apk包中的任何文件，那么在apk安装校验时，改变后的文件摘要信息与MANIFEST.MF的检验信息不同，于是验证失败，程序就不能成功安装。

其次，如果你对更改的过的文件相应的算出新的摘要值，然后更改MANIFEST.MF文件里面对应的属性值，那么必定与CERT.SF文件中算出的摘要值不一样，照样验证失败。

最后，如果你还不死心，继续计算MANIFEST.MF的摘要值，相应的更改CERT.SF里面的值，那么数字签名值必定与CERT.RSA文件中记录的不一样，还是失败。

那么能不能继续伪造数字签名呢？不可能，因为没有数字证书对应的私钥。

所以，如果要重新打包后的应用程序能再Android设备上安装，必须对其进行重签名。

结论：只要修改了Apk中的任何内容，就必须重新签名，否则会提示安装失败！

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

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

点击下载

3.3 使用说明

解压下载包

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

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

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

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

java -jar ApkSigner.jar [-appname test] -keystore keystorePath -alias alias [-pswd password] [-aliaspswd aliasPassword] -v1 true -v2 false in.apk
zipalign -c -f [alignmentSize] in.apk out.apk (可选)
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.4 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.4.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.4.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.4.3 v2 签名相对 v1 签名的优点

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

3.4.4 v3 签名

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

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

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

在这里插入图片描述

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

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

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

3.4.5 v4 签名

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

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

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

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

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

官方文档：v4签名

3.4.6 总结

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

3.4.7 小结

如果想无缝升级一个应用，Android系统要求应用程序的新版本与老版本具有相同的签名与包名。若包名相同而签名不同，系统会拒绝安装新版应用。

若APK签名策略由V1升级至V1+V2+V3，且升级前后的APP签名与包名保持一致，则可以做到无缝升级。

按照以下步骤实现APK签名、校验。

apksigner签名（签名结果：V1+V2+V3）

apksigner sign --ks android.jks --ks-key-alias android --out signed.apk unsigned.apk

查看签名文件
```
keytool -v -list -keystore xxx.jks
```

查看apk 签名

keytool -printcert -jarfile ./weixin806android1900_arm64.apk

签名策略校验
```
apksigner verify --verbose signed.apk
```
查看apk的基本配置信息（packageName、versionCode等info）
```
aapt dump badging test.apk
```

3.5 jarsigner 与 apksigner

3.5.1 jarsigner

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

比如我的 jarsigner 工具的位置在

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

效果图如下：

在这里插入图片描述

3.5.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 以下的系统版本。

为方便应用apksigner签名，可将apksigner径配置到系统环境变量path。实现步骤如下：

cd ~
open -e .bash_profile
source .bash_profile

.bash_profile文件内容如下：

source ~/.bashrc

# Git branch in prompt.

parse_git_branch() {

    git branch 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/ (\1)/'

}

export PS1="\u@\h \W\[\033[32m\]\$(parse_git_branch)\[\033[00m\] $ " 

source ~/.bashrc

export ANDROID_HOME=/Users/ccms-m-03/Library/Android/sdk
export PATH=${PATH}:${ANDROID_HOME}/tools
export PATH=${PATH}:${ANDROID_HOME}/platform-tools

export AAPT_HOME=/Users/ccms-m-03/Library/Android/sdk/build-tools/30.0.3
export PATH=$PATH:$AAPT_HOME

source ~/.bashrc

apksigner通过以下指令实现apk签名。

apksigner sign --ks android.jks --ks-key-alias android --out signed.apk unsigned.apk

--ks .jks文件路劲
--ks-key-alias 签名文件别名
--out 输出签名后的目标路径
unsigned.apk 未签名的原始apk文件路径

为了避免路径过长，书写错误的、问题，建议将加固包jks文件放置在同一目录。

在这里插入图片描述

其实从文件的大小我们就可以看到有变化，但是还得验证是否签名成功，用以下指令校验：

 apksigner verify --verbose signed.apk

签名成功如下图：

在这里插入图片描述

没有签名如下提示：

在这里插入图片描述

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

注⚠️：通过apksigner可视化工具签名后的签名方案为V1，用apksigner sign --ks android.jks --ks-key-alias android --out signed.apk unsigned.apk命令行签名后的签名方案为V1+V2+V3!

3.5.3 查看 Android 和 iOS 打包时间

3.5.3.1 查看 Android .apk 打包时间

解压后可查看META-INF下.RSA、 .SF、 .MF等文件的日期就是打包日期。

在这里插入图片描述

3.5.3.2 查看 iOS .ipa 打包时间

ios 可以查看 info.plist 文件的时间。
在这里插入图片描述

3.5.4 签名文件 jks 与 keystore 格式

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

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

3.5.4.1 jks 转 keystore

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

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

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

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

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

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

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

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

3.5.4.2 keystore 转 jks

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

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

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

3.6 签名验证

应用签名工具对APP做好签名后，如何验证签名的正确性，或者是给你一个apk，如何验证该apk是否完成了签名操作。

3.6.1 查看apk 签名

应用 keytool 工具可实现文件签名验证。

keytool -printcert -jarfile ./weixin806android1900_arm64.apk

若apk为已签名，则会显示以下信息：

在这里插入图片描述

若apk未签名，则会提示不是已签名的 jar 文件。

拓展阅读：KeyTool是Java中的数字证书管理工具，用于数字证书的申请、导入、导出和撤销等证书管理操作，位于<JAVA_HOME>\bin\keytool.exe。要获得数字证书需要使用数字证书管理工具（如KeyTool和OpenSSL)构建CSR(Certificate Signing Request，数字证书签发申请)，交由CA机构签发，形成最终的数字证书。

3.6.2 查看签名文件

同样使用 keytool 工具查看 xxx.keystore 或者 xxx.jks，注意查看自己的签名文件则需要密码输入才能查看。根据以下命令输出信息，通过对比apk签名输出的MD5、sha信息是否一致，一致则代表签名成功。

keytool -v -list -keystore xxx.jks

四、APP 信息校验

APP组好包之后，如何查看包信息？

4.1 APK 信息查看

首先找到aapt工具，在Android SDK文件夹下的build-tools包里应用aapt命令便可实现查看Android APK信息。

或者将aapt命令添加到环境变量。

然后，通过aapt命令便可查看apk包的packageName、versionCode、applicationLabel、launcherActivity、permission等各种详细信息

先 cd 到 apk 所在目录，然后执行以下命令：

查看apk的基本配置信息

aapt dump badging test.apk

在这里插入图片描述

查看apk的权限

aapt dump permissions test.apk

在这里插入图片描述

查看apk的资源列表

aapt dump resources test.apk

在这里插入图片描述

一般都会输出很多的信息，如要全部查看，请用下面这个命令：

aapt dump resources test.apk   > test.txt

这样会把所有的信息通过重定向符">"输出到test.txt文件中，然后再打开该文件即可查看。

查看apk配置信息

aapt dump configurations test.apk

在这里插入图片描述
查看指定apk的指定xml文件，以树形结构输出的xml信息

aapt dump xmltree test.apk res/***.xml

输出xml文件中所有的字符串信息

aapt dump xmlstrings test.apk res/***.xml

4.2 versionCode 与 versionName

4.2.1 versionCode

主要是用于版本升级所用，是Integer类型的，第一个版本定义为1，以后递增，这样只要判断该值就能确定是否需要升级，该值不显示给用户。

不要将versionCode设置的太大，最好不要超过Integer的取值范围，一般大发布第一个应用到市场的时候，版本取值为1（versionCode=1），这也是目前典型和普遍的做法。

每次发布更新版本时可以递增versionCode的值，一个新版本的应用的versionCode不能小于之前旧版本的versionCode值，否则进行替换更新升级时会出错，系统提示无法安装。这也不是强制的，只是正式发布应用时，建议必须考虑的问题。

注意⚠️：同一个APP低版本是不能直接覆盖安装手机中已存在的高版本应用（通过版本号(versionCode)来判断）。

4.2.2 versionName

这个是我们常说的版本号，这是一个值为String类型的属性，由三部分组成<major>.<minor>.<point>。VersionCode是方便程序开发者运行和维护Application而设置的一个有效值。versionName是一个版本的描述，给用户看的，也是用户放在各个第三方平台上提供给使用者看的一个版本名，可以说是对VersionCode的解释和描述。
其中，

major 是主版本号，一般在软件有重大升级时增长；
minor 是次版本号，一般在软件有新功能时增长；
maintenance 是维护版本，一般在软件有主要的问题修复后增长；

4.3 ipa 信息查看

解压IPA安装包文件，然后通过打开APP的信息文件：info.plist 来查看名称、Bundle ID、版本等基本信息，如果要查看证书文件名称，那就需要通过命令行工具：security 来查看描述文件：embedded.mobileprovision。在这里插入图片描述

在这里插入图片描述

4.4 查看应用签名信息

在第三方平台填的应用签名是不一样的，第三方平台填的签名信息是32位的。

注⚠️：应用签名由开发者签名该应用的.keystore文件决定。

使用签名生成工具查看该应用的签名:

任意下载一个(是一个apk文件)安装手机后运行：

在这里插入图片描述

五、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的要求。

5.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，确保在模拟器正常运行；

5.2 配置支持的CPU类型

5.2.1 可视化界面配置

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

5.2.2 源码视图配置

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

5.2.2.1 uni-app项目

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

  "app-plus": {
    "distribute": {
      "android": {
        "abiFilters": [
          "armeabi-v7a",
          "arm64-v8a"
        ]
        //...
      },
      //...
    },
    //...
  },
  //..

4.2.2.2 离线打包配置

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

defaultConfig{
	ndk {
            abiFilters 'arm64-v8a','armeabi-v7a'
        }
}

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

5.3 CPU类型

5.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指令。

5.3.2 查看apk支持的CPU类型

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

在这里插入图片描述

5.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]

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

在这里插入图片描述