تنسيق القسم

تنظيم صفحاتك في مجموعات يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.

في Android 10، لم يعُد نظام ملفات الجذر مضمّنًا في ramdisk.img، بل يتم دمجه بدلاً من ذلك في system.img (أي أنّه يتم إنشاء system.img دائمًا كملف إذا تم ضبط BOARD_BUILD_SYSTEM_ROOT_IMAGE). الأجهزة التي تعمل بالإصدار 10 من نظام التشغيل Android:

• استخدام تنسيق قسم النظام بصفتها الجذر (يتم فرضه تلقائيًا من خلال الإصدار بدون خيارات لتغيير السلوك)
• يجب استخدام قرص RAM، وهو مطلوب لنظام dm-linear.
• يجب ضبط BOARD_BUILD_SYSTEM_ROOT_IMAGE على false. لا يُستخدَم هذا الإعداد إلا للتمييز بين الأجهزة التي تستخدم ملف ramdisk والأجهزة التي لا تستخدمه (وبدلاً من ذلك يتم تركيب system.img مباشرةً).

يختلف معنى إعداد "النظام بصفتها الجذر" بين الإصدار 9 من Android والإصدار 10 من Android. في إعدادات نظام 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، لذا تُعالج هذه العملية من خلال مرحلة الإعداد الأولى.

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

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

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

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

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

استخدام المحتوى المركّب الخاص بالمورّد (<=AOSP 14)

يتيح لك تراكب المورّد إمكانية تراكب التغييرات على قسم 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>.

تنفيذ ميزة "العنصر الذي يظهر على سطح التطبيق" لمقدّم الخدمة

ثبِّت ملفات تراكب المورّدين في directory /product/vendor_overlay/<target_vendor_version>. تُضاف هذه الملفات فوق قسم vendor عند تشغيل الجهاز، ما يؤدي إلى استبدال الملفات التي تحمل الاسم نفسه وإضافة أي ملفات جديدة. لا يمكن للطبقة الإضافية الخاصة بالمورّد إزالة الملفات من قسم vendor.

يجب أن تتضمّن ملفات تراكب المورّدين سياق الملف نفسه المستخدَم في الملفات المستهدفة التي تحلّ محلها في قسم vendor. تكون الملفات في دليل /product/vendor_overlay/<target_vendor_version> مزوّدة تلقائيًا بالسياق vendor_file. في حال حدوث عدم تطابق في سياق الملفات بين ملفات التراكب الخاصة بالمورّد والملفات التي تستبدلها، حدِّد ذلك في سياسة الأمان الخاصة بالجهاز. يتم ضبط سياق الملف على مستوى الدليل. إذا كان سياق الملف لدليل التراكب الخاص بالمورّد لا يتطابق مع الدليل الهدف، ولم يتم تحديد سياق الملف الصحيح في سياسة الأمان الخاصة بالجهاز، لن يتم تراكب دليل التراكب الخاص بالمورّد على الدليل الهدف.

لاستخدام ميزة "التراكب من المصنّع"، يجب أن يفعّل ملفّ kernel OverlayFS من خلال ضبط الإعداد CONFIG_OVERLAY_FS=y. يجب أيضًا دمج النواة من النواة الشائعة 4.4 أو إصدار أحدث، أو تصحيحها باستخدام "overlayfs: override_creds=off option bypass creator_cred".

مثال على تنفيذ تراكب المورّد

يوضّح هذا الإجراء تنفيذ تراكب مورّد يتراكب مع الدلائل /vendor/lib/* و/vendor/etc/* و /vendor/app/*.

1. أضِف ملفات المورّدين المُعدّة مسبقًا في 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

2. ثبِّت ملفات المورّدين المُعدّة مسبقًا في ملف 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)

3. حدِّد سياقات الملفات إذا كانت ملفات قسم 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

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

يسرد الجدول التالي الاختلافات في أقسام الصور للأجهزة غير المزوّدة بميزة "التحديث الثنائي" قبل توفّر الإصدار 9 من Android وبعده.

ramdisk.img
  -/
    - init.rc
    - init
    - etc -> /system/etc
    - system/ (mount point)
    - vendor/ (mount point)
    - odm/ (mount point)
    ...

system.img
  -/
    - bin/
    - etc
    - vendor -> /vendor
    - ...

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.

vboot 1.0

بالنسبة إلى vboot 1.0، يجب أن تُحلِّل النواة البيانات الوصفية الخاصة بنظام التشغيل Android على /system، ثم تحوّلها إلى مَعلمات dm-verity لإعداد dm-verity (يتطلب ذلك تصحيحات النواة هذه). يوضّح المثال التالي الإعدادات ذات الصلة ببرنامج 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

vboot 2.0

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

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

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