في Android 10، لم يعد نظام الملفات الجذر مضمنًا في ramdisk.img
وتم دمجه بدلاً من ذلك في system.img
(أي يتم إنشاء system.img
دائمًا كما لو تم تعيين BOARD_BUILD_SYSTEM_ROOT_IMAGE
). الأجهزة التي تعمل بنظام Android 10:
- استخدم تخطيط قسم النظام كجذر (يتم فرضه تلقائيًا بواسطة البناء بدون خيارات لتغيير السلوك).
- يجب استخدام ramdisk، وهو مطلوب لـ dm-linear.
- يجب ضبط
BOARD_BUILD_SYSTEM_ROOT_IMAGE
علىfalse
. يتم استخدام هذا الإعداد فقط للتمييز بين الأجهزة التي تستخدم قرص ذاكرة الوصول العشوائي والأجهزة التي لا تستخدم قرص ذاكرة الوصول العشوائي (وبدلاً من ذلك يتم تحميلsystem.img
مباشرةً).
يختلف معنى تكوين النظام كجذر بين Android 9 وAndroid 10. في تكوين نظام Android 9 كجذر، يتم تعيين BOARD_BUILD_SYSTEM_ROOT_IMAGE
على true
، مما يفرض على الإنشاء دمج نظام الملفات الجذر في system.img
ثم قم بتحميل system.img
كنظام الملفات الجذر (rootfs). يعد هذا التكوين إلزاميًا للأجهزة التي تعمل بنظام Android 9 ولكنه اختياري للأجهزة التي تقوم بالترقية إلى Android 9 وللأجهزة التي تعمل بإصدارات أقل من Android. في تكوين نظام Android 10 كجذر، يدمج الإصدار دائمًا $TARGET_SYSTEM_OUT
و $TARGET_ROOT_OUT
في system.img
؛ هذا التكوين هو السلوك الافتراضي لجميع الأجهزة التي تعمل بنظام Android 10.
يُجري Android 10 مزيدًا من التغييرات لدعم الأقسام الديناميكية ، وهو نظام تقسيم مساحة المستخدم الذي يمكّن التحديثات عبر الهواء (OTA) من إنشاء الأقسام أو تغيير حجمها أو تدميرها. وكجزء من هذا التغيير، لم يعد بإمكان نواة Linux تحميل قسم النظام المنطقي على الأجهزة التي تعمل بنظام Android 10، لذلك تتم معالجة هذه العملية من خلال المرحلة الأولى من init.
تصف الأقسام التالية متطلبات النظام كجذر لوكالات السفر عبر الإنترنت للنظام فقط، وتوفر إرشادات حول تحديث الأجهزة لاستخدام النظام كجذر (بما في ذلك تغييرات تخطيط القسم ومتطلبات kernel dm-verity). للحصول على تفاصيل حول التغييرات التي تم إجراؤها على ramdisk، راجع أقسام Ramdisk .
حول وكالات السفر عبر الإنترنت للنظام فقط
تتطلب وكالات السفر عبر الإنترنت للنظام فقط، والتي تمكن إصدارات 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
. إذا كان هناك عدم تطابق في سياق الملف بين ملفات تراكب المورد والملفات التي تستبدلها، فحدد ذلك في السياسة الخاصة بالجهاز. يتم تعيين سياق الملف على مستوى الدليل. إذا كان سياق الملف الخاص بدليل تراكب البائع لا يتطابق مع الدليل الهدف، ولم يتم تحديد سياق الملف الصحيح في السياسة الخاصة بالجهاز، فلن يتم تراكب دليل تراكب البائع هذا على الدليل الهدف.
لاستخدام تراكب البائع، يجب على النواة تمكين OverlayFS عن طريق ضبط 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
، وإعداد dm-verity، وإزالة أي تبعيات تمهيد على المجلدات الجذرية الخاصة بالجهاز.
تحديث الأقسام
على عكس أجهزة A/B التي تعيد استخدام /boot
كقسم استرداد ، يجب على الأجهزة غير A/B أن تبقي قسم /recovery
منفصلاً لأنها لا تحتوي على قسم فتحة احتياطية (على سبيل المثال، من boot_a
إلى boot_b
). إذا تمت إزالة /recovery
على جهاز غير A/B وتم جعله مشابهًا لنظام A/B، فقد ينقطع وضع الاسترداد أثناء التحديث الفاشل لقسم /boot
. لهذا السبب، يجب أن يكون قسم /recovery
قسمًا منفصلاً عن /boot
للأجهزة غير A/B، مما يعني أن صورة الاسترداد سيستمر تحديثها بطريقة مؤجلة (أي كما هو الحال في الأجهزة التي تعمل بنظام 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) ... |
الأقسام نفسها لا تتغير. يستخدم كل من ramdisk والنظام كجذر نظام التقسيم التالي:
-
/boot
-
/system
-
/system
-
/recovery
-
/vendor
، الخ.
إعداد dm-verity
في النظام كجذر، يجب أن تقوم النواة بتركيب system.img
ضمن /
(نقطة التحميل) باستخدام dm-verity . يدعم AOSP تطبيقات dm-verity التالية لـ system.img
.
فبوت 1.0
بالنسبة إلى vboot 1.0 ، يجب على kernel تحليل البيانات التعريفية الخاصة بـ Android على /system
، ثم تحويلها إلى معلمات dm-verity لإعداد dm-verity (يتطلب تصحيحات kernel هذه ). يوضح المثال التالي الإعدادات ذات الصلة بـ dm-verity للنظام كجذر في سطر أوامر kernel:
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 params ، ويمرر المعلمات أخيرًا إلى kernel من خلال سطر أوامر kernel. (قد تكون واصفات Hashtree لـ /system
موجودة على /vbmeta
أو على /system
نفسه.)
يتطلب vboot 2.0 تصحيحات kernel التالية:
- https://android-review.googlesource.com/#/c/kernel/common/+/158491/
- تصحيحات kernel 4.4 وتصحيحات kernel 4.9 وما إلى ذلك.
يوضح المثال التالي الإعدادات ذات الصلة بـ dm-verity للنظام كجذر في سطر أوامر kernel:
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
لأنه تم استبدال محتوى الدليل الجذر بالكامل بواسطة النظام كجذر GSI. قد تؤدي إزالة هذه المجلدات إلى عدم إمكانية تشغيل الجهاز في حالة وجود تبعية للمجلدات الجذرية الخاصة بالجهاز (على سبيل المثال، يتم استخدامها كنقاط تحميل).
لتجنب هذه المشكلة، لا تستخدم BOARD_ROOT_EXTRA_FOLDERS
لإضافة المجلدات الجذرية الخاصة بالجهاز. إذا كنت بحاجة إلى تحديد نقاط تثبيت خاصة بالجهاز، فاستخدم /mnt/vendor/<mount point>
(تمت إضافته في قوائم التغيير هذه). يمكن تحديد نقاط التثبيت الخاصة بالمورد مباشرة في كل من شجرة جهاز fstab
(لتثبيت المرحلة الأولى) وملف /vendor/etc/fstab.{ro.hardware}
بدون إعداد إضافي (حيث يقوم fs_mgr
بإنشائها ضمن /mnt/vendor/*
تلقائيًا).