当前位置:网站首页>Android 应用安全机制实现方案探究

Android 应用安全机制实现方案探究

2022-08-06 07:11:54InfoQ

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

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

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

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

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

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

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

二、如何为 App 应用加固?

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

网易易顿加固截图信息:

null
顶象加固截图信息:

null
腾讯云加固截图信息(果然白嫖的不香~):

null
null
加固后效果如下:

null

三、APP签名

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

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

简单来说,APK 签名主要作用有两个:
  • 证明 APK 的所有者;
  • 允许 
    Android
     市场和设备校验 APK 的正确性。

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

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

点击下载

3.1 使用说明

  • 解压下载包
  • 命令行执行(需要
    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.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 签名。

null
缺点是:
不安全、速度慢

为了解决这些问题,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 分块 中。

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

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

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

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

null
从安全的角度 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 文件中,更改签名。

null
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

效果图如下:

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

效果图如下:

null
如果你用的是 
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="\[email protected]\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文件放置在同一目录。

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

 apksigner verify --verbose signed.apk

签名成功如下图:

null
没有签名如下提示:

null
签名后如果包能正确安装到手机(无需运行)则没有问题,如果安装失败请用命令安装:
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

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 -srckeystorecicc-keystore.keystore -destkeystore cicc-keystore.keystore-deststoretype pkcs12" 迁移到行业标准格式 PKCS12。

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

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

keytool -v -list -keystore test.keystore
3.3.3.1 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.4 签名验证

应用签名工具对APP做好签名后,如何验证签名的正确性,或者是给你一个apk,如何验证该apk是否完成了签名操作。
3.4.1 查看apk 签名
应用 
keytool
 工具可实现文件签名验证。

keytool -printcert -jarfile ./weixin806android1900_arm64.apk 

apk
为已签名,则会显示以下信息:

null
apk
未签名,则会提示
不是已签名的 jar 文件

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

null
查看apk的权限

aapt dump permissions test.apk

null
查看apk的资源列表

aapt dump resources test.apk

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

aapt dump resources test.apk > test.txt

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

查看apk配置信息

aapt dump configurations test.apk

null
查看指定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。

null
null

五、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类型:

null
5.2.2 源码视图配置
打开项目的
manifest.json
文件,切换到“源码视图”,根据项目类型进行配置。
5.2.2.1 uni-app项目
在 
&quot;app-plus&quot;->&quot;distribute&quot;->&quot;android&quot;
 节点的 
abiFilters
 属性配置支持的
CPU
类型,示例如下:

 &quot;app-plus&quot;: {
 &quot;distribute&quot;: {
 &quot;android&quot;: {
 &quot;abiFilters&quot;: [
 &quot;armeabi-v7a&quot;,
 &quot;arm64-v8a&quot;
 ]
 //...
 },
 //...
 },
 //...
 },
 //..
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类型,如下图所示:

null
5.3.3 常见问题
提交Google Play时要求支持64位,建议选择&quot;
armeabi-v7a
&quot;和&quot;
arm64-v8a
&quot;两个即可,也可以只选择&quot;
arm64-v8a
&quot;。

注意️:不要勾选&quot;x86&quot;!

如果打包选择的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拖到模拟器安装时会弹出如下提示框:

null
目前市面上常见的手机都是使用
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安全加固
原网站

版权声明
本文为[InfoQ]所创,转载请带上原文链接,感谢
https://xie.infoq.cn/article/b538f47c14b685f2b6f467d3c

随机推荐