AAB — 概要、APKとの違い、動作原理

AABとは

AAB（Android App Bundle）は、Google Playを通じて配信するためにGoogleがAPKの代替として開発した公開形式です。AABの中身は.aab拡張子のZIPアーカイブで、コンパイルされたコード、リソース、メタデータが含まれています。主な違いは、AABはデバイスに直接インストールされないことです。

仕組み

開発者はAABをGoogle Play Consoleにアップロードします。ユーザーがアプリケーションをインストールしようとすると、Google Playはデバイスの構成（画面密度（DPI）、CPUアーキテクチャ、言語、Androidバージョン）を分析します。この分析に基づいて、必要なコンポーネントのみを含む最小限のAPKが生成されます。

採用の経緯

Googleは2018年のI/OカンファレンスでAABを発表しました。2021年8月以降、Google Play上のすべての新しいアプリケーションでこの形式が必須になりました。既存のアプリケーションはAPKを引き続き使用できますが、新しいアプリケーションはAABでのみ公開する必要があります。

AABとAPKの違い

AABとAPKの違いは基本的なものです。APKはインストール準備ができた完全なインストールファイルです。AABは処理が必要なソースコンポーネントを含むコンテナです。

APKはGoogle Play以外での配信（ウェブサイト、メール、企業MDMシステム）に適しています。AABはGoogle Playのインフラストラクチャに依存しており、直接インストールできません。AABのテストにはbundletoolツールを使用し、ローカルマシンでAPK生成をエミュレートします。

AABファイルの構造

AABの内部構造はAPKに似ていますが、モジュールとその依存関係を記述するための追加のディレクトリとファイルが含まれています。

ベースモジュール（base）

baseモジュールはAABの必須コンポーネントです。メインのコード、リソース、アプリケーションマニフェストが含まれています。ベースモジュールなしではアプリケーションをビルドできません。他のすべてのモジュールはオプションで、Dynamic Deliveryを介して接続されます。

Protobuf形式

AABの設定はXMLの代わりにProtocol Buffers（protobuf）を使用します。.pbファイルはよりコンパクトで、Googleのサーバーインフラストラクチャによって高速に解析されます。bundletoolツールはデバッグ用にprotobufを読み取り可能な形式に変換します。

Dynamic Deliveryとアプリケーションモジュール

Dynamic DeliveryはAABの基盤となる主要技術です。これにより、ユーザーのデバイスと言語に一致するアプリケーションの部分のみを配信し、必要に応じて追加モジュールをロードできます。

モジュールの種類

Install-timeモジュールはインストール時にベースAPKとともにロードされます。Conditionalモジュールは条件が満たされた場合にのみ配信されます（例：4K画面用の素材を含むモジュール）。On-demandモジュールはアプリケーション内でユーザーの要求に応じてロードされます。

Play Asset Delivery（PAD）

大きなリソース（最大2GB）には、OBBファイルの代わりにPlay Asset Deliveryが使用されます。PADは同じ3つの配信モード（install-time、fast-follow（インストール直後）、on-demand）をサポートしています。

// SplitInstallManagerによるオンデマンドモジュールのロード
val manager = SplitInstallManagerFactory
    .create(context)

val request = SplitInstallRequest
    .newBuilder()
    .addModule("level_pack_3")
    .build()

manager.startInstall(request)
    .addOnSuccessListener {
        Log.d("AAB", "Module installed")
    }

Gradleでのモジュール設定

各動的モジュールは、配信タイプを指定した個別のbuild.gradleファイルで記述されます。モジュールはベースアプリケーションから独立した独自のリソース、コード、マニフェストを持つことができます。

GradleによるAABのビルド

AABのビルドは、Android Gradle PluginのbundleRelease（またはbundleDebug）タスクで実行されます。結果はbuild/outputs/bundle/ディレクトリに.aabファイルとして出力されます。

ビルド設定

AABのビルドに特別な設定は必要ありません。Android Gradle Pluginはデフォルトでバンドルをサポートしています。assembleの代わりにbundleタスクを指定するだけです。

// build.gradle.kts — 署名付きAABビルド
android {
    bundle {
        language {
            enableSplit = true
        }
        density {
            enableSplit = true
        }
        abi {
            enableSplit = true
        }
    }
}
// タスク: ./gradlew bundleRelease

bundletoolによるローカルテスト

GoogleはローカルマシンでAABからAPKを生成するためのbundletoolツールを提供しています。`bundletool build-apks --bundle=app.aab --output=app.apks`コマンドは、さまざまなデバイス構成でテストするためのAPKセットを作成します。

bundletoolはAABの解凍、設定の表示、Google Play Consoleにアップロード前の署名整合性の確認も行えます。デバッグには`bundletool dump manifest --bundle=app.aab`コマンドを使用してベースモジュールのマニフェストを表示します。

AABのスプリット設定

デフォルトでは、AABはリソースを3つの次元（言語、画面密度（density）、CPUアーキテクチャ（abi））で分割します。開発者はbuild.gradleで任意の分割を無効にできます（例：アプリケーションが英語のみをサポートする場合）。分割を無効にすると、すべてのバリアントのリソースがベースAPKに含まれます。

リソース最適化 — AABは自動的にPNGを品質損失なくWebPに変換し、未使用のリソースを圧縮し、重複する文字列を削除します。これらの最適化は、最終的なAPK生成時にGoogle Play側で適用されます。その結果、ユーザーは完全なアーカイブより15～25%小さいAPKを受け取ります。

Google PlayへのAAB公開

Google Play ConsoleでのAAB公開プロセスは、アップロードするファイルの形式のみがAPKと異なります。コンソールは.aabを受け入れ、その構造、署名、モジュール設定を確認した後、各デバイスタイプのAPKを生成します。

App Signing by Google Play

AABをアップロードすると、Google Playが署名鍵の管理を引き受けます。開発者はupload鍵で署名されたパッケージをアップロードし、Googleは生成されたAPKを自身の鍵で再署名します。これにより、鍵のローテーションとkeystore紛失時のアクセス復旧が簡素化されます。

リリース前のテスト

Google Play Consoleには組み込みのAABテスト機能があり、特定のデバイス向けに生成されたAPKをダウンロードしたり、Internal Testing、Closed Alpha、Open Betaのトラックを通じて内部テストを実行したりできます。

一般的なAABの問題と解決策

AABへの移行は、特に動的モジュールが多いプロジェクトやリソース設定が複雑なプロジェクトで問題を引き起こす可能性があります。

モジュール設定エラー

動的モジュールがベースモジュールのリソースを誤った名前で参照している場合、Google Playは検証段階でAABを拒否します。解決策は、ビルド前にlintチェックを使用し、すべてのモジュールをbundletoolでローカルテストすることです。

言語分割とパフォーマンスへの影響

言語による分割は、現在のロケールのリソースが動的にロードされる場合、アプリケーションの起動を遅くする可能性があります。Googleの推奨は、10未満の言語の場合は分割しないか、最も人気のある言語にはinstall-timeを使用することです。

サードパーティSDKとの互換性

一部のSDK（分析、広告、マップ）は完全なマニフェストとリソースへのアクセスを必要とします。移行前のAAB互換性の確認は必須のステップです。主要なSDK（Firebase、Google Ads、Crashlytics）は2022年以降、AABを完全にサポートしています。互換性の確認には--validateフラグ付きでbundletoolを使用し、サーバーサイドのAPK生成をエミュレートします。

AABのバージョニング

AABはベースモジュールのマニフェストからversionCodeを使用します。APKとは異なり、AABは各モジュールに個別のversionCodeもサポートしており、完全な再インストールなしでアプリケーションの個別部分を更新できます。Dynamic Deliveryはインストール済みモジュールを追跡し、Google Play経由の更新時に変更されたコンポーネントのみを配信します。

AABの監視と分析

Google Play Consoleは各AABの詳細な分析を提供します：生成されたAPK数、需要のあったスプリット、デバイスごとの平均ダウンロードサイズなど。Android Vitalsは生成されたAPKのパフォーマンスメトリクスを表示します。これらのデータはスプリット設定の最適化と、さまざまなデバイスカテゴリのダウンロードサイズ削減に役立ちます。