इस पेज का अनुवाद Cloud Translation API से किया गया है.

गतिशील विभाजन लागू करें

डायनेमिक विभाजन को लिनक्स कर्नेल में डीएम-लीनियर डिवाइस-मैपर मॉड्यूल का उपयोग करके कार्यान्वित किया जाता है। super विभाजन में super के भीतर प्रत्येक गतिशील विभाजन के नाम और ब्लॉक श्रेणियों को सूचीबद्ध करने वाला मेटाडेटा शामिल है। प्रथम-चरण init के दौरान, इस मेटाडेटा को पार्स और मान्य किया जाता है, और प्रत्येक गतिशील विभाजन का प्रतिनिधित्व करने के लिए वर्चुअल ब्लॉक डिवाइस बनाए जाते हैं।

ओटीए लागू करते समय, आवश्यकतानुसार डायनामिक विभाजन स्वचालित रूप से बनाए जाते हैं, आकार बदलते हैं या हटा दिए जाते हैं। ए/बी उपकरणों के लिए, मेटाडेटा की दो प्रतियां हैं, और परिवर्तन केवल लक्ष्य स्लॉट का प्रतिनिधित्व करने वाली प्रतिलिपि पर लागू होते हैं।

क्योंकि डायनेमिक विभाजन उपयोक्ता स्थान में कार्यान्वित किए जाते हैं, बूटलोडर के लिए आवश्यक विभाजन को गतिशील नहीं बनाया जा सकता है। उदाहरण के लिए, boot , dtbo , और vbmeta बूटलोडर द्वारा पढ़ा जाता है, और इसलिए उन्हें भौतिक विभाजन के रूप में रहना चाहिए।

प्रत्येक गतिशील विभाजन एक अद्यतन समूह से संबंधित हो सकता है। ये समूह उस अधिकतम स्थान को सीमित करते हैं जो उस समूह में विभाजन उपभोग कर सकता है। उदाहरण के लिए, system और vendor एक ऐसे समूह से संबंधित हो सकते हैं जो system और vendor के कुल आकार को प्रतिबंधित करता है।

नए उपकरणों पर गतिशील विभाजन लागू करें

यह अनुभाग विवरण देता है कि एंड्रॉइड 10 और उच्चतर के साथ लॉन्च होने वाले नए उपकरणों पर गतिशील विभाजन कैसे लागू किया जाए। मौजूदा डिवाइस को अपडेट करने के लिए, एंड्रॉइड डिवाइस को अपग्रेड करना देखें।

विभाजन परिवर्तन

एंड्रॉइड 10 के साथ लॉन्च होने वाले उपकरणों के लिए, super नामक एक विभाजन बनाएं। super विभाजन आंतरिक रूप से ए/बी स्लॉट को संभालता है, इसलिए ए/बी उपकरणों को अलग-अलग super_a और super_b विभाजन की आवश्यकता नहीं होती है। बूटलोडर द्वारा उपयोग नहीं किए जाने वाले सभी रीड-ओनली AOSP विभाजन गतिशील होने चाहिए और उन्हें GUID विभाजन तालिका (GPT) से हटा दिया जाना चाहिए। विक्रेता-विशिष्ट विभाजनों को गतिशील होना आवश्यक नहीं है और उन्हें GPT में रखा जा सकता है।

नोट: userdata या किसी अन्य स्थायी रीड-राइट विभाजन को super के अंदर रखने से बचें।

super के आकार का अनुमान लगाने के लिए, GPT से हटाए जा रहे विभाजन के आकार जोड़ें। ए/बी उपकरणों के लिए, इसमें दोनों स्लॉट का आकार शामिल होना चाहिए। चित्र 1 गतिशील विभाजन में परिवर्तित होने से पहले और बाद में एक उदाहरण विभाजन तालिका दिखाता है।

**चित्र 1.** गतिशील विभाजन में कनवर्ट करते समय नया भौतिक विभाजन तालिका लेआउट

समर्थित गतिशील विभाजन हैं:

प्रणाली
विक्रेता
उत्पाद
सिस्टम एक्सटेंशन
ओडीएम

एंड्रॉइड 10 के साथ लॉन्च होने वाले उपकरणों के लिए, कर्नेल कमांड लाइन विकल्प androidboot.super_partition खाली होना चाहिए ताकि कमांड sysprop ro.boot.super_partition खाली हो।

विभाजन संरेखण

यदि super विभाजन ठीक से संरेखित नहीं है तो डिवाइस-मैपर मॉड्यूल कम कुशलता से काम कर सकता है। super विभाजन को ब्लॉक परत द्वारा निर्धारित न्यूनतम I/O अनुरोध आकार के अनुरूप होना चाहिए। डिफ़ॉल्ट रूप से, बिल्ड सिस्टम ( lpmake के माध्यम से, जो super विभाजन छवि उत्पन्न करता है), मानता है कि प्रत्येक गतिशील विभाजन के लिए 1 MiB संरेखण पर्याप्त है। हालाँकि, विक्रेताओं को यह सुनिश्चित करना चाहिए कि super विभाजन ठीक से संरेखित है।

आप sysfs निरीक्षण करके किसी ब्लॉक डिवाइस का न्यूनतम अनुरोध आकार निर्धारित कर सकते हैं। उदाहरण के लिए:

# ls -l /dev/block/by-name/super
lrwxrwxrwx 1 root root 16 1970-04-05 01:41 /dev/block/by-name/super -> /dev/block/sda17
# cat /sys/block/sda/queue/minimum_io_size
786432

आप super पार्टीशन के संरेखण को इसी तरह से सत्यापित कर सकते हैं:

# cat /sys/block/sda/sda17/alignment_offset

संरेखण ऑफसेट 0 होना चाहिए।

डिवाइस कॉन्फ़िगरेशन बदलता है

गतिशील विभाजन को सक्षम करने के लिए, device.mk में निम्नलिखित ध्वज जोड़ें:

PRODUCT_USE_DYNAMIC_PARTITIONS := true

बोर्ड कॉन्फ़िगरेशन बदलता है

आपको super पार्टीशन का आकार सेट करना आवश्यक है:

BOARD_SUPER_PARTITION_SIZE := <size-in-bytes>

ए/बी उपकरणों पर, यदि गतिशील विभाजन छवियों का कुल आकार super विभाजन आकार के आधे से अधिक है, तो बिल्ड सिस्टम एक त्रुटि उत्पन्न करता है।

आप डायनामिक विभाजनों की सूची को निम्नानुसार कॉन्फ़िगर कर सकते हैं। अद्यतन समूहों का उपयोग करने वाले उपकरणों के लिए, समूहों को BOARD_SUPER_PARTITION_GROUPS चर में सूचीबद्ध करें। प्रत्येक समूह नाम में एक BOARD_ group _SIZE और BOARD_ group _PARTITION_LIST चर होता है। ए/बी उपकरणों के लिए, समूह का अधिकतम आकार केवल एक स्लॉट को कवर करना चाहिए, क्योंकि समूह के नाम आंतरिक रूप से स्लॉट-प्रत्यय के साथ जुड़े होते हैं।

यहां एक उदाहरण उपकरण है जो सभी विभाजनों को example_dynamic_partitions नामक समूह में रखता है:

BOARD_SUPER_PARTITION_GROUPS := example_dynamic_partitions
BOARD_EXAMPLE_DYNAMIC_PARTITIONS_SIZE := 6442450944
BOARD_EXAMPLE_DYNAMIC_PARTITIONS_PARTITION_LIST := system vendor product

यहां एक उदाहरण उपकरण है जो सिस्टम और उत्पाद सेवाओं को group_foo में रखता है, और vendor , product और odm group_bar में रखता है:

BOARD_SUPER_PARTITION_GROUPS := group_foo group_bar
BOARD_GROUP_FOO_SIZE := 4831838208
BOARD_GROUP_FOO_PARTITION_LIST := system product_services
BOARD_GROUP_BAR_SIZE := 1610612736
BOARD_GROUP_BAR_PARTITION_LIST := vendor product odm

ध्यान दें: ऐसे नाम चुनने से बचें जो बिल्ड वेरिएबल्स के साथ टकराव कर सकते हैं, जैसे कि सुपर और सुपर_पार्टिशन । पठनीयता के लिए, foo_dp , foo_dynamic_partitions , foo_dp_group , super_foo , या Group_foo जैसे नाम चुनें (जहां foo उस पार्टी का नाम है जो किसी दिए गए समूह को अपडेट करता है)। उदाहरण के लिए, group_OEM या group_VENDOR ।

वर्चुअल ए/बी लॉन्च डिवाइस के लिए, सभी समूहों के अधिकतम आकारों का योग अधिकतम होना चाहिए:
BOARD_SUPER_PARTITION_SIZE - ओवरहेड
वर्चुअल ए/बी लागू करना देखें।
ए/बी लॉन्च उपकरणों के लिए, सभी समूहों के अधिकतम आकारों का योग होना चाहिए:
BOARD_SUPER_PARTITION_SIZE / 2 - ओवरहेड
गैर-ए/बी उपकरणों और रेट्रोफिट ए/बी उपकरणों के लिए, सभी समूहों के अधिकतम आकारों का योग होना चाहिए:
BOARD_SUPER_PARTITION_SIZE - ओवरहेड
निर्माण के समय, अद्यतन समूह में प्रत्येक विभाजन की छवियों के आकार का योग समूह के अधिकतम आकार से अधिक नहीं होना चाहिए।
मेटाडेटा, संरेखण इत्यादि को ध्यान में रखते हुए गणना में ओवरहेड की आवश्यकता होती है। एक उचित ओवरहेड 4 MiB है, लेकिन आप डिवाइस की आवश्यकता के अनुसार बड़ा ओवरहेड चुन सकते हैं।

आकार गतिशील विभाजन

गतिशील विभाजन से पहले, यह सुनिश्चित करने के लिए कि उनमें भविष्य के अपडेट के लिए पर्याप्त जगह हो, विभाजन आकारों को अत्यधिक आवंटित किया गया था। वास्तविक आकार वैसे ही लिया गया था और अधिकांश रीड-ओनली विभाजनों के फ़ाइल सिस्टम में कुछ मात्रा में खाली स्थान था। गतिशील विभाजन में, वह खाली स्थान अनुपयोगी होता है और इसका उपयोग ओटीए के दौरान विभाजन को बढ़ाने के लिए किया जा सकता है। यह सुनिश्चित करना महत्वपूर्ण है कि विभाजन स्थान बर्बाद नहीं कर रहे हैं और न्यूनतम संभव आकार में आवंटित किए गए हैं।

केवल पढ़ने योग्य ext4 छवियों के लिए, यदि कोई हार्डकोडेड विभाजन आकार निर्दिष्ट नहीं है तो बिल्ड सिस्टम स्वचालित रूप से न्यूनतम आकार आवंटित करता है। बिल्ड सिस्टम छवि को फिट करता है ताकि फ़ाइल सिस्टम में यथासंभव कम अप्रयुक्त स्थान हो। यह सुनिश्चित करता है कि डिवाइस उस स्थान को बर्बाद नहीं करता है जिसका उपयोग ओटीए के लिए किया जा सकता है।

इसके अतिरिक्त, ब्लॉक-स्तरीय डिडुप्लीकेशन को सक्षम करके ext4 छवियों को और अधिक संपीड़ित किया जा सकता है। इसे सक्षम करने के लिए, निम्न कॉन्फ़िगरेशन का उपयोग करें:

BOARD_EXT4_SHARE_DUP_BLOCKS := true

यदि किसी विभाजन के न्यूनतम आकार का स्वचालित आवंटन अवांछनीय है, तो विभाजन के आकार को नियंत्रित करने के दो तरीके हैं। आप BOARD_ partition IMAGE_PARTITION_RESERVED_SIZE के साथ न्यूनतम खाली स्थान निर्दिष्ट कर सकते हैं, या आप गतिशील विभाजन को एक विशिष्ट आकार में बाध्य करने के लिए BOARD_ partition IMAGE_PARTITION_SIZE निर्दिष्ट कर सकते हैं। जब तक आवश्यक न हो इनमें से किसी की भी अनुशंसा नहीं की जाती है।

उदाहरण के लिए:

BOARD_PRODUCTIMAGE_PARTITION_RESERVED_SIZE := 52428800

यह product.img में फ़ाइल सिस्टम को 50 MiB अप्रयुक्त स्थान के लिए बाध्य करता है।

सिस्टम-ए-रूट परिवर्तन

एंड्रॉइड 10 के साथ लॉन्च होने वाले उपकरणों को सिस्टम-एज़-रूट का उपयोग नहीं करना चाहिए।

डायनामिक विभाजन वाले डिवाइस (चाहे वह डायनामिक विभाजन के साथ लॉन्च हो या रेट्रोफ़िट हो) को सिस्टम-एज़-रूट का उपयोग नहीं करना चाहिए। लिनक्स कर्नेल super विभाजन की व्याख्या नहीं कर सकता है और इसलिए system स्वयं माउंट नहीं कर सकता है। system अब प्रथम-चरण init द्वारा माउंट किया गया है, जो रैमडिस्क में रहता है।

BOARD_BUILD_SYSTEM_ROOT_IMAGE सेट न करें. एंड्रॉइड 10 में, BOARD_BUILD_SYSTEM_ROOT_IMAGE ध्वज का उपयोग केवल यह अंतर करने के लिए किया जाता है कि सिस्टम कर्नेल द्वारा माउंट किया गया है या रैमडिस्क में प्रथम-चरण init द्वारा।

BOARD_BUILD_SYSTEM_ROOT_IMAGE को true पर सेट करने से PRODUCT_USE_DYNAMIC_PARTITIONS भी true होने पर बिल्ड त्रुटि उत्पन्न होती है।

जब BOARD_USES_RECOVERY_AS_BOOT को सत्य पर सेट किया जाता है, तो पुनर्प्राप्ति छवि को Boot.img के रूप में बनाया जाता है, जिसमें पुनर्प्राप्ति की रैमडिस्क होती है। पहले, बूटलोडर ने यह तय करने के लिए कि किस मोड में बूट करना है, skip_initramfs कर्नेल कमांड लाइन पैरामीटर का उपयोग किया था। एंड्रॉइड 10 उपकरणों के लिए, बूटलोडर को skip_initramfs कर्नेल कमांड-लाइन पर पास नहीं करना चाहिए। इसके बजाय, पुनर्प्राप्ति को छोड़ने और सामान्य एंड्रॉइड को बूट करने के लिए बूटलोडर को androidboot.force_normal_boot=1 पास करना चाहिए। Android 12 या उसके बाद के संस्करण के साथ लॉन्च होने वाले उपकरणों को androidboot.force_normal_boot=1 पास करने के लिए Bootconfig का उपयोग करना होगा।

AVB कॉन्फ़िगरेशन बदलता है

एंड्रॉइड सत्यापित बूट 2.0 का उपयोग करते समय, यदि डिवाइस श्रृंखलाबद्ध विभाजन डिस्क्रिप्टर का उपयोग नहीं कर रहा है, तो कोई बदलाव आवश्यक नहीं है। हालाँकि, यदि श्रृंखलाबद्ध विभाजन का उपयोग किया जा रहा है और सत्यापित विभाजनों में से एक गतिशील है, तो परिवर्तन आवश्यक हैं।

यहां एक डिवाइस के लिए एक उदाहरण कॉन्फ़िगरेशन है जो system और vendor विभाजन के लिए vbmeta जोड़ता है।

BOARD_AVB_SYSTEM_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem
BOARD_AVB_SYSTEM_ALGORITHM := SHA256_RSA2048
BOARD_AVB_SYSTEM_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP)
BOARD_AVB_SYSTEM_ROLLBACK_INDEX_LOCATION := 1

BOARD_AVB_VENDOR_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem
BOARD_AVB_VENDOR_ALGORITHM := SHA256_RSA2048
BOARD_AVB_VENDOR_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP)
BOARD_AVB_VENDOR_ROLLBACK_INDEX_LOCATION := 1

इस कॉन्फ़िगरेशन के साथ, बूटलोडर system और vendor विभाजन के अंत में एक vbmeta पाद लेख खोजने की उम्मीद करता है। क्योंकि ये विभाजन अब बूटलोडर को दिखाई नहीं देते हैं (वे super में रहते हैं), दो परिवर्तनों की आवश्यकता है।

डिवाइस की विभाजन तालिका में vbmeta_system और vbmeta_vendor विभाजन जोड़ें। ए/बी उपकरणों के लिए, vbmeta_system_a , vbmeta_system_b , vbmeta_vendor_a , और vbmeta_vendor_b जोड़ें। यदि इनमें से एक या अधिक विभाजन जोड़ते हैं, तो उनका आकार vbmeta विभाजन के समान होना चाहिए।

VBMETA_ जोड़कर कॉन्फ़िगरेशन फ़्लैग का नाम बदलें और निर्दिष्ट करें कि चेनिंग किस विभाजन तक फैली हुई है:

BOARD_AVB_VBMETA_SYSTEM := system
BOARD_AVB_VBMETA_SYSTEM_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem
BOARD_AVB_VBMETA_SYSTEM_ALGORITHM := SHA256_RSA2048
BOARD_AVB_VBMETA_SYSTEM_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP)
BOARD_AVB_VBMETA_SYSTEM_ROLLBACK_INDEX_LOCATION := 1

BOARD_AVB_VBMETA_VENDOR := vendor
BOARD_AVB_VBMETA_VENDOR_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem
BOARD_AVB_VBMETA_VENDOR_ALGORITHM := SHA256_RSA2048
BOARD_AVB_VBMETA_VENDOR_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP)
BOARD_AVB_VBMETA_VENDOR_ROLLBACK_INDEX_LOCATION := 1

कोई डिवाइस इनमें से एक, दोनों या किसी भी विभाजन का उपयोग नहीं कर सकता है। परिवर्तनों की आवश्यकता केवल तार्किक विभाजन से जुड़ते समय ही होती है।

AVB बूटलोडर बदलता है

यदि बूटलोडर में libavb एम्बेडेड है, तो निम्नलिखित पैच शामिल करें:

818cf56740775446285466eda984acedd4baeac0 - "libavb: केवल विभाजन GUID को क्वेरी करें जब cmdline को उनकी आवश्यकता हो।"
5abd6bc2578968d24406d834471adfd995a0c2e9 - "सिस्टम विभाजन को अनुपस्थित रहने की अनुमति दें"
9ba3b6613b4e5130fa01a11d984c6b5f0eb3af05 - "AvbSlotVerifyData ठीक करें->cmdline शून्य हो सकती है"

यदि जंजीर विभाजन का उपयोग कर रहे हैं, तो एक अतिरिक्त पैच शामिल करें:

49936b4c0109411fdd38bd4ba3a32a01c40439a9 - "libavb: विभाजन की शुरुआत में vbmeta ब्लॉब्स का समर्थन करें।"
नोट: पहले, AvbOps में get_size_of_partition लागू करना वैकल्पिक था। इस परिवर्तन के बाद यह आवश्यक है, और बूटलोडर को इस फ़ंक्शन को लागू करना होगा।

कर्नेल कमांड लाइन बदल जाती है

एक नया पैरामीटर, androidboot.boot_devices , कर्नेल कमांड लाइन में जोड़ा जाना चाहिए। इसका उपयोग init द्वारा /dev/block/by-name सिम्लिंक को सक्षम करने के लिए किया जाता है। यह ueventd द्वारा बनाए गए अंतर्निहित उप-नाम सिम्लिंक का डिवाइस पथ घटक होना चाहिए, अर्थात, /dev/block/platform/ device-path /by-name/ partition-name Android 12 या उसके बाद के संस्करण के साथ लॉन्च होने वाले उपकरणों को androidboot.boot_devices init में पास करने के लिए Bootconfig का उपयोग करना होगा।

उदाहरण के लिए, यदि सुपर पार्टीशन बाय-नेम सिम्लिंक /dev/block/platform/ soc/100000.ufshc /by-name/super है, तो आप BoardConfig.mk फ़ाइल में कमांड लाइन पैरामीटर को इस प्रकार जोड़ सकते हैं:

BOARD_KERNEL_CMDLINE += androidboot.boot_devices=soc/100000.ufshc

आपboardConfig.mk फ़ाइल में बूटकॉन्फिग पैरामीटर को इस प्रकार जोड़ सकते हैं:

BOARD_BOOTCONFIG += androidboot.boot_devices=soc/100000.ufshc

fstab परिवर्तन

डिवाइस ट्री और डिवाइस ट्री ओवरले में fstab प्रविष्टियाँ नहीं होनी चाहिए। एक fstab फ़ाइल का उपयोग करें जो रैमडिस्क का हिस्सा होगी।

तार्किक विभाजन के लिए fstab फ़ाइल में परिवर्तन किए जाने चाहिए:

fs_mgr फ़्लैग फ़ील्ड में logical फ़्लैग और first_stage_mount फ़्लैग शामिल होना चाहिए, जो एंड्रॉइड 10 में पेश किया गया है, जो इंगित करता है कि पहले चरण में एक विभाजन माउंट किया जाना है।
एक विभाजन avb= vbmeta partition name fs_mgr ध्वज के रूप में निर्दिष्ट कर सकता है और फिर किसी भी डिवाइस को माउंट करने का प्रयास करने से पहले निर्दिष्ट vbmeta विभाजन को पहले चरण init द्वारा प्रारंभ किया जाता है।
dev फ़ील्ड विभाजन नाम होना चाहिए.

निम्नलिखित fstab प्रविष्टियाँ उपरोक्त नियमों का पालन करते हुए सिस्टम, विक्रेता और उत्पाद को तार्किक विभाजन के रूप में सेट करती हैं।

#<dev>  <mnt_point> <type>  <mnt_flags options> <fs_mgr_flags>
system   /system     ext4    ro,barrier=1        wait,slotselect,avb=vbmeta,logical,first_stage_mount
vendor   /vendor     ext4    ro,barrier=1        wait,slotselect,avb,logical,first_stage_mount
product  /product    ext4    ro,barrier=1        wait,slotselect,avb,logical,first_stage_mount

नोट: गैर-ए/बी डिवाइस के लिए slotselect शामिल न करें।

fstab फ़ाइल को पहले चरण रैमडिस्क में कॉपी करें।

SELinux बदलता है

सुपर पार्टीशन ब्लॉक डिवाइस को super_block_device लेबल से चिह्नित किया जाना चाहिए। उदाहरण के लिए, यदि सुपर पार्टीशन उप-नाम सिम्लिंक /dev/block/platform/ soc/100000.ufshc /by-name/super है, तो निम्न पंक्ति को file_contexts में जोड़ें:

/dev/block/platform/soc/10000\.ufshc/by-name/super   u:object_r:super_block_device:s0

fastbootd

बूटलोडर (या कोई गैर-यूजरस्पेस फ्लैशिंग टूल) गतिशील विभाजन को नहीं समझता है, इसलिए यह उन्हें फ्लैश नहीं कर सकता है। इसे संबोधित करने के लिए, उपकरणों को फास्टबूट प्रोटोकॉल के उपयोगकर्ता-स्पेस कार्यान्वयन का उपयोग करना चाहिए, जिसे फास्टबूटडी कहा जाता है।

फास्टबूट को लागू करने के तरीके के बारे में अधिक जानकारी के लिए, फास्टबूट को यूजर स्पेस में ले जाना देखें।

एडीबी रिमाउंट

eng या userdebug बिल्ड का उपयोग करने वाले डेवलपर्स के लिए, adb remount तेज़ पुनरावृत्ति के लिए बेहद उपयोगी है। डायनेमिक विभाजन adb remount के लिए एक समस्या पैदा करता है क्योंकि प्रत्येक फ़ाइल सिस्टम में अब कोई खाली स्थान नहीं है। इसे संबोधित करने के लिए, डिवाइस ओवरलेफ़्स सक्षम कर सकते हैं। जब तक सुपर विभाजन के भीतर खाली जगह है, adb remount स्वचालित रूप से एक अस्थायी गतिशील विभाजन बनाता है और लिखने के लिए ओवरलेफ़्स का उपयोग करता है। अस्थायी विभाजन को scratch नाम दिया गया है, इसलिए अन्य विभाजनों के लिए इस नाम का उपयोग न करें।

ओवरलेफ़्स को सक्षम करने के तरीके के बारे में अधिक जानकारी के लिए, AOSP में ओवरलेफ़्स README देखें।

Android डिवाइस अपग्रेड करें

यदि आप किसी डिवाइस को एंड्रॉइड 10 में अपग्रेड करते हैं, और ओटीए में डायनामिक विभाजन समर्थन शामिल करना चाहते हैं, तो आपको अंतर्निहित विभाजन तालिका को बदलने की आवश्यकता नहीं है। कुछ अतिरिक्त कॉन्फ़िगरेशन की आवश्यकता है.

डिवाइस कॉन्फ़िगरेशन बदलता है

गतिशील विभाजन को पुनः स्थापित करने के लिए, device.mk में निम्नलिखित झंडे जोड़ें:

PRODUCT_USE_DYNAMIC_PARTITIONS := true
PRODUCT_RETROFIT_DYNAMIC_PARTITIONS := true

बोर्ड कॉन्फ़िगरेशन बदलता है

आपको निम्नलिखित बोर्ड वेरिएबल सेट करने होंगे:

गतिशील विभाजन के विस्तार को संग्रहीत करने के लिए उपयोग किए जाने वाले ब्लॉक उपकरणों की सूची में BOARD_SUPER_PARTITION_BLOCK_DEVICES सेट करें। यह डिवाइस पर मौजूदा भौतिक विभाजनों के नामों की सूची है।
BOARD_SUPER_PARTITION_BLOCK_DEVICES में प्रत्येक ब्लॉक डिवाइस के आकार में क्रमशः BOARD_SUPER_PARTITION_ partition _DEVICE_SIZE सेट करें। यह डिवाइस पर मौजूदा भौतिक विभाजनों के आकारों की सूची है। मौजूदा बोर्ड कॉन्फ़िगरेशन में यह आमतौर पर BOARD_ partition IMAGE_PARTITION_SIZE है।
BOARD_SUPER_PARTITION_BLOCK_DEVICES में सभी विभाजनों के लिए मौजूदा BOARD_ partition IMAGE_PARTITION_SIZE अनसेट करें।
BOARD_SUPER_PARTITION_SIZE BOARD_SUPER_PARTITION_ partition _DEVICE_SIZE के योग पर सेट करें।
BOARD_SUPER_PARTITION_METADATA_DEVICE को उस ब्लॉक डिवाइस पर सेट करें जहां डायनामिक विभाजन मेटाडेटा संग्रहीत है। यह BOARD_SUPER_PARTITION_BLOCK_DEVICES में से एक होना चाहिए। आमतौर पर, इसे system पर सेट किया जाता है।
क्रमशः BOARD_SUPER_PARTITION_GROUPS , BOARD_ group _SIZE , और BOARD_ group _PARTITION_LIST सेट करें। विवरण के लिए नए उपकरणों पर बोर्ड कॉन्फ़िगरेशन परिवर्तन देखें।

उदाहरण के लिए, यदि डिवाइस में पहले से ही सिस्टम और विक्रेता विभाजन हैं, और आप उन्हें गतिशील विभाजन में परिवर्तित करना चाहते हैं और अपडेट के दौरान एक नया उत्पाद विभाजन जोड़ना चाहते हैं, तो इस बोर्ड कॉन्फ़िगरेशन को सेट करें:

BOARD_SUPER_PARTITION_BLOCK_DEVICES := system vendor
BOARD_SUPER_PARTITION_METADATA_DEVICE := system

# Rename BOARD_SYSTEMIMAGE_PARTITION_SIZE to BOARD_SUPER_PARTITION_SYSTEM_DEVICE_SIZE.
BOARD_SUPER_PARTITION_SYSTEM_DEVICE_SIZE := <size-in-bytes>

# Rename BOARD_VENDORIMAGE_PARTITION_SIZE to BOARD_SUPER_PARTITION_VENDOR_DEVICE_SIZE
BOARD_SUPER_PARTITION_VENDOR_DEVICE_SIZE := <size-in-bytes>

# This is BOARD_SUPER_PARTITION_SYSTEM_DEVICE_SIZE + BOARD_SUPER_PARTITION_VENDOR_DEVICE_SIZE
BOARD_SUPER_PARTITION_SIZE := <size-in-bytes>

# Configuration for dynamic partitions. For example:
BOARD_SUPER_PARTITION_GROUPS := group_foo
BOARD_GROUP_FOO_SIZE := <size-in-bytes>
BOARD_GROUP_FOO_PARTITION_LIST := system vendor product

SELinux बदलता है

सुपर पार्टीशन ब्लॉक डिवाइस को super_block_device_type विशेषता के साथ चिह्नित किया जाना चाहिए। उदाहरण के लिए, यदि डिवाइस में पहले से ही system और vendor विभाजन हैं, तो आप उन्हें गतिशील विभाजन के विस्तार को संग्रहीत करने के लिए ब्लॉक डिवाइस के रूप में उपयोग करना चाहते हैं, और उनके उप-नाम सिम्लिंक को system_block_device के रूप में चिह्नित किया गया है:

/dev/block/platform/soc/10000\.ufshc/by-name/system   u:object_r:system_block_device:s0
/dev/block/platform/soc/10000\.ufshc/by-name/vendor   u:object_r:system_block_device:s0

फिर, निम्न पंक्ति को device.te में जोड़ें:

typeattribute system_block_device super_block_device_type;

अन्य कॉन्फ़िगरेशन के लिए, नए उपकरणों पर गतिशील विभाजन लागू करना देखें।

रेट्रोफिट अपडेट के बारे में अधिक जानकारी के लिए, डायनामिक पार्टिशन के बिना ए/बी डिवाइस के लिए ओटीए देखें।

फ़ैक्टरी छवियाँ

डायनामिक विभाजन समर्थन के साथ लॉन्च होने वाले डिवाइस के लिए, फ़ैक्टरी छवियों को फ्लैश करने के लिए यूजरस्पेस फास्टबूट का उपयोग करने से बचें, क्योंकि यूजरस्पेस में बूटिंग अन्य फ्लैशिंग विधियों की तुलना में धीमी है।

इसे संबोधित करने के लिए, make dist अब एक अतिरिक्त super.img छवि बनाता है जिसे सीधे सुपर पार्टीशन पर फ्लैश किया जा सकता है। यह स्वचालित रूप से तार्किक विभाजन की सामग्री को बंडल करता है, जिसका अर्थ है कि इसमें super विभाजन मेटाडेटा के अलावा system.img , vendor.img , इत्यादि शामिल हैं। इस छवि को बिना किसी अतिरिक्त टूलिंग या फास्टबूट का उपयोग किए सीधे super पार्टीशन पर फ्लैश किया जा सकता है। निर्माण के बाद, super.img ${ANDROID_PRODUCT_OUT} में रखा गया है।

गतिशील विभाजन के साथ लॉन्च होने वाले ए/बी उपकरणों के लिए, super.img में A स्लॉट में छवियां होती हैं। सुपर इमेज को सीधे फ्लैश करने के बाद, डिवाइस को रीबूट करने से पहले स्लॉट ए को बूट करने योग्य के रूप में चिह्नित करें।

रेट्रोफ़िट उपकरणों के लिए, make dist super_*.img छवियों का एक सेट बनाता है जिन्हें सीधे संबंधित भौतिक विभाजनों पर फ्लैश किया जा सकता है। उदाहरण के लिए, जब BOARD_SUPER_PARTITION_BLOCK_DEVICES सिस्टम विक्रेता है, make dist super_system.img और super_vendor.img बनाता है। ये छवियां OTA फ़ोल्डर में target_files.zip में रखी गई हैं।

डिवाइस मैपर स्टोरेज-डिवाइस ट्यूनिंग

गतिशील विभाजन कई गैर-नियतात्मक डिवाइस-मैपर ऑब्जेक्ट को समायोजित करता है। ये सभी अपेक्षा के अनुरूप त्वरित नहीं हो सकते हैं, इसलिए आपको सभी माउंट को ट्रैक करना होगा, और सभी संबद्ध विभाजनों के एंड्रॉइड गुणों को उनके अंतर्निहित स्टोरेज डिवाइस के साथ अपडेट करना होगा।

init के अंदर एक तंत्र माउंट को ट्रैक करता है और एंड्रॉइड गुणों को एसिंक्रोनस रूप से अपडेट करता है। इसमें लगने वाला समय किसी विशिष्ट अवधि के भीतर होने की गारंटी नहीं है, इसलिए आपको सभी on property ट्रिगर्स को प्रतिक्रिया देने के लिए पर्याप्त समय प्रदान करना होगा। गुण dev.mnt.blk. <partition> उदाहरण के लिए dev.mnt.blk. <partition> जहां <partition> root , system , data या vendor है। प्रत्येक प्रॉपर्टी बेस स्टोरेज-डिवाइस नाम से जुड़ी हुई है, जैसा कि इन उदाहरणों में दिखाया गया है:

taimen:/ % getprop | grep dev.mnt.blk
[dev.mnt.blk.data]: [sda]
[dev.mnt.blk.firmware]: [sde]
[dev.mnt.blk.metadata]: [sde]
[dev.mnt.blk.persist]: [sda]
[dev.mnt.blk.root]: [dm-0]
[dev.mnt.blk.vendor]: [dm-1]

blueline:/ $ getprop | grep dev.mnt.blk
[dev.mnt.blk.data]: [dm-4]
[dev.mnt.blk.metadata]: [sda]
[dev.mnt.blk.mnt.scratch]: [sda]
[dev.mnt.blk.mnt.vendor.persist]: [sdf]
[dev.mnt.blk.product]: [dm-2]
[dev.mnt.blk.root]: [dm-0]
[dev.mnt.blk.system_ext]: [dm-3]
[dev.mnt.blk.vendor]: [dm-1]
[dev.mnt.blk.vendor.firmware_mnt]: [sda]

init.rc भाषा एंड्रॉइड गुणों को नियमों के हिस्से के रूप में विस्तारित करने की अनुमति देती है, और स्टोरेज डिवाइस को इन जैसे कमांड के साथ आवश्यकतानुसार प्लेटफ़ॉर्म द्वारा ट्यून किया जा सकता है:

write /sys/block/${dev.mnt.blk.root}/queue/read_ahead_kb 128
write /sys/block/${dev.mnt.blk.data}/queue/read_ahead_kb 128

एक बार जब कमांड प्रोसेसिंग दूसरे चरण के init में शुरू हो जाती है, epoll loop सक्रिय हो जाता है, और मान अपडेट होने लगते हैं। हालाँकि, क्योंकि प्रॉपर्टी ट्रिगर लेट- init तक सक्रिय नहीं होते हैं, इसलिए उन्हें root , system , या vendor संभालने के लिए प्रारंभिक बूट चरणों में उपयोग नहीं किया जा सकता है। आप उम्मीद कर सकते हैं कि कर्नेल डिफ़ॉल्ट read_ahead_kb तब तक पर्याप्त होगा जब तक कि init.rc स्क्रिप्ट early-fs (जब विभिन्न डेमॉन और सुविधाएं शुरू नहीं हो जाती) में ओवरराइड नहीं हो जातीं। इसलिए, Google अनुशंसा करता है कि आप संचालन के समय से निपटने और दौड़ की स्थिति को रोकने के लिए, init.rc -नियंत्रित संपत्ति जैसे sys.read_ahead_kb के साथ on property सुविधा का उपयोग करें, जैसा कि इन उदाहरणों में है:

on property:dev.mnt.blk.root=* && property:sys.read_ahead_kb=*
    write /sys/block/${dev.mnt.blk.root}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048}

on property:dev.mnt.blk.system=* && property:sys.read_ahead_kb=*
    write /sys/block/${dev.mnt.blk.system}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048}

on property:dev.mnt.blk.vendor=* && property:sys.read_ahead_kb=*
    write /sys/block/${dev.mnt.blk.vendor}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048}

on property:dev.mnt.blk.product=* && property:sys.read_ahead_kb=*
    write /sys/block/${dev.mnt.blk.system_ext}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048}

on property:dev.mnt.blk.oem=* && property:sys.read_ahead_kb=*
    write /sys/block/${dev.mnt.blk.oem}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048}

on property:dev.mnt.blk.data=* && property:sys.read_ahead_kb=*
    write /sys/block/${dev.mnt.blk.data}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048}

on early-fs:
    setprop sys.read_ahead_kb ${ro.read_ahead_kb.boot:-2048}

on property:sys.boot_completed=1
   setprop sys.read_ahead_kb ${ro.read_ahead_kb.bootcomplete:-128}