डायनेमिक विभाजन को लिनक्स कर्नेल में डीएम-लीनियर डिवाइस-मैपर मॉड्यूल का उपयोग करके कार्यान्वित किया जाता है। super
विभाजन में super
के भीतर प्रत्येक गतिशील विभाजन के नाम और ब्लॉक श्रेणियों को सूचीबद्ध करने वाला मेटाडेटा शामिल है। प्रथम-चरण init
के दौरान, इस मेटाडेटा को पार्स और मान्य किया जाता है, और प्रत्येक गतिशील विभाजन का प्रतिनिधित्व करने के लिए वर्चुअल ब्लॉक डिवाइस बनाए जाते हैं।
ओटीए लागू करते समय, आवश्यकतानुसार डायनामिक विभाजन स्वचालित रूप से बनाए जाते हैं, आकार बदलते हैं या हटा दिए जाते हैं। ए/बी उपकरणों के लिए, मेटाडेटा की दो प्रतियां हैं, और परिवर्तन केवल लक्ष्य स्लॉट का प्रतिनिधित्व करने वाली प्रतिलिपि पर लागू होते हैं।
क्योंकि डायनेमिक विभाजन उपयोक्ता स्थान में कार्यान्वित किए जाते हैं, बूटलोडर के लिए आवश्यक विभाजन को गतिशील नहीं बनाया जा सकता है। उदाहरण के लिए, boot
, dtbo
, और vbmeta
बूटलोडर द्वारा पढ़ा जाता है, और इसलिए उन्हें भौतिक विभाजन के रूप में रहना चाहिए।
प्रत्येक गतिशील विभाजन एक अद्यतन समूह से संबंधित हो सकता है। ये समूह उस अधिकतम स्थान को सीमित करते हैं जो उस समूह में विभाजन उपभोग कर सकता है। उदाहरण के लिए, system
और vendor
एक ऐसे समूह से संबंधित हो सकते हैं जो system
और vendor
के कुल आकार को प्रतिबंधित करता है।
नए उपकरणों पर गतिशील विभाजन लागू करें
यह अनुभाग विवरण देता है कि एंड्रॉइड 10 और उच्चतर के साथ लॉन्च होने वाले नए उपकरणों पर गतिशील विभाजन कैसे लागू किया जाए। मौजूदा डिवाइस को अपडेट करने के लिए, एंड्रॉइड डिवाइस को अपग्रेड करना देखें।
विभाजन परिवर्तन
एंड्रॉइड 10 के साथ लॉन्च होने वाले उपकरणों के लिए, super
नामक एक विभाजन बनाएं। super
विभाजन आंतरिक रूप से ए/बी स्लॉट को संभालता है, इसलिए ए/बी उपकरणों को अलग-अलग super_a
और super_b
विभाजन की आवश्यकता नहीं होती है। बूटलोडर द्वारा उपयोग नहीं किए जाने वाले सभी रीड-ओनली AOSP विभाजन गतिशील होने चाहिए और उन्हें GUID विभाजन तालिका (GPT) से हटा दिया जाना चाहिए। विक्रेता-विशिष्ट विभाजनों को गतिशील होना आवश्यक नहीं है और उन्हें GPT में रखा जा सकता है।
super
के आकार का अनुमान लगाने के लिए, GPT से हटाए जा रहे विभाजन के आकार जोड़ें। ए/बी उपकरणों के लिए, इसमें दोनों स्लॉट का आकार शामिल होना चाहिए। चित्र 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
- वर्चुअल ए/बी लॉन्च डिवाइस के लिए, सभी समूहों के अधिकतम आकारों का योग अधिकतम होना चाहिए:
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 ब्लॉब्स का समर्थन करें।"
कर्नेल कमांड लाइन बदल जाती है
एक नया पैरामीटर, 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
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}