AAB — ano ito, pagkakaiba sa APK at prinsipyo ng paggana

Ano ang AAB

AAB (Android App Bundle) — ay isang format ng pag-publish na binuo ng Google bilang kapalit ng APK para sa pamamahagi sa pamamagitan ng Google Play. Sa loob ng AAB ay isang ZIP archive na may extension na .aab, na naglalaman ng naka-compile na code, mga mapagkukunan at metadata. Ang pangunahing pagkakaiba: ang AAB ay hindi direktang naka-install sa device.

Prinsipyo ng paggana

Ina-upload ng developer ang AAB sa Google Play Console. Kapag sinubukan ng user na i-install ang application, sinusuri ng Google Play ang configuration ng device: density ng screen (DPI), arkitektura ng CPU, wika at bersyon ng Android. Batay sa pagsusuring ito, nabuo ang isang minimal na APK na naglalaman lamang ng mga kinakailangang bahagi.

Kasaysayan ng implementasyon

Ipinakilala ng Google ang AAB noong 2018 sa kumperensya ng I/O. Mula noong Agosto 2021, ang format ay naging sapilitan para sa lahat ng bagong application sa Google Play. Ang mga umiiral na application ay maaaring patuloy na gumamit ng APK, ngunit ang mga bago ay dapat na i-publish lamang sa format na AAB.

Paano naiiba ang AAB sa APK

Ang pagkakaiba sa pagitan ng AAB at APK ay pangunahing: APK ay isang kumpletong file ng pag-install, handa nang i-install. AAB ay isang lalagyan na may mga sangkap na pinagmulan na nangangailangan ng pagproseso.

APK ay angkop para sa pamamahagi sa labas ng Google Play — sa pamamagitan ng mga website, email o corporate MDM system. Ang AAB ay nakatali sa imprastraktura ng Google Play at hindi direktang naka-install. Para sa pagsubok ng AAB, ginagamit ang tool na bundletool, na ginagaya ang pagbuo ng APK sa lokal na makina.

Istraktura ng file ng AAB

Ang panloob na istraktura ng AAB ay katulad ng APK, ngunit naglalaman ng mga karagdagang direktoryo at file para sa paglalarawan ng mga modyul at kanilang mga dependency.

Base na modyul (base)

Ang base na modyul — ay isang sapilitang bahagi ng AAB. Ito ay naglalaman ng pangunahing code, mga mapagkukunan at manifest ng application. Kung wala ang base na modyul, hindi mabubuo ang application. Lahat ng iba pang mga modyul ay opsyonal at konektado sa pamamagitan ng Dynamic Delivery.

Protobuf format

Ang configuration ng AAB ay gumagamit ng Protocol Buffers (protobuf) sa halip na XML. Ang mga .pb file ay mas compact at mas mabilis na nai-parse ng imprastraktura ng server ng Google. Ang tool na bundletool ay nagko-convert ng protobuf sa isang nababasang format para sa debugging.

Dynamic Delivery at mga modyul ng application

Dynamic Delivery — ang pangunahing teknolohiya kung saan itinayo ang AAB. Ito ay nagpapahintulot sa paghahatid sa user ng mga bahagi lamang ng application na tumutugma sa kanyang device at wika, pati na rin ang pag-load ng mga karagdagang modyul kapag hiniling.

Mga uri ng modyul

Ang mga modyul na Install-time ay na-load kasama ng base APK sa panahon ng pag-install. Ang mga modyul na Conditional ay inihahatid lamang kapag natugunan ang mga kundisyon — halimbawa, isang modyul na may mga materyales para sa 4K na screen. Ang mga modyul na On-demand ay na-load kapag hiniling ng user sa loob ng application.

Play Asset Delivery (PAD)

Para sa malalaking mapagkukunan (hanggang 2 GB) ginagamit ang Play Asset Delivery sa halip na mga OBB file. Sinusuportahan ng PAD ang parehong tatlong mode ng paghahatid: install-time, fast-follow (kaagad pagkatapos ng pag-install) at on-demand.

// Pag-load ng on-demand na modyul sa pamamagitan ng SplitInstallManager
val manager = SplitInstallManagerFactory
    .create(context)

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

manager.startInstall(request)
    .addOnSuccessListener {
        Log.d("AAB", "Naka-install ang modyul")
    }

Configuration ng modyul sa Gradle

Ang bawat dynamic na modyul ay inilalarawan ng isang hiwalay na build.gradle file na may pagtukoy ng uri ng paghahatid. Ang modyul ay maaaring magkaroon ng sarili nitong mga mapagkukunan, code at manifest, na independiyente sa base na application.

Pagbuo ng AAB sa pamamagitan ng Gradle

Ang pagbuo ng AAB ay ginagawa sa pamamagitan ng Android Gradle Plugin gamit ang gawaing bundleRelease (o bundleDebug). Ang resulta — isang .aab file sa direktoryo ng build/outputs/bundle/.

Configuration ng pagbuo

Para sa pagbuo ng AAB, walang mga espesyal na setting ang kinakailangan — ang Android Gradle Plugin ay sumusuporta sa mga bundle bilang default. Sapat na tukuyin ang gawaing bundle sa halip na assemble.

// build.gradle.kts — pagbuo ng AAB na may lagda
android {
    bundle {
        language {
            enableSplit = true
        }
        density {
            enableSplit = true
        }
        abi {
            enableSplit = true
        }
    }
}
// Gawain: ./gradlew bundleRelease

Lokal na pagsubok sa pamamagitan ng bundletool

Ang Google ay nagbibigay ng tool na bundletool para sa pagbuo ng APK mula sa AAB sa lokal na makina. Ang utos na `bundletool build-apks --bundle=app.aab --output=app.apks` ay lumilikha ng isang set ng mga APK para sa pagsubok sa iba't ibang configuration ng device.

bundletool ay maaari ring mag-unpack ng AAB, ipakita ang configuration nito, at suriin ang integridad ng lagda bago i-upload sa Google Play Console. Para sa debugging, ginagamit ang utos na `bundletool dump manifest --bundle=app.aab`, na nagpapakita ng manifest ng base na modyul.

Configuration ng paghahati sa AAB

Bilang default, hinahati ng AAB ang mga mapagkukunan ayon sa tatlong dimensyon: wika (language), density ng screen (density) at arkitektura ng CPU (abi). Maaaring i-disable ng developer ang anumang paghahati sa build.gradle — halimbawa, kung ang application ay sumusuporta lamang sa Ingles. Ang pag-disable ng paghahati ay nangangahulugan na ang mga mapagkukunan para sa lahat ng variant ay mapupunta sa base APK.

Resource optimisation — awtomatikong kino-convert ng AAB ang PNG sa WebP nang walang pagkawala ng kalidad, pinipiga ang mga hindi ginagamit na mapagkukunan at inaalis ang mga duplicate na string. Ang mga optimization na ito ay inilalapat sa panig ng Google Play kapag bumubuo ng panghuling APK. Bilang resulta, ang user ay tumatanggap ng APK na 15–25% na mas maliit kaysa sa buong archive.

Pag-publish ng AAB sa Google Play

Ang proseso ng pag-publish ng AAB sa Google Play Console ay naiiba sa APK lamang sa format ng na-upload na file. Tinatanggap ng console ang .aab, sinusuri ang istraktura, lagda at configuration ng mga modyul nito, pagkatapos ay bumubuo ng APK para sa bawat uri ng device.

App Signing by Google Play

Kapag nag-upload ng AAB, pinangangasiwaan ng Google Play ang pamamahala ng mga susi ng lagda. Ina-upload ng developer ang package na nilagdaan gamit ang upload key, at ang Google ay muling pumipirma sa mga nabuong APK gamit ang sarili nitong key. Pinapasimple nito ang pag-ikot ng mga susi at pagbawi ng access kung mawala ang keystore.

Pagsubok bago ilabas

Ang Google Play Console ay nagbibigay ng built-in na pagsubok ng AAB: maaaring i-download ang nabuong APK para sa isang partikular na device o magpatakbo ng panloob na pagsubok sa pamamagitan ng mga track na Internal Testing, Closed Alpha at Open Beta.

Mga karaniwang problema sa AAB at ang kanilang solusyon

Ang paglipat sa AAB ay maaaring magdulot ng mga problema, lalo na sa mga proyektong may maraming dynamic na modyul o kumplikadong configuration ng mapagkukunan.

Mga error sa configuration ng modyul

Kung ang isang dynamic na modyul ay tumutukoy sa mga mapagkukunan ng base na modyul na may maling pangalan, tinatanggihan ng Google Play ang AAB sa yugto ng pag-verify. Solusyon — gumamit ng lint check bago ang pagbuo at subukan ang lahat ng modyul sa pamamagitan ng bundletool nang lokal.

Paghahati sa wika at pagbaba ng pagganap

Ang paghahati ayon sa wika ay maaaring magpabagal sa pagsisimula ng application kung ang mga mapagkukunan para sa kasalukuyang lokalisasyon ay na-load nang dynamic. Rekomendasyon ng Google — huwag hatiin ang mga wika kung mas mababa sa 10, o gumamit ng install-time para sa pinakasikat.

Pagkakatugma sa mga SDK ng third-party

Ang ilang SDK (analytics, mga ad, mapa) ay nangangailangan ng access sa buong manifest at mga mapagkukunan. Pagsusuri ng pagkakatugma sa AAB ay isang sapilitang hakbang bago ang migration. Karamihan sa mga malalaking SDK (Firebase, Google Ads, Crashlytics) ay ganap na sumusuporta sa AAB mula noong 2022. Para sa pagsusuri ng pagkakatugma, ginagamit ang bundletool na may flag na --validate, na ginagaya ang pagbuo ng APK sa server.

Pag-bersyon ng AAB

Gumagamit ang AAB ng versionCode mula sa manifest ng base na modyul. Hindi tulad ng APK, sinusuportahan din ng AAB ang hiwalay na versionCode para sa bawat modyul — ito ay nagpapahintulot sa pag-update ng mga indibidwal na bahagi ng application nang walang buong muling pag-install. Sinusubaybayan ng Dynamic Delivery ang mga naka-install na modyul at naghahatid lamang ng mga binagong bahagi sa pag-update sa pamamagitan ng Google Play.

Pagmonitor at analytics ng AAB

Ang Google Play Console ay nagbibigay ng detalyadong analytics para sa bawat AAB: ilang APK ang nabuo, anong mga paghahati ang hiniling, ano ang average na laki ng pag-download ayon sa device. Android Vitals ay nagpapakita ng mga sukatan ng pagganap ng mga nabuong APK. Ang datos na ito ay tumutulong sa pag-optimize ng configuration ng paghahati at pagbawas ng laki ng pag-download para sa iba't ibang kategorya ng device.