Android ऐप्लिकेशन बंडल, .aab
फ़ाइल एक्सटेंशन वाली एक फ़ाइल होती है. इसे Google Play पर अपलोड किया जाता है.
ऐप्लिकेशन बंडल, हस्ताक्षर वाली बाइनरी होती हैं. ये आपके ऐप्लिकेशन के कोड और संसाधनों को मॉड्यूल में व्यवस्थित करती हैं, जैसा कि पहली इमेज में दिखाया गया है. हर मॉड्यूल के लिए कोड और संसाधन, ठीक उसी तरह व्यवस्थित किए जाते हैं जैसे आपको किसी APK में मिलते हैं. ऐसा इसलिए होता है, क्योंकि इनमें से हर मॉड्यूल को अलग-अलग APK के तौर पर जनरेट किया जा सकता है. इसके बाद, Google Play ऐप्लिकेशन बंडल का इस्तेमाल करके, उपयोगकर्ताओं को दिखाए जाने वाले अलग-अलग APK जनरेट करता है. जैसे, बेस APK, सुविधा वाले APK, कॉन्फ़िगरेशन APK, और ऐसे डिवाइसों के लिए मल्टी-APK जो स्प्लिट APK के साथ काम नहीं करते. नीले रंग में दिखने वाली डायरेक्ट्री, जैसे कि drawable/
, values/
, और lib/
डायरेक्ट्री, कोड और संसाधनों को दिखाती हैं. Google Play इनका इस्तेमाल, हर मॉड्यूल के लिए कॉन्फ़िगरेशन APK बनाने के लिए करता है.
पहली इमेज. एक बेस मॉड्यूल, दो फ़ीचर मॉड्यूल, और दो ऐसेट पैक वाले Android ऐप्लिकेशन बंडल का कॉन्टेंट.
इस सूची में, ऐप्लिकेशन बंडल की कुछ फ़ाइलों और डायरेक्ट्री के बारे में ज़्यादा जानकारी दी गई है:
- base/, feature1/, और feature2/: इनमें से हर टॉप-लेवल डायरेक्ट्री, आपके ऐप्लिकेशन के किसी अलग मॉड्यूल को दिखाती है. आपके ऐप्लिकेशन का बेस मॉड्यूल, हमेशा ऐप्लिकेशन बंडल की
base
डायरेक्ट्री में मौजूद होता है. हालांकि, हर सुविधा वाले मॉड्यूल की डायरेक्ट्री को, मॉड्यूल के मेनिफ़ेस्ट मेंsplit
एट्रिब्यूट से तय किया गया नाम दिया जाता है. ज़्यादा जानने के लिए, सुविधा मॉड्यूल मेनिफ़ेस्ट के बारे में पढ़ें. - asset_pack_1/ और asset_pack_2/: बड़े और ज़्यादा ग्राफ़िक वाले ऐप्लिकेशन या गेम के लिए, ऐसेट को ऐसेट पैक में मॉड्यूलर किया जा सकता है. ऐसेट पैक का साइज़ ज़्यादा होने की वजह से, ये गेम के लिए सबसे सही होते हैं. डिवाइस पर हर ऐसेट पैक को डाउनलोड करने का तरीका और समय, अपनी पसंद के मुताबिक तय किया जा सकता है. इसके लिए, डिलीवरी के तीन मोड उपलब्ध हैं: इंस्टॉल के समय, फ़ास्ट-फ़ॉलो, और मांग पर उपलब्ध. सभी ऐसेट पैक, Google Play पर होस्ट किए जाते हैं और वहां से ही उपलब्ध कराए जाते हैं. अपने ऐप्लिकेशन बंडल में ऐसेट पैक जोड़ने के तरीके के बारे में ज़्यादा जानने के लिए, Play की ऐसेट डिलीवरी की खास जानकारी देखें.
- BUNDLE-METADATA/: इस डायरेक्ट्री में मेटाडेटा फ़ाइलें शामिल होती हैं. इनमें टूल या ऐप स्टोर के लिए काम की जानकारी होती है. ऐसी मेटाडेटा फ़ाइलों में, ProGuard मैपिंग और आपके ऐप्लिकेशन की DEX फ़ाइलों की पूरी सूची शामिल हो सकती है. इस डायरेक्ट्री में मौजूद फ़ाइलों को आपके ऐप्लिकेशन के APK में पैकेज नहीं किया जाता.
- मॉड्यूल प्रोटोकॉल बफ़र (
*.pb
) फ़ाइलें: ये फ़ाइलें मेटाडेटा उपलब्ध कराती हैं. इससे, Google Play जैसे ऐप्लिकेशन स्टोर को हर ऐप्लिकेशन मॉड्यूल के कॉन्टेंट के बारे में बताने में मदद मिलती है. उदाहरण के लिए,BundleConfig.pb
बंडल के बारे में जानकारी देता है. जैसे, ऐप्लिकेशन बंडल बनाने के लिए, बंडल टूल के किस वर्शन का इस्तेमाल किया गया था. साथ ही,native.pb
औरresources.pb
हर मॉड्यूल में मौजूद कोड और संसाधनों के बारे में बताते हैं. यह जानकारी तब काम की होती है, जब Google Play अलग-अलग डिवाइस कॉन्फ़िगरेशन के लिए APKs को ऑप्टिमाइज़ करता है. - manifest/: APKs के उलट, ऐप्लिकेशन बंडल हर मॉड्यूल की
AndroidManifest.xml
फ़ाइल को इस अलग डायरेक्ट्री में सेव करते हैं. - dex/: APK के मुकाबले, ऐप्लिकेशन बंडल में हर मॉड्यूल के लिए DEX फ़ाइलें, इस अलग डायरेक्ट्री में सेव होती हैं.
- res/, lib/, और assets/: ये डायरेक्ट्री, आम तौर पर APK में मौजूद डायरेक्ट्री से मिलती-जुलती होती हैं. ऐप्लिकेशन बंडल अपलोड करने पर, Google Play इन डायरेक्ट्री की जांच करता है. साथ ही, सिर्फ़ उन फ़ाइलों को पैकेज करता है जो टारगेट डिवाइस के कॉन्फ़िगरेशन के मुताबिक हों. ऐसा करते समय, फ़ाइल पाथ को सुरक्षित रखा जाता है.
root/: इस डायरेक्ट्री में ऐसी फ़ाइलें सेव की जाती हैं जिन्हें बाद में, उस APK के रूट में ले जाया जाता है जिसमें यह डायरेक्ट्री मौजूद होती है. उदाहरण के लिए, किसी ऐप्लिकेशन बंडल की
base/root/
डायरेक्ट्री में, Java पर आधारित ऐसे रिसॉर्स शामिल हो सकते हैं जिन्हें आपका ऐप्लिकेशनClass.getResource()
का इस्तेमाल करके लोड करता है. बाद में, उन फ़ाइलों को आपके ऐप्लिकेशन के आधार APK और Google Play से जनरेट किए गए हर मल्टी-APK की रूट डायरेक्ट्री में ले जाया जाता है. इस डायरेक्ट्री में मौजूद पाथ भी सुरक्षित रहते हैं. इसका मतलब है कि डायरेक्ट्री और उनकी सब-डायरेक्ट्री को भी APK के रूट में ले जाया जाता है.
अलग-अलग डिवाइसों के हिसाब से APK बनाने की सुविधा के बारे में खास जानकारी
ऑप्टिमाइज़ किए गए ऐप्लिकेशन उपलब्ध कराने का एक बुनियादी कॉम्पोनेंट, स्प्लिट APK मशीन है. यह Android 5.0 (एपीआई लेवल 21) और इसके बाद के वर्शन पर उपलब्ध है. Split APK, सामान्य APK से काफ़ी मिलते-जुलते हैं. इनमें कंपाइल किया गया DEX बाइटकोड, संसाधन, और Android मेनिफ़ेस्ट शामिल होता है. हालांकि, Android प्लैटफ़ॉर्म, इंस्टॉल किए गए एक से ज़्यादा Split APK को एक ही ऐप्लिकेशन के तौर पर इस्तेमाल कर सकता है. इसका मतलब है कि एक से ज़्यादा Split APK इंस्टॉल किए जा सकते हैं. इनमें सामान्य कोड और संसाधनों का ऐक्सेस होता है और ये डिवाइस पर एक ही ऐप्लिकेशन के तौर पर दिखते हैं.
अलग-अलग APK बनाने का फ़ायदा यह है कि एक बड़े APK को छोटे-छोटे पैकेज में बांटा जा सकता है. बड़े APK में, आपके ऐप्लिकेशन के साथ काम करने वाली सभी सुविधाओं और डिवाइस कॉन्फ़िगरेशन का कोड और संसाधन शामिल होते हैं. ये छोटे पैकेज, उपयोगकर्ता के डिवाइस पर ज़रूरत के हिसाब से इंस्टॉल किए जाते हैं.
उदाहरण के लिए, किसी स्प्लिट APK में ऐसी अतिरिक्त सुविधा का कोड और संसाधन शामिल हो सकते हैं जिसकी ज़रूरत आपके कुछ ही उपयोगकर्ताओं को होती है. वहीं, किसी दूसरे स्प्लिट APK में सिर्फ़ किसी खास भाषा या स्क्रीन डेंसिटी के लिए संसाधन शामिल हो सकते हैं. जब उपयोगकर्ता इनमें से किसी APK को डाउनलोड करने का अनुरोध करता है या डिवाइस के लिए इनमें से किसी APK की ज़रूरत होती है, तब इनमें से हर APK को डाउनलोड और इंस्टॉल किया जाता है.
यहां अलग-अलग तरह के APKs के बारे में बताया गया है. ये APKs, किसी डिवाइस पर एक साथ इंस्टॉल किए जा सकते हैं, ताकि आपको ऐप्लिकेशन का पूरा अनुभव मिल सके. इस पेज के अगले सेक्शन में, आपको अपने ऐप्लिकेशन प्रोजेक्ट को इन APK के साथ काम करने के लिए कॉन्फ़िगर करने का तरीका पता चलेगा.
- बेस APK: इस APK में कोड और संसाधन होते हैं जिन्हें सभी अन्य Split APK ऐक्सेस कर सकते हैं. साथ ही, यह आपके ऐप्लिकेशन के लिए बुनियादी सुविधाएं उपलब्ध कराता है. जब कोई उपयोगकर्ता आपके ऐप्लिकेशन को डाउनलोड करने का अनुरोध करता है, तो सबसे पहले यह APK डाउनलोड और इंस्टॉल किया जाता है. ऐसा इसलिए है, क्योंकि सिर्फ़ बेस APK के मेनिफ़ेस्ट में आपके ऐप्लिकेशन की सेवाओं, कॉन्टेंट उपलब्ध कराने वाली कंपनियों, अनुमतियों, प्लैटफ़ॉर्म वर्शन की ज़रूरी शर्तों, और सिस्टम की सुविधाओं पर निर्भरता के बारे में पूरी जानकारी होती है. Google Play, आपके प्रोजेक्ट के ऐप्लिकेशन (या बेस) मॉड्यूल से आपके ऐप्लिकेशन के लिए बेस APK जनरेट करता है. अगर आपको अपने ऐप्लिकेशन के डाउनलोड किए जाने के शुरुआती साइज़ को कम करना है, तो यह ध्यान रखना ज़रूरी है कि इस मॉड्यूल में शामिल सभी कोड और संसाधन, आपके ऐप्लिकेशन के बेस APK में शामिल होते हैं.
- कॉन्फ़िगरेशन APK: इनमें से हर APK में, किसी खास स्क्रीन डेंसिटी, सीपीयू आर्किटेक्चर या भाषा के लिए नेटिव लाइब्रेरी और संसाधन शामिल होते हैं. जब कोई उपयोगकर्ता आपका ऐप्लिकेशन डाउनलोड करता है, तो उसका डिवाइस सिर्फ़ उन कॉन्फ़िगरेशन APK को डाउनलोड और इंस्टॉल करता है जो उसके डिवाइस को टारगेट करते हैं. हर कॉन्फ़िगरेशन APK, बेस APK या सुविधा मॉड्यूल APK पर निर्भर करता है. इसका मतलब है कि इन्हें उस APK के साथ डाउनलोड और इंस्टॉल किया जाता है जिसके लिए ये कोड और संसाधन उपलब्ध कराते हैं. बेस और सुविधा वाले मॉड्यूल के उलट, आपको कॉन्फ़िगरेशन APKs के लिए अलग मॉड्यूल बनाने की ज़रूरत नहीं होती. अगर आपने अपने बेस और सुविधा वाले मॉड्यूल के लिए, कॉन्फ़िगरेशन के हिसाब से संसाधनों को व्यवस्थित करने के लिए स्टैंडर्ड तरीकों का इस्तेमाल किया है, तो Google Play आपके लिए कॉन्फ़िगरेशन APK अपने-आप जनरेट करेगा.
- फ़ीचर मॉड्यूल APK: इनमें से हर APK में आपके ऐप्लिकेशन की किसी ऐसी सुविधा का कोड और संसाधन शामिल होता है जिसे फ़ीचर मॉड्यूल का इस्तेमाल करके मॉड्यूलर बनाया जाता है. इसके बाद, आपके पास यह तय करने का विकल्प होता है कि किसी डिवाइस पर यह सुविधा कब और कैसे डाउनलोड की जाए. उदाहरण के लिए, Play Core लाइब्रेरी का इस्तेमाल करके, उपयोगकर्ता को अतिरिक्त सुविधाएं देने के लिए, डिवाइस पर बेस APK इंस्टॉल होने के बाद, ज़रूरत के हिसाब से सुविधाएं इंस्टॉल की जा सकती हैं. मान लें कि कोई चैट ऐप्लिकेशन, फ़ोटो खींचने और भेजने की सुविधा को सिर्फ़ तब डाउनलोड और इंस्टॉल करता है, जब उपयोगकर्ता उस सुविधा का इस्तेमाल करने का अनुरोध करता है. ऐसा हो सकता है कि सुविधा मॉड्यूल, इंस्टॉल के समय उपलब्ध न हों. इसलिए, आपको बेस APK में कोई भी सामान्य कोड और संसाधन शामिल करने चाहिए. इसका मतलब है कि आपके सुविधा मॉड्यूल को यह मान लेना चाहिए कि इंस्टॉल के समय सिर्फ़ बेस APK का कोड और संसाधन उपलब्ध हैं. Google Play, आपके प्रोजेक्ट के फ़ीचर मॉड्यूल से आपके ऐप्लिकेशन के लिए फ़ीचर मॉड्यूल के APK जनरेट करता है.
मान लें कि आपके पास तीन सुविधा वाले मॉड्यूल वाला ऐप्लिकेशन है, जो कई डिवाइस कॉन्फ़िगरेशन के साथ काम करता है. नीचे दिए गए पहले चित्र में दिखाया गया है कि ऐप्लिकेशन के अलग-अलग APKs के लिए डिपेंडेंसी ट्री कैसा दिख सकता है. ध्यान दें कि बेस APK, ट्री का हेड होता है और बाकी सभी APK, बेस APK पर निर्भर होते हैं. (अगर आपको यह जानना है कि इन APK के मॉड्यूल, Android ऐप्लिकेशन बंडल में कैसे दिखाए जाते हैं, तो Android ऐप्लिकेशन बंडल का फ़ॉर्मैट देखें.)
पहली इमेज. अलग-अलग डिवाइसों के हिसाब से बनाए गए APK का इस्तेमाल करके दिखाए जाने वाले ऐप्लिकेशन के लिए डिपेंडेंसी ट्री
ध्यान रखें कि आपको इन APK को खुद बनाने की ज़रूरत नहीं है. Google Play, Android Studio की मदद से बनाए गए साइन किए गए एक ऐप्लिकेशन बंडल का इस्तेमाल करके, ऐसा आपके लिए करता है. ऐप्लिकेशन बंडल फ़ॉर्मैट और उसे बनाने के तरीके के बारे में ज़्यादा जानने के लिए, Android ऐप्लिकेशन बंडल बनाना, डिप्लॉय करना, और अपलोड करना लेख पढ़ें.
Android 4.4 (एपीआई लेवल 19) और उससे पहले के वर्शन पर चलने वाले डिवाइस
Android 4.4 (एपीआई लेवल 19) और उससे पहले के वर्शन पर चलने वाले डिवाइसों पर, स्प्लिट APKs को डाउनलोड और इंस्टॉल नहीं किया जा सकता. इसलिए, Google Play उन डिवाइसों पर एक APK उपलब्ध कराता है. इसे मल्टी-APK कहा जाता है. यह डिवाइस के कॉन्फ़िगरेशन के हिसाब से ऑप्टिमाइज़ किया जाता है. इसका मतलब है कि एक से ज़्यादा APK, आपके ऐप्लिकेशन के पूरे अनुभव को दिखाते हैं. हालांकि, इनमें ज़रूरत के मुताबिक कोड और संसाधन शामिल नहीं होते. जैसे, स्क्रीन के अन्य घनत्व और सीपीयू आर्किटेक्चर के लिए ज़रूरी कोड और संसाधन.
हालांकि, इनमें उन सभी भाषाओं के संसाधन शामिल होते हैं जिन पर आपका ऐप्लिकेशन काम करता है. उदाहरण के लिए, इससे उपयोगकर्ताओं को आपके ऐप्लिकेशन की पसंदीदा भाषा की सेटिंग बदलने की सुविधा मिलती है. इसके लिए, उन्हें एक से ज़्यादा APK वाला कोई दूसरा ऐप्लिकेशन डाउनलोड करने की ज़रूरत नहीं पड़ती.
एक से ज़्यादा APK वाले ऐप्लिकेशन में, बाद में मांग पर सुविधा मॉड्यूल डाउनलोड करने की सुविधा नहीं होती. इस APK में कोई सुविधा मॉड्यूल शामिल करने के लिए, आपको सुविधा मॉड्यूल बनाते समय मांग पर उपलब्ध सुविधा को बंद करना होगा या फ़्यूज़िंग सुविधा को चालू करना होगा.
ध्यान रखें कि ऐप्लिकेशन बंडल की मदद से, आपको अपने ऐप्लिकेशन के साथ काम करने वाले हर डिवाइस कॉन्फ़िगरेशन के लिए, APKs बनाने, उन पर हस्ताक्षर करने, अपलोड करने, और उन्हें मैनेज करने की ज़रूरत नहीं होती. अब भी आपको अपने पूरे ऐप्लिकेशन के लिए सिर्फ़ एक ऐप्लिकेशन बंडल बनाना और अपलोड करना होगा. बाकी का काम Google Play करेगा. इसलिए, चाहे आप Android 4.4 या इससे पहले के वर्शन वाले डिवाइसों पर ऐप्लिकेशन उपलब्ध कराना चाहें या नहीं, Google Play आपके और आपके उपयोगकर्ताओं, दोनों के लिए ऐप्लिकेशन उपलब्ध कराने का एक आसान तरीका उपलब्ध कराता है.
उपयोगकर्ता की भाषा में बदलाव
ऐप्लिकेशन बंडल की मदद से, डिवाइस सिर्फ़ वही कोड और संसाधन डाउनलोड करते हैं जो आपके ऐप्लिकेशन को चलाने के लिए ज़रूरी होते हैं. इसलिए, भाषा के संसाधनों के लिए, उपयोगकर्ता का डिवाइस सिर्फ़ आपके ऐप्लिकेशन के उन भाषा के संसाधनों को डाउनलोड करता है जो डिवाइस की सेटिंग में चुनी गई एक या उससे ज़्यादा भाषाओं से मेल खाते हैं.
जब कोई उपयोगकर्ता डिवाइस की सेटिंग में जाकर भाषा बदलता है, तो हो सकता है कि ऐप्लिकेशन को नई भाषा में दिखाने से पहले, Google Play को कुछ और अलग-अलग APK डाउनलोड और इंस्टॉल करने पड़ें.
भाषा बदलने के तुरंत बाद, Google Play अन्य भाषाओं को डाउनलोड करने की कोशिश करता है. अगर उपयोगकर्ता का डिवाइस ऑफ़लाइन है, डाउनलोड पूरा नहीं हो पाता या संसाधन बहुत बड़े हैं, तो Google Play डिवाइस की स्थिति के बेहतर होने पर, बैकग्राउंड में डाउनलोड करने की कोशिश करता है. अगर आपका ऐप्लिकेशन, Android 9.0 (एपीआई लेवल 28) या उससे पहले के वर्शन वाले डिवाइस पर चल रहा है और भाषा के हिसाब से अलग-अलग APKs इंस्टॉल किए जा रहे हैं, तो ऐप्लिकेशन को बंद कर दिया जाता है.
अगर आपके ऐप्लिकेशन के लिए, डिवाइस पर सभी भाषाएं किसी भी समय उपलब्ध होनी चाहिए, तो अपने बिल्ड कॉन्फ़िगरेशन में भाषा के बंटवारे की सुविधा बंद करें.
अगर आपके ऐप्लिकेशन को डिवाइस की सेटिंग में चुनी गई भाषाओं के अलावा, अन्य भाषाओं को डाउनलोड करने की ज़रूरत है, तो Play Core लाइब्रेरी का इस्तेमाल करें. उदाहरण के लिए, ऐप्लिकेशन में भाषा चुनने की सुविधा लागू करने के लिए. ज़रूरत पड़ने पर, इन भाषाओं को डाउनलोड किया जा सकता है.