Android 10 में, रूट फ़ाइल सिस्टम अब काम नहीं करता
ramdisk.img
में शामिल है और इसके बजाय इसे इसमें मर्ज कर दिया गया है
system.img
(इसका मतलब है कि system.img
को हमेशा इस तरह बनाया जाता है
यदि BOARD_BUILD_SYSTEM_ROOT_IMAGE
सेट है). डिवाइसों की सूची
Android 10 के साथ लॉन्च होने पर:
- रूट विभाजन लेआउट के रूप में सिस्टम का उपयोग करें (अपने आप लागू होने वाला जिसमें बदलाव करने का कोई विकल्प न हो).
- रैम डिस्क का इस्तेमाल करना ज़रूरी है, जो dm-लीनियर के लिए ज़रूरी है.
BOARD_BUILD_SYSTEM_ROOT_IMAGE
कोfalse
पर सेट करना ज़रूरी है. इस सेटिंग का इस्तेमाल, सिर्फ़ रैम डिस्क का इस्तेमाल करने वाले डिवाइसों में अंतर करने के लिए किया जाता है और ऐसे डिवाइस जो रैम डिस्क का इस्तेमाल नहीं करते (और इसके बजाय माउंटsystem.img
सीधे).
सिस्टम-ए-रूट कॉन्फ़िगरेशन का मतलब Android 9 और
Android 10. Android 9 सिस्टम में पहले से मौजूद है
कॉन्फ़िगरेशन. BOARD_BUILD_SYSTEM_ROOT_IMAGE
इस पर सेट है
true
, जो बिल्ड को रूट फ़ाइल सिस्टम में मर्ज करने के लिए मजबूर करता है
system.img
को रूट फ़ाइल के तौर पर माउंट करें. इसके बाद, system.img
को माउंट करें
सिस्टम (रूटफ़्स). डिवाइसों के लिए, यह कॉन्फ़िगरेशन ज़रूरी है
इसे Android 9 के साथ लॉन्च किया जा रहा है. हालांकि, इसमें अपग्रेड किए जा रहे डिवाइसों के लिए यह ज़रूरी नहीं है
Android 9 और Android के पुराने वर्शन वाले डिवाइसों पर काम करता है. Android में
10 सिस्टम-एज़-रूट कॉन्फ़िगरेशन, बिल्ड हमेशा
$TARGET_SYSTEM_OUT
और $TARGET_ROOT_OUT
को इसमें मर्ज करता है
system.img
; यह कॉन्फ़िगरेशन सभी डिवाइसों के लिए डिफ़ॉल्ट सेटिंग है
Android 10 वर्शन पर चल रहे हैं.
Android 10 के लिए, सहायता करने के तरीकों में किए जाएंगे नए बदलाव डाइनैमिक पार्टिशन, यह यूज़रस्पेस पार्टीशन सिस्टम है, जो ओवर द एयर (ओटीए) अपडेट को चालू करता है सेगमेंट बनाना, उनका साइज़ बदलना या उन्हें मिटाना. इस बदलाव के तहत, Linux कर्नेल, अब चल रहे डिवाइसों पर लॉजिकल सिस्टम पार्टीशन को माउंट नहीं कर सकता Android 10. इसलिए, यह कार्रवाई स्टेज इनिट.
ये सेक्शन सिर्फ़ सिस्टम से जुड़े ओटीए, सिस्टम को रूट करने की सुविधा का इस्तेमाल करने के लिए, डिवाइसों को अपडेट करने के बारे में दिशा-निर्देश दें (इसमें पार्टिशन लेआउट के बदलाव और डीएम-वेरिटी कर्नेल की ज़रूरी शर्तें शामिल हैं). इसके लिए रैम में हुए बदलावों की जानकारी, देखें रामडिस्क सेगमेंट.
सिर्फ़ सिस्टम वाले ओटीए के बारे में जानकारी
सिर्फ़ सिस्टम के साथ काम करने वाले ओटीए, जो Android की रिलीज़ को अपडेट करने में मदद करते हैं
system.img
और product.img
में कोई बदलाव नहीं किया गया
विभाजन के लिए, सिस्टम-के रूप में रूट विभाजन लेआउट की आवश्यकता होती है. Android डिवाइस पर चल रहे सभी डिवाइस
10 को रूट पार्टीशन लेआउट का इस्तेमाल करना होगा,
सिर्फ़ सिस्टम पर चलने वाले ओटीए चालू करें.
- A/B डिवाइस, जो
system
पार्टिशन को रूटएफ़ के तौर पर माउंट करते हैं, पहले से ही सिस्टम-ए-रूट का इस्तेमाल कर रहा है. साथ ही, सिस्टम ओटीए के साथ काम करने के लिए किसी बदलाव की ज़रूरत नहीं है. - नॉन-A/B डिवाइस, जो
system
पार्टिशन को माउंट करते हैं/system
, इस्तेमाल करने के लिए अपडेट होना चाहिए सिस्टम ओटीए के साथ काम करने के लिए, सिस्टम-ए-रूट पार्टिशन लेआउट है.
A/B और गैर-A/B डिवाइसों के बारे में जानकारी पाने के लिए, इसे देखें A/B (आसान) सिस्टम अपडेट.
वेंडर ओवरले का इस्तेमाल करें
वेंडर ओवरले की मदद से, 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
. साथ ही, कर्नेल को
सामान्य कर्नेल 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
-
पहले से बनी वेंडर फ़ाइलों को यहां इंस्टॉल करें:
product/vendor_overlay
इंचdevice/google/device/device.mk
: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 के लिए एक टेस्ट मॉड्यूल मौजूद है:
$ atest -v fs_mgr_vendor_overlay_test
सिस्टम के मुताबिक रूट में अपडेट करें
गैर-A/B डिवाइसों को सिस्टम-ऐज़-रूट का इस्तेमाल करने के लिए अपडेट करने के लिए, आपको
boot.img
और system.img
के पार्टीशन की स्कीम सेट की गई
डीएम-वेरिटी सेट अप करें. साथ ही, डिवाइस के लिए बने रूट से किसी भी बूट डिपेंडेंसी को हटाएं
फ़ोल्डर.
सेगमेंट अपडेट करें
ऐसे A/B डिवाइसों के उलट जो /boot
को अलग-अलग
रिकवरी पार्टीशन,
गैर-A/B डिवाइसों में /recovery
विभाजन होना चाहिए
अलग करें, क्योंकि इनमें फ़ॉलबैक स्लॉट का पार्टिशन नहीं होता (उदाहरण के लिए,
boot_a
से boot_b
तक). अगर /recovery
है
इसे नॉन-A/B डिवाइस से हटाया गया है. साथ ही, इसे A/B स्कीम, रिकवरी मोड की तरह बनाया गया है
/boot
विभाजन में असफल अपडेट के दौरान भंग हो सकती है. इसके लिए
इस कारण, /recovery
विभाजन को होना चाहिए
गैर-A/B डिवाइसों के लिए /boot
से अलग किया गया विभाजन, जिसका मतलब है
कि रिकवरी इमेज देर से अपडेट होती रहे
Android 8.1.0 या इससे पहले के वर्शन वाले डिवाइसों के जैसा ही होता है.
नीचे दी गई टेबल में, नॉन-A/B डिवाइसों के लिए इमेज के बंटवारे के अंतर की सूची दी गई है Android 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
वगैरह
डीएम-वेरिटी सेट अप करें
सिस्टम-ए-रूट में, कर्नेल को system.img
को
/
(माउंट पॉइंट) के साथ
dm-verity. AOSP नीचे दी गई डीएम-वेरिटी के साथ काम करता है
system.img
के लिए लागू.
vboot 1.0
vboot 1.0 के लिए, कर्नेल को पार्स होना चाहिए
Android के लिए खास
मेटाडेटा चालू है
/system
, फिर इसमें बदलें
dm-verity सेट अप करने के लिए 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
के लिए हैशट्री डिस्क्रिप्टर, रूपांतरण करता है
CANNOT TRANSLATE
dm-verity पैरामीटर और अंत में पैरामीटर को
कर्नेल को कर्नेल कमांड लाइन के ज़रिए बनाएँ. (/system
के बारे में बताने वाले हैशट्री
/vbmeta
या /system
पर हो सकती है.)
vboot 2.0 के लिए निम्न कर्नेल पैच की आवश्यकता है:
- https://android-review.googlesource.com/#/c/kernel/common/+/158491/
- कर्नेल 4.4 पैच, kernel 4.9 पैच वगैरह.
नीचे दिए गए उदाहरण में सिस्टम-ए-रूट के लिए dm-verity से जुड़ी सेटिंग दिखाई गई हैं कर्नेल कमांड लाइन:
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"
डिवाइस के हिसाब से रूट फ़ोल्डर इस्तेमाल करें
सिस्टम-ए-रूट के साथ, जेनरिक सिस्टम इमेज के बाद
(GSI) डिवाइस पर (और चलने से पहले) फ़्लैश करता है
Vendor Test Suite के टेस्ट), कोई भी
डिवाइस के हिसाब से, BOARD_ROOT_EXTRA_FOLDERS
के साथ जोड़े गए रूट फ़ोल्डर जोड़े गए
मौजूद नहीं हैं, क्योंकि पूरी रूट डायरेक्ट्री का कॉन्टेंट
रूट जीएसआई के रूप में काम करते हैं. इन फ़ोल्डर को हटाने से डिवाइस पर ये कार्रवाइयां हो सकती हैं
डिवाइस के लिए खास रूट फ़ोल्डर पर डिपेंडेंसी मौजूद होने पर, बूट करने की सुविधा बंद हो जाती है
उदाहरण के लिए, इनका इस्तेमाल माउंट पॉइंट के तौर पर किया जाता है.
इस समस्या से बचने के लिए, BOARD_ROOT_EXTRA_FOLDERS
का इस्तेमाल इन कामों के लिए न करें
डिवाइस के लिए खास रूट फ़ोल्डर जोड़ने की अनुमति दें. अगर आपको अलग-अलग डिवाइस के हिसाब से माउंट को तय करने की ज़रूरत है, तो
पॉइंट, /mnt/vendor/<mount point>
का इस्तेमाल करें (इन में जोड़ा गया है)
चेंजलिस्ट). वेंडर के लिए तय किए गए इन माउंट पॉइंट को
fstab
डिवाइस ट्री में सीधे तौर पर तय किया जाता है (पहले चरण के लिए
माउंट) और बिना /vendor/etc/fstab.{ro.hardware}
फ़ाइल
अतिरिक्त सेटअप को अनुमति देता है (क्योंकि fs_mgr
उन्हें
/mnt/vendor/*
अपने-आप).