تتيح لك ميزة "التحديثات الديناميكية للنظام" (DSU) إنشاء صورة نظام Android يمكن للمستخدمين تنزيلها من الإنترنت وتجربتها بدون المخاطرة بتلف صورة النظام الحالية. يوضِّح هذا المستند كيفية توفير ميزة "التحديث من خلال الجهاز".
متطلبات النواة
راجِع مقالة تنفيذ الأقسام الديناميكية للاطّلاع على متطلبات kernel.
بالإضافة إلى ذلك، تعتمد أداة DSU على ميزة جهاز التعيين والتحقق من الصحة (dm-verity) في نواة النظام للتحقّق من صورة نظام Android. لذلك، عليك تفعيل ملفَّي ملفَّات برمجة kernel التالية:
CONFIG_DM_VERITY=yCONFIG_DM_VERITY_FEC=y
متطلبات التقسيم
بدءًا من الإصدار 11 من Android، تتطلّب أداة DSU أن يستخدم القسم /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
إذا استغرقت العملية وقتًا أطول بكثير على منصتك، ننصحك بالتحقّق مما إذا كان ملف العلامة mount يحتوي على أي علامة تؤدي إلى كتابة "sync"، أو يمكنك تحديد علامة "async" بشكل صريح للحصول على أداء أفضل.
يجب توفُّر قسم metadata (16 ميغابايت أو أكثر) لتخزين البيانات ذات الصلة
بالصور المثبَّتة. يجب تثبيته أثناء مرحلة التثبيت الأولى.
يجب أن يستخدم قسم userdata نظام الملفات F2FS أو ext4. عند استخدام F2FS،
يجب تضمين جميع الإصلاحات ذات الصلة بـ F2FS المتوفّرة في
النواة المشتركة لنظام التشغيل Android.
تم تطوير أداة DSU واختبارها باستخدام kernel/common 4.9. ننصحك باستخدام 4.9 kernel والإصدارات الأحدث من أجل هذه الميزة.
سلوك طبقة HAL الخاصة بالمورّد
Weaver HAL
يوفّر weaver 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، ضَع مستوى تصحيح الأمان لملف رمز التمهيد الحالي
في 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 غير مُستخدَمة عندما تكون متوفّرة. لا تتوافق ميزة "التخزين المؤقت على السحابة الإلكترونية" مع بطاقات SD المُدمَجة.
واجهات المستخدم المتاحة
يمكنك تشغيل أداة DSU باستخدام adb أو تطبيق المصنّع الأصلي للجهاز أو أداة تحميل DSU بنقرة واحدة (في
Android 11 أو إصدار أحدث).
تشغيل أداة 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 هي 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.gzp.aosp_taimen-userdebug.2018dev.raw.gz
أداة تحميل DSU بنقرة واحدة
يقدّم نظام Android 11 أداة تحميل DSU بنقرة واحدة، وهي واجهة أمامية في إعدادات المطوّر.
الشكل 1: بدء تشغيل أداة تحميل DSU
عندما ينقر المطوِّر على الزر DSU Loader (أداة تحميل DSU)، يتم جلب وصف DSU JSON الذي تم ضبطه مسبقًا من الويب وعرض كل الصور السارية في الجدول المتغير في الشاشة. اختَر صورة لبدء تثبيت 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 للقيام بعمليات إضافة/حذف/تغيير صورة النظام التي تم إصدارها.
يجب أن تكون الصور متاحة للجميع، كما هو موضّح هنا:
الشكل 4: إتاحة الوصول للجميع في Google Cloud Engine
تتوفّر إجراءات إتاحة العنصر للجميع في مستندات Google Cloud.
حزمة DSU متعددة الأقسام في ملف ZIP
بدءًا من الإصدار 11 من نظام التشغيل Android، يمكن أن يتضمّن نظام DSU أكثر من قطعة واحدة. على سبيل المثال، يمكن أن يحتوي على product.img بالإضافة إلى
system.img. عند تشغيل الجهاز، ترصد المرحلة الأولى init
أقسام وحدة 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.
وصف DSU بتنسيق JSON
يصف وصف 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، وفي Android 11، يكون الرمزos_versionهو11. عند تحديد هذه السمة، يجب أن تكون مساوية لسمة النظامro.system.build.version.releaseأو أكبر منها. يُستخدَم هذا التحقّق لمنع تشغيل صورة GSI لنظام التشغيل Android 10 على جهاز مثبَّت عليه نظام التشغيل Android 11 ، وهو غير متوافق حاليًا. يُسمح بتشغيل صورة 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
يصف هذا القسم كيفية تنفيذ العديد من إجراءات ضبط وحدة التحكّم في حدود الجلسة.
إنشاء مفتاحَي تشفير جديدَين
استخدِم الأمر 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 بعد إنشاء المفتاح. اطّلِع على قسم إضافة المفتاح العام للإقران إلى ذاكرة الوصول العشوائي المؤقت للحصول على تعليمات لإنشاء المفتاح العام لبروتوكول AVB من شهادة x509.
لتحويل شهادة x509 إلى تنسيق PEM:
$ openssl x509 -pubkey -noout -in oem_cert_pub.x509.pem > oem_cert_pub.pem
يمكنك تخطّي هذه الخطوة إذا كانت الشهادة ملف PEM.
إضافة مفتاح التشفير العام للإقران إلى ذاكرة الوصول العشوائي
يجب وضع oem_cert.avbpubkey ضمن /avb/*.avbpubkey للتحقّق من
حزمة DSU الموقَّعة. أولاً، عليك تحويل المفتاح العام بتنسيق PEM إلى تنسيق المفتاح العام لبروتوكول AVB:
$ avbtool extract_public_key --key oem_cert_pub.pem --output oem_cert.avbpubkey
بعد ذلك، أدرِج المفتاح العام في ذاكرة الوصول العشوائي (RAM) للخطوة الأولى باتّباع الخطوات التالية.
أضِف وحدة مُنشأة مسبقًا لنسخ
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
إنشاء سمة مفتاح AVB العام في الوصف بتنسيق 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.
الشكل 7: ربط البيانات الوصفية المنشورة لوحدة DSU