एंड्रॉइड 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/*
निर्देशिकाओं को ओवरले करती है।
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
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)
यदि लक्ष्य
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
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 को निम्नलिखित कर्नेल पैच की आवश्यकता है:
- https://android-review.googlesource.com/#/c/kernel/common/+/158491/
- कर्नेल 4.4 पैच , कर्नेल 4.9 पैच , आदि।
निम्नलिखित उदाहरण कर्नेल कमांड लाइन में सिस्टम-एज़-रूट के लिए डीएम-वेरिटी संबंधित सेटिंग्स दिखाता है:
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/*
स्वचालित रूप से)।