تنفيذ التقسيم الديناميكي باستخدام أداة تخطيط الأجهزة الخطية بنظام dm
في نواة Linux. يحتوي القسم super
على
البيانات الوصفية التي تسرد أسماء كل قسم ديناميكي ونطاقات الحظر
في حدود super
. خلال المرحلة الأولى من init
، سيتم
تحليل بيانات التعريف والتحقق من صحتها، ويتم إنشاء أجهزة الكتل الافتراضية
لتمثيل كل قسم ديناميكي.
عند تطبيق التحديث عبر الهواء، يتم إنشاء أقسام ديناميكية تلقائيًا، أو تغيير حجمها أو حذفها حسب الحاجة. بالنسبة لأجهزة A/B، هناك نسختان من بيانات التعريف، ولا يتم تطبيق التغييرات إلا على النسخة التي تمثل الشريحة المستهدفة.
يجب إنشاء أقسام بسبب تطبيق الأقسام الديناميكية في مساحة المستخدم
من خلال برنامج الإقلاع. على سبيل المثال: boot
تتم قراءة dtbo
وvbmeta
من خلال برنامج الإقلاع
لذلك يجب أن تظل كأقسام مادية.
يمكن أن ينتمي كل قسم ديناميكي إلى مجموعة تحديثات. هذه
تحدد المجموعات الحد الأقصى للمساحة التي يمكن أن تستهلكها الأقسام في هذه المجموعة.
على سبيل المثال، يمكن أن ينتمي system
وvendor
إلى
التي تفرض قيودًا على الحجم الإجمالي لـ system
vendor
تنفيذ التقسيمات الديناميكية على الأجهزة الجديدة
يوضّح هذا القسم كيفية تنفيذ التقسيمات الديناميكية على الأجهزة الجديدة. لنظام التشغيل Android 10 والإصدارات الأحدث. للتحديث الأجهزة الحالية، راجع ترقية Android الأجهزة.
تغييرات الأقسام
بالنسبة إلى الأجهزة التي تعمل بنظام التشغيل Android 10، أنشئ
قسم يسمى super
. super
تتعامل أجهزة التقسيم مع منافذ A/B داخليًا، لذلك لا تحتاج أجهزة A/B إلى
الفصل بين القسمَين super_a
وsuper_b
.
يجب أن تكون جميع أقسام AOSP للقراءة فقط ولا تستخدمها برنامج الإقلاع
أن تكون ديناميكية ويجب إزالتها من جدول تقسيم المعرّف الفريد العالمي (GPT).
لا يجب أن تكون الأقسام الخاصة بالمورّدين ديناميكية، ويمكن وضعها
في جدول تقسيم المعرّف الفريد العمومي.
لتقدير حجم super
، أضِف مقاسات
الأقسام التي يتم حذفها من GPT. بالنسبة لأجهزة A/B، ينطبق هذا
حجم كلتا الخانتين. يوضّح الشكل 1
مثال لجدول التقسيم قبل وبعد التحويل إلى التحويل الديناميكي
الأقسام.
الأقسام الديناميكية المتوافقة هي:
- النظام
- المورّد
- المنتَج
- ملحقات النظام
- ODM
بالنسبة إلى الأجهزة التي تعمل بنظام التشغيل Android 10، سيتم تطبيق
خيار سطر أوامر النواة androidboot.super_partition
فارغًا بحيث يمكن للأمر sys تلك
حقل ro.boot.super_partition
فارغ.
محاذاة القسم
وقد تعمل وحدة خرائط الأجهزة بكفاءة أقل إذا
لم تتم محاذاة قسم super
بشكل صحيح. تشير رسالة الأشكال البيانية
يجب محاذاة قسم super
مع الحد الأدنى من وحدات الإدخال/الإخراج
طلب الحجم على النحو الذي تحدده طبقة الكتلة. بشكل افتراضي،
(عبر lpmake
، والذي ينشئ
super
لصورة القسم)، تفترض أن المحاذاة بقيمة 1 ميبيبايت
كافيًا لكل قسم ديناميكي ومع ذلك، يجب على البائعين
تأكَّد من محاذاة قسم super
بشكل صحيح.
يمكنك تحديد الحد الأدنى لحجم الطلب لجهاز حظر من خلال
فحص sysfs
. مثلاً:
# ls -l /dev/block/by-name/super lrwxrwxrwx 1 root root 16 1970-04-05 01:41 /dev/block/by-name/super -> /dev/block/sda17 # cat /sys/block/sda/queue/minimum_io_size 786432
يمكنك التحقّق من محاذاة القسم super
في
بطريقة مماثلة:
# cat /sys/block/sda/sda17/alignment_offset
يجب أن تكون إزاحة المحاذاة 0.
التغييرات على إعدادات الجهاز
لتفعيل التقسيم الديناميكي، أضِف العلامة التالية في
device.mk
:
PRODUCT_USE_DYNAMIC_PARTITIONS := true
تغييرات إعدادات لوحة الجهاز
عليك ضبط حجم قسم "super
":
BOARD_SUPER_PARTITION_SIZE := <size-in-bytes>
في أجهزة A/B، يعرض نظام التصميم رسالة خطأ إذا كان الحجم الإجمالي
في صور الأقسام الديناميكية أكثر من نصف super
حجم القسم.
يمكنك ضبط قائمة الأقسام الديناميكية على النحو التالي. بالنسبة
الأجهزة التي تستخدم مجموعات التحديث، اسرد المجموعات في
متغيّر "BOARD_SUPER_PARTITION_GROUPS
" كل اسم مجموعة
يتضمّن BOARD_group_SIZE
وBOARD_group_PARTITION_LIST
المتغير.
بالنسبة إلى أجهزة A/B، يجب أن يشمل الحد الأقصى لحجم المجموعة عنصرًا واحدًا فقط.
خانة، حيث تكون أسماء المجموعات مُدخلة داخليًا في خانة.
في ما يلي مثال على جهاز يضع جميع الأقسام في مجموعة.
يُسمى example_dynamic_partitions
:
BOARD_SUPER_PARTITION_GROUPS := example_dynamic_partitions BOARD_EXAMPLE_DYNAMIC_PARTITIONS_SIZE := 6442450944 BOARD_EXAMPLE_DYNAMIC_PARTITIONS_PARTITION_LIST := system vendor product
في ما يلي مثال على جهاز يضع خدمات النظام والمنتجات في
group_foo
، وvendor
، وproduct
،
وodm
إلى group_bar
:
BOARD_SUPER_PARTITION_GROUPS := group_foo group_bar BOARD_GROUP_FOO_SIZE := 4831838208 BOARD_GROUP_FOO_PARTITION_LIST := system product_services BOARD_GROUP_BAR_SIZE := 1610612736 BOARD_GROUP_BAR_PARTITION_LIST := vendor product odm
-
بالنسبة إلى أجهزة إطلاق A/B الافتراضية، يجب أن يكون مجموع الحد الأقصى لكل المجموعات
على الأكثر:
BOARD_SUPER_PARTITION_SIZE
- النفقات العامة
راجع تنفيذ اختبار A/B الافتراضي. -
بالنسبة لأجهزة إطلاق A/B، يجب أن يكون مجموع الحد الأقصى للأحجام لكل المجموعات
ستكون:
BOARD_SUPER_PARTITION_SIZE
/ 2 - النفقات العامة -
بالنسبة للأجهزة بخلاف أجهزة A/B وأجهزة تعديل A/B، يكون مجموع عرض السعر
يجب أن تكون أحجام كل المجموعات:
BOARD_SUPER_PARTITION_SIZE
- النفقات العامة - أثناء وقت الإنشاء، يشير هذا المصطلح إلى مجموع أحجام الصور في كل قسم. في مجموعة التحديث، يجب ألا يتجاوز الحد الأقصى لحجم المجموعة.
- النفقات العامة مطلوبة في العمليات الحسابية لحساب البيانات الوصفية، والمحاذاة، وما إلى ذلك. تبلغ النفقات العامة المعقولة 4 ميبيبايت، ولكنك يمكنك اختيار زيادة أكبر حسب الحاجة بواسطة الجهاز.
حجم الأقسام الديناميكية
قبل الأقسام الديناميكية، كان يتم تخصيص أحجام الأقسام بشكل زائد والتأكد من توفر مساحة كافية لها للتحديثات المستقبلية. الحجم الفعلي على النحو المعتاد، وكان لدى معظم الأقسام المخصصة للقراءة فقط مقدارًا من البيانات المجانية مساحة في نظام الملفات الخاص بها. في الأقسام الديناميكية، تكون هذه المساحة الخالية ويمكن استخدامها لزيادة التقسيمات أثناء إجراء التحديث عبر الهواء. من الضروري التأكد من أن الأقسام لا تهدر مساحة وأنها المخصصة لأدنى حجم ممكن.
بالنسبة إلى صور ext4 للقراءة فقط، يخصِّص نظام التصميم تلقائيًا الحد الأدنى للحجم في حال عدم تحديد حجم القسم الثابت. تشير رسالة الأشكال البيانية نظام التصميم يناسب الصورة بحيث يحتوي نظام الملفات على أقل قدر ممكن مساحة غير مستخدمة قدر الإمكان. يضمن هذا عدم إهدار الجهاز المساحة التي يمكن استخدامها لوكالات السفر على الإنترنت.
ويمكن أيضًا ضغط الصور ext4 عن طريق تفعيل إزالة تكرار المستوى. لتفعيل ذلك، استخدِم الإعدادات التالية:
BOARD_EXT4_SHARE_DUP_BLOCKS := true
في حال كان التخصيص التلقائي للحد الأدنى للقسم غير مرغوب فيه،
هناك طريقتان للتحكّم في حجم القسم. يمكنك تحديد
الحد الأدنى من المساحة الخالية
BOARD_partitionIMAGE_PARTITION_RESERVED_SIZE
,
أو يمكنك تحديد
BOARD_partitionIMAGE_PARTITION_SIZE
للفرض
أقسام ديناميكية محددة إلى حجم معين. لا يهمّني أيّ منهما
أوصى به إلا في حالة الضرورة.
مثلاً:
BOARD_PRODUCTIMAGE_PARTITION_RESERVED_SIZE := 52428800
يفرض ذلك على نظام الملفات في product.img
مساحة تخزين غير مُستخدَمة تبلغ 50 ميغا بايت.
التغييرات في النظام كجذر
يجب ألّا تعمل الأجهزة التي تعمل بنظام التشغيل Android 10 استخدام النظام كجذر.
الأجهزة التي تحتوي على أقسام ديناميكية (سواء تم تشغيلها مع عمليات التعديل أو تم فتحها)
أقسام ديناميكية) يجب ألا يستخدم النظام كجذر. لا يمكن لنواة Linux
تفسير قسم super
وبالتالي لا يمكن التثبيت
system
نفسه تم تثبيت system
الآن من خلال
المرحلة الأولى من "init
" المتوفّرة في الهرم.
لا تضبط السمة BOARD_BUILD_SYSTEM_ROOT_IMAGE
. ضِمن
Android 10،
تُستخدَم العلامة BOARD_BUILD_SYSTEM_ROOT_IMAGE
فقط
ما إذا كان النظام مثبّتًا بواسطة النواة (kernel) أو من خلال
المرحلة الأولى من "init
" في ramdisk.
جارٍ ضبط BOARD_BUILD_SYSTEM_ROOT_IMAGE
على true
إلى حدوث خطأ في الإصدار عند
PRODUCT_USE_DYNAMIC_PARTITIONS
هو أيضًا true
.
عند ضبط BOARD_USES_RECOVERY_AS_BOOT
على "صحيح"،
النسخة المخصصة لاسترداد البيانات بتنسيق Boot.img، وهي تحتوي على
رمكس. في السابق، كان برنامج الإقلاع يستخدم النواة skip_initramfs
.
سطر الأوامر لتحديد الوضع الذي يتم التمهيد فيه. بالنسبة
أجهزة Android 10، يجب ألا يجتاز برنامج الإقلاع برنامج الإقلاع
skip_initramfs
إلى سطر أوامر النواة. ولكن بدلاً من ذلك،
يجب اجتياز androidboot.force_normal_boot=1
لتخطّي عملية الاسترداد
وتشغيل Android العادي. إطلاق الأجهزة التي تعمل بنظام التشغيل Android 12
أو في وقت لاحق يجب أن يستخدم Bootconfig لاجتياز androidboot.force_normal_boot=1
.
تغييرات إعدادات AVB
عند استخدام Android الإصدار 2.0 من نظام التشغيل الذي تم التحقّق منه، إذا كان الجهاز لا يستخدم القسم المتسلسل واصفات البيانات، فلا يلزم إجراء أي تغيير. في حال استخدام سلاسل إلا أن أحد الأقسام التي تم التحقق منها هو قسم ديناميكي، تكون التغييرات ضرورية.
في ما يلي مثال على عملية ضبط لجهاز يستند إلى سلسلة
vbmeta
لكل من system
vendor
قسمًا.
BOARD_AVB_SYSTEM_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem BOARD_AVB_SYSTEM_ALGORITHM := SHA256_RSA2048 BOARD_AVB_SYSTEM_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP) BOARD_AVB_SYSTEM_ROLLBACK_INDEX_LOCATION := 1 BOARD_AVB_VENDOR_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem BOARD_AVB_VENDOR_ALGORITHM := SHA256_RSA2048 BOARD_AVB_VENDOR_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP) BOARD_AVB_VENDOR_ROLLBACK_INDEX_LOCATION := 1
باستخدام هذه الإعدادات، من المتوقع أن يعثر برنامج الإقلاع على رمز vbmeta
التذييل في نهاية system
قسمان (vendor
). لأنّ هذه الأقسام لم تعُد
مرئية لبرنامج الإقلاع (الظاهر على super
)، اثنان
الحاجة إلى التغييرات.
-
إضافة
vbmeta_system
وvbmeta_vendor
الأقسام إلى جدول أقسام الجهاز. بالنسبة إلى أجهزة A/B، يمكنك إضافةvbmeta_system_a
،vbmeta_system_b
،vbmeta_vendor_a
، وvbmeta_vendor_b
. في حال حذف إضافة قسم واحد أو أكثر من هذه الأقسام، فيجب أن تكون بنفس الحجم باعتباره قسمvbmeta
. -
عليك إعادة تسمية علامات الإعداد من خلال إضافة
VBMETA_
تحديد الأقسام التي تمتد التسلسل إليها:BOARD_AVB_VBMETA_SYSTEM := system BOARD_AVB_VBMETA_SYSTEM_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem BOARD_AVB_VBMETA_SYSTEM_ALGORITHM := SHA256_RSA2048 BOARD_AVB_VBMETA_SYSTEM_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP) BOARD_AVB_VBMETA_SYSTEM_ROLLBACK_INDEX_LOCATION := 1 BOARD_AVB_VBMETA_VENDOR := vendor BOARD_AVB_VBMETA_VENDOR_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem BOARD_AVB_VBMETA_VENDOR_ALGORITHM := SHA256_RSA2048 BOARD_AVB_VBMETA_VENDOR_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP) BOARD_AVB_VBMETA_VENDOR_ROLLBACK_INDEX_LOCATION := 1
وقد يستخدم الجهاز قسمًا واحدًا من هذين القسمَين أو كليهما أو لا يستخدم أيًا منهما. التغييرات إلا عند إجراء تسلسل إلى قسم منطقي.
التغييرات على برنامج إقلاع AVB
إذا كان برنامج الإقلاع مضمَّنًا في libavb، تضمين التصحيحات التالية:
- 818cf56740775446285466eda984acedd4baeac0 — "libavb: طلب البحث عن معرفات GUID فقط عندما يحتاج cmdline ".
- 5abd6bc2578968d24406d834471adfd995a0c2e9 — "السماح بعدم ظهور قسم النظام"
- 9ba3b6613b4e5130fa01a11d984c6b5f0eb3af05 — "Fix AvbSlotVerifyData->cmdline ربما يكون NULL"
في حال استخدام الأقسام المتسلسلة، يجب تضمين رمز تصحيح إضافي:
- 49936b4c0109411fdd38bd4ba3a32a01c40439a9 — "libavb: دعم وحدات تخزين البيانات الثنائية الكبيرة vbmeta في بداية التقسيم"
تغييرات سطر أوامر Kernel
يجب إضافة مَعلمة جديدة androidboot.boot_devices
.
إلى سطر أوامر النواة. يتم استخدام ذلك من قِبل init
من أجل
لتفعيل الروابط الرمزية لـ /dev/block/by-name
. يجب أن تكون
مكوّن مسار الجهاز إلى الرابط الرمزي الأساسي حسب الاسم الذي تم إنشاؤه بواسطة
ueventd
، أي
/dev/block/platform/device-path/by-name/partition-name
يجب أن تستخدم الأجهزة التي تعمل بنظام التشغيل Android 12 أو الإصدارات الأحدث
التمهيد لتمرير androidboot.boot_devices
إلى init
.
على سبيل المثال، إذا كان الرابط الرمزي الخاص بالقسم المميز حسب الاسم
/dev/block/platform/soc/100000.ufshc/by-name/super
,
يمكنك إضافة معلمة سطر الأوامر في ملف BoardConfig.mk
التالي:
BOARD_KERNEL_CMDLINE += androidboot.boot_devices=soc/100000.ufshcيمكنك إضافة مَعلمة Bootconfig في ملف BoardConfig.mk على النحو التالي:
BOARD_BOOTCONFIG += androidboot.boot_devices=soc/100000.ufshc
تغييرات fstab
يجب ألا تحتوي شجرة الجهاز وتراكبات شجرة الأجهزة على برنامج fstab الإدخالات. استخدم ملف fstab الذي سيكون جزءًا من ramdisk.
يجب إجراء التغييرات على ملف fstab للأقسام المنطقية:
-
يجب أن يشتمل حقل العلامات fs_mgr على علامة
logical
. وعلامةfirst_stage_mount
، اللتان تم طرحهما في نظام التشغيل Android 10، الذي يشير إلى أن أحد الأقسام يجب مثبّتة في المرحلة الأولى. -
قد يحدد التقسيم
avb=vbmeta partition name
كـ علامةfs_mgr
ثم علامةvbmeta
المحددة يتم إعداد التقسيم من خلال المرحلة الأولىinit
قبل محاولة تثبيت أي أجهزة. -
يجب أن يكون الحقل
dev
هو اسم القسم.
تعيّن إدخالات fstab التالية النظام والبائع والمنتج كمنطقي الأقسام وفقًا للقواعد المذكورة أعلاه.
#<dev> <mnt_point> <type> <mnt_flags options> <fs_mgr_flags> system /system ext4 ro,barrier=1 wait,slotselect,avb=vbmeta,logical,first_stage_mount vendor /vendor ext4 ro,barrier=1 wait,slotselect,avb,logical,first_stage_mount product /product ext4 ro,barrier=1 wait,slotselect,avb,logical,first_stage_mount
انسخ ملف fstab إلى المرحلة الأولى من ذاكرة القرص.
التغييرات على SELinux
يجب وضع علامة التصنيف على جهاز حظر التقسيم الفائق.
super_block_device
على سبيل المثال، إذا كان الرابط الرمزي الخاص بالقسم المميز حسب الاسم
/dev/block/platform/soc/100000.ufshc/by-name/super
,
أضف السطر التالي إلى file_contexts
:
/dev/block/platform/soc/10000\.ufshc/by-name/super u:object_r:super_block_device:s0
Fastbootd
برنامج الإقلاع (أو أي أداة فلاش غير تابعة لـ مساحة المستخدم) لا يفهم وأقسام ديناميكية، حتى لا يعمل فلاش لهم. لحل هذه المشكلة، تستخدم الأجهزة تنفيذ بروتوكول Fastboot على مساحة المستخدم، والذي يسمى Fastbootd.
لمزيد من المعلومات حول كيفية تنفيذ Fastbootd، يُرجى الاطّلاع على نقل Fastboot إلى مساحة المستخدم.
إعادة تحميل adb
للمطوّرين الذين يستخدمون إصدارات eng أو userdebug، adb remount
مفيدة للغاية للتكرار السريع. تشكل الأقسام الديناميكية
مشكلة في adb remount
لأنه لم يعد متاحًا
مساحة داخل كل نظام ملفات. لحلّ هذه المشكلة، يمكن للأجهزة تفعيل
تراكبات الصور. ما دام هناك مساحة خالية داخل التقسيم الفائق،
ينشئ adb remount
تلقائيًا محتوى ديناميكي مؤقتًا.
واستخدام تراكبات الصور في عمليات الكتابة. التقسيم المؤقت هو
بالاسم scratch
، لذا لا تستخدم هذا الاسم لمواقع أخرى
الأقسام.
لمزيد من المعلومات حول كيفية تمكين تراكبات الصور، راجع التراكبات قراءة في AOSP.
ترقية أجهزة Android
في حال ترقية جهاز إلى Android 10 إذا كنت تريد تضمين دعم الأقسام الديناميكية في التحديث عبر الهواء، فلن تحتاج إلى تغيير جدول الأقسام المدمج. بعض التكوينات الإضافية هي مطلوبة.
التغييرات على إعدادات الجهاز
لتعديل التقسيم الديناميكي، أضف العلامات التالية في
device.mk
:
PRODUCT_USE_DYNAMIC_PARTITIONS := true PRODUCT_RETROFIT_DYNAMIC_PARTITIONS := true
تغييرات إعدادات لوحة الجهاز
يُطلب منك تعيين متغيرات اللوحة التالية:
- ضبط
BOARD_SUPER_PARTITION_BLOCK_DEVICES
على قائمة الأجهزة المحظورة المستخدمة لتخزين نطاقات الأقسام الديناميكية. هذه قائمة بأسماء العناصر المادية الموجودة الأقسام على الجهاز. - ضبط
BOARD_SUPER_PARTITION_partition_DEVICE_SIZE
على المقاسات من كل جهاز للكتلة فيBOARD_SUPER_PARTITION_BLOCK_DEVICES
، على التوالي. هذه قائمة بأحجام الأقسام الفعلية الحالية على الجهاز. عادة ما يكون هذا "BOARD_partitionIMAGE_PARTITION_SIZE
" في اللوحة الحالية الإعدادات. - إلغاء ضبط
BOARD_partitionIMAGE_PARTITION_SIZE
الحالية للجميع الأقسام فيBOARD_SUPER_PARTITION_BLOCK_DEVICES
. - ضبط
BOARD_SUPER_PARTITION_SIZE
على مجموعBOARD_SUPER_PARTITION_partition_DEVICE_SIZE
- يجب ضبط
BOARD_SUPER_PARTITION_METADATA_DEVICE
على جهاز التخزين الكتلي الذي تخزين البيانات الوصفية للقسم الديناميكي. يجب أن تكون واحدة منBOARD_SUPER_PARTITION_BLOCK_DEVICES
عادةً، يتم تعيين هذا علىsystem
- تعيين
BOARD_SUPER_PARTITION_GROUPS
،BOARD_group_SIZE
وBOARD_group_PARTITION_LIST
، على التوالي. عرض تغييرات إعدادات لوحة الجهاز على الأجهزة الجديدة لمزيد من التفاصيل.
على سبيل المثال، إذا كان الجهاز يحتوي على أقسام النظام والمورّد، وأردت تحويل إلى الأقسام الديناميكية وإضافة قسم منتج جديد أثناء التحديث، اضبط إعدادات اللوحة هذه:
BOARD_SUPER_PARTITION_BLOCK_DEVICES := system vendor BOARD_SUPER_PARTITION_METADATA_DEVICE := system # Rename BOARD_SYSTEMIMAGE_PARTITION_SIZE to BOARD_SUPER_PARTITION_SYSTEM_DEVICE_SIZE. BOARD_SUPER_PARTITION_SYSTEM_DEVICE_SIZE := <size-in-bytes> # Rename BOARD_VENDORIMAGE_PARTITION_SIZE to BOARD_SUPER_PARTITION_VENDOR_DEVICE_SIZE BOARD_SUPER_PARTITION_VENDOR_DEVICE_SIZE := <size-in-bytes> # This is BOARD_SUPER_PARTITION_SYSTEM_DEVICE_SIZE + BOARD_SUPER_PARTITION_VENDOR_DEVICE_SIZE BOARD_SUPER_PARTITION_SIZE := <size-in-bytes> # Configuration for dynamic partitions. For example: BOARD_SUPER_PARTITION_GROUPS := group_foo BOARD_GROUP_FOO_SIZE := <size-in-bytes> BOARD_GROUP_FOO_PARTITION_LIST := system vendor product
التغييرات على SELinux
يجب استخدام السمة للإشارة إلى الأجهزة التي تحظر التقسيم الفائق.
super_block_device_type
على سبيل المثال، إذا كان الجهاز يحتوي بالفعل
قسمان system
وvendor
، وتريد استخدامهما كجزء
الأجهزة التي تخزن نطاقات من الأقسام الديناميكية، ويتم تمييز الارتباطات الرمزية حسب الاسم
system_block_device
:
/dev/block/platform/soc/10000\.ufshc/by-name/system u:object_r:system_block_device:s0 /dev/block/platform/soc/10000\.ufshc/by-name/vendor u:object_r:system_block_device:s0
بعد ذلك، أضِف السطر التالي إلى device.te
:
typeattribute system_block_device super_block_device_type;
لمعرفة الإعدادات الأخرى، يمكنك الاطّلاع على تنفيذ الأقسام الديناميكية على الأجهزة الجديدة
لمزيد من المعلومات حول تحديثات عمليات المراجعة، راجع عبر الهواء لأجهزة A/B التي لا تتضمّن النظام الديناميكي الأقسام:
الصور الأصلية
بالنسبة إلى الأجهزة التي يتم تشغيلها والتي تتيح استخدام الأقسام الديناميكية، تجنَّب استخدام userspace Fastboot إلى صور المصنع، نظرًا لأن التمهيد في مساحة المستخدم أبطأ من طرق الوامضة الأخرى.
لمعالجة هذه المشكلة، تنشئ make dist
الآن إضافة
صورة super.img
التي يمكن تحديثها مباشرةً إلى العنصر
قسم القرص. فهو يجمع تلقائيًا محتويات العناصر المنطقية
الأقسام، مما يعني أنه يحتوي على system.img
،
vendor.img
وما إلى ذلك، بالإضافة إلى super
البيانات الوصفية للأقسام. ويمكن وميض هذه الصورة مباشرةً في
super
بدون أي أدوات أو استخدام إضافية
Fastbootd. بعد الإصدار، يتم وضع super.img
في.
${ANDROID_PRODUCT_OUT}
في أجهزة A/B التي يتم تشغيلها باستخدام أقسام ديناميكية،
يحتوي super.img
على صور في الخانة A. بعد وميض
صورة مميزة مباشرة، فقم بوضع علامة على الفتحة A كقابلة للتشغيل قبل إعادة تشغيل
الخاص بك.
بالنسبة إلى الأجهزة المعدَّلة، ينشئ make dist
مجموعة من
super_*.img
من الصور التي يمكن وميضها مباشرةً
الأقسام المادية المقابلة. على سبيل المثال: make dist
الإصداران super_system.img
وsuper_vendor.img
عندما يكون BOARD_SUPER_PARTITION_BLOCK_DEVICES
هو النظام
البائع. يتم وضع هذه الصور في مجلد OTA في
target_files.zip
ضبط أجهزة التخزين المخصّصة لمصممي خرائط الأجهزة
يستوعب التقسيم الديناميكي عددًا من محددات الأجهزة غير المحددة الأخرى. قد لا تؤدي جميعها إلى إنشاء مثيل كما هو متوقع، لذا يجب تتبع جميع وتحديث خصائص Android لجميع الأقسام المرتبطة به أجهزة التخزين الأساسية الخاصة بهم.
تعمل آلية داخل init
على تتبُّع عمليات التثبيت وبشكل غير متزامن.
يتم تحديث خصائص Android. مقدار الوقت الذي يستغرقه ذلك ليس مضمونًا
أن تكون خلال فترة محددة، لذا يجب توفير وقت كافٍ
للتفاعل مع جميع عوامل التشغيل الـ on property
. الخصائص هي
مكان dev.mnt.blk.<partition>
قيمة <partition>
هي root
،
system
أو data
أو
vendor
، مثلاً. يرتبط كل موقع
اسم جهاز التخزين الأساسي، كما هو موضّح في الأمثلة التالية:
taimen:/ % getprop | grep dev.mnt.blk [dev.mnt.blk.data]: [sda] [dev.mnt.blk.firmware]: [sde] [dev.mnt.blk.metadata]: [sde] [dev.mnt.blk.persist]: [sda] [dev.mnt.blk.root]: [dm-0] [dev.mnt.blk.vendor]: [dm-1] blueline:/ $ getprop | grep dev.mnt.blk [dev.mnt.blk.data]: [dm-4] [dev.mnt.blk.metadata]: [sda] [dev.mnt.blk.mnt.scratch]: [sda] [dev.mnt.blk.mnt.vendor.persist]: [sdf] [dev.mnt.blk.product]: [dm-2] [dev.mnt.blk.root]: [dm-0] [dev.mnt.blk.system_ext]: [dm-3] [dev.mnt.blk.vendor]: [dm-1] [dev.mnt.blk.vendor.firmware_mnt]: [sda]
تتيح اللغة init.rc
استخدام خصائص Android.
وتوسيعها كجزء من القواعد، ويمكن ضبط أجهزة التخزين بواسطة النظام الأساسي
حسب الحاجة باستخدام أوامر مثل هذه:
write /sys/block/${dev.mnt.blk.root}/queue/read_ahead_kb 128 write /sys/block/${dev.mnt.blk.data}/queue/read_ahead_kb 128
بعد بدء معالجة الأمر في المرحلة الثانية init
،
تصبح السمة epoll loop
نشطة، ويبدأ تعديل القيم. ومع ذلك،
لأنّ مشغِّلات المواقع لم تكن نشطة حتى أواخر شهر init
،
ولا يمكن استخدامه في مراحل التمهيد الأولية للتعامل مع root
،
system
أو vendor
. قد تتوقع أن
تكون read_ahead_kb
التلقائية للنواة كافية حتى
يمكن إلغاء init.rc
نص برمجي في early-fs
(عند
البرامج الخفية والمرافق المختلفة). لذلك، تنصح Google بأن
عند استخدام ميزة on property
إلى جانب
السمة التي يتحكّم فيها init.rc
، مثل sys.read_ahead_kb
للتعامل مع توقيت العمليات وتجنب ظروف السباق، كما هو الحال في
الأمثلة:
on property:dev.mnt.blk.root=* && property:sys.read_ahead_kb=* write /sys/block/${dev.mnt.blk.root}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048} on property:dev.mnt.blk.system=* && property:sys.read_ahead_kb=* write /sys/block/${dev.mnt.blk.system}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048} on property:dev.mnt.blk.vendor=* && property:sys.read_ahead_kb=* write /sys/block/${dev.mnt.blk.vendor}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048} on property:dev.mnt.blk.product=* && property:sys.read_ahead_kb=* write /sys/block/${dev.mnt.blk.system_ext}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048} on property:dev.mnt.blk.oem=* && property:sys.read_ahead_kb=* write /sys/block/${dev.mnt.blk.oem}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048} on property:dev.mnt.blk.data=* && property:sys.read_ahead_kb=* write /sys/block/${dev.mnt.blk.data}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048} on early-fs: setprop sys.read_ahead_kb ${ro.read_ahead_kb.boot:-2048} on property:sys.boot_completed=1 setprop sys.read_ahead_kb ${ro.read_ahead_kb.bootcomplete:-128}