पार्टीशन के बारे में खास जानकारी

Android डिवाइसों में कई पार्टिशन या स्टोरेज के खास सेक्शन होते हैं. इनका इस्तेमाल डिवाइस के सॉफ़्टवेयर के खास हिस्सों को सेव करने के लिए किया जाता है. हर पार्टीशन में, पार्टिशन इमेज (एक IMG फ़ाइल) या पार्टीशन के सभी सॉफ़्टवेयर का स्नैपशॉट होता है. पहली इमेज में, किसी डिवाइस पर मौजूद मुख्य पार्टीशन का लेआउट दिखाया गया है:

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

पार्टिशन को तीन कैटगरी में बांटा गया है:

• सिस्टम पार्टीशन ऐसे पार्टीशन होते हैं जिन्हें ओएस और अन्य सुविधाओं को अपडेट करते समय अपडेट किया जाता है. system, boot, और init_boot, कोर सिस्टम के पार्टीशन हैं.

• वेंडर पार्टीशन में डिवाइस और हार्डवेयर से जुड़ा कोड होता है. ऐसा हो सकता है कि शुरुआती रिलीज़ के बाद, इसे कभी अपडेट न किया जाए. vendor, vendor_boot, और odm पार्टिशन, वेंडर के मुख्य पार्टिशन होते हैं.

• अपडेट नहीं किए जा सकने वाले पार्टीशन ऐसे पार्टीशन होते हैं जिनके कॉन्टेंट को अपडेट नहीं किया जाता या उपयोगकर्ता के डेटा के साथ अपडेट किया जाता है.

सिस्टम और वेंडर पार्टिशन में मौजूद कोड, वेंडर इंटरफ़ेस (वीआईएनटीएफ़) नाम के स्टेबल इंटरफ़ेस का इस्तेमाल करके इंटरैक्ट कर सकते हैं.

सिस्टम के सेगमेंट

यहां सभी सिस्टम पार्टीशन और उनके इस्तेमाल की सूची दी गई है:

• boot पार्टीशन. इस पार्टीशन में जेनरिक कर्नल इमेज (जीकेआई) शामिल है. इस पार्टीशन में, Android 12 और उससे पहले के वर्शन में लॉन्च किए गए डिवाइसों में मौजूद सामान्य रैमडिस्क भी शामिल होता है. जेनरिक रैमडिस्क के बारे में ज़्यादा जानने के लिए, जेनरिक रैमडिस्क इमेज का कॉन्टेंट देखें.

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

• system पार्टीशन. इस पार्टीशन में, ओईएम प्रॉडक्ट के लिए इस्तेमाल की गई सिस्टम इमेज होती है.

• system_ext पार्टीशन. इस पार्टिशन में सिस्टम के संसाधन और मालिकाना हक वाले सिस्टम मॉड्यूल होते हैं. ये system पार्टिशन में मौजूद सामान्य सिस्टम इमेज को बढ़ाते हैं.

• system_dlkm पार्टीशन. इस पार्टीशन में GKI मॉड्यूल होते हैं. इस पार्टीशन के बारे में ज़्यादा जानकारी के लिए, GKI मॉड्यूल पार्टीशन लागू करना लेख पढ़ें.

• product पार्टीशन. इस पार्टीशन में प्रॉडक्ट के हिसाब से मॉड्यूल शामिल हो सकते हैं. इन्हें किसी दूसरे पार्टीशन के साथ बंडल नहीं किया जाता है.

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

• generic_bootloader पार्टीशन. इस पार्टीशन में सामान्य बूटलोडर होता है.

वेंडर के सेगमेंट

यहां सभी वेंडर पार्टीशन और उनके इस्तेमाल की जानकारी दी गई है:

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

• recovery पार्टीशन. इस पार्टीशन में रिकवरी इमेज सेव होती है. इसे ओवर-द-एयर (OTA) अपडेट की प्रोसेस के दौरान बूट किया जाता है. जिन डिवाइसों पर बिना किसी रुकावट के अपडेट इंस्टॉल किए जा सकते हैं वे रिकवरी इमेज को boot या init_boot इमेज में शामिल रैमडिस्क के तौर पर सेव कर सकते हैं. बिना किसी रुकावट के अपडेट होने की सुविधा के बारे में ज़्यादा जानने के लिए, A/B (बिना किसी रुकावट के) अपडेट देखें.

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

• vbmeta पार्टीशन. इस पार्टीशन में, सभी पार्टीशन के लिए वेरिफ़ाइड बूट की जानकारी होती है. इस जानकारी से यह पुष्टि होती है कि हर पार्टीशन में इंस्टॉल की गई इमेज भरोसेमंद हैं. वेरिफ़ाइड बूट के बारे में ज़्यादा जानने के लिए, वेरिफ़ाइड बूट लेख पढ़ें.

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

• vendor_dlkm पार्टीशन. इस पार्टीशन में वेंडर कर्नल मॉड्यूल होते हैं. वेंडर कर्नेल मॉड्यूल को vendor पार्टिशन के बजाय इस पार्टिशन में सेव करके, vendor पार्टिशन को अपडेट किए बिना कर्नेल मॉड्यूल को अपडेट किया जा सकता है. ज़्यादा जानकारी के लिए, वेंडर और ओडीएम के DKLM पार्टीशन लेख पढ़ें.

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

• odm_dlkm पार्टीशन. इस पार्टीशन का इस्तेमाल, ओडीएम कर्नल मॉड्यूल को सेव करने के लिए किया जाता है. ODM कर्नेल मॉड्यूल को odm पार्टिशन के बजाय इस पार्टिशन में सेव करके, odm पार्टिशन को अपडेट किए बिना ODM कर्नेल मॉड्यूल को अपडेट किया जा सकता है. ज़्यादा जानकारी के लिए, वेंडर और ओडीएम के DKLM पार्टीशन लेख पढ़ें.

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

अपडेट नहीं किए जा सकने वाले पार्टिशन

यहां उन सभी पार्टिशन की सूची दी गई है जिन्हें अपडेट नहीं किया जा सकता. साथ ही, उनके इस्तेमाल के बारे में भी बताया गया है:

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

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

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

पार्टिशन अपडेट करने के नियम और सुझाव

हमारा सुझाव है कि सभी सिस्टम पार्टीशन को एक साथ और सभी वेंडर पार्टीशन को एक साथ अपडेट करें. पार्टिशन के पूरे सेट को अपडेट करके, यह जांच की जा सकती है कि हर पार्टिशन में मौजूद इमेज के बीच इंटरफ़ेस स्थिर रहे.

पार्टिशन को अपडेट करने का तरीका चाहे जो भी हो, यहां दिए गए पार्टिशन को अपडेट करना ज़रूरी है. ऐसा इसलिए, क्योंकि ये एक-दूसरे से जुड़े हुए हैं और इनके लिए स्टेबल एपीआई उपलब्ध नहीं हैं:

• boot और system_dlkm पार्टीशन
• init_boot, system, system_ext, और product पार्टीशन

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

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

सूनग प्रॉडक्ट के वैरिएंट

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

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