اعتبارًا من عام 2026، ولضمان اتّساق نموذج التطوير الثابت الأساسي واستقرار المنصة في النظام المتكامل، سننشر رمز المصدر في مشروع Android مفتوح المصدر (AOSP) في الربعَين الثاني والرابع. لبناء مشروع Android مفتوح المصدر والمساهمة فيه، استخدِم android-latest-release. سيشير فرع بيان android-latest-release دائمًا إلى أحدث إصدار تم نشره في مشروع Android مفتوح المصدر. لمزيد من المعلومات، يُرجى الاطّلاع على التغييرات في مشروع Android مفتوح المصدر.

تستخدم Google تكنولوجيا الذكاء الاصطناعي لترجمة المحتوى إلى لغتك المفضّلة، وقد تتضمّن بعض الأخطاء.

تنسيق القسم

في نظام التشغيل 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). هذا الإعداد إلزامي للأجهزة التي تعمل بالإصدار 9 من نظام التشغيل Android عند إطلاقها، ولكنه اختياري للأجهزة التي يتم ترقيتها إلى الإصدار 9 من نظام التشغيل Android والأجهزة التي تعمل بإصدارات أقدم من نظام التشغيل Android. في إعدادات Android 10 التي تستخدم النظام كجذر، يدمج الإصدار دائمًا $TARGET_SYSTEM_OUT و$TARGET_ROOT_OUT في system.img، وهذا الإعداد هو السلوك التلقائي لجميع الأجهزة التي تعمل بنظام التشغيل Android 10.

يُجري نظام التشغيل Android 10 المزيد من التغييرات لدعم الأقسام الديناميكية، وهو نظام تقسيم لمساحة المستخدم يتيح إجراء التحديثات عبر الهواء (OTA) لإنشاء الأقسام أو تغيير حجمها أو إزالتها. في إطار هذا التغيير، لم يعُد بإمكان نواة Linux تثبيت قسم النظام المنطقي على الأجهزة التي تعمل بنظام التشغيل Android 10، لذا تتولّى عملية التثبيت عملية init في المرحلة الأولى.

توضّح الأقسام التالية متطلبات نظام التشغيل كجذر لنظام OTA، وتقدّم إرشادات حول تعديل الأجهزة لاستخدام نظام التشغيل كجذر (بما في ذلك تغييرات تصميم الأقسام ومتطلبات نواة dm-verity). للحصول على تفاصيل حول التغييرات التي أُجريت على ramdisk، يُرجى الاطّلاع على أقسام Ramdisk.

لمحة عن تحديثات النظام عبر شبكة غير سلكية فقط

تتطلّب تحديثات OTA للنظام فقط، والتي تتيح تحديث إصدارات Android لقسمَي system.img وproduct.img بدون تغيير الأقسام الأخرى، تصميم قسم "النظام كجذر". يجب أن تستخدم جميع الأجهزة التي تعمل بنظام التشغيل Android 10 تصميم أقسام بنظام التشغيل كجذر لتفعيل تحديثات عبر الأثير (OTA) للنظام فقط.

تستخدم أجهزة A/B، التي يتم فيها تركيب القسم system كملف rootfs، ميزة "النظام كجذر"، ولا تتطلّب إجراء تغييرات لتوفير تحديثات عبر الأثير للنظام.
يجب تعديل الأجهزة غير المتوافقة مع A/B لاستخدام تصميم قسم نظام كجذر من أجل إتاحة تحديثات النظام عبر الأثير، وذلك لأنّها تثبّت القسم system في /system.

للحصول على تفاصيل حول الأجهزة التي تتضمّن تقسيمًا إلى قسمين (A/B) والأجهزة التي لا تتضمّن هذا التقسيم، يُرجى الرجوع إلى تحديثات النظام (السلسة) من النوع أ/ب.

استخدام المحتوى المركّب الخاص بالمورّد (الإصدار 14 من نظام التشغيل Android أو إصدار أقدم)

تتيح لك طبقة المورّد إمكانية تطبيق تغييرات على القسم 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، ما يعني أنّه سيستمر تعديل صورة استرداد الإعدادات الأصلية بطريقة مؤجّلة (أي كما هو الحال في الأجهزة التي تعمل بالإصدار 8.1.0 من نظام التشغيل Android أو الإصدارات الأقدم).

يسرد الجدول التالي اختلافات أقسام الصور للأجهزة غير المتوافقة مع A/B قبل وبعد الإصدار 9 من نظام التشغيل Android.

صورة	Ramdisk (قبل الإصدار 9 من نظام التشغيل Android)	System-as-root (بعد الإصدار 9 من نظام التشغيل Android)
`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 وsystem-as-root مخطط الأقسام التالي:

/boot
/system
/system
/recovery
‫/vendor وما إلى ذلك

إعداد dm-verity

في نظام التشغيل كجذر، يجب أن يركّب النواة system.img ضمن / (نقطة التركيب) باستخدام dm-verity. يتوافق AOSP مع عمليات تنفيذ dm-verity التالية لـ system.img.

الإصدار 1.0 من vboot

بالنسبة إلى vboot 1.0، يجب أن يحلّل النواة البيانات الوصفية الخاصة بنظام Android على /system، ثم يحوّلها إلى مَعلمات dm-verity لإعداد dm-verity (يتطلّب ذلك تصحيحات النواة هذه). يوضّح المثال التالي الإعدادات ذات الصلة بـ dm-verity لنظام التشغيل system-as-root في سطر أوامر النواة:

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

vboot 2.0

في الإصدار 2.0 من عملية التحقّق من صحة نظام التشغيل (AVB)، يجب أن يدمج برنامج الإقلاع external/avb/libavb، الذي يحلّل واصف شجرة التجزئة لـ /system، ويحوّله إلى مَعلمات dm-verity، ثم يمرّر المَعلمات إلى النواة من خلال سطر أوامر النواة. (قد تكون واصفات Hashtree الخاصة بـ /system موجودة على /vbmeta أو على /system نفسها).

يتطلّب الإصدار 2.0 من vboot تصحيحات النواة التالية:

يوضّح المثال التالي الإعدادات ذات الصلة بـ dm-verity لنظام التشغيل system-as-root في سطر أوامر النواة:

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) على الجهاز (وقبل تشغيل اختبارات مجموعة اختبارات المورّدين)، ستتم إزالة أي مجلدات جذر خاصة بالجهاز تمت إضافتها باستخدام BOARD_ROOT_EXTRA_FOLDERS، لأنّه تم استبدال محتوى دليل الجذر بالكامل بصورة النظام العامة (GSI) التي تستخدم نظام التشغيل كجذر. قد يؤدي إزالة هذه المجلدات إلى تعذُّر تشغيل الجهاز إذا كان هناك اعتماد على مجلدات الجذر الخاصة بالجهاز (على سبيل المثال، إذا كانت تُستخدم كنقاط ربط).

لتجنُّب هذه المشكلة، لا تستخدِم BOARD_ROOT_EXTRA_FOLDERS لإضافة مجلدات جذر خاصة بالجهاز. إذا كنت بحاجة إلى تحديد نقاط ربط خاصة بالجهاز، استخدِم /mnt/vendor/<mount point> (تمت إضافتها في قوائم تغييرات هذه). يمكن تحديد نقاط الربط الخاصة بالمورّد مباشرةً في كل من شجرة الأجهزة fstab (لعملية الربط في المرحلة الأولى) وملف /vendor/etc/fstab.{ro.hardware} بدون الحاجة إلى إعدادات إضافية (لأنّ fs_mgr ينشئها تلقائيًا ضمن /mnt/vendor/*).