AAB — यह क्या है, APK से अंतर और कार्य सिद्धांत

AAB क्या है

AAB (Android App Bundle) एक प्रकाशन प्रारूप है जिसे Google ने Google Play के माध्यम से वितरण के लिए APK के प्रतिस्थापन के रूप में विकसित किया है। AAB के अंदर .aab एक्सटेंशन वाला एक ZIP संग्रह है जिसमें संकलित कोड, संसाधन और मेटाडेटा होता है। मुख्य अंतर: AAB सीधे डिवाइस पर इंस्टॉल नहीं होता है।

यह कैसे काम करता है

डेवलपर AAB को Google Play Console पर अपलोड करता है। जब उपयोगकर्ता एप्लिकेशन इंस्टॉल करने का प्रयास करता है, Google Play डिवाइस कॉन्फ़िगरेशन का विश्लेषण करता है: स्क्रीन घनत्व (DPI), CPU आर्किटेक्चर, भाषा और Android संस्करण। इस विश्लेषण के आधार पर, केवल आवश्यक घटकों वाला एक न्यूनतम APK जनरेट किया जाता है।

अपनाने का इतिहास

Google ने 2018 में I/O सम्मेलन में AAB पेश किया। अगस्त 2021 से, 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 का अनिवार्य घटक है। इसमें मुख्य कोड, संसाधन और एप्लिकेशन मेनिफेस्ट होता है। base मॉड्यूल के बिना एप्लिकेशन नहीं बनाया जा सकता। अन्य सभी मॉड्यूल वैकल्पिक हैं और 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)

बड़े संसाधनों (2 GB तक) के लिए OBB फ़ाइलों के बजाय Play Asset Delivery का उपयोग किया जाता है। PAD समान तीन वितरण मोड का समर्थन करता है: 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 संसाधनों को तीन आयामों में विभाजित करता है: भाषा, स्क्रीन घनत्व (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 के प्रदर्शन मेट्रिक्स दिखाता है। यह डेटा स्प्लिट कॉन्फ़िगरेशन को अनुकूलित करने और विभिन्न डिवाइस श्रेणियों के लिए डाउनलोड आकार कम करने में मदद करता है।