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

تحديثات النظام الديناميكية

تتيح لك ميزة "تحديثات النظام الديناميكية" (DSU) إنشاء صورة نظام Android يمكن للمستخدمين تنزيلها من الإنترنت وتجربتها بدون المخاطرة بإتلاف صورة النظام الحالية. يوضّح هذا المستند كيفية توفير الدعم لميزة "تحديثات النظام الديناميكية".

متطلبات النواة

لمعرفة متطلبات النواة، يُرجى الاطّلاع على مقالة تنفيذ الأقسام الديناميكية.

بالإضافة إلى ذلك، تعتمد ميزة "تحديثات النظام الديناميكية" على ميزة النواة device-mapper-verity (dm-verity) للتحقّق من صورة نظام Android. لذا، يجب تفعيل إعدادات النواة التالية:

CONFIG_DM_VERITY=y
CONFIG_DM_VERITY_FEC=y

متطلبات الأقسام

اعتبارًا من Android 11، تتطلّب ميزة "تحديثات النظام الديناميكية" أن يستخدم قسم /data نظام الملفات F2FS أو ext4. يوفّر نظام الملفات F2FS أداءً أفضل وننصح باستخدامه، ولكن من المفترض ألا يكون الفرق كبيرًا.

في ما يلي بعض الأمثلة على المدة التي يستغرقها تحديث النظام الديناميكي على جهاز Pixel:

باستخدام نظام الملفات F2FS:
- 109 ثوانٍ، 8 غيغابايت للمستخدم، 867 ميغابايت للنظام، نوع نظام الملفات: F2FS: encryption=aes-256-xts:aes-256-cts
- 104 ثوانٍ، 8 غيغابايت للمستخدم، 867 ميغابايت للنظام، نوع نظام الملفات: F2FS: encryption=ice
باستخدام نظام الملفات ext4:
- 135 ثانية، 8 غيغابايت للمستخدم، 867 ميغابايت للنظام، نوع نظام الملفات: ext4: encryption=aes-256-xts:aes-256-cts

إذا استغرقت العملية وقتًا أطول بكثير على منصتك، قد يكون عليك التحقّق مما إذا كانت علامة التحميل تحتوي على أي علامة تؤدي إلى كتابة "المزامنة"، أو يمكنك تحديد علامة "غير متزامن" بشكلٍ صريح للحصول على أداء أفضل.

مطلوب قسم metadata (16 ميغابايت أو أكبر) لتخزين البيانات ذات الصلة بالصور المثبَّتة. يجب تحميله أثناء عملية التحميل في المرحلة الأولى.

يجب أن يستخدم قسم userdata نظام الملفات F2FS أو ext4. عند استخدام نظام الملفات F2FS، يجب تضمين جميع التصحيحات ذات الصلة بنظام الملفات F2FS المتوفّرة في النواة الشائعة لنظام Android.

تم تطوير ميزة "تحديثات النظام الديناميكية" واختبارها باستخدام kernel/common 4.9. ننصح باستخدام النواة 4.9 والإصدارات الأحدث لهذه الميزة.

سلوك طبقة تجريد الأجهزة الخاصة بالبائع

طبقة تجريد الأجهزة Weaver HAL

توفر طبقة تجريد الأجهزة Weaver HAL عددًا ثابتًا من الخانات لتخزين مفاتيح المستخدم. تستهلك ميزة "تحديثات النظام الديناميكية" خانتَي مفاتيح إضافيتَين. إذا كان لدى الشركة المصنّعة للمعدات الأصلية طبقة تجريد الأجهزة Weaver HAL، يجب أن تحتوي على عدد كافٍ من الخانات لصورة نظام عامة (GSI) وصورة مضيف.

طبقة تجريد الأجهزة Gatekeeper HAL

يجب أن تتيح طبقة تجريد الأجهزة Gatekeeper HAL قيم USER_ID الكبيرة، لأنّ صورة النظام العامة تعوّض معرّفات المستخدمين (UID) في طبقة تجريد الأجهزة بمقدار +1000000.

التشغيل المتحقّق منه

إذا كنت تريد السماح بتشغيل صور النظام العامة للمطوّرين في الحالة LOCKED بدون إيقاف التشغيل المتحقّق منه، عليك تضمين مفاتيح صور النظام العامة للمطوّرين عن طريق إضافة السطر التالي إلى الملف device/<device_name>/device.mk:

$(call inherit-product, $(SRC_TARGET_DIR)/product/developer_gsi_keys.mk)

الحماية من العودة إلى الحالة السابقة

عند استخدام ميزة "تحديثات النظام الديناميكية"، يجب أن تكون صورة نظام Android التي تم تنزيلها أحدث من صورة النظام الحالية على الجهاز. يتم ذلك عن طريق مقارنة مستويات رموز تصحيح الأمان في واصف سمة التشغيل المتحقّق منه من Android (AVB) لكلتا صورتَي النظام: Prop: com.android.build.system.security_patch -> '2019-04-05'.

بالنسبة إلى الأجهزة التي لا تستخدم بث الصوت والفيديو (AVB)، ضَع مستوى رمز تصحيح الأمان لصورة النظام الحالية في سطر أوامر النواة أو bootconfig باستخدام برنامج إقلاع: androidboot.system.security_patch=2019-04-05.

متطلبات الأجهزة

عند تشغيل مثيل من ميزة "تحديثات النظام الديناميكية"، يتم تخصيص ملفَين مؤقتَين:

قسم منطقي لتخزين GSI.img (من 1 إلى 1.5 غيغابايت)
قسم /data فارغ بحجم 8 غيغابايت كبيئة تجريبية لتشغيل صورة النظام العامة

ننصحك بحجز مساحة خالية تبلغ 10 غيغابايت على الأقل قبل تشغيل مثيل من ميزة "تحديثات النظام الديناميكية". تتيح ميزة "تحديثات النظام الديناميكية" أيضًا التخصيص من بطاقة SD. عند توفّر بطاقة SD، تكون لها الأولوية القصوى في عملية التخصيص. إنّ توفّر بطاقة SD أمر بالغ الأهمية للأجهزة منخفضة الطاقة التي قد لا تتضمّن مساحة تخزين داخلية كافية. عند توفّر بطاقة SD، تأكَّد من عدم استخدامها كوحدة تخزين داخلية. لا تتيح ميزة "تحديثات النظام الديناميكية" استخدام بطاقات SD كوحدة تخزين داخلية.

الواجهات الأمامية المتاحة

يمكنك تشغيل ميزة "تحديثات النظام الديناميكية" باستخدام adb أو تطبيق من الشركة المصنّعة للمعدات الأصلية أو أداة تحميل "تحديثات النظام الديناميكية" بنقرة واحدة (في Android 11 أو الإصدارات الأحدث).

تشغيل ميزة "تحديثات النظام الديناميكية" باستخدام adb

لتشغيل ميزة "تحديثات النظام الديناميكية" باستخدام adb، أدخِل الأوامر التالية:

$ simg2img out/target/product/.../system.img system.raw
$ gzip -c system.raw > system.raw.gz
$ adb push system.raw.gz /storage/emulated/0/Download
$ adb shell am start-activity \
-n com.android.dynsystem/com.android.dynsystem.VerificationActivity  \
-a android.os.image.action.START_INSTALL    \
-d file:///storage/emulated/0/Download/system.raw.gz  \
--el KEY_SYSTEM_SIZE $(du -b system.raw|cut -f1)  \
--el KEY_USERDATA_SIZE 8589934592

تشغيل ميزة "تحديثات النظام الديناميكية" باستخدام تطبيق

نقطة الدخول الرئيسية إلى ميزة "تحديثات النظام الديناميكية" هي واجهة برمجة التطبيقات android.os.image.DynamicSystemClient.java:

public class DynamicSystemClient {


...
...

     /**
     * Start installing DynamicSystem from URL with default userdata size.
     *
     * @param systemUrl A network URL or a file URL to system image.
     * @param systemSize size of system image.
     */
    public void start(String systemUrl, long systemSize) {
        start(systemUrl, systemSize, DEFAULT_USERDATA_SIZE);
    }

يجب تجميع هذا التطبيق أو تثبيته مسبقًا على الجهاز. بما أنّ DynamicSystemClient هي واجهة برمجة تطبيقات للنظام، لا يمكنك إنشاء التطبيق باستخدام واجهة برمجة التطبيقات العادية لحزمة تطوير البرامج (SDK) ولا يمكنك نشره على Google Play. الغرض من هذا التطبيق هو:

جلب قائمة صور وعنوان URL المقابل باستخدام مخطط محدّد من قِبل البائع
مطابقة الصور في القائمة مع الجهاز وعرض الصور المتوافقة ليختارها المستخدم

استدعاء DynamicSystemClient.start على النحو التالي:

DynamicSystemClient aot = new DynamicSystemClient(...)
   aot.start(
        ...URL of the selected image...,
        ...uncompressed size of the selected image...);

يشير عنوان URL إلى ملف صورة نظام غير مضغوط ومضغوط باستخدام gzip، ويمكنك إنشاؤه باستخدام الأوامر التالية:

$ simg2img ${OUT}/system.img ${OUT}/system.raw
$ gzip ${OUT}/system.raw
$ ls ${OUT}/system.raw.gz

يجب أن يتبع اسم الملف هذا التنسيق:

<android version>.<lunch name>.<user defined title>.raw.gz

أمثلة:

o.aosp_taimen-userdebug.2018dev.raw.gz
p.aosp_taimen-userdebug.2018dev.raw.gz

أداة تحميل "تحديثات النظام الديناميكية" بنقرة واحدة

يقدّم Android 11 أداة تحميل "تحديثات النظام الديناميكية" بنقرة واحدة، وهي واجهة أمامية في إعدادات المطوّرين.

الشكل 1: تشغيل أداة تحميل "تحديثات النظام الديناميكية"

عندما ينقر المطوّر على الزر DSU Loader (أداة تحميل "تحديثات النظام الديناميكية")، يتم جلب واصف JSON مُعدّ مسبقًا لميزة "تحديثات النظام الديناميكية" من الويب وعرض جميع الصور السارية في القائمة العائمة. اختَر صورة لبدء عملية تثبيت "تحديثات النظام الديناميكية"، ويظهر مستوى التقدّم على شريط الإشعارات.

مستوى تقدّم عملية تثبيت صورة DSU

الشكل 2: مستوى تقدّم عملية تثبيت صورة "تحديثات النظام الديناميكية"

تلقائيًا، تحمِّل أداة تحميل "تحديثات النظام الديناميكية" واصف JSON يحتوي على صور النظام العامة. توضّح الأقسام التالية كيفية إنشاء حِزم "تحديثات النظام الديناميكية" الموقَّعة من الشركة المصنّعة للمعدات الأصلية وتحميلها من أداة تحميل "تحديثات النظام الديناميكية".

علامة الميزة

تندرج ميزة "تحديثات النظام الديناميكية" ضمن علامة الميزة settings_dynamic_android. قبل استخدام ميزة "تحديثات النظام الديناميكية"، تأكَّد من تفعيل علامة الميزة المقابلة.

تفعيل علامة الميزة

الشكل 3: تفعيل علامة الميزة

قد لا تكون واجهة مستخدم علامة الميزة متاحة على جهاز يعمل بإصدار للمستخدمين. في هذه الحالة، استخدِم أمر adb بدلاً من ذلك:

$ adb shell setprop persist.sys.fflag.override.settings_dynamic_system 1

صور نظام المضيف الخاصة بالبائع على Google Compute Engine (اختياري)

أحد مواقع التخزين المحتملة لصور النظام هو مجموعة Google Compute Engine (GCE). يستخدم مشرف الإصدار وحدة تحكّم التخزين في Google Cloud Platform لـ إضافة صورة النظام التي تم إصدارها أو حذفها أو تغييرها.

يجب أن تكون الصور متاحة للجميع، كما هو موضّح هنا:

إتاحة الوصول للجميع في GCE

الشكل 4: إتاحة الوصول للجميع في Google Compute Engine

يتوفّر الإجراء لجعل عنصر ما متاحًا للجميع في مستندات Google Cloud.

تحديثات النظام الديناميكية المتعددة الأقسام في ملف ZIP

اعتبارًا من Android 11، يمكن أن تحتوي ميزة "تحديثات النظام الديناميكية" على أكثر من قسم واحد. على سبيل المثال، يمكن أن تحتوي على product.img بالإضافة إلى system.img. عند تشغيل الجهاز، ترصد المرحلة الأولى init أقسام "تحديثات النظام الديناميكية" المثبَّتة وتستبدل القسم على الجهاز فقط مؤقتًا عند تفعيل "تحديثات النظام الديناميكية" المثبَّتة. قد تحتوي حزمة "تحديثات النظام الديناميكية" على قسم ليس له قسم مطابق على الجهاز.

عملية DSU مع أقسام متعددة

الشكل 5: عملية "تحديثات النظام الديناميكية" مع أقسام متعددة

تحديثات النظام الديناميكية الموقَّعة من الشركة المصنّعة للمعدات الأصلية

للتأكّد من أنّ جميع الصور التي يتم تشغيلها على الجهاز معتمَدة من الشركة المصنّعة للمعدات الأصلية، يجب توقيع جميع الصور ضِمن حزمة "تحديثات النظام الديناميكية". على سبيل المثال، لنفترض أنّ هناك حزمة "تحديثات النظام الديناميكية" تحتوي على صورتَي قسمَين على النحو التالي:

dsu.zip {
    - system.img
    - product.img
}

يجب توقيع كل من system.img وproduct.img باستخدام مفتاح الشركة المصنّعة للمعدات الأصلية قبل وضعهما في ملف ZIP. إنّ الممارسة الشائعة هي استخدام خوارزمية غير متماثلة، مثل RSA، حيث يُستخدم المفتاح السري لتوقيع الحزمة ويُستخدم المفتاح العام للتحقّق منها. يجب أن يتضمّن ملف ramdisk في المرحلة الأولى المفتاح العام للإقران، مثلاً /avb/*.avbpubkey. إذا كان الجهاز قد اعتمد التشغيل المتحقّق منه من Android، سيكون إجراء التوقيع الحالي كافيًا. توضّح الأقسام التالية عملية التوقيع وتبرز موضع المفتاح العام لـ AVB الذي يُستخدم للتحقّق من الصور في حزمة DSU.

واصف JSON لميزة "تحديثات النظام الديناميكية"

يصف واصف JSON لميزة "تحديثات النظام الديناميكية" حِزم "تحديثات النظام الديناميكية". ويتيح استخدام عنصرَين أساسيَين. أولاً، يتضمّن العنصر الأساسي include واصفات JSON إضافية أو يعيد توجيه أداة تحميل "تحديثات النظام الديناميكية" إلى موقع جديد. على سبيل المثال:

{
    "include": ["https://.../gsi-release/gsi-src.json"]
}

ثانيًا، يُستخدم العنصر الأساسي image لوصف حِزم "تحديثات النظام الديناميكية" التي تم إصدارها. ضِمن العنصر الأساسي `image`، هناك عدة سمات:

السمتان name وdetails هما سلسلتان يتم عرضهما في مربّع الحوار ليختار المستخدم إحداهما.
تُستخدم السمات cpu_api وvndk وos_version لإجراء عمليات التحقّق من التوافق، والتي يتم وصفها في القسم التالي.
تصف السمة الاختيارية pubkey المفتاح العام الذي يقترن بالمفتاح السري الذي يُستخدم لتوقيع حزمة "تحديثات النظام الديناميكية". عند تحديد هذه السمة، يمكن لخدمة "تحديثات النظام الديناميكية" التحقّق مما إذا كان الجهاز يحتوي على المفتاح المستخدَم للتحقّق من حزمة "تحديثات النظام الديناميكية". يؤدي ذلك إلى تجنُّب تثبيت حزمة "تحديثات النظام الديناميكية" غير معروفة، مثلاً تثبيت حزمة "تحديثات النظام الديناميكية" موقَّعة من الشركة المصنّعة للمعدات الأصلية (أ) على جهاز من صنع الشركة المصنّعة للمعدات الأصلية (ب).
تشير السمة الاختيارية tos إلى ملف نصي يصف بنود الخدمة لحزمة "تحديثات النظام الديناميكية" المقابلة. عندما يختار المطوّر حزمة "تحديثات النظام الديناميكية" تم تحديد سمة بنود الخدمة لها، يفتح مربّع الحوار الموضّح في الشكل 6، ويطلب من المطوّر قبول بنود الخدمة قبل تثبيت حزمة "تحديثات النظام الديناميكية".

الشكل 6: مربّع حوار بنود الخدمة

للعلم، إليك واصف JSON لميزة "تحديثات النظام الديناميكية" لصورة النظام العامة:

{
   "images":[
      {
         "name":"GSI+GMS x86",
         "os_version":"10",
         "cpu_abi": "x86",
         "details":"exp-QP1A.190711.020.C4-5928301",
         "vndk":[
            27,
            28,
            29
         ],
         "pubkey":"",
         "tos": "https://dl.google.com/developers/android/gsi/gsi-tos.txt",
         "uri":"https://.../gsi/gsi_gms_x86-exp-QP1A.190711.020.C4-5928301.zip"
      },
      {
         "name":"GSI+GMS ARM64",
         "os_version":"10",
         "cpu_abi": "arm64-v8a",
         "details":"exp-QP1A.190711.020.C4-5928301",
         "vndk":[
            27,
            28,
            29
         ],
         "pubkey":"",
         "tos": "https://dl.google.com/developers/android/gsi/gsi-tos.txt",
         "uri":"https://.../gsi/gsi_gms_arm64-exp-QP1A.190711.020.C4-5928301.zip"
      },
      {
         "name":"GSI ARM64",
         "os_version":"10",
         "cpu_abi": "arm64-v8a",
         "details":"exp-QP1A.190711.020.C4-5928301",
         "vndk":[
            27,
            28,
            29
         ],
         "pubkey":"",
         "uri":"https://.../gsi/aosp_arm64-exp-QP1A.190711.020.C4-5928301.zip"
      },
      {
         "name":"GSI x86_64",
         "os_version":"10",
         "cpu_abi": "x86_64",
         "details":"exp-QP1A.190711.020.C4-5928301",
         "vndk":[
            27,
            28,
            29
         ],
         "pubkey":"",
         "uri":"https://.../gsi/aosp_x86_64-exp-QP1A.190711.020.C4-5928301.zip"
      }
   ]
}

إدارة التوافق

تُستخدم عدة سمات لتحديد التوافق بين حزمة "تحديثات النظام الديناميكية" والجهاز المحلي:

cpu_api هي سلسلة تصف بنية الجهاز. هذه السمة إلزامية وتتم مقارنتها بسمة النظام ro.product.cpu.abi. يجب أن تتطابق قيمهما تمامًا.
os_version هو عدد صحيح اختياري يحدّد إصدار Android. على سبيل المثال، بالنسبة إلى Android 10، تكون قيمة os_version هي 10 وبالنسبة إلى Android 11، تكون قيمة os_version هي 11. عند تحديد هذه السمة، يجب أن تكون أكبر من أو مساوية لسمة النظام ro.system.build.version.release. يُستخدم هذا التحقّق لمنع تشغيل صورة نظام عامة لنظام Android 10 على جهاز بائع يعمل بنظام Android 11، وهو أمر غير متاح حاليًا. يُسمح بتشغيل صورة نظام عامة لنظام Android 11 على جهاز يعمل بنظام Android 10.
vndk هي مصفوفة اختيارية تحدّد جميع حِزم VNDK المضمّنة في حزمة "تحديثات النظام الديناميكية". عند تحديد هذه السمة، تتحقّق أداة تحميل "تحديثات النظام الديناميكية" مما إذا كان الرقم المستخرَج من سمة النظام ro.vndk.version مضمّنًا.

إبطال مفاتيح "تحديثات النظام الديناميكية" لأغراض الأمان

في الحالات النادرة جدًا التي يتم فيها اختراق زوج مفاتيح RSA المستخدَم لتوقيع صور "تحديثات النظام الديناميكية"، يجب تعديل ملف ramdisk في أقرب وقت ممكن لإزالة المفتاح الذي تم اختراقه. بالإضافة إلى تعديل قسم التشغيل، يمكنك حظر المفاتيح التي تم اختراقها باستخدام قائمة إبطال مفاتيح "تحديثات النظام الديناميكية" (قائمة المفاتيح المحظورة) من عنوان URL لبروتوكول HTTPS.

تحتوي قائمة إبطال مفاتيح تحديثات النظام الديناميكية على قائمة بالمفاتيح العامة لـ AVB التي تم إبطالها. أثناء تثبيت "تحديثات النظام الديناميكية"، يتم التحقّق من صحة المفاتيح العامة ضِمن صور "تحديثات النظام الديناميكية" باستخدام قائمة الإبطال. إذا تبيّن أنّ الصور تحتوي على مفتاح عام تم إبطاله، تتوقف عملية تثبيت "تحديثات النظام الديناميكية".

يجب أن يكون عنوان URL لقائمة إبطال المفاتيح عنوان URL لبروتوكول HTTPS لضمان قوة الأمان، ويتم تحديده في سلسلة موارد:

frameworks/base/packages/DynamicSystemInstallationService/res/values/strings.xml@key_revocation_list_url

قيمة السلسلة هي https://dl.google.com/developers/android/gsi/gsi-keyblacklist.json، وهي قائمة إبطال لمفاتيح صور النظام العامة التي أصدرتها Google. يمكن إضافة طبقة فوق سلسلة الموارد هذه وتخصيصها، حتى تتمكّن الشركات المصنّعة للمعدات الأصلية التي تعتمد ميزة "تحديثات النظام الديناميكية" من توفير قائمة المفاتيح المحظورة الخاصة بها والحفاظ عليها. يوفّر ذلك طريقة للشركة المصنّعة للمعدات الأصلية لحظر مفاتيح عامة معيّنة بدون تعديل صورة ملف ramdisk للجهاز.

تنسيق قائمة الإبطال هو:

{
   "entries":[
      {
         "public_key":"bf14e439d1acf231095c4109f94f00fc473148e6",
         "status":"REVOKED",
         "reason":"Key revocation test key"
      },
      {
         "public_key":"d199b2f29f3dc224cca778a7544ea89470cbef46",
         "status":"REVOKED",
         "reason":"Key revocation test key"
      }
   ]
}

public_key هو ملخّص SHA-1 للمفتاح الذي تم إبطاله، بالتنسيق الموضّح في قسم إنشاء المفتاح العام للتشغيل المتحقّق منه من Android.
status يشير إلى حالة إبطال المفتاح. القيمة المسموح بها حاليًا هي REVOKED.
reason هي سلسلة اختيارية تصف سبب الإبطال.

إجراءات "تحديثات النظام الديناميكية"

يوضّح هذا القسم كيفية تنفيذ عدة إجراءات لإعداد ميزة "تحديثات النظام الديناميكية".

إنشاء زوج مفاتيح جديد

استخدِم أمر openssl لإنشاء زوج مفاتيح RSA خاص/عام بتنسيق .pem (على سبيل المثال، بحجم 2048 بت):

$ openssl genrsa -out oem_cert_pri.pem 2048
$ openssl rsa -in oem_cert_pri.pem -pubout -out oem_cert_pub.pem

قد لا يكون المفتاح الخاص متاحًا ويتم الاحتفاظ به فقط في وحدة أمان الأجهزة (HSM). في هذه الحالة، قد تتوفّر شهادة مفتاح عام x509 بعد إنشاء المفتاح. راجِع قسم إضافة المفتاح العام للإقران إلى ملف ramdisk للحصول على تعليمات حول إنشاء المفتاح العام للتشغيل المتحقّق منه من Android من شهادة x509.

لتحويل شهادة x509 إلى تنسيق PEM:

$ openssl x509 -pubkey -noout -in oem_cert_pub.x509.pem > oem_cert_pub.pem

يمكنك تخطّي هذه الخطوة إذا كانت الشهادة ملف PEM.

إضافة المفتاح العام للإقران إلى ملف ramdisk

يجب وضع oem_cert.avbpubkey ضِمن /avb/*.avbpubkey للتحقّق من حزمة "تحديثات النظام الديناميكية" الموقَّعة. أولاً، حوِّل المفتاح العام بتنسيق PEM إلى تنسيق المفتاح العام للتشغيل المتحقّق منه من Android:

$ avbtool extract_public_key --key oem_cert_pub.pem --output oem_cert.avbpubkey

بعد ذلك، ضَمِّن المفتاح العام في ملف ramdisk في المرحلة الأولى باتّباع الخطوات التالية.

أضِف وحدة مُنشأة مسبقًا لنسخ avbpubkey. على سبيل المثال، أضِف device/<company>/<board>/oem_cert.avbpubkey و device/<company>/<board>/avb/Android.mk بمحتوى على النحو التالي:

include $(CLEAR_VARS)

LOCAL_MODULE := oem_cert.avbpubkey
LOCAL_MODULE_CLASS := ETC
LOCAL_SRC_FILES := $(LOCAL_MODULE)
ifeq ($(BOARD_USES_RECOVERY_AS_BOOT),true)
LOCAL_MODULE_PATH := $(TARGET_RECOVERY_ROOT_OUT)/first_stage_ramdisk/avb
else
LOCAL_MODULE_PATH := $(TARGET_RAMDISK_OUT)/avb
endif

include $(BUILD_PREBUILT)

اجعل هدف droidcore يعتمد على oem_cert.avbpubkey الذي تمّت إضافته:
```
droidcore: oem_cert.avbpubkey
```

إنشاء سمة المفتاح العام للتشغيل المتحقّق منه من Android في واصف JSON

oem_cert.avbpubkey بتنسيق المفتاح العام الثنائي للتشغيل المتحقّق منه من Android. استخدِم SHA-1 لجعله قابلاً للقراءة قبل وضعه في واصف JSON:

$ sha1sum oem_cert.avbpubkey | cut -f1 -d ' '
3e62f2be9d9d813ef5........866ac72a51fd20

سيكون هذا محتوى سمة pubkey لواصف JSON.

   "images":[
      {
         ...
         "pubkey":"3e62f2be9d9d813ef5........866ac72a51fd20",
         ...
      },

توقيع حزمة "تحديثات النظام الديناميكية"

استخدِم إحدى الطرق التالية لتوقيع حزمة "تحديثات النظام الديناميكية":

الطريقة 1: أعِد استخدام العنصر الذي تم إنشاؤه من خلال عملية التوقيع الأصلية للتشغيل المتحقّق منه من Android لإنشاء حزمة "تحديثات النظام الديناميكية". هناك نهج بديل يتمثل في استخراج الصور الموقَّعة مسبقًا من حزمة الإصدار واستخدام الصور المستخرَجة لإنشاء ملف ZIP مباشرةً.

الطريقة 2: استخدِم الأوامر التالية لتوقيع أقسام "تحديثات النظام الديناميكية" إذا كان المفتاح الخاص متاحًا. يتم توقيع كل img ضِمن حزمة "تحديثات النظام الديناميكية" (ملف ZIP) بشكلٍ منفصل:

$ key_len=$(openssl rsa -in oem_cert_pri.pem -text | grep Private-Key | sed -e 's/.*(\(.*\) bit.*/\1/')
$ for partition in system product; do
    avbtool add_hashtree_footer \
        --image ${OUT}/${partition}.img \
        --partition_name ${partition} \
        --algorithm SHA256_RSA${key_len} \
        --key oem_cert_pri.pem
done

لمزيد من المعلومات حول إضافة add_hashtree_footer باستخدام avbtool، يُرجى الاطّلاع على مقالة استخدام avbtool.

التحقّق من حزمة "تحديثات النظام الديناميكية" محليًا

ننصحك بالتحقّق من صحة جميع الصور المحلية باستخدام المفتاح العام للإقران باستخدام الأوامر التالية:


for partition in system product; do
    avbtool verify_image --image ${OUT}/${partition}.img  --key oem_cert_pub.pem
done

يبدو الناتج المتوقّع على النحو التالي:

Verifying image dsu/system.img using key at oem_cert_pub.pem
vbmeta: Successfully verified footer and SHA256_RSA2048 vbmeta struct in dsu/system.img
: Successfully verified sha1 hashtree of dsu/system.img for image of 898494464 bytes

Verifying image dsu/product.img using key at oem_cert_pub.pem
vbmeta: Successfully verified footer and SHA256_RSA2048 vbmeta struct in dsu/product.img
: Successfully verified sha1 hashtree of dsu/product.img for image of 905830400 bytes

إنشاء حزمة "تحديثات النظام الديناميكية"

ينشئ المثال التالي حزمة "تحديثات النظام الديناميكية" تحتوي على system.img وproduct.img:

dsu.zip {
    - system.img
    - product.img
}

بعد توقيع كلتا الصورتَين، استخدِم الأمر التالي لإنشاء ملف ZIP:

$ mkdir -p dsu
$ cp ${OUT}/system.img dsu
$ cp ${OUT}/product.img dsu
$ cd dsu && zip ../dsu.zip *.img && cd -

تخصيص ميزة "تحديثات النظام الديناميكية" بنقرة واحدة

تلقائيًا، تشير أداة تحميل "تحديثات النظام الديناميكية" إلى بيانات وصفية لصور النظام العامة هي https://...google.com/.../gsi-src.json.

يمكن للمصنّعين الأصليين للأجهزة الكتابة فوق القائمة عن طريق تحديد السمة persist.sys.fflag.override.settings_dynamic_system.list التي تشير إلى واصف JSON الخاص بها. على سبيل المثال، قد تقدّم الشركة المصنّعة للمعدات الأصلية بيانات وصفية بتنسيق JSON تتضمّن صورة النظام العامة بالإضافة إلى الصور الخاصة بالشركة المصنّعة للمعدات الأصلية على النحو التالي:

{
    "include": ["https://dl.google.com/.../gsi-src.JSON"]
    "images":[
      {
         "name":"OEM image",
         "os_version":"10",
         "cpu_abi": "arm64-v8a",
         "details":"...",
         "vndk":[
            27,
            28,
            29
         ],
         "spl":"...",
         "pubkey":"",
         "uri":"https://.../....zip"
      },

}

من الممكن أن تربط الشركة المصنّعة للمعدات الأصلية البيانات الوصفية المنشورة لميزة "تحديثات النظام الديناميكية" على النحو الموضّح في الشكل 7.

تسلسل البيانات الوصفية المنشورة لوحدة تخزين البيانات

الشكل 7: ربط البيانات الوصفية المنشورة لميزة "تحديثات النظام الديناميكية"

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