APK बनाम AAB: समझिए एंड्रॉइड का नया डिस्ट्रिब्यूशन फॉर्मेट
APK असल में क्या है (और इसने 15 सालों तक एंड्रॉइड पर राज क्यों किया)
15 सालों तक, एंड्रॉइड पैकेज किट—APK—ही एकमात्र विकल्प था। यह 2008 में प्लेटफॉर्म के लॉन्च के बाद से एंड्रॉइड ऐप्स के लिए मानक रहा है। एक APK वास्तव में सिर्फ एक ZIP आर्काइव है जिसकी एक बहुत ही विशिष्ट आंतरिक संरचना होती है: इसमें कंपाइल्ड AndroidManifest.xml, DEX बाइटकोड (classes.dex), एक resources.arsc टेबल, और एसेट्स, नेटिव लाइब्रेरीज़ और अन्य रॉ रिसोर्सेज़ के लिए फ़ोल्डर्स होते हैं। जब आप किसी वेबसाइट से कोई ऐप डाउनलोड करते हैं या ब्लूटूथ से किसी दोस्त को भेजते हैं, तो आप एक सिंगल .apk फ़ाइल भेज रहे होते हैं जिसमें किसी भी एंड्रॉइड डिवाइस पर चलने के लिए ज़रूरी सब कुछ होता है। यह 'एक-साइज़-सबके-लिए-फिट' वाला दृष्टिकोण ही APK की सबसे बड़ी ताकत और उसकी सबसे बड़ी खामी दोनों है। गूगल प्ले स्टोर से एक सिंगल APK को 64-बिट ARM चिप वाले सैमसंग गैलेक्सी S25 अल्ट्रा से लेकर 32-बिट ARM चिप वाले एक बजट टेक्नो फोन तक, साथ ही x86 प्रोसेसर वाले क्रोमबुक और हर संभव स्क्रीन डेंसिटी को सपोर्ट करना होता है। ऐसा करने के लिए, डेवलपर्स को हर नेटिव लाइब्रेरी, अनुवादित स्ट्रिंग और स्क्रीन-डेंसिटी इमेज के हर संस्करण को एक बड़े पैकेज में पैक करना पड़ता था। इसका परिणाम? गूगल मैप्स जैसे ऐप्स 100 MB के APK भेजते थे, जबकि आपके डिवाइस को उसमें से केवल 40 MB की ही ज़रूरत होती थी। बाकी सब सिर्फ फालतू का बोझ था—डाउनलोड और स्टोर किया गया, लेकिन कभी इस्तेमाल नहीं हुआ।
एंड्रॉइड ऐप बंडल: 2018 में क्या बदला और गूगल ने इसे अनिवार्य क्यों किया
गूगल ने आखिरकार गूगल I/O 2018 में एंड्रॉइड ऐप बंडल (AAB) के साथ APK की बढ़ते साइज़ की समस्या का समाधान किया, और अगस्त 2021 में नए प्ले स्टोर ऐप्स के लिए इसे अनिवार्य कर दिया। हालांकि इसका एक्सटेंशन .aab है और यह भी एक ZIP आर्काइव है, पर यह एक इंस्टॉल करने योग्य ऐप नहीं है। इसे एक रेसिपी और सामग्री के डिब्बे की तरह समझें, न कि तैयार केक। एक AAB में कंपाइल्ड कोड और रिसोर्सेज़ मॉड्यूल्स में होते हैं, लेकिन गूगल प्ले के सर्वर अंतिम असेंबली करते हैं। इस प्रक्रिया को डायनामिक डिलीवरी (Dynamic Delivery) कहा जाता है। जब कोई उपयोगकर्ता प्ले स्टोर में 'इंस्टॉल' पर क्लिक करता है, तो गूगल के सर्वर उनके विशिष्ट डिवाइस को देखते हैं—उसका सीपीयू आर्किटेक्चर (ABI), स्क्रीन डेंसिटी, और भाषा सेटिंग्स। फिर, वे केवल वही स्प्लिट APKs का एक कस्टमाइज्ड सेट बनाते और भेजते हैं जिसकी उस डिवाइस को ज़रूरत होती है। अंग्रेज़ी में एंड्रॉइड 15 चलाने वाले पिक्सेल 9 को 38 MB का डाउनलोड मिल सकता है, जबकि पुराना मोनोलिथिक APK 95 MB का होता। साइज़ में यह कमी सैद्धांतिक नहीं है; यह महत्वपूर्ण और मापने योग्य है। गूगल के अपने 2021 के आंकड़ों से पता चला है कि AAB पर स्विच करने वाले ऐप्स के लिए औसत साइज़ में 15% की कमी आई, कुछ ने तो अपने साइज़ में 50% से अधिक की कटौती की। एक ऐसे गेम के लिए जिसमें विभिन्न GPU कंप्रेशन फॉर्मेट (जैसे ETC2, ASTC, और S3TC) के लिए डिज़ाइन किए गए बड़े टेक्सचर एटलस होते हैं, बचत बहुत ज़्यादा हो सकती है, जिससे उपयोगकर्ता के फोन पर अंतिम इंस्टॉलेशन से सैकड़ों मेगाबाइट आसानी से कम हो जाते हैं।
एक AAB फ़ाइल की आंतरिक संरचना
अगर आप किसी ZIP यूटिलिटी से AAB को खोलकर देखें, तो आप तुरंत देखेंगे कि यह एक APK नहीं है। टॉप लेवल पर एक BundleConfig.pb फ़ाइल होती है, जो बंडल के कॉन्फ़िगरेशन को परिभाषित करती है, एक BUNDLE-METADATA डायरेक्टरी, और कम से कम एक मॉड्यूल डायरेक्टरी। मुख्य मॉड्यूल को हमेशा `base/` कहा जाता है, और यह अंदर से थोड़ा APK जैसा दिखता है, जिसमें `dex/`, `manifest/`, `res/`, `root/`, और `lib/` फ़ोल्डर्स होते हैं। लेकिन एक महत्वपूर्ण अंतर है: रिसोर्सेज़ को एक `resources.pb` प्रोटो फॉर्मेट में संग्रहीत किया जाता है, न कि APK के फ्लैट बाइनरी `resources.arsc` में। यह एक मुख्य कारण है कि AAB को सीधे इंस्टॉल नहीं किया जा सकता है। अन्य फ़ीचर मॉड्यूल `base/` मॉड्यूल के साथ दिखाई देते हैं, जैसे `onboarding/` या `ar_features/`। प्रत्येक का अपना मैनिफेस्ट और रिसोर्सेज़ होते हैं और इसे इंस्टॉल-टाइम पर, इंस्टॉल के तुरंत बाद (फास्ट-फॉलो), या केवल ज़रूरत पड़ने पर डाउनलोड करने के लिए सेट किया जा सकता है। यह ऑन-डिमांड मॉडल है कि कैसे गूगल अर्थ जैसा ऐप हर उपयोगकर्ता पर 3D शहर के डेटा का बोझ डालने से बच सकता है, इसे प्ले कोर लाइब्रेरी के माध्यम से केवल तभी प्राप्त करता है जब कोई वास्तव में उस कवरेज वाले शहर को देखने की कोशिश करता है। प्रत्येक मॉड्यूल के भीतर `lib/` डायरेक्टरी वह जगह है जहाँ साइज़ बचाने का असली जादू होता है। एक क्रॉस-प्लेटफ़ॉर्म गेम में `arm64-v8a`, `armeabi-v7a`, और `x86_64` सब-डायरेक्टरी हो सकती हैं, जिनमें से प्रत्येक कंपाइल्ड .so लाइब्रेरी से भरी होती है। एक मोनोलिथिक APK उन सभी को बंडल करेगा। AAB के साथ, डायनामिक डिलीवरी यह सुनिश्चित करती है कि केवल एक, मेल खाने वाली ABI डायरेक्टरी ही भेजी जाए। प्रति ABI 80 MB के नेटिव कोड वाले गेम के लिए, यह एक आधुनिक 64-बिट फोन पर तुरंत 160 MB की बचत है जिसे 32-बिट या x86 लाइब्रेरी की कोई आवश्यकता नहीं है।
APK बनाम AAB: डेवलपर्स के लिए क्या मायने रखता है, इसकी सीधी तुलना
तो डेवलपर्स, QA, और उपयोगकर्ताओं के लिए इन अंतरों का व्यावहारिक रूप से क्या मतलब है? चलिए इस तुलना को उन चीज़ों के आधार पर समझते हैं जो आपके दिन-प्रतिदिन के काम में वास्तव में मायने रखती हैं। **डिस्ट्रिब्यूशन चैनल सपोर्ट:** गूगल प्ले नए ऐप्स के लिए AAB की मांग करता है। बात सीधी है। हालांकि, AAB एक गूगल-ओनली तकनीक है। अमेज़न ऐपस्टोर, सैमसंग गैलेक्सी स्टोर, हुआवेई ऐपगैलरी, और F-Droid जैसे वैकल्पिक एंड्रॉइड ऐप स्टोर सभी को पुराने पारंपरिक APKs की आवश्यकता होती है। यदि आप अपना ऐप गूगल प्ले के बाहर वितरित कर रहे हैं, तो आपको अभी भी APK के साथ ही काम करना होगा। यह कोई मामूली बात नहीं है, खासकर उन बाज़ारों में जहाँ गूगल प्ले उपलब्ध नहीं है और केवल APK-डिस्ट्रिब्यूशन ही मानक है। **सीधा इंस्टॉलेशन:** आप AAB को साइडलोड नहीं कर सकते। `adb install app.aab` के साथ एक को इंस्टॉल करने की कोशिश करने पर आपको बस एक एरर मिलेगा। एक AAB को स्थानीय रूप से टेस्ट करने के लिए, आपको गूगल के `bundletool` का उपयोग करके एक स्थानीय APK सेट जेनरेट करना होगा या अपने बिल्ड में `--local-testing` फ्लैग का उपयोग करना होगा। कोई भी जिसने किसी गैर-तकनीकी हितधारक से बिल्ड का टेस्ट करवाने की कोशिश की है, वह जानता है कि अतिरिक्त कदम जोड़ना निराशा का कारण बनता है। यह निश्चित रूप से QA वर्कफ़्लो में बाधा डालता है। **बिल्ड टूलिंग:** एंड्रॉइड स्टूडियो में, आप Build > Generate Signed Bundle/APK > Android App Bundle के साथ, या `./gradlew bundleRelease` टास्क के साथ एक AAB बनाते हैं। आप `./gradlew assembleRelease` के साथ एक APK बनाते हैं। अधिकांश टीमें दोनों का उपयोग करती हैं, आंतरिक परीक्षण के लिए APK बनाती हैं और अंतिम प्ले स्टोर अपलोड के लिए AAB बनाती हैं। **डिस्क पर फ़ाइल साइज़:** यहाँ एक आम भ्रम है: आपकी AAB फ़ाइल लगभग हमेशा आपके APK से बड़ी होगी। एक 60 MB का APK 80 MB का AAB उत्पन्न कर सकता है क्योंकि AAB में *सभी* डिवाइस कॉन्फ़िगरेशन के लिए रिसोर्सेज़ होते हैं। साइज़ की बचत केवल उपयोगकर्ता के डिवाइस पर दिखाई देती है जब गूगल प्ले अपना जादू चला देता है। **सुरक्षा मॉडल:** दोनों फॉर्मेट साइन किए गए हैं, लेकिन प्रक्रिया अलग है। AABs के साथ, आपको प्ले ऐप साइनिंग का उपयोग करना होगा। इसका मतलब है कि आप अपना बंडल अपलोड करते हैं और गूगल अंतिम स्प्लिट APKs को फिर से साइन करता है जिसे वह एक कुंजी के साथ उत्पन्न करता है जिसे वह प्रबंधित करता है। जबकि आप इस कुंजी को पंजीकृत करते हैं, अंततः गूगल इसे अपने पास रखता है, एक तथ्य जो कुछ सुरक्षा के प्रति सचेत टीमों को चिंतित करता है। APKs के साथ, आप अपनी खुद की कुंजियों के साथ पूरी साइनिंग प्रक्रिया को नियंत्रित कर सकते हैं, जिसमें गूगल की कोई भागीदारी नहीं होती है।
APK और AAB के बीच कनवर्ट करना: क्या संभव है और क्या नहीं
यह वह जगह है जहाँ ईमानदार जवाब मार्केटिंग के वादों से ज़्यादा मायने रखते हैं। चलिए साफ-साफ बात करते हैं: किसी मौजूदा APK को वापस AAB में बदलना असल में संभव नहीं है, और आपको किसी भी ऐसे टूल पर पूरी तरह से संदेह करना चाहिए जो यह दावा करता है कि वह इसे स्वचालित रूप से कर सकता है। समस्या मौलिक है। एक AAB को मूल स्रोत जानकारी की आवश्यकता होती है—स्क्रीन डेंसिटी और भाषा के अनुसार अच्छी तरह से व्यवस्थित रिसोर्स फ़ाइलें, प्रोटो-फॉर्मेट रिसोर्स टेबल, मॉड्यूल संरचना। जब एक APK बनाया जाता है तो उस सारे डेटा को कंपाइल, फ्लैट और ऑप्टिमाइज़ कर दिया जाता है। एक APK में `resources.arsc` फ़ाइल एक बाइनरी ब्लॉब होती है; मूल `res/drawable-hdpi/` फ़ोल्डर संरचना चली जाती है। एक कंपाइल्ड APK से उसे फिर से बनाने की कोशिश करना कनवर्ज़न नहीं है; यह रिवर्स इंजीनियरिंग की एक दर्दनाक प्रक्रिया है, और परिणाम लगभग हमेशा अधूरे होते हैं। CocoConvert को APK-से-APK संचालन के लिए बनाया गया है। आप इसका उपयोग रीपैकेज करने, नाम बदलने और, सबसे उपयोगी रूप से, निरीक्षण के लिए APK फ़ाइलों की सामग्री निकालने के लिए कर सकते हैं। एक APK अपलोड करें, और आप उसका मैनिफेस्ट निकाल सकते हैं, उसकी रिसोर्स टेबल देख सकते हैं, या विशिष्ट एसेट्स प्राप्त कर सकते हैं। लेकिन जो CocoConvert नहीं कर सकता है, वह है एक APK से एक वैध, प्ले-रेडी AAB बनाना। सच कहूँ तो, कोई भी टूल इसे विश्वसनीय रूप से नहीं कर सकता है यदि आपके पास मूल स्रोत कोड प्रोजेक्ट नहीं है। यदि आपने अपना स्रोत खो दिया है और आपके पास केवल एक APK है, तो आपका सबसे अच्छा दांव `apktool` जैसा एक टूल है। यह पैकेज को स्माली बाइटकोड में डीकंपाइल कर सकता है और आपको रिसोर्सेज़ का एक अनुमान दे सकता है, लेकिन इसे वापस एक उचित प्रोजेक्ट में बदलना जिसे AAB में बनाया जा सके, इसके लिए बहुत अधिक मैनुअल काम की आवश्यकता होती है। CocoConvert जिस काम के लिए वास्तव में उपयोगी है, वह ऐसे कार्य हैं जो मोबाइल QA और सुरक्षा अनुसंधान में हर समय सामने आते हैं। आप APKs को ZIP फ़ाइलों में बदल सकते हैं ताकि उनकी सामग्री को ब्राउज़ कर सकें, विशिष्ट छवियों या ऑडियो फ़ाइलों को निकाल सकें, और यहां तक कि ऑडिट करने के लिए APKs के पूरे फ़ोल्डर को बैच-प्रोसेस कर सकें। ये वे व्यावहारिक, वास्तविक दुनिया के काम हैं जिनमें हम मदद कर सकते हैं।
साइडलोडिंग का पहलू और APK क्यों चलन से बाहर नहीं होगा
गूगल द्वारा AAB के लिए बड़े जोर के बावजूद, साधारण APK कहीं नहीं जा रहा है। इसकी स्थायित्व उन सभी उपयोग के मामलों से आती है जो गूगल के नियंत्रण से पूरी तरह से बाहर मौजूद हैं। साइडलोडिंग—प्ले स्टोर के बाहर से एक APK इंस्टॉल करना—एंड्रॉइड की एक मुख्य विशेषता है, जो आपके फ़ोन की सेटिंग्स में एक त्वरित बदलाव से सक्षम होती है (आमतौर पर सेटिंग्स > ऐप्स > स्पेशल ऐप एक्सेस > अज्ञात ऐप्स इंस्टॉल करें के तहत, हालांकि पथ भिन्न हो सकता है)। और साइडलोडिंग इकोसिस्टम बहुत बड़ा है। APKMirror प्ले स्टोर ऐप्स के सत्यापित APKs को होस्ट करता है, जिससे उपयोगकर्ता एक चरणबद्ध रोलआउट उन तक पहुंचने से पहले अपडेट प्राप्त कर सकते हैं या पुराने संस्करण इंस्टॉल कर सकते हैं। VMware और Microsoft के एंटरप्राइज मोबाइल डिवाइस मैनेजमेंट (MDM) टूल हजारों कॉर्पोरेट डिवाइसों पर APKs को बिना प्ले स्टोर को छुए पुश करते हैं। गेम मॉडिंग समुदाय मॉडिफाइड APKs पर ही जीते हैं। सीमित प्ले स्टोर एक्सेस वाले क्षेत्रों में डेवलपर्स के लिए, APKs साझा करना वितरण का प्राथमिक तरीका है। इनमें से किसी भी उपयोगकर्ता के लिए, AAB बस अप्रासंगिक है। यह एक ऐसा फॉर्मेट है जो गूगल के बंद इकोसिस्टम के अंदर ही जीता और मरता है। जिस क्षण किसी ऐप को उस इकोसिस्टम के बाहर साझा, तैनात या इंस्टॉल करने की आवश्यकता होती है, उसे एक APK होना चाहिए। यह नए नियमों के साथ और भी प्रासंगिक होता जा रहा है। यूरोपीय संघ का डिजिटल मार्केट्स एक्ट एप्पल और गूगल दोनों को वैकल्पिक ऐप स्टोर के लिए खुलने पर मजबूर कर रहा है। जैसे-जैसे यूरोप में तीसरे पक्ष के एंड्रॉइड मार्केटप्लेस कर्षण प्राप्त करेंगे, उन्हें सबमिशन के लिए एक सार्वभौमिक फॉर्मेट की आवश्यकता होगी। चूंकि वे गूगल के मालिकाना डायनामिक डिलीवरी इंफ्रास्ट्रक्चर का उपयोग नहीं कर सकते, इसलिए वह फॉर्मेट APK होगा। यह विडंबना ही है कि दुनिया के कुछ सबसे बड़े बाज़ारों में APK के महत्व में फिर से वृद्धि हो सकती है, भले ही गूगल अपने स्टोर के लिए AAB पर दोगुना जोर दे रहा हो।
आपकी स्थिति के आधार पर व्यावहारिक सिफारिशें
तो, चलिए सीधे मुद्दे पर आते हैं। सही फॉर्मेट पूरी तरह से इस बात पर निर्भर करता है कि आप क्या करने की कोशिश कर रहे हैं। यहाँ आपकी भूमिका के आधार पर एक सीधी-सादी गाइड है। **यदि आप गूगल प्ले पर एक नया ऐप प्रकाशित कर रहे हैं:** आपके पास कोई विकल्प नहीं है। आपको अगस्त 2021 से किसी भी नए ऐप के लिए एक AAB जमा करना होगा। प्ले कंसोल में प्ले ऐप साइनिंग कॉन्फ़िगर करें (सेटअप > ऐप इंटीग्रिटी), अपना ग्रेडल साइनिंग कॉन्फ़िग सेट करें, और `./gradlew bundleRelease` चलाएँ। `bundletool build-apks --bundle=app.aab --output=app.apks --local-testing` के बाद `bundletool install-apks --apks=app.apks` के साथ इसे स्थानीय रूप से टेस्ट करना सुनिश्चित करें। **यदि आप MDM के माध्यम से एंटरप्राइज डिवाइसों में वितरित कर रहे हैं:** APKs का ही उपयोग करें। `./gradlew assembleRelease` के साथ एक बनाएं। आपका MDM समाधान APK को सीधे डिवाइसों पर पुश करता है। यहाँ AAB का उपयोग करने से कोई फायदा नहीं होता और सिर्फ सिरदर्द पैदा होता है। **यदि आप वैकल्पिक ऐप स्टोर पर वितरित कर रहे हैं:** APKs बनाएं। उदाहरण के लिए, अमेज़न ऐपस्टोर का APK अपलोड और डिवाइस टारगेटिंग के लिए अपना डेवलपर पोर्टल है। वे गूगल के सिस्टम का उपयोग नहीं करते हैं। **यदि आप एक QA इंजीनियर हैं जो एक बिल्ड का परीक्षण कर रहे हैं:** अपने दैनिक स्मोक टेस्ट और रिग्रेशन टेस्टिंग के लिए APKs का उपयोग करें; वे तेज़ होते हैं और `adb install` के साथ सीधे इंस्टॉल हो जाते हैं। अंतिम प्री-रिलीज़ सत्यापन के लिए, आपको एक AAB बनाना चाहिए और `bundletool` का उपयोग करके यह सुनिश्चित करना चाहिए कि आप वही परीक्षण कर रहे हैं जो उपयोगकर्ताओं को वास्तव में प्ले स्टोर से मिलेगा। **यदि आपको प्राप्त हुए APK का निरीक्षण करने की आवश्यकता है:** आप इसे CocoConvert पर अपलोड करके इसकी सामग्री को जल्दी से निकाल सकते हैं, या एंड्रॉइड स्टूडियो के अपने APK एनालाइज़र (Build > Analyze APK) का उपयोग कर सकते हैं। एनालाइज़र फ़ाइल साइज़ का एक शानदार विज़ुअल ब्रेकडाउन देता है और दो अलग-अलग बिल्ड की तुलना करके यह देखने के लिए एकदम सही है कि क्या बदला है। अंततः, APK बनाम AAB बहस इस बारे में नहीं है कि कौन सा फॉर्मेट तकनीकी रूप से बेहतर है। यह लॉजिस्टिक्स के बारे में है। सही विकल्प आपके डिस्ट्रिब्यूशन चैनल और आपकी टूलिंग द्वारा निर्धारित होता है। दोनों फॉर्मेट यहाँ बने रहने के लिए हैं, जो विशाल एंड्रॉइड इकोसिस्टम में अलग-अलग रास्तों की सेवा कर रहे हैं।