تخطيط القسم

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

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

يختلف معنى ضبط النظام كجذر بين الإصدار Android 9 الإصدار 10 من نظام التشغيل Android في نظام Android 9 كجذر الإعداد، تم ضبط BOARD_BUILD_SYSTEM_ROOT_IMAGE على true، وهو ما يفرض على الإصدار دمج نظام الملفات الجذر في system.img ثم تثبيت system.img كملف الجذر النظام (rootfs). هذه الإعدادات إلزامية للأجهزة. التي تعمل بنظام التشغيل Android 9 ولكنها اختيارية للأجهزة التي تتم ترقيتها إلى الإصدار 9 من نظام التشغيل Android والأجهزة التي تعمل بإصدارات أقدم من نظام التشغيل Android في جهاز Android 10 من إعدادات النظام كجذر، سيتواصل الإصدار يدمج $TARGET_SYSTEM_OUT و$TARGET_ROOT_OUT في system.img؛ هذه الإعدادات هي السلوك التلقائي لجميع الأجهزة. يعمل بنظام Android 10.

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

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

لمحة عن وكالات السفر على الإنترنت المستندة إلى النظام فقط

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

• أجهزة A/B التي يتم تثبيت قسم system عليها كبرامج الجذر تستخدم النظام كجذر بالفعل ولا تتطلب تغييرات لدعم وكالات السفر على الإنترنت للنظام.
• الأجهزة غير A/B التي يتم تثبيت قسم 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>

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

تثبيت ملفات تراكب المورّدين في /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/*

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 وإزالة أي تبعيات تشغيل على الجذر الخاص بالجهاز المجلدات.

تحديث الأقسام

على عكس أجهزة 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. قبل الإصدار 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.

الإصدار 1.0 من نظام التشغيل vboot

بالنسبة إلى vboot 1.0، يجب أن تحلّل النواة kernel. خاص بنظام 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 من vboot (AVB)، يجب أن يتم دمج برنامج الإقلاع. external/avb/libavb، الذي يحلّل واصف التجزئة لـ /system، يتم تحويله إلى معلمات dm-verity، وأخيرًا تمرير المَعلمات إلى عبر سطر أوامر النواة. (واصفات التجزئة للدالة /system قد يكون على /vbmeta أو على /system نفسه).

يتطلب vboot 2.0 تصحيحات النواة التالية:

• https://android-review.googlesource.com/#/c/kernel/common/+/158491/
• تصحيحات النواة 4.4 تصحيحات النواة 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) تومض على الجهاز (وقبل التشغيل حزمة اختبار البائعين)، وأي تمت إضافة مجلدات الجذر الخاصة بالجهاز باستخدام BOARD_ROOT_EXTRA_FOLDERS اختفت بسبب استبدال محتوى الدليل الجذر بالكامل نظام GSI الخاص بالنظام والجذر. وقد تؤدي إزالة هذه المجلدات إلى تصبح غير قابلة للتشغيل في حال وجود تبعية على مجلدات الجذر الخاصة بالجهاز (على سبيل المثال، تستخدم كنقاط تثبيت).

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