AAB — apa itu, perbedaan dengan APK dan prinsip kerja

Apa itu AAB

AAB (Android App Bundle) — adalah format publikasi yang dikembangkan oleh Google sebagai pengganti APK untuk distribusi melalui Google Play. Di dalam AAB terdapat arsip ZIP dengan ekstensi .aab, berisi kode yang dikompilasi, sumber daya, dan metadata. Perbedaan utama: AAB tidak diinstal langsung di perangkat.

Prinsip kerja

Pengembang mengunggah AAB ke Google Play Console. Saat pengguna mencoba menginstal aplikasi, Google Play menganalisis konfigurasi perangkat: kerapatan layar (DPI), arsitektur CPU, bahasa, dan versi Android. Berdasarkan analisis ini, APK minimal dihasilkan yang hanya berisi komponen yang diperlukan.

Sejarah implementasi

Google memperkenalkan AAB pada tahun 2018 di konferensi I/O. Sejak Agustus 2021, format ini menjadi wajib untuk semua aplikasi baru di Google Play. Aplikasi yang ada masih dapat menggunakan APK, tetapi aplikasi baru harus dipublikasikan hanya dalam format AAB.

Perbedaan AAB dengan APK

Perbedaan antara AAB dan APK bersifat fundamental: APK adalah file instalasi lengkap yang siap diinstal. AAB adalah wadah dengan komponen sumber yang memerlukan pemrosesan.

APK cocok untuk distribusi di luar Google Play — melalui situs web, email, atau sistem MDM perusahaan. AAB terikat dengan infrastruktur Google Play dan tidak diinstal langsung. Untuk menguji AAB digunakan alat bundletool yang mengemulasikan pembuatan APK di mesin lokal.

Struktur file AAB

Struktur internal AAB mirip dengan APK, tetapi berisi direktori dan file tambahan untuk mendeskripsikan modul dan dependensinya.

Modul dasar (base)

Modul base — adalah komponen wajib AAB. Modul ini berisi kode utama, sumber daya, dan manifes aplikasi. Tanpa modul base, aplikasi tidak dapat dibangun. Semua modul lainnya bersifat opsional dan dihubungkan melalui Dynamic Delivery.

Format protobuf

Konfigurasi AAB menggunakan Protocol Buffers (protobuf) sebagai pengganti XML. File .pb lebih kompak dan diurai lebih cepat oleh infrastruktur server Google. Alat bundletool mengonversi protobuf ke format yang dapat dibaca untuk debugging.

Dynamic Delivery dan modul aplikasi

Dynamic Delivery — teknologi utama tempat AAB dibangun. Teknologi ini memungkinkan pengiriman hanya bagian aplikasi yang sesuai dengan perangkat dan bahasa pengguna, serta memuat modul tambahan berdasarkan permintaan.

Jenis modul

Modul Install-time dimuat bersama APK dasar saat instalasi. Modul Conditional dikirimkan hanya jika kondisi terpenuhi — misalnya, modul dengan materi untuk layar 4K. Modul On-demand dimuat berdasarkan permintaan pengguna di dalam aplikasi.

Play Asset Delivery (PAD)

Untuk sumber daya besar (hingga 2 GB) digunakan Play Asset Delivery sebagai pengganti file OBB. PAD mendukung tiga mode pengiriman yang sama: install-time, fast-follow (segera setelah instalasi) dan on-demand.

// Memuat modul on-demand melalui SplitInstallManager
val manager = SplitInstallManagerFactory
    .create(context)

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

manager.startInstall(request)
    .addOnSuccessListener {
        Log.d("AAB", "Modul terinstal")
    }

Konfigurasi modul di Gradle

Setiap modul dinamis dijelaskan dengan file build.gradle terpisah yang menentukan jenis pengiriman. Modul dapat memiliki sumber daya, kode, dan manifes sendiri, independen dari aplikasi dasar.

Membangun AAB melalui Gradle

Pembangunan AAB dilakukan melalui Android Gradle Plugin dengan tugas bundleRelease (atau bundleDebug). Hasilnya — file .aab di direktori build/outputs/bundle/.

Konfigurasi pembangunan

Untuk membangun AAB tidak diperlukan pengaturan khusus — Android Gradle Plugin mendukung bundel secara default. Cukup dengan menentukan tugas bundle sebagai pengganti assemble.

// build.gradle.kts — membangun AAB dengan tanda tangan
android {
    bundle {
        language {
            enableSplit = true
        }
        density {
            enableSplit = true
        }
        abi {
            enableSplit = true
        }
    }
}
// Tugas: ./gradlew bundleRelease

Pengujian lokal melalui bundletool

Google menyediakan alat bundletool untuk menghasilkan APK dari AAB di mesin lokal. Perintah `bundletool build-apks --bundle=app.aab --output=app.apks` membuat kumpulan APK untuk pengujian pada berbagai konfigurasi perangkat.

bundletool juga dapat membongkar AAB, menampilkan konfigurasinya, dan memeriksa integritas tanda tangan sebelum diunggah ke Google Play Console. Untuk debugging digunakan perintah `bundletool dump manifest --bundle=app.aab` yang menampilkan manifes modul dasar.

Konfigurasi pemisahan di AAB

Secara default, AAB membagi sumber daya berdasarkan tiga dimensi: bahasa (language), kerapatan layar (density), dan arsitektur CPU (abi). Pengembang dapat menonaktifkan pemisahan apa pun di build.gradle — misalnya, jika aplikasi hanya mendukung bahasa Inggris. Menonaktifkan pemisahan berarti sumber daya untuk semua varian akan masuk ke APK dasar.

Resource optimisation — AAB secara otomatis mengonversi PNG ke WebP tanpa kehilangan kualitas, mengompresi sumber daya yang tidak digunakan, dan menghapus string duplikat. Optimalisasi ini diterapkan di sisi Google Play saat menghasilkan APK akhir. Hasilnya, pengguna menerima APK 15–25% lebih kecil dari arsip lengkap.

Publikasi AAB di Google Play

Proses publikasi AAB di Google Play Console berbeda dari APK hanya dalam format file yang diunggah. Konsol menerima .aab, memeriksa struktur, tanda tangan, dan konfigurasi modulnya, setelah itu menghasilkan APK untuk setiap jenis perangkat.

App Signing by Google Play

Saat mengunggah AAB, Google Play mengambil alih pengelolaan kunci tanda tangan. Pengembang mengunggah paket yang ditandatangani dengan kunci upload, dan Google menandatangani ulang APK yang dihasilkan dengan kuncinya sendiri. Ini menyederhanakan rotasi kunci dan pemulihan akses jika keystore hilang.

Pengujian sebelum rilis

Google Play Console menyediakan pengujian AAB bawaan: Anda dapat mengunduh APK yang dihasilkan untuk perangkat tertentu atau menjalankan pengujian internal melalui track Internal Testing, Closed Alpha, dan Open Beta.

Masalah umum dengan AAB dan solusinya

Peralihan ke AAB dapat menyebabkan masalah, terutama pada proyek dengan banyak modul dinamis atau konfigurasi sumber daya yang kompleks.

Kesalahan konfigurasi modul

Jika modul dinamis merujuk ke sumber daya modul dasar dengan nama yang salah, Google Play menolak AAB pada tahap verifikasi. Solusinya — gunakan pemeriksaan lint sebelum pembangunan dan uji semua modul melalui bundletool secara lokal.

Pemisahan bahasa dan penurunan kinerja

Pemisahan berdasarkan bahasa dapat memperlambat startup aplikasi jika sumber daya untuk lokalisasi saat ini dimuat secara dinamis. Rekomendasi Google — jangan memisahkan bahasa jika jumlahnya kurang dari 10, atau gunakan install-time untuk yang paling populer.

Kompatibilitas dengan SDK pihak ketiga

Beberapa SDK (analitik, iklan, peta) memerlukan akses ke manifes dan sumber daya lengkap. Pemeriksaan kompatibilitas dengan AAB adalah langkah wajib sebelum migrasi. Sebagian besar SDK besar (Firebase, Google Ads, Crashlytics) mendukung penuh AAB sejak tahun 2022. Untuk memeriksa kompatibilitas, gunakan bundletool dengan flag --validate yang mengemulasikan pembuatan APK di sisi server.

Versi AAB

AAB menggunakan versionCode dari manifes modul dasar. Berbeda dengan APK, AAB juga mendukung versionCode terpisah untuk setiap modul — ini memungkinkan pembaruan bagian individu aplikasi tanpa instalasi ulang penuh. Dynamic Delivery melacak modul yang diinstal dan hanya mengirimkan komponen yang diubah saat pembaruan melalui Google Play.

Pemantauan dan analitik AAB

Google Play Console menyediakan analitik terperinci untuk setiap AAB: berapa banyak APK yang dihasilkan, pemisahan apa yang diminta, berapa ukuran unduhan rata-rata per perangkat. Android Vitals menunjukkan metrik kinerja APK yang dihasilkan. Data ini membantu mengoptimalkan konfigurasi pemisahan dan mengurangi ukuran unduhan untuk berbagai kategori perangkat.