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

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

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

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

علاوة على ذلك، يعتمد DSU على ميزة نواة خرائط الأجهزة (dm-verity) للتحقق من صورة نظام Android. لذلك، عليك تفعيل ملفَّي ملفَّات برمجة kernel التالية:

  • CONFIG_DM_VERITY=y
  • CONFIG_DM_VERITY_FEC=y

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

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

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

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

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

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

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

تم تطوير أداة DSU واختبارها باستخدام kernel/common 4.9. يوصى باستخدام النواة 4.9 والإصدارات الأعلى لهذه الميزة.

سلوك HAL للمورّد

قناة Weaver HAL

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

واجهة برمجة التطبيقات لطبقة تجريد الأجهزة في موفِّر الخدمات

يجب أن يقبل HAL الخاص بـ Gatekeeper قيم USER_ID كبيرة، لأنّ واجهة GSI تضيف 1000000 إلى معرّفات المستخدمين في HAL.

التأكّد من التشغيل

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

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

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

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

في الأجهزة التي لا تستخدم AVB، يمكنك وضع مستوى رمز تصحيح الأمان لصورة النظام الحالية في kernel cmdline أو Bootconfig باستخدام برنامج الإقلاع: androidboot.system.security_patch=2019-04-05.

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

عند تشغيل مثيل DSU، يتم تخصيص ملفين مؤقتين:

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

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

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

يمكنك إطلاق DSU باستخدام adb، أو أحد تطبيقات المصنّع الأصلي للجهاز، أو أداة تحميل DSU بنقرة واحدة (في الإصدار 11 من Android أو الإصدارات الأحدث).

تشغيل أداة DSU باستخدام adb

لبدء DSU باستخدام 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

تشغيل DSU باستخدام تطبيق

نقطة الدخول الرئيسية إلى DSU هي 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. الغرض من هذا التطبيق:

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

  3. استدعِ 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

أداة تحميل DSU بنقرة واحدة

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

بدء تشغيل أداة تحميل DSU

الشكل 1. تشغيل محمّل DSU

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

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

الشكل 2: مستوى تقدُّم تثبيت صورة DSU

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

علامة ميزة

تتوفّر ميزة DSU ضمن علامة الميزة settings_dynamic_android. قبل استخدام DSU، تأكَّد من تفعيل علامة الميزة المقابلة.

جارٍ تفعيل علامة الميزة.

الشكل 3. تفعيل ميزة "تبديل أوضاع الميزات"

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

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

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

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

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

إتاحة الوصول للجميع في Google Cloud Engine

الشكل 4. إتاحة الوصول للجميع في خدمة Google Compute Engine (GCE)

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

حزمة DSU متعددة الأقسام في ملف ZIP

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

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

الشكل 5. عملية DSU مع أقسام متعددة

DSU الموقَّعة من المصنّع الأصلي للجهاز

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

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

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

واصف JSON لـ DSU

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

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

ثانيًا، يتم استخدام العنصر الأساسي image لوصف حِزم DSU التي تم إصدارها. في العنصر الأساسي للصورة، تتوفّر عدة سمات:

  • السمتَان name وdetails هما سلسلة تظهر في مربّع الحوار ليختارها المستخدم.

  • تُستخدَم سمات cpu_api وvndk وos_version في عمليات التحقّق من التوافق الموضّحة في القسم التالي.

  • تصف السمة pubkey الاختيارية المفتاح العام الذي يقترن بالمفتاح السري المستخدم للتوقيع على حزمة DSU. عند تحديدها، يمكن لخدمة DSU التحقّق مما إذا كان الجهاز يتضمّن المفتاح المستخدَم لإثبات صحة حزمة DSU. ويؤدي ذلك إلى تجنُّب تثبيت حِزمة DSU غير معروفة، على سبيل المثال، تثبيت حِزمة DSU موقَّعة من الشركة المصنّعة "أ" على جهاز من الشركة المصنّعة "ب".

  • تشير السمة الاختيارية tos إلى ملف نصي يصف بنود الخدمة لحزمة DSU المقابلة. عندما يختار مطوّر برامج حزمة DSU مع تحديد سمة بنود الخدمة، يفتح مربّع الحوار المعروض في الشكل 6 يطلب من المطوّر قبول بنود الخدمة قبل تثبيت حزمة DSU.

    مربع حوار بنود الخدمة

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

كمرجع، إليك وصف DSU بتنسيق JSON لـ GSI:

{
   "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"
      }
   ]
}

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

تُستخدَم عدة سمات لتحديد التوافق بين حزمة DSU والجهاز المحلي:

  • cpu_api هي سلسلة تصف بنية الجهاز. هذه السمة إلزامية وتتم مقارنتها بالسمة ro.product.cpu.abi الخاصة بالنظام. ويجب أن تتطابق قيمها تمامًا.

  • os_version هو عدد صحيح اختياري يحدّد إصدار Android. على سبيل المثال، في Android 10، يمثّل الرمز os_version الرمز 10، ويمثّل الرمز os_version الرمز 11 في Android 11. عند تحديد هذه السمة، يجب أن تكون مساوية لسمة النظام ro.system.build.version.release أو أكبر منها. تُستخدم هذه العملية لمنع تشغيل صورة GSI التي تعمل بالإصدار 10 من نظام التشغيل Android على جهاز مورّد يعمل بالإصدار 11 من نظام التشغيل Android، وهو غير متاح حاليًا. يُسمح بتشغيل صورة GSI لنظام التشغيل Android 11 على جهاز Android 10.

  • vndk هي مصفوفة اختيارية تحدّد جميع حِزم VNDK المضمّنة في حزمة DSU. عند تحديده، يتحقّق أداة تحميل DSU ممّا إذا كان الرقم المستخرَج من سمة النظام ro.vndk.version مضمّنًا.

إبطال مفاتيح DSU لأغراض الأمان

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

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

يجب أن يكون عنوان 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، وهي قائمة إبطال لمفاتيح GSI التي تصدرها Google. يمكن دمج سلسلة الموارد هذه وتخصيصها، حتى يتمكّن المصنّعون الأصليون للأجهزة الذين يتّبعون ميزة DSU من تقديم قائمتهم السوداء للمفاتيح والاحتفاظ بها. يوفر ذلك طريقة لمصنعي المعدّات الأصلية لحظر مفاتيح عامة معيّنة بدون تعديل صورة ذاكرة الوصول العشوائي (RAM) للجهاز.

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

{
   "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 للمفتاح المُلغى، بالتنسيق الموضّح في القسم إنشاء المفتاح العام لAVB .
  • يشير الرمز status إلى حالة إبطال المفتاح. وفي الوقت الحالي، القيمة الوحيدة المسموح بها هي REVOKED.
  • reason هي سلسلة اختيارية تصف سبب الإبطال.

إجراءات DSU

يصف هذا القسم كيفية تنفيذ العديد من إجراءات إعداد DSU.

إنشاء مفتاحَي تشفير جديدَين

استخدِم الأمر 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 متاحة بعد إنشاء المفتاح. يمكنك الاطّلاع على قسم إضافة مفتاح pubkey للإقران إلى ramdisk للحصول على تعليمات حول إنشاء مفتاح AVB العام من شهادة x509.

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

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

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

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

يجب وضع oem_cert.avbpubkey ضمن /avb/*.avbpubkey للتحقّق من حزمة DSU الموقَّعة. أولاً، عليك تحويل المفتاح العام بتنسيق PEM إلى تنسيق المفتاح العام AVB:

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

بعد ذلك، أدرِج المفتاح العام في ذاكرة الوصول العشوائي (RAM) للخطوة الأولى باتّباع الخطوات التالية.

  1. أضِف وحدة معدّة مسبقًا لنسخ 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)

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

    droidcore: oem_cert.avbpubkey

إنشاء سمة AVB pubkey في واصف JSON

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

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

في ما يلي محتوى السمة pubkey الخاصة بواصف JSON.

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

توقيع حزمة DSU

استخدِم إحدى الطريقتَين التاليتَين لتوقيع حزمة DSU:

  • الطريقة 1: إعادة استخدام العنصر الذي تم إنشاؤه من خلال عملية التوقيع الأصلية لAVB ل إنشاء حزمة DSU هناك طريقة بديلة تتمثل في استخراج الصور الموقعة بالفعل من حزمة الإصدار واستخدام الصور المستخرجة لإنشاء ملف ZIP مباشرةً.

  • الطريقة 2: استخدِم الأوامر التالية لتوقيع أقسام DSU في حال توفّر المفتاح الخاص. يتم توقيع كل img ضمن حزمة DSU (ملف 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.

التحقّق من حزمة DSU على الجهاز

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


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

إنشاء حزمة DSU

ينشئ المثال التالي حزمة DSU تحتوي على 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 -

تخصيص عملية إعداد الجهاز للمؤسسات بنقرة واحدة

توجّه أداة تحميل DSU تلقائيًا إلى البيانات الوصفية لصور GSI، وهي https://...google.com/.../gsi-src.json.

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

{
    "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"
      },

}

من الممكن للمصنّع الأصلي للجهاز أن يسلسلة البيانات الوصفية لـ DSU المنشورة كما هو موضح في الشكل 7.

سلسلة البيانات الوصفية المنشورة DSU

الشكل 7: ربط البيانات الوصفية المنشورة لوحدة DSU