Apk转Aab(Android App Bundle)

Posted 2023-04-07

参考技术A

根据 Google Play的政策 要求，自 2021 年 8 月起，Google Play 将开始要求新应用使用 android App Bundle（以下简称aab） 进行发布。该格式将取代 APK 作为标准发布格式

正常情况下直接用AS的打包生成aab就可以满足需求，上传到Google play了。

但是会有这么一个问题，并不是所有时候你都可以拿到一个游戏工程或者源码的，如果给你的是一个apk包，那你怎么办呢？

接下来，就向大家介绍如何从apk一步步转化成aab。

解压apk

通过apktool去解压apk包

解压apk后 decode_apk_dir 目录结构：

编译资源

编译资源使用aapt2编译生成 *.flat文件集合

生成compiled_resources.zip文件

关联资源

生成base.apk

解压base.apk

解压到base文件夹，目录结构：

拷贝资源

创建base文件夹，以base文件夹为根目录

将解压得到的resources.pb拷贝到 ./temp/base/resources.pb

将解压得到的res拷贝到 ./temp/base/res

创建manifest文件夹， 将解压得到的AndroidManifest.xml拷贝到 ./temp/base/manifest

拷贝assets , 将 ./temp/decode_apk_dir/assets 拷贝到 ./temp/base/assets

拷贝lib， 将 ./temp/decode_apk_dir/lib 拷贝到 ./temp/base/lib

创建root文件夹，拷贝unknown， 将 ./temp/decode_apk_dir/unknown 拷贝到 ./temp/base/root/unknown

拷贝kotlin， 将 ./temp/decode_apk_dir/kotlin拷贝到 ./temp/base/root/kotlin

root目录下创建META-INF文件夹，得到 ./temp/base/root/META-INF

创建dex 文件夹，将 ./temp/decode_apk_dir/*.dex拷贝到 ./temp/base/dex（多个dex都要一起拷贝过来）

最终的目录结构

压缩资源

将base文件夹，压缩成base.zip 一定要zip格式

注意：压缩后双击打开显示的是所有资源，而不是显示base，点击base再显示所有资源；否则会报AndroidManifest.xml找不到的错

编译aab

打包app bundle需要使用bundletool

aab签名

注意 ：您不能使用 apksigner 为 aab 签名。签名aab的时候不需要使用v2签名，使用JDK的普通签名就行。

限于篇幅，Aab的测试与安装放在下一篇文章
详见 Aab(Android App Bundle)测试与安装

过程中有问题或者需要交流的同学、独立开发者同学、都可以私信我拉群（加好友的备注下，因为Apk转Aab和独立开发俱乐部，是分开的两个群）

AAB 扶正！APK 将退出历史舞台

Google 自8月起要求 Google Play 上架的应用必须采用 AAB 的新格式，对我来说这并非新闻，早在去年12月份官方就提前做了通知：

https://android-developers.googleblog.com/2020/11/new-android-app-bundle-and-target-api.html

令我惊讶的是，这样一条“旧闻”最近却被炒得沸沸扬扬，原来竟还是因为蹭了鸿蒙的热度：

要知道 AAB 的首次亮相是在2018年的 GoogleI/O 上，难道彼时谷歌就遇见到鸿蒙的出现了？

不过客观来说，AAB 虽然早已出现，但在国内很少被提及，因此造成部分媒体的错误解读也有情可原。那么本文就为大家做一个关于 AAB 的科普，打消鸿蒙支持者们的顾虑。

Android App Bundle

---

Android App Bundle（简称AAB） 是 Google 2018年推出的一种动态化的打包方式。当应用程序以 AAB 的格式上传 Google Play（或其他支持 AAB 的应用市场）后，可以根据不同用户实现 features 或者 resources 的按需下发。Google Play (简称GP) 目前提供的动态化服务都是基于 AAB 实现的（不少文章说这些服务是 AAB 的，这种说法不严谨，准确的说是 GP 的）

• Play Feature Delivery（PFD) ：借助 AAB 实现 Feature 的按需动态加载，这类似于国内流行的“插件化”技术
• Play Asset Delivery (PAD) ：借助 AAB 实现一些资源素材的按需动态下载，这特别适合一些游戏类APP，无需为了适配所有机型保留全部游戏素材

除了游戏资源以外，对于常规资源，AAB 也可以做到按需下发。例如无需同时存在 hdpi、xhdpi 等多套图片，不少 APP 因此在包大小方面有显著提高：

更小的包体积意味着更高的装机率，这在用户推广成本激高的今天至关重要：

App Bundle 文件格式

---

我们先来看一下 AAB 的文件格式，与传统的 APK 有何不同

解压后的 AAB 中的内容和 APK 很相似，但又有不少区别：

aab fiels	descriptions
base/feature1/feature2	base 是应用的基本功能，feature 承载各 DynamicFeature 的内容（后文介绍）
manifest.xml	APK 中只有一个 manifest 且是二进制格式，AAB 会存在于每个模块中e中，且使用 ProtoBuf（pb）格式，便于处理
dex	与 APK 不同，AAB 将每个模块的 dex 文件存储在各自目录中
res/assets/libs	该目录与 APK 中相同，当上传 AAB 时，GP 会检查这些目录并仅打包满足目标设备需要的最小文件
resources.pb	类似于 resource.arsc 文件，是一个资源索引表，其中描述了应用程序内部存在的资源和目标的细节，可用于 GP 针对不同设备配置 APK。
assets.pb	相当于应用程序 assets 的资源表，可用于 GP 针对不同设备配置 APK。例如将 assets 资源放到 assets/languages#lang_xx 或 assets/i18n#lang_xx 路径下，则会根据语言配置下发 assets 资源。
native.pb	这相当于native库的资源表，可用于 GP 针对不同设备配置 APK

后三个.bp文件是 AAB 格式的重要部分，它们描述了 APP 的不同服务目标，动态下发根据这些目标从 drawable/hdpi、lib/armeabi-v7a 或者 values/es 等路径中组织不同资源进行下发。

Split APKs

---

Split APKs 机制是 AAB 实现动态下发的基础，它允许将一个庞大的 APK 按不同维度拆分成独立的 APK，当用户在 GP 下载应用时，Android Framework 通过 IPC 与 GP 通信，为当前设备匹配并下载最小构成的 APK, 这只在 Android 5.0 以上的设备才有效。

AAB 上传后，GP 通过分析找出所有设备的共同资源, 生成一个 Base APK，当用户下载应用时，Base APK 将被首先安装。

GP 又根据language、density、abi 等三个维度，分别生成 Configuration APKs（Splits）， Splits 与 Base 共享 versionCode 、packageName等，在进程管理器中以一个应用的形式存在。

当用户从市场下载应用时，GP 根据设备类型，为其下发不同的 Splits，实现最小化下发。

如下图，针对三种不同设备下发不同 Splits

当用户的设备发生 Configuration Changed （比如切换了系统语言）时，GP 会下发新的 Splits 到手机，如果此时手机不在线会等待下次上线时自动下发。

Split APKs 的这种动态下发只能用于 Android 5.0 以上设备，对于更旧的设备，AAB 会根据 这些 Splits 的矩阵生成多个 Standalone 的 APK，虽然缺少了动态下发的能力必须一次安装到位，但是相对于传统 APK 仍然减小了一定包大小。

作为开发者，我们无需关心这些具体的下发策略，只需要向市场上传一个 AAB ，后续就交给 FW 和 GP 去处理了。

创建 App Bundle

---

打包 AAB

使用 Android Studio 可以方便地打包 AAB

此外，也可以使用 Gradle 命令打包，这更适用于一些 CI 流程中。

如下使用 gradle 打包一个 debug 版的 AAB

./gradlew :base:bundleDebug

如果要生成 release 的 AAB 需要配置签名，与 APK 的配置方式是一样的。

AAB 默认会为三种 Configurations 都生成 Splits，当然你可以根据需求自己配置：

bundle {
        language {
            enableSplit = false
        }
        density {
            enableSplit = true
        }
        abi {
            enableSplit = true
        }
    }

上传应用市场

生成 AAB 后就可以上传应用市场了，GP 中上传 AAB 和 APK 的入口在一起，当然 8 月以后就没有 APK 的上传入口了。

AAB 上传后，通过后台可以查看其详细信息

例如可以查看 AAB 支持的屏幕密度，以及包体积的减少等信息

Bundle Tool

---

AAB 是无法直接安装到手机的，如果想本地对 AAB 做测试，需要将 AAB 转成 APK，这需要使用 Google 官方提供的 Bundletool 工具

Bundletool 可以获取当前设备信息

bundletool get-device-spec --output=/tmp/device-spec.json

设备的 Configurations 信息输出到指定 json 中

{
  "supportedAbis": ["arm64-v8a", "armeabi-v7a", "armeabi"],
  "supportedLocales": ["zh-CN"],
  "deviceFeatures" : // ...
  "screenDensity": 480,
  "sdkVersion": 28
}

Bundletool 根据 json 生成 .apks 中间文件

bundletool build-apks 
--bundle=/MyApp/my_app.aab 
--output=/MyApp/my_app.apks 
--ks=/MyApp/keystore.jks
--ks-pass=file:/MyApp/keystore.pwd
--ks-key-alias=MyKeyAlias
--key-pass=file:/MyApp/key.pwd
--device-spec=file:device-spec.json

apks 的产物分为 splits 和 standalones 两个目录，splits 是按照 Configuration维度拆分的 Split APKs，必须依赖 base.apk 一起安装；standalone 必须独立安装，这是为了兼容 Android 5.0 以下的版本。

toc.pb 是 apks 的存档清单，包含 APK 集合信息的描述文件

然后再根据 json 文件，从 apks 中提取 apk ：

bundletool extract-apks 
--apks=${apksPath} 
--device-spec={deviceSpecJsonPath} 
--output-dir={outputDirPath}

最后，通过 Bundletool 将 apk 安装到手机上。 注意该命令实际安装 apk 并非 apks

bundletool install-apks --apks=/MyApp/my_app.apks

总结一下 Bundletool 生成 APK 的整体流程：

创建 Dynamic Feature

---

除了下发 Configuration APKs，还可以以业务模块为单元“插件化”地动态下发，也就是所谓的 Dynamic Features（简称 DF）

IDE 中选择 New 一个 DF 的 Module：

点击 next，选择 DF 的安装时机，例如一次安装到位或是按需安装

创建好的 DynamicFeature Module， 目录和一个普通的 Gadle Module 类似

但是 build.gradle 中 plugin 有所不同：com.android.dynamic-feature

plugins {
    id 'com.android.dynamic-feature'
    id 'kotlin-android'
}

build.gradle 中也无需配置 versionCode、versionName、signConfig等，DF 本质上也是 Split APKs，所以共享 Base APK 的这些信息。

此时再打开 app/ 的 build.gradle，会发现多了如下配置

dynamicFeatures = [':dynamicfeature']

这是 APP 当前支持的所有 DF 的声明

最后，DF 的 Manifeset 也发生了变化：

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:dist="http://schemas.android.com/apk/distribution"
    package="com.github.dynamicfeature">

    <dist:module
        dist:instant="false"
        dist:title="@string/title_dynamicfeature">
        <dist:delivery>
            <dist:on-demand />
        </dist:delivery>
        <dist:fusing dist:include="true" />
    </dist:module>
</manifest>

• dist:delivery: 在创建 Dynmaic Feature 的 Module 时选择的下发方式， onDemand 表示方式为按需下发
• title：当用户确认下载 Module 时，标识相关名称
• fusing include：设为 ture，意味着 5.0 以下的设备可以以 multi-APK 的形式安装此 Feature，此时必须设置为 onDemand 方式。

安装 Dynamic Feature

---

当应用支持 DF 之后，我可以按需的请求并安装这些 Features，这需要集成 Play Core SDK

implementation 'com.google.android.play:core:$latest_version'

Play Core 允许用户通过交互的方式请求 DF 的下载安装，并监听下载状态

发起下载请求

DF 的下载需要借助 SplitInstallManager

SplitInstallManager splitInstallManager =
    SplitInstallManagerFactory.create(context);

创建 SplitInstallRequest， 请求下载 Module

//动态请求模块
SplitInstallRequest request =
    SplitInstallRequest
        .newBuilder()
        .addModule("someDynamicModule")
        .build();

addModule() 可以多次调用，添加多个请求的 DF

使用 SplitInstallManager 启动 Request 进行请求，并设置回调监听为下载状态

splitInstallManager
        .startInstall(request)
        .addOnSuccessListener {  }
        .addOnFailureListener {  }
        .addOnCompleteListener {  }

startInstall() 调用后会立即发起请求。另外还可以使用 deferredInstall 延迟请求, 当应用切到后台启动时才开始请求。

splitInstallManager
      .deferredInstall(Arrays.asList("someDynamicModule"));

除了请求指定 DF 以外，也可以请求指定的资源，比如安装语言资源

SplitInstallRequest request =
    SplitInstallRequest.newBuilder()
        .addLanguage(Locale.forLanguageTag(sharedPrefs.getString(LANGUAGE_SELECTION)))
        .build();

发起请求后，会返回一个 Int 值作为 session ID，通过调用 cancelInstall(Int), 可以取消当前的下载。

发起请求后，可能无法正常建立链接，此时会返回错误信息如下

Error	Descriptions
ACCESS_DENIED	鉴于当前设备的某些原因，无法下载
ACTIVE_SESSIONS_LIMIT_EXCEEDED	当前应用的请求 session 太多
API_NOT_AVAILABLE	请求 API 目前无法使用
INCOMPATIBLE_WITH_EXISTING_SESSION	请求的 session 中包含了已经请求中的 DF
INTERNAL_ERROR	内部错误
INVALID_REQUEST	无效请求
MODULE_UNAVAILABLE	请求的 DF 不存在
NETWORK_ERROR	网络错误
NO_ERROR	无法获得错误信息
SERVICE_DIED	服务无响应
SESSION_NOT_FOUND	无法获取被请求的 session

下载安装

成功建立了连接后，便进入下载、安装阶段。使用 SplitInstallStateUpdatedListener 能够监听下载安装的状态，可以根据这些状态为对下载进度等进行用户提示

val stateListener = SplitInstallStateUpdatedListener { state ->
    when (state.status()) {
        PENDING -> { }
        DOWNLOADING -> { }
        DOWNLOADED -> { }
        INSTALLED -> { }
        INSTALLING -> { }
        REQUIRES_USER_CONFIRMATION -> { }
        FAILED -> { }
        CANCELING -> { }
        CANCELED -> { }
    }
}
splitInstallManager.registerListener(stateListener)

State	Description
CANCELED	下载被取消
CANCELING	下载取消中
DOWNLOADED	下载完成，但是尚未安装
DOWNLOADING	下载即将完成
FAILED	下载或安装失败
INSTALLED	成功安装
INSTALLING	安装中
PENDING	下载等待中
REQUIRES_USER_CONFIRMATION	等待用户确认
UNKNOWN	未知

卸载模块

成功安装后，通过 getInstalledModules 可以获取所有已安装的 Module

val installedModules = splitInstallManager.installedModules

另外，通过 deferredUninstall 可以对 DF 进行指定卸载

splitInstallManager
        .deferredUninstall(listOf("someDynamicModule"))
        .addOnSuccessListener {  }
        .addOnFailureListener {  }
        .addOnCompleteListener {  }

AAB 使用效果

---

根据 Google 官方的数据，AAB 比 APK 的包大小平均会减小 20% ，这同时意味着节省了 20% 的下载流量。 以 Twitter 为例，采用 AAB 之后

• language 相关资源节省 95%
• density 相关的 Splits 节省 45%
• abi 相关资源节省 20%

除了包大小方面的优势以外，使用 AAB 在开发效率上也有收益，无需再针对不同目标点设备，配置多个 Flavor、生成多个 APK 并分别上传，只要上传一个 AAB，剩下的事情交由应用市场去做就好了。

国内的 AAB 使用

---

Qigsaw 是爱奇艺提供的一套基于 Android App Bundle 的动态化方案，无需 Google Play Service 即可在国内体验 Android App Bundle 开发工具。它支持动态下发插件 APK，采用单类加载器方式，让应用能够在不重新安装的情况下实现动态安装插件。

此外，华为应用市场也早就支持了 AAB 的上传和动态下发，所以不要再说 AAB 是打压华为的产物了 😅

https://developer.huawei.com/consumer/cn/doc/distribution/app/agc-help-releasebundle-0000001100316672