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

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

ओटीए लागू करते समय, डाइनैमिक पार्टिशन अपने-आप बन जाते हैं, बदला जा सकता है या ज़रूरत के हिसाब से मिटाया जा सकता है. A/B डिवाइसों के लिए, और बदलाव सिर्फ़ उस कॉपी पर लागू होते हैं जिसमें टारगेट स्लॉट.

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

हर डाइनैमिक पार्टीशन, किसी अपडेट ग्रुप से जुड़ा हो सकता है. ये ग्रुप उस ज़्यादा से ज़्यादा स्टोरेज को सीमित करते हैं जो उस ग्रुप के पार्टीशन का इस्तेमाल कर सकते हैं. उदाहरण के लिए, system और vendor किसी वह ग्रुप जो system और vendor.

नए डिवाइसों में डाइनैमिक पार्टिशन लागू करना

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

विभाजन में बदलाव

Android 10 के साथ लॉन्च होने वाले डिवाइसों के लिए, एक विभाजन है जिसे super कहते हैं. super पार्टीशन, A/B स्लॉट को अंदरूनी तौर पर हैंडल करता है, इसलिए A/B डिवाइसों को इनकी ज़रूरत नहीं है super_a और super_b सेगमेंट को अलग करें. बूटलोडर के पास, रीड-ओनली ऐक्सेस वाले ऐसे सभी एओएसपी पार्टीशन को शामिल करना ज़रूरी है जिनका इस्तेमाल नहीं किया जा रहा है कोड डाइनैमिक होना चाहिए और इसे जीयूआईडी पार्टिशन टेबल (GPT) से हटाना ज़रूरी है. वेंडर के आधार पर बांटे गए सेगमेंट, डाइनैमिक नहीं होते हैं. इन्हें बांटा जा सकता है को भी कॉपी कर सकता है.

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

पार्टीशन टेबल का लेआउट
पहली इमेज. नया फ़िज़िकल पार्टिशन टेबल लेआउट, जब डाइनैमिक पार्टिशन में बदलना

इस्तेमाल किए जा सकने वाले डाइनैमिक पार्टीशन हैं:

  • सिस्टम
  • वेंडर
  • प्रॉडक्ट
  • सिस्टम एक्सटेंट
  • ओडीएम

Android 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>

A/B डिवाइसों पर, कुल साइज़ होने पर बिल्ड सिस्टम गड़बड़ी दिखाता है super के आधे से ज़्यादा हिस्से डाइनैमिक बंटवारे वाली इमेज हैं सेगमेंट का साइज़.

डाइनैमिक पार्टीशन की सूची को इस तरह कॉन्फ़िगर किया जा सकता है. इसके लिए अपडेट ग्रुप का इस्तेमाल कर रहे हैं, तो ग्रुप की सूची BOARD_SUPER_PARTITION_GROUPS वैरिएबल. हर ग्रुप का नाम इसके बाद, BOARD_group_SIZE है और BOARD_group_PARTITION_LIST वैरिएबल. A/B डिवाइसों के लिए, ग्रुप में ज़्यादा से ज़्यादा सिर्फ़ एक साइज़ होना चाहिए स्लॉट, क्योंकि ग्रुप के नाम आंतरिक रूप से स्लॉट-सफ़िक्स होते हैं.

यहां एक डिवाइस का उदाहरण दिया गया है, जिसमें सभी सेगमेंट को ग्रुप में रखा गया है 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
अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है
  • वर्चुअल A/B लॉन्च डिवाइसों के लिए, सभी ग्रुप के ज़्यादा से ज़्यादा साइज़ का योग ऐसा होना चाहिए ज़्यादा से ज़्यादा इतना होना चाहिए:
    BOARD_SUPER_PARTITION_SIZE - ओवरहेड
    वर्चुअल A/B को लागू करना देखें.
  • A/B लॉन्च डिवाइसों के लिए, सभी ग्रुप के ज़्यादा से ज़्यादा साइज़ का योग ऐसा होना चाहिए होना:
    BOARD_SUPER_PARTITION_SIZE / 2 - ओवरहेड
  • नॉन-A/B डिवाइसों और रेट्रोफ़िट A/B डिवाइसों के लिए, सबसे ज़्यादा का योग सभी ग्रुप के साइज़ इस तरह होने चाहिए:
    BOARD_SUPER_PARTITION_SIZE - ओवरहेड
  • बिल्ड के समय, हर हिस्से की इमेज के कुल साइज़ का जोड़ अपडेट ग्रुप में, ग्रुप के साइज़ की सीमा से ज़्यादा नहीं होना चाहिए.
  • मेटाडेटा के आकलन के लिए, ओवरहेड की ज़रूरत होती है, अलाइनमेंट, और इसी तरह के अन्य काम किए जा सकते हैं. एक उचित ओवरहेड 4 MiB है, लेकिन डिवाइस की ज़रूरत के हिसाब से बड़ा ओवरहेड चुना जा सकता है.

डाइनैमिक पार्टिशन का साइज़ बदलना

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

रीड-ओनली ext4 इमेज के लिए, बिल्ड सिस्टम अपने-आप हार्डकोड किए गए पार्टिशन का साइज़ तय न होने पर, कम से कम साइज़. कॉन्टेंट बनाने बिल्ड सिस्टम के साथ इमेज फ़िट हो जाती है, ताकि फ़ाइल सिस्टम में जितना हो सके उतना स्टोरेज इस्तेमाल करें. इससे यह पक्का होता है कि डिवाइस की बर्बादी न हो का इस्तेमाल ओटीए के लिए किया जा सकता है.

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

BOARD_EXT4_SHARE_DUP_BLOCKS := true

अगर किसी बंटवारे के लिए तय किए गए कम से कम साइज़ का अपने-आप बंटवारा करना पसंद न हो, सेगमेंट के साइज़ को कंट्रोल करने के दो तरीके हैं. आप कम से कम खाली जगह BOARD_partitionIMAGE_PARTITION_RESERVED_SIZE, या अपने हिसाब से बदलाव करें हर हाल में लागू करने के लिए BOARD_partitionIMAGE_PARTITION_SIZE किसी खास साइज़ के डाइनैमिक सेगमेंट. इनमें से कोई नहीं का सुझाव दिया जाता है.

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

BOARD_PRODUCTIMAGE_PARTITION_RESERVED_SIZE := 52428800

इससे product.img में फ़ाइल सिस्टम को 50 एमआईबी जगह का इस्तेमाल नहीं हुआ है.

रूट के मुताबिक सिस्टम में होने वाले बदलाव

Android 10 के साथ लॉन्च होने वाले डिवाइसों में सिस्टम-ए-रूट इस्तेमाल करता है.

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

BOARD_BUILD_SYSTEM_ROOT_IMAGE सेट न करें. तय सीमा में Android 10, BOARD_BUILD_SYSTEM_ROOT_IMAGE फ़्लैग का इस्तेमाल सिर्फ़ इनके लिए किया जाता है यह पता लगाएं कि सिस्टम, कर्नेल से माउंट किया गया है या रैम डिस्क में पहला चरण init.

BOARD_BUILD_SYSTEM_ROOT_IMAGE को true पर सेट किया जा रहा है बिल्ड में गड़बड़ी होती है, जब PRODUCT_USE_DYNAMIC_PARTITIONS भी true है.

जब BOARD_USES_RECOVERY_AS_BOOT को 'सही है' पर सेट किया जाता है, तो रिकवरी इमेज कोबूट.img के तौर पर बनाया गया है. इसमें रिकवरी की इमेज रैम डिस्क. पहले, बूटलोडर ने skip_initramfs कर्नेल का इस्तेमाल किया था कमांड लाइन पैरामीटर जोड़कर तय करें कि किस मोड में बूट करना है. इसके लिए Android 10 डिवाइस, बूटलोडर पास नहीं होने चाहिए skip_initramfs को कर्नेल कमांड-लाइन में भेजा जा सकता है. इसके बजाय, बूटलोडर रिकवरी स्किप करने के लिए, androidboot.force_normal_boot=1 पास होना चाहिए और सामान्य Android को चालू करते हैं. Android 12 के साथ लॉन्च होने वाले डिवाइस androidboot.force_normal_boot=1 को पास करने के लिए, बूट कॉन्फ़िगरेशन का इस्तेमाल करना होगा.

एवीबी कॉन्फ़िगरेशन में बदलाव

Android का इस्तेमाल करते समय वेरिफ़ाइड बूट 2.0, अगर डिवाइस चेन वाले पार्टिशन का इस्तेमाल नहीं कर रहा हो डिस्क्रिप्टर का इस्तेमाल करते हैं, तो किसी बदलाव की ज़रूरत नहीं होती है. अगर एक से ज़्यादा चैनलों का इस्तेमाल किया जा रहा है, तो हालांकि, पुष्टि किया गया एक हिस्सा डाइनैमिक होता है. तो परिवर्तन ज़रूरी हैं.

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

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

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

  • vbmeta_system और vbmeta_vendor जोड़ें डिवाइस के सेगमेंट में बांटी गई टेबल के सेगमेंट. A/B डिवाइसों के लिए, जोड़ें 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

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

एवीबी बूटलोडर में बदलाव

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

अगर चेन पार्टिशन का इस्तेमाल किया जा रहा है, तो एक और पैच शामिल करें:

  • 49936b4c0109411fdd38bd4ba3a32a01c40439a9 — "libavb: विभाजन की शुरुआत में vbmeta BLOBs का समर्थन करें."

कर्नेल कमांड लाइन में बदलाव

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

उदाहरण के लिए, अगर नाम का सिमलिंक के हिसाब से सुपर पार्टीशन /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 फ़ाइल का इस्तेमाल करें जो ramdisk का हिस्सा होगी.

लॉजिकल पार्टिशन के लिए, fstab फ़ाइल में बदलाव करना ज़रूरी है:

  • fs_mgr फ़्लैग फ़ील्ड में logical फ़्लैग शामिल होना चाहिए और first_stage_mount फ़्लैग, Android 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

फ़ास्टबूट

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

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

adb रीमाउंट

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

ओवरलेफ़ को चालू करने के तरीके के बारे में ज़्यादा जानने के लिए, overlayfs देखें AOSP में README करें.

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

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

डिवाइस के कॉन्फ़िगरेशन में किए गए बदलाव

डाइनैमिक पार्टीशन को पहले जैसा करने के लिए, नीचे दिए गए फ़्लैग जोड़ें device.mk: 

PRODUCT_USE_DYNAMIC_PARTITIONS := true
PRODUCT_RETROFIT_DYNAMIC_PARTITIONS := true

बोर्ड के कॉन्फ़िगरेशन में बदलाव

आपको बोर्ड के नीचे दिए गए वैरिएबल को सेट करना होगा:

  • BOARD_SUPER_PARTITION_BLOCK_DEVICES को उन डिवाइसों की सूची पर सेट करें जिन्हें ब्लॉक किया गया है का इस्तेमाल करें. यह मौजूदा फ़िज़िकल नामों की सूची है पार्टिशन.
  • BOARD_SUPER_PARTITION_partition_DEVICE_SIZE को साइज़ पर सेट करें BOARD_SUPER_PARTITION_BLOCK_DEVICES में हर ब्लॉक डिवाइस की संख्या मिलती है. यह डिवाइस पर मौजूद भौतिक विभाजनों के आकार की सूची है. आम तौर पर ऐसा होता है मौजूदा बोर्ड में BOARD_partitionIMAGE_PARTITION_SIZE कॉन्फ़िगरेशन.
  • सभी के लिए, मौजूदा BOARD_partitionIMAGE_PARTITION_SIZE को अनसेट करें BOARD_SUPER_PARTITION_BLOCK_DEVICES में विभाजन.
  • 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;

अन्य कॉन्फ़िगरेशन के लिए, लागू करना नए डिवाइसों पर डाइनैमिक पार्टिशन.

रेट्रोफ़िट की सुविधा से जुड़े अपडेट के बारे में ज़्यादा जानने के लिए, यहां जाएं बिना डाइनैमिक वाले A/B डिवाइसों के लिए ओटीए सेगमेंट.

फ़ैक्ट्री इमेज

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

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

डाइनैमिक पार्टिशन के साथ लॉन्च होने वाले A/B डिवाइसों के लिए, super.img में A स्लॉट में इमेज हैं. फ़्लैश करने के बाद सुपर इमेज है, तो डिवाइस को फिर से चालू करने से पहले, स्लॉट A को 'बूट होने लायक' के तौर पर मार्क करें डिवाइस.

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

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

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

init में मौजूद सिस्टम, माउंट को और एसिंक्रोनस तरीके से ट्रैक करता है Android की प्रॉपर्टी अपडेट करता है. इसमें लगने वाले समय की कोई गारंटी नहीं है एक समयावधि में विज्ञापन दिखाए जा सकते हैं. इसलिए, आपको इसके लिए ज़रूरी है कि के लिए सभी on property ट्रिगर का इस्तेमाल किया जा सकता है. प्रॉपर्टी 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 भाषा की मदद से, Android प्रॉपर्टी नियमों के तहत बढ़ाई गई है. साथ ही, स्टोरेज डिवाइसों को प्लैटफ़ॉर्म से ट्यून किया जा सकता है इनकी मदद से, नीचे दिए गए निर्देशों का पालन करें:

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 early-fs में init.rc स्क्रिप्ट बदली जा सकती हैं (जब अलग-अलग डीमन और सुविधाएं शुरू होती हैं. इसलिए, Google का सुझाव है कि आप on property सुविधा का इस्तेमाल करते हैं. ऐसी प्रॉपर्टी जिसे init.rc कंट्रोल करता है, जैसे कि sys.read_ahead_kb, चलाने के लिए सही समय तय करें, जैसे कि उदाहरण:

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}