खास जानकारी

Android डिवाइसों में कई सेक्शन होते हैं, जो बूट प्रोसेस में अलग-अलग फ़ंक्शन करते हैं.

स्टैंडर्ड पार्टिशन

  • boot विभाजन. इस पार्टीशन में एक कर्नेल इमेज होती है और इसे mkbootimg का इस्तेमाल करके बनाया जाता है. किसी भी इमेज को सीधे फ़्लैश करने के लिए, वर्चुअल पार्टीशन का इस्तेमाल किया जा सकता है. इसके लिए, नया बूट पार्टीशन फ़्लैश करने की ज़रूरत नहीं होती. इस सेगमेंट में, Android 13 से पहले लॉन्च किए गए डिवाइसों में मौजूद जेनरिक रैम डिस्क भी शामिल है.

    • कर्नेल. वर्चुअल kernel विभाजन, पुरानी कर्नेल इमेज पर कर्नेल इमेज लिखकर (zImage, zImage-dtb, Image.gz-dtb) कर्नेल इमेज को ओवरराइट कर देता है. अगर दिया गया डेवलपमेंट कर्नेल काम नहीं करता है, तो आपको vendor, system या dtb सेक्शन (अगर मौजूद है) को, उससे जुड़े कर्नेल मॉड्यूल के साथ अपडेट करना पड़ सकता है.

    • ramdisk. वर्चुअल ramdisk विभाजन, पुरानी ramdisk इमेज पर नई ramdisk इमेज को लिख कर रैम डिस्क को बदल देता है.

    ओवरराइट करने की प्रोसेस से, eMMC में मौजूद इमेज की शुरुआती जगह का पता चलता है. साथ ही, नई इमेज को उस जगह पर कॉपी किया जाता है. हो सकता है कि नई इमेज (कर्नल या रैम डिस्क) मौजूदा इमेज से बड़ी हो. जगह बनाने के लिए, बूटलोडर, इमेज के बाद मौजूद डेटा को दूसरी जगह ले जा सकता है या गड़बड़ी की वजह से प्रोसेस को बंद कर सकता है.

  • init_boot पार्टीशन. इस सेगमेंट में, Android 13 और उसके बाद के वर्शन वाले डिवाइसों के लिए सामान्य रैमडिस्क शामिल है.

  • system पार्टीशन. इस पार्टीशन में Android फ़्रेमवर्क होता है.

  • odm विभाजन. इस पार्टीशन में, सिस्टम-ऑन-चिप (SoC) वेंडर बोर्ड-सपोर्ट पैकेज (बीएसपी) के लिए, ओरिजनल डिज़ाइन मैन्युफ़ैक्चरर (ओडीएम) के कस्टमाइज़ेशन शामिल होते हैं. इस तरह के कस्टमाइज़ेशन की मदद से, ओडीएम, SoC कॉम्पोनेंट को बदल सकते हैं या उन्हें पसंद के मुताबिक बना सकते हैं. साथ ही, बोर्ड के हिसाब से कॉम्पोनेंट, डीमन, और हार्डवेयर एब्स्ट्रैक्शन लेयर (एचएएल) पर ओडीएम के हिसाब से बनाई गई सुविधाओं के लिए, कर्नेल मॉड्यूल लागू कर सकते हैं. यह विभाजन ज़रूरी नहीं है. आम तौर पर, इसका इस्तेमाल पसंद के मुताबिक बनाने के लिए किया जाता है, ताकि डिवाइस कई हार्डवेयर एसकेयू के लिए, एक ही वेंडर इमेज का इस्तेमाल कर सकें. ज़्यादा जानकारी के लिए, ओडीएम के पार्टिशन देखें.

  • odm_dlkm विभाजन. यह सेगमेंट, ODM कर्नेल मॉड्यूल को सेव करने के लिए है. odm विभाजन के उलट, odm_dlkm पार्टीशन में ODM कर्नेल मॉड्यूल को स्टोर करने से odm विभाजन को अपडेट किए बिना ODM कर्नेल मॉड्यूल को अपडेट किया जा सकता है.

  • recovery पार्टीशन. इस हिस्से में रिकवरी इमेज सेव होती है, जो ओटीए प्रोसेस के दौरान चालू होती है. बिना किसी रुकावट के अपडेट की सुविधा वाले डिवाइसों में, रिकवरी इमेज को अलग इमेज के बजाय, boot या init_boot इमेज में मौजूद रैम डिस्क के तौर पर सेव किया जा सकता है.

  • cache पार्टीशन. यह विभाजन अस्थायी डेटा को संग्रहित करता है और अगर डिवाइस बिना किसी रुकावट के अपडेट का उपयोग करता है तो यह वैकल्पिक है. कैश पार्टिशन को बूटलोडर से लिखने लायक बनाने की ज़रूरत नहीं है. हालांकि, इसे मिटाने लायक बनाना ज़रूरी है. डिवाइस के टाइप और userdata में जगह की उपलब्धता के हिसाब से, सेगमेंट का साइज़ तय होता है. आम तौर पर, 50 से 100 एमबी का सेगमेंट काफ़ी होता है.

  • misc पार्टीशन. इस सेगमेंट का इस्तेमाल, रिकवरी पार्टीशन में किया जाता है. यह 4 केबी या इससे बड़ा होता है.

  • userdata विभाजन. इस पार्टीशन में, उपयोगकर्ता के इंस्टॉल किए गए ऐप्लिकेशन और डेटा शामिल होता है. इसमें, पसंद के मुताबिक बनाने से जुड़ा डेटा भी शामिल होता है.

  • metadata पार्टीशन. जब डिवाइस मेटाडेटा एन्क्रिप्शन का इस्तेमाल करता है, तो इस पार्टीशन का इस्तेमाल मेटाडेटा एन्क्रिप्शन की को सेव करने के लिए किया जाता है. साइज़ 16 एमबी या उससे ज़्यादा हो. इस डेटा को एन्क्रिप्ट (सुरक्षित) नहीं किया गया है और इसके डेटा का स्नैपशॉट भी नहीं लिया गया है. डिवाइस को फ़ैक्ट्री रीसेट करने पर, यह जानकारी मिट जाती है. इस पार्टीशन का इस्तेमाल, ज़रूरत के हिसाब से ही किया जा सकता है.

  • vendor पार्टीशन. इस पार्टीशन में ऐसी कोई भी बाइनरी शामिल होती है जिसे AOSP में डिस्ट्रिब्यूट नहीं किया जा सकता. अगर डिवाइस में मालिकाना जानकारी नहीं है, तो इस विभाजन को छोड़ा जा सकता है.

  • vendor_dlkm पार्टीशन. यह सेगमेंट, वेंडर के कर्नेल मॉड्यूल को स्टोर करने के लिए है. वेंडर कर्नेल मॉड्यूल को vendor_dlkm partition में सेव करने पर, vendor partition को अपडेट किए बिना ही कर्नेल मॉड्यूल अपडेट किए जा सकते हैं.vendor

  • radio पार्टीशन. इस पार्टीशन में रेडियो इमेज होती है. इसकी ज़रूरत सिर्फ़ उन डिवाइसों के लिए होती है जिनमें रेडियो के लिए खास सॉफ़्टवेयर के साथ रेडियो होता है.

  • tos पार्टीशन. इस पार्टीशन में, Trusty OS की बाइनरी इमेज सेव होती है. इसका इस्तेमाल सिर्फ़ तब किया जाता है, जब डिवाइस में Trusty हो. ज़्यादा जानकारी के लिए, सेवा की शर्तों के बंटवारे की जानकारी देखें.

  • pvmfw पार्टीशन. इस पार्टीशन में, सुरक्षित वर्चुअल मशीन फ़र्मवेयर (pvmfw) सेव होता है. यह पहला कोड होता है, जो सुरक्षित वर्चुअल मशीन में चलता है. ज़्यादा जानकारी के लिए, सुरक्षित वर्चुअल मशीन फ़र्मवेयर देखें.

डाइनैमिक पार्टीशन

Android 11 और इसके बाद के वर्शन पर चलने वाले डिवाइसों में डाइनैमिक पार्टिशन की सुविधा काम करती है. यह Android के लिए, उपयोगकर्ता स्पेस का पार्टिशन करने वाला सिस्टम है. इसकी मदद से, ओवर-द-एयर (ओटीए) अपडेट के दौरान, पार्टिशन बनाए जा सकते हैं, उनका साइज़ बदला जा सकता है या उन्हें मिटाया जा सकता है. ज़्यादा जानकारी के लिए, डाइनैमिक पार्टिशन देखें.

ज़रूरी पार्टीशन तय करना

अगर डिवाइस को चलने के लिए किसी खास पार्टीशन या डेटा की ज़रूरत है, तो आपको उन पार्टीशन या डेटा को पूरी तरह से सुरक्षित या फिर से फ़्लैश किया जा सकने वाला के तौर पर सेट करना होगा. इसका मतलब है कि उन्हें fastboot oem कमांड का इस्तेमाल करके फिर से बनाया जा सकता है, उपलब्ध कराया जा सकता है या निकाला जा सकता है. इसमें, हर डिवाइस के हिसाब से फ़ैक्ट्री सेटअप की सेटिंग, सीरियल नंबर, कैलिब्रेशन डेटा वगैरह शामिल होता है.

Android 11 में किए गए बदलाव

Android 11 में, पार्टीशन में कई बदलाव किए गए हैं. इनमें, लाइब्रेरी से लिंक करने पर पाबंदियां और Soong इमेज के नए वैरिएंट शामिल हैं.

Android पार्टीशन का लेआउट

पहली इमेज. Android 11 में पार्टीशन का लेआउट

  • सिंगल सिस्टम इमेज (एसएसआई). नई और कॉन्सेप्चुअल इमेज, जिसमें system और system_ext इमेज शामिल हैं. जब ये पार्टीशन, टारगेट किए गए डिवाइसों के किसी सेट के लिए सामान्य होते हैं, तो वे डिवाइस एसएसआई शेयर कर सकते हैं और system और system_ext इमेज बनाने की प्रोसेस को छोड़ सकते हैं.

  • system_ext विभाजन. एक नया पार्टिशन जो system संसाधनों का इस्तेमाल कर सकता है और इसमें ऐसे सिस्टम मॉड्यूल शामिल हो सकते हैं जो:

    • system पार्टीशन में एओएसपी सिस्टम मॉड्यूल को बढ़ाएं. हमारा सुझाव है कि आप ऐसे मॉड्यूल को AOSP में अपस्ट्रीम करें, ताकि उन्हें बाद में system partition में इंस्टॉल किया जा सके.

    • OEM या SoC के हिसाब से बंडल किए गए मॉड्यूल. हमारा सुझाव है कि ऐसे मॉड्यूल को अलग करें, ताकि उन्हें product या vendor पार्टीशन में इंस्टॉल किया जा सके.

  • system विभाजन. OEM प्रॉडक्ट के लिए इस्तेमाल की जाने वाली सामान्य सिस्टम इमेज. हमारा सुझाव है कि मालिकाना मॉड्यूल को system पार्टीशन से हटाएं. इसके लिए, उन्हें AOSP में अपस्ट्रीम करें या system_ext पार्टीशन में ले जाएं.

  • product पार्टीशन. अब इस पार्टीशन में, अनुमति वाले इंटरफ़ेस का इस्तेमाल करके, प्रॉडक्ट के हिसाब से ऐसे मॉड्यूल इंस्टॉल किए जा सकते हैं जो किसी दूसरे पार्टीशन के साथ बंडल नहीं किए गए हैं.

VNDK में हुए बदलाव

वेंडर नेटिव डेवलपमेंट किट (VNDK), system सेक्शन में इंस्टॉल की गई लाइब्रेरी का एक सेट है. इसे खास तौर पर वेंडर के लिए डिज़ाइन किया गया है, ताकि वे अपने एचएएल लागू कर सकें.

  • Android 10 और उससे पहले के वर्शन में, vendor पार्टीशन, system पार्टीशन में मौजूद VNDK लाइब्रेरी से लिंक हो सकता है. हालांकि, वह system पार्टीशन में मौजूद अन्य लाइब्रेरी से लिंक नहीं हो सकता. product पार्टीशन में मौजूद नेटिव मॉड्यूल, system पार्टीशन में मौजूद किसी भी लाइब्रेरी से लिंक कर सकते हैं.

  • Android 11 और उसके बाद के वर्शन में, product और vendor पार्टिशन, system पार्टिशन में मौजूद VNDK लाइब्रेरी से लिंक किए जा सकते हैं. हालांकि, ये system पार्टिशन में मौजूद अन्य लाइब्रेरी से लिंक नहीं किए जा सकते.

Soong के प्रॉडक्ट के वैरिएंट

Soong बिल्ड सिस्टम, डिपेंडेंसी को अलग-अलग करने के लिए इमेज के वैरिएंट का इस्तेमाल करता है. नेटिव मॉड्यूल (/build/soong/cc), सिस्टम प्रोसेस मॉड्यूल को मुख्य वैरिएंट और वेंडर प्रोसेस मॉड्यूल को वेंडर वैरिएंट में बदल सकता है. हालांकि, इमेज के एक वैरिएंट का मॉड्यूल, इमेज के किसी दूसरे वैरिएंट के मॉड्यूल से लिंक नहीं कर सकता है.

  • Android 10 या उससे पहले के वर्शन में, सिस्टम मॉड्यूल अपने-आप मुख्य वैरिएंट बनाता है. यह अपनी Android.bp फ़ाइलों में vendor_available: true तय करके, वेंडर वैरिएंट भी बना सकता है. इससे वेंडर मॉड्यूल, सिस्टम मॉड्यूल से लिंक हो पाते हैं. वीएनडीके लाइब्रेरी, जो system लाइब्रेरी के वेंडर वैरिएंट हैं. इन लाइब्रेरी की Android.bp फ़ाइलों में vendor_available: true की जानकारी देकर भी, वेंडर मॉड्यूल के लिए वेंडर वैरिएंट बनाए जा सकते हैं (उदाहरण देखें).

  • Android 11 में, कोई सिस्टम मॉड्यूल vendor_available: true तय करके, कोर और वेंडर वैरिएंट के अलावा प्रॉडक्ट वैरिएंट भी बना सकता है.

  • Android 12 या उसके बाद के वर्शन में, vendor_available: true वाला सिस्टम मॉड्यूल, मुख्य वैरिएंट के अलावा वेंडर वैरिएंट बनाता है. प्रॉडक्ट का वैरिएंट बनाने के लिए, product_available: true की वैल्यू तय होनी चाहिए. product_available: true के बिना काम करने वाली कुछ VNDK लाइब्रेरी, प्रॉडक्ट मॉड्यूल के लिए उपलब्ध नहीं हैं.