يتم تنفيذ التقسيم الديناميكي باستخدام وحدة مخطط الجهاز الخطي dm في Linux kernel. يحتوي القسم super
على بيانات وصفية تسرد الأسماء ونطاقات الحظر لكل قسم ديناميكي داخل super
. أثناء المرحلة الأولى init
، يتم تحليل هذه البيانات التعريفية والتحقق من صحتها، ويتم إنشاء أجهزة الحظر الافتراضية لتمثيل كل قسم ديناميكي.
عند تطبيق OTA، يتم إنشاء الأقسام الديناميكية أو تغيير حجمها أو حذفها تلقائيًا حسب الحاجة. بالنسبة لأجهزة 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 للقراءة فقط والتي لا يستخدمها أداة تحميل التشغيل ديناميكية ويجب إزالتها من جدول أقسام GUID (GPT). ليس من الضروري أن تكون الأقسام الخاصة بالمورد ديناميكية ويمكن وضعها في GPT.
لتقدير حجم super
، قم بإضافة أحجام الأقسام التي سيتم حذفها من GPT. بالنسبة لأجهزة A/B، يجب أن يشمل ذلك حجم كلا الفتحتين. يوضح الشكل 1 مثالاً لجدول الأقسام قبل التحويل إلى الأقسام الديناميكية وبعده.

الأقسام الديناميكية المدعومة هي:
- نظام
- بائع
- منتج
- تحويلة النظام
- أوديإم
بالنسبة للأجهزة التي تعمل بنظام التشغيل Android 10، يجب أن يكون خيار سطر أوامر kernel androidboot.super_partition
فارغًا بحيث يكون الأمر sysprop ro.boot.super_partition
فارغًا.
محاذاة التقسيم
قد تعمل وحدة مخطط الجهاز بكفاءة أقل إذا لم تتم محاذاة القسم super
بشكل صحيح. يجب محاذاة القسم super
مع الحد الأدنى لحجم طلب الإدخال/الإخراج كما هو محدد بواسطة طبقة الكتلة. افتراضيًا، يفترض نظام البناء (عبر lpmake
، الذي ينشئ صورة القسم super
)، أن محاذاة 1 MiB كافية لكل قسم ديناميكي. ومع ذلك، يجب على البائعين التأكد من محاذاة القسم 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 ميجابايت، ولكن يمكنك اختيار حمل أكبر حسب حاجة الجهاز.
حجم الأقسام الديناميكية
قبل الأقسام الديناميكية، تم تخصيص أحجام الأقسام بشكل زائد للتأكد من أن لديها مساحة كافية للتحديثات المستقبلية. تم أخذ الحجم الفعلي كما هو وكانت معظم الأقسام المخصصة للقراءة فقط تحتوي على قدر من المساحة الحرة في نظام الملفات الخاص بها. في الأقسام الديناميكية، تكون هذه المساحة الحرة غير قابلة للاستخدام ويمكن استخدامها لزيادة حجم الأقسام أثناء OTA. من المهم التأكد من أن الأقسام لا تهدر المساحة وأن يتم تخصيصها بأقل حجم ممكن.
بالنسبة لصور ext4 للقراءة فقط، يقوم نظام الإنشاء تلقائيًا بتخصيص الحد الأدنى للحجم إذا لم يتم تحديد حجم قسم مضمن. يناسب نظام البناء الصورة بحيث يكون لنظام الملفات أقل مساحة غير مستخدمة قدر الإمكان. وهذا يضمن أن الجهاز لا يهدر المساحة التي يمكن استخدامها لـ OTAs.
بالإضافة إلى ذلك، يمكن ضغط صور ext4 بشكل أكبر عن طريق تمكين إلغاء البيانات المكررة على مستوى الكتلة. لتمكين هذا، استخدم التكوين التالي:
BOARD_EXT4_SHARE_DUP_BLOCKS := true
إذا كان التخصيص التلقائي للحد الأدنى لحجم القسم غير مرغوب فيه، فهناك طريقتان للتحكم في حجم القسم. يمكنك تحديد الحد الأدنى من المساحة الحرة باستخدام BOARD_ partition IMAGE_PARTITION_RESERVED_SIZE
، أو يمكنك تحديد BOARD_ partition IMAGE_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
في قرص ذاكرة الوصول العشوائي.
يؤدي تعيين BOARD_BUILD_SYSTEM_ROOT_IMAGE
إلى true
إلى حدوث خطأ في البناء عندما يكون PRODUCT_USE_DYNAMIC_PARTITIONS
true
أيضًا.
عند تعيين BOARD_USES_RECOVERY_AS_BOOT
على true، يتم إنشاء صورة الاسترداد كـ boot.img، والتي تحتوي على قرص الاسترداد الخاص بالاسترداد. في السابق، كان برنامج تحميل التشغيل يستخدم معلمة سطر أوامر kernel skip_initramfs
لتحديد الوضع الذي سيتم التمهيد فيه. بالنسبة للأجهزة التي تعمل بنظام التشغيل Android 10، يجب ألا يقوم برنامج تحميل التشغيل بتمرير skip_initramfs
إلى سطر أوامر kernel. بدلاً من ذلك، يجب أن يمرر برنامج bootloader androidboot.force_normal_boot=1
لتخطي عملية الاسترداد وتشغيل Android العادي. يجب على الأجهزة التي تعمل بنظام التشغيل Android 12 أو الإصدارات الأحدث استخدام bootconfig لتمرير androidboot.force_normal_boot=1
.
تغييرات تكوين AVB
عند استخدام Android Verified Boot 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 — "إصلاح AvbSlotVerifyData->cmdline قد يكون فارغًا"
في حالة استخدام الأقسام المتسلسلة، قم بتضمين تصحيح إضافي:
- 49936b4c0109411fdd38bd4ba3a32a01c40439a9 — "libavb: دعم vbmeta blobs في بداية التقسيم."
تغييرات سطر أوامر Kernel
يجب إضافة معلمة جديدة، androidboot.boot_devices
، إلى سطر أوامر kernel. يتم استخدام هذا بواسطة init
لتمكين الروابط /dev/block/by-name
. يجب أن يكون مكون مسار الجهاز للارتباط الرمزي الأساسي الذي تم إنشاؤه بواسطة ueventd
، أي /dev/block/platform/ device-path /by-name/ partition-name
. يجب على الأجهزة التي يتم تشغيلها بنظام التشغيل Android 12 أو الإصدارات الأحدث استخدام bootconfig لتمرير 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 الذي سيكون جزءًا من قرص الذاكرة.
يجب إجراء التغييرات على ملف 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 إلى مساحة المستخدم .
إعادة تحميل بنك التنمية الآسيوي
بالنسبة للمطورين الذين يستخدمون إصدارات eng أو userdebug، فإن adb remount
مفيدة للغاية للتكرار السريع. تشكل الأقسام الديناميكية مشكلة عند adb remount
لأنه لم تعد هناك مساحة خالية داخل كل نظام ملفات. ولمعالجة هذه المشكلة، يمكن للأجهزة تمكين التراكبات. طالما أن هناك مساحة خالية داخل القسم الفائق، adb remount
يقوم تلقائيًا بإنشاء قسم ديناميكي مؤقت ويستخدم التراكبات للكتابة. يُسمى القسم المؤقت scratch
" لذا لا تستخدم هذا الاسم للأقسام الأخرى.
لمزيد من المعلومات حول كيفية تمكين التراكبات، راجع ملف README للتراكبات في AOSP.
ترقية أجهزة أندرويد
إذا قمت بترقية جهاز إلى Android 10، وترغب في تضمين دعم الأقسام الديناميكية في OTA، فلن تحتاج إلى تغيير جدول الأقسام المدمج. مطلوب بعض التكوين الإضافي.
تغييرات تكوين الجهاز
لتعديل التقسيم الديناميكي، قم بإضافة العلامات التالية في 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_ partition IMAGE_PARTITION_SIZE
في تكوينات اللوحة الحالية. - قم بإلغاء تعيين
BOARD_ partition IMAGE_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;
للحصول على تكوينات أخرى، راجع تنفيذ الأقسام الديناميكية على الأجهزة الجديدة .
لمزيد من المعلومات حول التحديثات التحديثية، راجع OTA لأجهزة A/B بدون أقسام ديناميكية .
صور المصنع
بالنسبة لجهاز يتم تشغيله بدعم الأقسام الديناميكية، تجنب استخدام 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}