تمت ترجمة هذه الصفحة بواسطة Cloud Translation API‏.

تخطيط التقسيم

في 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/* تلقائيًا).