विभाजन लेआउट

एंड्रॉइड 10 में, रूट फ़ाइल सिस्टम अब ramdisk.img में शामिल नहीं है और इसके बजाय इसे system.img में विलय कर दिया गया है (अर्थात, system.img हमेशा ऐसे बनाया जाता है जैसे कि BOARD_BUILD_SYSTEM_ROOT_IMAGE सेट किया गया हो)। Android 10 के साथ लॉन्च होने वाले डिवाइस:

  • सिस्टम-ए-रूट विभाजन लेआउट का उपयोग करें (व्यवहार को बदलने के लिए बिना किसी विकल्प के बिल्ड द्वारा स्वचालित रूप से लागू)।
  • रैमडिस्क का उपयोग अवश्य करें, जो डीएम-लीनियर के लिए आवश्यक है।
  • BOARD_BUILD_SYSTEM_ROOT_IMAGE को false पर सेट करना होगा। इस सेटिंग का उपयोग केवल उन डिवाइसों के बीच अंतर करने के लिए किया जाता है जो रैमडिस्क का उपयोग करते हैं और वे डिवाइस जो रैमडिस्क का उपयोग नहीं करते हैं (और इसके बजाय सीधे system.img माउंट करते हैं)।

सिस्टम-एज़-रूट कॉन्फ़िगरेशन का अर्थ एंड्रॉइड 9 और एंड्रॉइड 10 के बीच भिन्न होता है। एंड्रॉइड 9 सिस्टम-एज़-रूट कॉन्फ़िगरेशन में, BOARD_BUILD_SYSTEM_ROOT_IMAGE को true पर सेट किया जाता है, जो बिल्ड को रूट फ़ाइल सिस्टम को system.img में मर्ज करने के लिए मजबूर करता है। system.img रूट फ़ाइल सिस्टम (rootfs) के रूप में माउंट करें। यह कॉन्फ़िगरेशन एंड्रॉइड 9 के साथ लॉन्च होने वाले उपकरणों के लिए अनिवार्य है लेकिन एंड्रॉइड 9 में अपग्रेड करने वाले उपकरणों और एंड्रॉइड के निचले संस्करणों पर चलने वाले उपकरणों के लिए वैकल्पिक है। एंड्रॉइड 10 सिस्टम-एज़-रूट कॉन्फ़िगरेशन में, बिल्ड हमेशा $TARGET_SYSTEM_OUT और $TARGET_ROOT_OUT system.img में मर्ज कर देता है; यह कॉन्फ़िगरेशन एंड्रॉइड 10 चलाने वाले सभी उपकरणों के लिए डिफ़ॉल्ट व्यवहार है।

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

निम्नलिखित अनुभाग केवल-सिस्टम ओटीए के लिए सिस्टम-एज़-रूट आवश्यकताओं का वर्णन करते हैं, सिस्टम-एज़-रूट (विभाजन लेआउट परिवर्तन और डीएम-सत्यापन कर्नेल आवश्यकताओं सहित) का उपयोग करने के लिए उपकरणों को अपडेट करने पर मार्गदर्शन प्रदान करते हैं। रैमडिस्क में परिवर्तनों के विवरण के लिए, रैमडिस्क विभाजन देखें।

केवल सिस्टम ओटीए के बारे में

सिस्टम-केवल ओटीए, जो एंड्रॉइड रिलीज़ को अन्य विभाजनों को बदले बिना system.img और product.img अपडेट करने में सक्षम बनाता है, को सिस्टम-ए-रूट विभाजन लेआउट की आवश्यकता होती है। एंड्रॉइड 10 चलाने वाले सभी उपकरणों को केवल सिस्टम ओटीए को सक्षम करने के लिए सिस्टम-एज़-रूट विभाजन लेआउट का उपयोग करना होगा।

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

ए/बी और गैर-ए/बी उपकरणों के विवरण के लिए, ए/बी (सीमलेस) सिस्टम अपडेट देखें।

विक्रेता ओवरले का उपयोग करना

विक्रेता ओवरले आपको डिवाइस बूट समय पर vendor विभाजन में परिवर्तनों को ओवरले करने की अनुमति देता है। विक्रेता ओवरले product विभाजन में विक्रेता मॉड्यूल का एक सेट है जो डिवाइस के बूट होने पर vendor विभाजन पर ओवरलेड हो जाता है, मौजूदा मॉड्यूल को बदलता है और जोड़ता है।

जब डिवाइस बूट होता है, तो init प्रक्रिया पहला चरण माउंट पूरा करती है और डिफ़ॉल्ट गुणों को पढ़ती है। फिर यह /product/vendor_overlay/<target_vendor_version> खोजता है और प्रत्येक उपनिर्देशिका को उसके संबंधित vendor विभाजन निर्देशिका पर माउंट करता है, यदि निम्नलिखित शर्तें पूरी होती हैं:

  • /vendor/<overlay_dir> मौजूद है।
  • /product/vendor_overlay/<target_vendor_version>/<overlay_dir> फ़ाइल संदर्भ /vendor/<overlay_dir> जैसा ही है।
  • init को /vendor/<overlay_dir> के फ़ाइल संदर्भ पर माउंट करने की अनुमति है।

विक्रेता ओवरले को कार्यान्वित करना

/product/vendor_overlay/<target_vendor_version> में विक्रेता ओवरले फ़ाइलें स्थापित करें। जब डिवाइस बूट होता है तो वे फ़ाइलें vendor विभाजन को ओवरले करती हैं, उसी नाम की फ़ाइलों को प्रतिस्थापित करती हैं और कोई नई फ़ाइलें जोड़ती हैं। विक्रेता ओवरले vendor विभाजन से फ़ाइलें नहीं हटा सकता.

विक्रेता ओवरले फ़ाइलों में vendor विभाजन में प्रतिस्थापित लक्ष्य फ़ाइलों के समान फ़ाइल संदर्भ होना चाहिए। डिफ़ॉल्ट रूप से, /product/vendor_overlay/<target_vendor_version> निर्देशिका की फ़ाइलों में vendor_file संदर्भ होता है। यदि विक्रेता ओवरले फ़ाइलों और उनके द्वारा प्रतिस्थापित फ़ाइलों के बीच फ़ाइल संदर्भ बेमेल है, तो उसे डिवाइस-विशिष्ट सेपॉलिसी में निर्दिष्ट करें। फ़ाइल संदर्भ निर्देशिका स्तर पर सेट किया गया है। यदि विक्रेता ओवरले निर्देशिका का फ़ाइल संदर्भ लक्ष्य निर्देशिका से मेल नहीं खाता है, और सही फ़ाइल संदर्भ डिवाइस-विशिष्ट सेपॉलिसी में निर्दिष्ट नहीं है, तो वह विक्रेता ओवरले निर्देशिका लक्ष्य निर्देशिका पर ओवरलेड नहीं है।

विक्रेता ओवरले का उपयोग करने के लिए, कर्नेल को CONFIG_OVERLAY_FS=y सेट करके OverlayFS को सक्षम करना होगा। साथ ही, कर्नेल को सामान्य कर्नेल 4.4 या बाद के संस्करण से मर्ज किया जाना चाहिए, या "overlayfs: override_creds=off option bypass creator_cred" के साथ पैच किया जाना चाहिए।

विक्रेता ओवरले कार्यान्वयन उदाहरण

यह प्रक्रिया एक विक्रेता ओवरले को लागू करने को प्रदर्शित करती है जो /vendor/lib/* , /vendor/etc/* , और /vendor/app/* निर्देशिकाओं को ओवरले करती है।

  1. device/<vendor>/<target>/vendor_overlay/<target_vendor_version>/ में पूर्वनिर्मित विक्रेता फ़ाइलें जोड़ें:

    device/google/device/vendor_overlay/28/lib/libfoo.so
device/google/device/vendor_overlay/28/lib/libbar.so
device/google/device/vendor_overlay/28/etc/baz.xml
device/google/device/vendor_overlay/28/app/qux.apk

  2. device/google/device/device.mk में product/vendor_overlay पर पूर्वनिर्मित विक्रेता फ़ाइलें स्थापित करें:

    PRODUCT_COPY_FILES += \
    $(call find-copy-subdir-files,*,device/google/device/vendor_overlay,$(TARGET_COPY_OUT_PRODUCT)/vendor_overlay)

  3. यदि लक्ष्य vendor विभाजन फ़ाइलों में vendor_file के अलावा अन्य संदर्भ हैं तो फ़ाइल संदर्भों को परिभाषित करें। क्योंकि /vendor/lib/* vendor_file संदर्भ का उपयोग करता है, इस उदाहरण में वह निर्देशिका शामिल नहीं है।

    निम्नलिखित को device/google/device-sepolicy/private/file_contexts में जोड़ें:

    /(product|system/product)/vendor_overlay/[0-9]+/etc(/.*)?   u:object_r:vendor_configs_file:s0
/(product|system/product)/vendor_overlay/[0-9]+/app(/.*)?   u:object_r:vendor_app_file:s0

  4. init प्रक्रिया को vendor_file के अलावा अन्य फ़ाइल संदर्भों पर विक्रेता ओवरले माउंट करने की अनुमति दें। चूँकि init प्रक्रिया को पहले से ही vendor_file संदर्भ पर माउंट करने की अनुमति है, यह उदाहरण vendor_file के लिए नीति को परिभाषित नहीं करता है।

    निम्नलिखित को device/google/device-sepolicy/public/init.te में जोड़ें:

    allow init vendor_configs_file:dir mounton;
allow init vendor_app_file:dir mounton;

विक्रेता ओवरले को मान्य करना

विक्रेता ओवरले कॉन्फ़िगरेशन को मान्य करने के लिए, /product/vendor_overlay/<target_vendor_version>/<overlay_dir> में फ़ाइलें जोड़ें और जांचें कि क्या फ़ाइलें /vendor/<overlay_dir> में फ़ाइलों पर ओवरलेड हैं।

userdebug बिल्ड के लिए, एटेस्ट के लिए एक परीक्षण मॉड्यूल है:

$ atest -v fs_mgr_vendor_overlay_test

सिस्टम-एज़-रूट में अद्यतन किया जा रहा है

सिस्टम-ए-रूट का उपयोग करने के लिए गैर-ए/बी डिवाइस को अपडेट करने के लिए, आपको boot.img और system.img के लिए विभाजन योजना को अपडेट करना होगा, डीएम-वेरिटी सेट करना होगा, और डिवाइस-विशिष्ट रूट फ़ोल्डरों पर किसी भी बूट निर्भरता को हटाना होगा।

विभाजन अद्यतन किया जा रहा है

ए/बी उपकरणों के विपरीत, जो /boot पुनर्प्राप्ति विभाजन के रूप में पुन: उपयोग करते हैं, गैर-ए/बी उपकरणों को /recovery विभाजन को अलग रखना होगा क्योंकि उनके पास फ़ॉलबैक स्लॉट विभाजन नहीं है (उदाहरण के लिए, boot_a से boot_b तक)। यदि /recovery गैर-ए/बी डिवाइस पर हटा दिया जाता है और ए/बी योजना के समान बनाया जाता है, तो /boot विभाजन में असफल अद्यतन के दौरान रिकवरी मोड टूट सकता है। इस कारण से, /recovery विभाजन गैर-ए/बी उपकरणों के लिए /boot से एक अलग विभाजन होना चाहिए , जिसका अर्थ है कि पुनर्प्राप्ति छवि को विलंबित तरीके से अपडेट किया जाना जारी रहेगा (अर्थात, एंड्रॉइड चलाने वाले उपकरणों के समान ही) 8.1.0 या उससे कम)।

निम्न तालिका एंड्रॉइड 9 से पहले और बाद में गैर-ए/बी उपकरणों के लिए छवि विभाजन अंतरों को सूचीबद्ध करती है।

छवि रैमडिस्क (9 से पहले) सिस्टम-एज़-रूट (9 के बाद)
boot.img इसमें एक कर्नेल और एक ramdisk.img शामिल है: 
ramdisk.img
  -/
    - init.rc
    - init
    - etc -> /system/etc
    - system/ (mount point)
    - vendor/ (mount point)
    - odm/ (mount point)
    ...
 इसमें केवल सामान्य बूट कर्नेल होता है।
recovery.img इसमें एक रिकवरी कर्नेल और एक रिकवरी ramdisk.img शामिल है।
system.img इसमें निम्नलिखित शामिल हैं: 
system.img
  -/
    - bin/
    - etc
    - vendor -> /vendor
    - ...
 इसमें मूल system.img और ramdisk.img की मर्ज की गई सामग्री शामिल है: 
system.img
  -/
    - init.rc
    - init
    - etc -> /system/etc
    - system/
      - bin/
      - etc/
      - vendor -> /vendor
      - ...
    - vendor/ (mount point)
    - odm/ (mount point)
    ...

विभाजन स्वयं नहीं बदलते; रैमडिस्क और सिस्टम-एज़-रूट दोनों निम्नलिखित विभाजन योजना का उपयोग करते हैं:

  • /boot
  • /system
  • /system
  • /recovery
  • /vendor , आदि

डीएम-वेरिटी की स्थापना

सिस्टम-एज़-रूट में, कर्नेल को dm-verity के साथ / (माउंट पॉइंट) के अंतर्गत system.img माउंट करना होगा। AOSP system.img के लिए निम्नलिखित dm-verity कार्यान्वयन का समर्थन करता है।

वीबूट 1.0

Vboot 1.0 के लिए, कर्नेल को /system पर एंड्रॉइड-विशिष्ट मेटाडेटा को पार्स करना होगा, फिर dm-verity सेट करने के लिए dm-verity पैरामीटर में कनवर्ट करना होगा ( इन कर्नेल पैच की आवश्यकता है)। निम्नलिखित उदाहरण कर्नेल कमांड लाइन में सिस्टम-एज़-रूट के लिए डीएम-वेरिटी संबंधित सेटिंग्स दिखाता है:

ro root=/dev/dm-0 rootwait skip_initramfs init=/init
dm="system none ro,0 1 android-verity /dev/sda34"
veritykeyid=id:7e4333f9bba00adfe0ede979e28ed1920492b40f

वीबूट 2.0

Vboot 2.0 ( AVB ) के लिए, बूटलोडर को external/avb/libavb को एकीकृत करना होगा, जो तब /system के लिए हैशट्री डिस्क्रिप्टर को पार्स करता है, इसे dm-verity पैरामीटर में परिवर्तित करता है, और अंत में कर्नेल कमांड लाइन के माध्यम से पैरामीटर को कर्नेल में भेजता है। ( /system के हैशट्री डिस्क्रिप्टर /vbmeta पर या /system पर ही हो सकते हैं।)

vboot 2.0 को निम्नलिखित कर्नेल पैच की आवश्यकता है:

निम्नलिखित उदाहरण कर्नेल कमांड लाइन में सिस्टम-एज़-रूट के लिए डीएम-वेरिटी संबंधित सेटिंग्स दिखाता है:

ro root=/dev/dm-0 rootwait  skip_initramfs init=/init

dm="1 vroot none ro 1,0 5159992 verity 1
PARTUUID=00000016-0000-0000-0000-000000000000
PARTUUID=00000016-0000-0000-0000-000000000000 4096 4096 644999 644999
sha1 d80b4a8be3b58a8ab86fad1b498640892d4843a2
8d08feed2f55c418fb63447fec0d32b1b107e42c 10 restart_on_corruption
ignore_zero_blocks use_fec_from_device
PARTUUID=00000016-0000-0000-0000-000000000000 fec_roots 2 fec_blocks
650080 fec_start 650080"

डिवाइस-विशिष्ट रूट फ़ोल्डर का उपयोग करना

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

इस समस्या से बचने के लिए, डिवाइस-विशिष्ट रूट फ़ोल्डर जोड़ने के लिए BOARD_ROOT_EXTRA_FOLDERS उपयोग न करें। यदि आपको डिवाइस-विशिष्ट माउंट पॉइंट निर्दिष्ट करने की आवश्यकता है, तो /mnt/vendor/<mount point> (इन चेंजलिस्ट में जोड़ा गया) का उपयोग करें। इन विक्रेता-विशिष्ट माउंट बिंदुओं को सीधे fstab डिवाइस ट्री (प्रथम-चरण माउंट के लिए) और /vendor/etc/fstab.{ro.hardware} फ़ाइल में अतिरिक्त सेटअप के बिना निर्दिष्ट किया जा सकता है (क्योंकि fs_mgr उन्हें /mnt/vendor/* के अंतर्गत बनाता है) /mnt/vendor/* स्वचालित रूप से)।