APK vs AAB: Penjelasan Format Distribusi Android yang Baru
Apa Itu APK Sebenarnya (Dan Mengapa Ia Merajai Android Selama 15 Tahun)
Selama 15 tahun, Android Package Kit—APK—adalah satu-satunya pilihan yang ada. Ini telah menjadi standar untuk aplikasi Android sejak platform ini diluncurkan pada 2008. Sebuah APK sebenarnya hanyalah arsip ZIP dengan struktur internal yang sangat spesifik: isinya adalah AndroidManifest.xml yang sudah dikompilasi, bytecode DEX (classes.dex), tabel resources.arsc, serta folder untuk aset, library native, dan sumber daya mentah lainnya. Saat kamu mengambil aplikasi dari situs web atau mengirimnya ke teman pakai Bluetooth, kamu sedang mengirim satu file .apk yang berisi semua yang dibutuhkan untuk berjalan di perangkat Android mana pun. Pendekatan satu-ukuran-untuk-semua itu adalah kekuatan terbesar sekaligus kelemahan fatal APK. Satu APK dari Google Play Store harus mendukung segalanya, mulai dari Samsung Galaxy S25 Ultra dengan chip ARM 64-bit hingga ponsel Tecno murah dengan chip ARM 32-bit, ditambah Chromebook di prosesor x86 dan setiap kepadatan layar yang bisa dibayangkan. Untuk melakukan ini, developer harus memasukkan setiap versi dari setiap library native, string terjemahan, dan gambar untuk kepadatan layar yang berbeda ke dalam satu paket raksasa. Hasilnya? Aplikasi seperti Google Maps bisa mengirimkan APK berukuran 100 MB padahal perangkatmu hanya butuh sekitar 40 MB dari itu. Sisanya hanyalah beban mati—diunduh dan disimpan, tetapi tidak pernah digunakan.
Android App Bundle: Apa yang Berubah di 2018 dan Mengapa Google Mewajibkannya
Google akhirnya mengatasi masalah pembengkakan ukuran APK di Google I/O 2018 dengan Android App Bundle (AAB), dan mewajibkannya untuk aplikasi baru di Play Store pada Agustus 2021. Meskipun berekstensi .aab dan juga merupakan arsip ZIP, ini bukanlah aplikasi yang bisa di-install. Anggap saja ini resep dan sekotak bahan, bukan kue yang sudah jadi. Sebuah AAB berisi kode dan sumber daya yang telah dikompilasi dalam bentuk modul, tetapi server Google Play yang melakukan perakitan akhirnya. Proses ini disebut Dynamic Delivery. Saat pengguna menekan 'Install' di Play Store, server Google akan melihat perangkat spesifik mereka—arsitektur CPU (ABI), kepadatan layar, dan pengaturan bahasa. Kemudian, mereka membangun dan menyajikan satu set split APK yang disesuaikan yang hanya berisi apa yang dibutuhkan oleh perangkat tersebut. Sebuah Pixel 9 yang menjalankan Android 15 dalam bahasa Inggris mungkin akan mendapatkan unduhan 38 MB, sedangkan APK monolitik yang lama ukurannya bisa mencapai 95 MB. Pengurangan ukuran ini bukan cuma teori; ini signifikan dan terukur. Data Google sendiri pada tahun 2021 menunjukkan pengurangan ukuran rata-rata sebesar 15% untuk aplikasi yang beralih ke AAB, dengan beberapa aplikasi berhasil memangkas ukurannya lebih dari 50%. Untuk game dengan atlas tekstur raksasa yang dirancang untuk format kompresi GPU yang berbeda (seperti ETC2, ASTC, dan S3TC), penghematannya bisa sangat besar, dengan mudah memangkas ratusan megabita dari instalasi akhir di ponsel pengguna.
Struktur Internal File AAB
Kalau kamu coba buka file AAB dengan utilitas ZIP, kamu akan langsung melihat bahwa ini bukan APK. Di level paling atas, ada file BundleConfig.pb, yang mendefinisikan konfigurasi bundle, direktori BUNDLE-METADATA, dan setidaknya satu direktori modul. Modul utama selalu bernama `base/`, dan di dalamnya terlihat sedikit seperti APK, dengan folder `dex/`, `manifest/`, `res/`, `root/`, dan `lib/`. Tapi ada perbedaan penting: sumber daya disimpan dalam format proto `resources.pb`, bukan format biner datar `resources.arsc` seperti pada APK. Inilah alasan utama mengapa AAB tidak bisa di-install secara langsung. Modul fitur lainnya muncul di samping modul `base/`, dengan nama seperti `onboarding/` atau `ar_features/`. Masing-masing memiliki manifest dan sumber dayanya sendiri dan dapat diatur untuk diunduh saat instalasi, segera setelah instalasi (fast-follow), atau hanya saat dibutuhkan. Model on-demand inilah yang memungkinkan aplikasi seperti Google Earth menghindari membebani setiap pengguna dengan data kota 3D, dan mengambilnya melalui library Play Core hanya ketika seseorang benar-benar mencoba melihat kota dengan cakupan tersebut. Direktori `lib/` di dalam setiap modul adalah tempat keajaiban penghematan ukuran yang sesungguhnya terjadi. Sebuah game lintas platform mungkin memiliki subdirektori `arm64-v8a`, `armeabi-v7a`, dan `x86_64`, masing-masing diisi dengan library .so yang telah dikompilasi. APK monolitik akan menggabungkan semuanya. Dengan AAB, Dynamic Delivery memastikan hanya satu direktori ABI yang cocok yang dikirim. Untuk game dengan kode native 80 MB per ABI, itu berarti penghematan instan 160 MB pada ponsel 64-bit modern yang tidak memerlukan library 32-bit atau x86.
APK vs AAB: Perbandingan Langsung Hal-Hal yang Penting bagi Developer
Jadi, apa arti perbedaan ini dalam praktiknya bagi developer, QA, dan pengguna? Mari kita bedah perbandingannya berdasarkan apa yang benar-benar penting dalam pekerjaanmu sehari-hari. **Dukungan channel distribusi:** Google Play mewajibkan AAB untuk aplikasi baru. Sesimpel itu. Namun, AAB adalah teknologi khusus Google. Toko aplikasi Android alternatif seperti Amazon Appstore, Samsung Galaxy Store, Huawei AppGallery, dan F-Droid semuanya masih memerlukan APK konvensional. Jika kamu mendistribusikan aplikasimu di luar Google Play, kamu masih berkutat dengan APK. Ini bukan detail kecil, terutama di pasar di mana Google Play tidak tersedia dan distribusi hanya-APK adalah standarnya. **Instalasi langsung:** Kamu tidak bisa melakukan sideload AAB. Mencoba menginstalnya dengan `adb install app.aab` hanya akan menghasilkan error. Untuk menguji AAB secara lokal, kamu harus menggunakan `bundletool` dari Google untuk menghasilkan satu set APK lokal atau menggunakan flag `--local-testing` dalam build kamu. Siapa pun yang pernah mencoba meminta stakeholder non-teknis untuk menguji sebuah build tahu bahwa menambahkan langkah ekstra pasti bikin frustrasi. Ini jelas menambah hambatan pada alur kerja QA. **Tool untuk build:** Di Android Studio, kamu membuat AAB dengan Build > Generate Signed Bundle/APK > Android App Bundle, atau dengan task `./gradlew bundleRelease`. Kamu membuat APK dengan `./gradlew assembleRelease`. Sebagian besar tim menggunakan keduanya, membuat APK untuk pengujian internal dan AAB untuk unggahan akhir ke Play Store. **Ukuran file di disk:** Ini adalah poin yang sering menimbulkan kebingungan: file AAB-mu hampir selalu lebih besar dari APK-mu. APK 60 MB mungkin menghasilkan AAB 80 MB karena AAB berisi sumber daya untuk *semua* konfigurasi perangkat. Penghematan ukuran baru terlihat di perangkat pengguna setelah Google Play melakukan 'sihirnya'. **Model keamanan:** Kedua format ditandatangani (signed), tetapi prosesnya berbeda. Dengan AAB, kamu harus menggunakan Play App Signing. Ini berarti kamu mengunggah bundle-mu dan Google menandatangani ulang (re-sign) split APK final yang dihasilkannya dengan kunci yang mereka kelola. Meskipun kamu mendaftarkan kunci ini, pada akhirnya Google yang memegangnya, sebuah fakta yang membuat beberapa tim yang sadar keamanan menjadi was-was. Dengan APK, kamu bisa mengontrol seluruh proses penandatanganan dengan kuncimu sendiri, tanpa keterlibatan Google.
Mengubah Antara APK dan AAB: Apa yang Mungkin dan Tidak Mungkin
Di sinilah jawaban jujur lebih penting daripada janji-janji marketing. Mari kita blak-blakan: mengubah APK yang sudah ada kembali menjadi AAB itu mustahil, dan kamu harus sangat skeptis terhadap tool apa pun yang mengklaim bisa melakukannya secara otomatis. Masalahnya fundamental. Sebuah AAB membutuhkan informasi sumber asli—file sumber daya yang diatur rapi berdasarkan kepadatan layar dan bahasa, tabel sumber daya format proto, struktur modul. Semua data itu dikompilasi, diratakan, dan dioptimalkan hingga hilang saat sebuah APK dibuat. File `resources.arsc` dalam APK adalah sebuah binary blob; struktur folder `res/drawable-hdpi/` yang asli sudah tidak ada. Mencoba membangunnya kembali dari APK yang sudah dikompilasi bukanlah konversi; itu adalah proses reverse engineering yang menyakitkan, dan hasilnya hampir selalu tidak lengkap. CocoConvert dibuat untuk operasi APK-ke-APK. Kamu bisa menggunakannya untuk mengemas ulang, mengganti nama, dan, yang paling berguna, mengekstrak isi file APK untuk diperiksa. Unggah sebuah APK, dan kamu bisa menarik manifest-nya, melihat tabel sumber dayanya, atau mengambil aset tertentu. Tapi yang tidak bisa dilakukan CocoConvert adalah menghasilkan AAB yang valid dan siap untuk Play Store dari sebuah APK. Terus terang, tidak ada tool yang bisa melakukan ini dengan andal jika kamu tidak punya proyek source code aslinya. Jika kamu kehilangan source code dan hanya punya APK, pilihan terbaikmu adalah tool seperti `apktool`. Tool ini bisa melakukan decompile paket menjadi bytecode smali dan memberimu perkiraan sumber dayanya, tetapi mengubahnya kembali menjadi proyek yang layak untuk di-build menjadi AAB memerlukan pekerjaan manual yang sangat besar. Kegunaan CocoConvert yang *sebenarnya* adalah untuk tugas-tugas yang sering muncul dalam riset QA dan keamanan seluler. Kamu bisa mengubah APK menjadi file ZIP untuk menelusuri isinya, mengekstrak gambar atau file audio tertentu, dan bahkan memproses seluruh folder APK secara batch untuk mengauditnya. Inilah pekerjaan praktis di dunia nyata yang bisa kami bantu.
Masalah Sideloading dan Mengapa APK Tidak Akan Hilang
Meskipun Google gencar mendorong penggunaan AAB, APK yang sederhana ini tidak akan hilang. Daya tahannya berasal dari semua kasus penggunaan yang ada sepenuhnya di luar kendali Google. Sideloading—menginstal APK dari luar Play Store—adalah fitur inti Android, yang diaktifkan dengan cukup membuka pengaturan ponselmu (biasanya di bawah Settings > Apps > Special App Access > Install Unknown Apps, meskipun jalurnya bervariasi). Dan ekosistem sideloading sangat besar. APKMirror menyediakan APK terverifikasi dari aplikasi Play Store, memungkinkan pengguna mendapatkan pembaruan sebelum peluncuran bertahap mencapai mereka atau menginstal versi yang lebih lama. Alat Enterprise Mobile Device Management (MDM) dari VMware dan Microsoft mengirimkan APK ke ribuan perangkat perusahaan tanpa pernah menyentuh Play Store. Komunitas modding game sangat bergantung pada APK yang dimodifikasi. Bagi developer di wilayah dengan akses Play Store terbatas, berbagi APK adalah metode distribusi utama. Bagi semua pengguna ini, AAB sama sekali tidak relevan. Ini adalah format yang hidup dan mati di dalam ekosistem tertutup Google. Begitu sebuah aplikasi perlu dibagikan, di-deploy, atau diinstal di luar ekosistem itu, formatnya harus APK. Hal ini menjadi semakin relevan dengan adanya peraturan baru. Digital Markets Act dari Uni Eropa memaksa Apple dan Google untuk membuka diri terhadap toko aplikasi alternatif. Seiring dengan semakin populernya marketplace Android pihak ketiga di Eropa, mereka akan membutuhkan format universal untuk pengiriman aplikasi. Karena mereka tidak bisa memanfaatkan infrastruktur Dynamic Delivery milik Google, format itu pastilah APK. Ironisnya, ini justru bisa menyebabkan kebangkitan kembali pentingnya APK di beberapa pasar terbesar dunia, bahkan saat Google semakin fokus pada AAB untuk tokonya sendiri.
Rekomendasi Praktis Berdasarkan Situasimu
Jadi, mari kita langsung ke intinya. Format yang tepat sepenuhnya tergantung pada apa yang ingin kamu lakukan. Berikut adalah panduan praktis tanpa basa-basi berdasarkan peranmu. **Jika kamu menerbitkan aplikasi baru ke Google Play:** Kamu tidak punya pilihan. Kamu harus mengirimkan AAB untuk setiap aplikasi baru sejak Agustus 2021. Konfigurasikan Play App Signing di Play Console (Setup > App Integrity), atur konfigurasi penandatanganan Gradle-mu, dan jalankan `./gradlew bundleRelease`. Pastikan untuk mengujinya secara lokal dengan `bundletool build-apks --bundle=app.aab --output=app.apks --local-testing` yang diikuti oleh `bundletool install-apks --apks=app.apks`. **Jika kamu mendistribusikan ke perangkat enterprise via MDM:** Tetap gunakan APK. Buat satu dengan `./gradlew assembleRelease`. Solusi MDM-mu akan mengirimkan APK langsung ke perangkat. Menggunakan AAB di sini tidak menambah nilai apa pun dan hanya membuat pusing. **Jika kamu mendistribusikan ke app store alternatif:** Buat APK. Amazon Appstore, misalnya, memiliki portal developer sendiri untuk unggahan APK dan logikanya sendiri untuk penargetan perangkat. Mereka tidak menggunakan sistem Google. **Jika kamu seorang QA engineer yang menguji build:** Gunakan APK untuk smoke test harian dan regression testing; format ini cepat dan bisa diinstal langsung dengan `adb install`. Untuk validasi akhir sebelum rilis, kamu harus membuat AAB dan menggunakan `bundletool` untuk memastikan kamu menguji apa yang akan didapatkan pengguna dari Play Store. **Jika kamu perlu memeriksa APK yang kamu terima:** Kamu bisa mengunggahnya ke CocoConvert untuk mengekstrak isinya dengan cepat, atau menggunakan APK Analyzer bawaan Android Studio (Build > Analyze APK). Analyzer memberikan rincian visual ukuran file yang bagus dan sempurna untuk membandingkan dua build yang berbeda untuk melihat apa yang berubah. Pada akhirnya, perdebatan APK vs. AAB bukanlah tentang format mana yang secara teknis lebih unggul secara terpisah. Ini tentang logistik. Pilihan yang tepat ditentukan oleh channel distribusi dan tool yang kamu gunakan. Kedua format ini akan tetap ada, melayani jalur yang berbeda dalam ekosistem Android yang luas.