खास जानकारी

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

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

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

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

    • ramdisk. वर्चुअल ramdisk पार्टीशन, पुरानी रैमडиск इमेज पर नई रैमडиск इमेज लिखकर, रैमडиск को ओवरराइट करता है.

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

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

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

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

  • odm_dlkm पार्टीशन. यह पार्टीशन, ओडीएम कर्नेल के मॉड्यूल को सेव करने के लिए है. odm_dlkm पार्टीशन में ODM के kernel मॉड्यूल स्टोर करने पर, odm पार्टीशन को अपडेट किए बिना ही ODM के kernel मॉड्यूल अपडेट किए जा सकते हैं.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 सिस्टम मॉड्यूल जोड़ें. हमारा सुझाव है कि आप ऐसे मॉड्यूल को AOSP में अपस्ट्रीम करें, ताकि उन्हें बाद में system partition में इंस्टॉल किया जा सके.

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

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

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

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

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

  • 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 तय करके, वेंडर वैरिएंट भी बना सकता है. इससे वेंडर मॉड्यूल, सिस्टम मॉड्यूल से लिंक हो पाते हैं. VNDK लाइब्रेरी, system लाइब्रेरी के वेंडर वैरिएंट हैं. ये लाइब्रेरी, अपनी Android.bp फ़ाइलों में vendor_available: true तय करके, वेंडर मॉड्यूल के लिए वेंडर वैरिएंट भी बना सकती हैं. उदाहरण देखें.

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

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