تتيح لك تحديثات النظام الديناميكية (DSU) إنشاء صورة لنظام Android يمكن للمستخدمين تنزيلها من الإنترنت وتجربتها دون المخاطرة بإتلاف صورة النظام الحالية. يصف هذا المستند كيفية دعم DSU.
متطلبات النواة
راجع تنفيذ الأقسام الديناميكية لمعرفة متطلبات kernel.
بالإضافة إلى ذلك، تعتمد DSU على ميزة kernel Device-mapper-verity (dm-verity) للتحقق من صورة نظام Android. لذلك يجب عليك تمكين تكوينات kernel التالية:
-
CONFIG_DM_VERITY=y
-
CONFIG_DM_VERITY_FEC=y
متطلبات التقسيم
بدءًا من Android 11، يتطلب DSU قسم /data
لاستخدام نظام الملفات F2FS أو ext4. يوفر F2FS أداءً أفضل ويوصى به، ولكن يجب أن يكون الفرق بسيطًا.
فيما يلي بعض الأمثلة على المدة التي يستغرقها التحديث الديناميكي للنظام باستخدام جهاز Pixel:
- باستخدام F2FS:
- 109s، مستخدم 8G، نظام 867M، نوع نظام الملفات: F2FS: التشفير=aes-256-xts:aes-256-cts
- 104s، مستخدم 8G، نظام 867M، نوع نظام الملفات: F2FS: التشفير = الجليد
- باستخدام ext4:
- 135s، مستخدم 8G، نظام 867M، نوع نظام الملفات: ext4: التشفير=aes-256-xts:aes-256-cts
إذا استغرق الأمر وقتًا أطول بكثير على نظامك الأساسي، فقد ترغب في التحقق مما إذا كانت علامة التثبيت تحتوي على أي علامة تجعل الكتابة "متزامنة"، أو يمكنك تحديد علامة "غير متزامن" بشكل صريح للحصول على أداء أفضل.
مطلوب قسم metadata
(16 ميجابايت أو أكبر) لتخزين البيانات المتعلقة بالصور المثبتة. يجب أن يتم تركيبه أثناء تركيب المرحلة الأولى.
يجب أن يستخدم قسم userdata
نظام الملفات F2FS أو ext4. عند استخدام F2FS، قم بتضمين جميع التصحيحات ذات الصلة بـ F2FS المتوفرة في kernel الشائع لنظام Android .
تم تطوير واختبار DSU باستخدام kernel/common 4.9. يوصى باستخدام kernel 4.9 والإصدارات الأحدث لهذه الميزة.
سلوك HAL للمورد
ويفر هال
يوفر ويفر HAL عددًا ثابتًا من الفتحات لتخزين مفاتيح المستخدم. يستهلك DSU فتحتين إضافيتين للمفاتيح. إذا كان لدى الشركة المصنعة للمعدات الأصلية (HAL) ويفر، فيجب أن يكون لديها فتحات كافية لصورة النظام العامة (GSI) وصورة المضيف.
حارس البوابة هال
يحتاج Gatekeeper HAL إلى دعم قيم USER_ID
الكبيرة، لأن GSI تقوم بإزاحة UIDs إلى HAL بمقدار +1000000.
التحقق من التمهيد
إذا كنت تريد دعم تشغيل صور Developer GSI في حالة القفل دون تعطيل التمهيد الذي تم التحقق منه، فقم بتضمين مفاتيح Developer GSI عن طريق إضافة السطر التالي إلى الملف device/<device_name>/device.mk
:
$(call inherit-product, $(SRC_TARGET_DIR)/product/developer_gsi_keys.mk)
حماية التراجع
عند استخدام DSU، يجب أن تكون صورة نظام Android التي تم تنزيلها أحدث من صورة النظام الحالية على الجهاز. يتم ذلك عن طريق مقارنة مستويات تصحيح الأمان في واصف خاصية AVB لنظام Android Verified Boot (AVB) لكلا صورتي النظام: Prop: com.android.build.system.security_patch -> '2019-04-05'
.
بالنسبة للأجهزة التي لا تستخدم AVB، ضع مستوى تصحيح الأمان لصورة النظام الحالية في cmdline kernel أو bootconfig باستخدام أداة تحميل التشغيل: androidboot.system.security_patch=2019-04-05
.
متطلبات الأجهزة
عند تشغيل مثيل DSU، يتم تخصيص ملفين مؤقتين:
- قسم منطقي لتخزين
GSI.img
(1~1.5G) - قسم
/data
فارغ بسعة 8 جيجابايت باعتباره وضع الحماية لتشغيل GSI
نوصي بحجز ما لا يقل عن 10 جيجابايت من المساحة الحرة قبل تشغيل مثيل DSU. يدعم DSU أيضًا التخصيص من بطاقة SD. عند وجود بطاقة SD، تكون لها الأولوية القصوى للتخصيص. يعد دعم بطاقة SD أمرًا بالغ الأهمية للأجهزة ذات الطاقة المنخفضة التي قد لا تحتوي على مساحة تخزين داخلية كافية. عند وجود بطاقة SD، تأكد من عدم اعتمادها. لا يدعم DSU بطاقات SD المعتمدة .
الواجهات الأمامية المتاحة
يمكنك تشغيل DSU باستخدام adb
أو تطبيق OEM أو أداة تحميل 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 باستخدام أحد التطبيقات
نقطة الدخول الرئيسية إلى DSU هي android.os.image.DynamicSystemClient.java
API:
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 إلى ملف صورة نظام مضغوط بتنسيق gzipp وغير متفرق، والذي يمكنك إنشاؤه باستخدام الأوامر التالية:
$ 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 بنقرة واحدة، وهي واجهة أمامية في إعدادات المطور.
الشكل 1. إطلاق محمل DSU
عندما ينقر المطور على زر DSU Loader ، فإنه يجلب واصف DSU JSON الذي تم تكوينه مسبقًا من الويب ويعرض جميع الصور القابلة للتطبيق في القائمة العائمة. حدد صورة لبدء تثبيت DSU، وسيظهر التقدم على شريط الإعلام.
الشكل 2. تقدم عملية تثبيت صورة DSU
افتراضيًا، يقوم محمل DSU بتحميل واصف JSON الذي يحتوي على صور GSI. توضح الأقسام التالية كيفية إنشاء حزم DSU موقعة من قبل OEM وتحميلها من أداة تحميل DSU.
علم الميزة
توجد ميزة DSU ضمن علامة ميزة settings_dynamic_android
. قبل استخدام DSU، تأكد من تمكين علامة الميزة المقابلة.
الشكل 3. تمكين علامة الميزة
قد تكون واجهة مستخدم علامة الميزة غير متاحة على جهاز يقوم بتشغيل إصدار مستخدم. في هذه الحالة، استخدم الأمر adb
بدلاً من ذلك:
$ adb shell setprop persist.sys.fflag.override.settings_dynamic_system 1
صور النظام المضيف للمورد على GCE (اختياري)
أحد مواقع التخزين المحتملة لصور النظام هو مجموعة Google Compute Engine (GCE). يستخدم مسؤول الإصدار وحدة تحكم تخزين GCP لإضافة/حذف/تغيير صورة النظام التي تم إصدارها.
يجب أن تكون الصور متاحة للعامة، كما هو موضح هنا:
الشكل 4. وصول الجمهور إلى الحملة العالمية للتعليم
يتوفر الإجراء الخاص بجعل العنصر عامًا متاحًا في وثائق Google Cloud .
DSU متعدد الأقسام في ملف ZIP
بدءًا من Android 11، يمكن أن تحتوي وحدة DSU على أكثر من قسم واحد. على سبيل المثال، يمكن أن يحتوي على product.img
بالإضافة إلى ملف system.img
. عند init
الجهاز، تكتشف المرحلة الأولى أقسام DSU المثبتة وتستبدل القسم الموجود على الجهاز مؤقتًا، عند تمكين DSU المثبت. قد تحتوي حزمة DSU على قسم لا يحتوي على قسم مطابق على الجهاز.
الشكل 5. عملية DSU مع أقسام متعددة
DSU موقعة من قبل OEM
للتأكد من أن جميع الصور التي يتم تشغيلها على الجهاز معتمدة من قبل الشركة المصنعة للجهاز، يجب توقيع جميع الصور الموجودة ضمن حزمة DSU. على سبيل المثال، افترض أن هناك حزمة DSU تحتوي على صورتين للقسم كما هو موضح أدناه:
dsu.zip {
- system.img
- product.img
}
يجب توقيع كل من system.img
و product.img
بواسطة مفتاح OEM قبل وضعهما في ملف ZIP. الممارسة الشائعة هي استخدام خوارزمية غير متماثلة، على سبيل المثال، RSA، حيث يتم استخدام المفتاح السري لتوقيع الحزمة ويتم استخدام المفتاح العام للتحقق منها. يجب أن يتضمن قرص ذاكرة الوصول العشوائي للمرحلة الأولى مفتاح التقشير العام، على سبيل المثال، /avb/*.avbpubkey
. إذا كان الجهاز يستخدم بالفعل AVB، فسيكون إجراء التوقيع الحالي كافيًا. توضح الأقسام التالية عملية التوقيع وتسلط الضوء على موضع مفتاح AVB العمومي المستخدم للتحقق من الصور الموجودة في حزمة DSU.
واصف DSU JSON
يصف واصف DSU JSON حزم 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 موقعة بواسطة OEM-A على جهاز مصنوع بواسطة OEM-B.تشير سمة
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
. يُستخدم هذا الفحص لمنع تشغيل صورة Android 10 GSI على جهاز بائع يعمل بنظام Android 11، وهو غير مدعوم حاليًا. يُسمح بتشغيل صورة Android 11 GSI على جهاز يعمل بنظام Android 10.vndk
عبارة عن مصفوفة اختيارية تحدد جميع VNDKs المضمنة في حزمة DSU. عندما يتم تحديده، يتحقق محمل DSU من تضمين الرقم المستخرج من خاصية النظامro.vndk.version
.
قم بإلغاء مفاتيح DSU للأمان
في الحالات النادرة للغاية عندما يتم اختراق زوج مفاتيح RSA المستخدم لتوقيع صور DSU، يجب تحديث قرص الذاكرة في أقرب وقت ممكن لإزالة المفتاح المخترق. بالإضافة إلى تحديث قسم التمهيد، يمكنك حظر المفاتيح المخترقة باستخدام قائمة إبطال مفاتيح 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 توفير القائمة السوداء الرئيسية الخاصة بهم والحفاظ عليها. يوفر هذا طريقة لـ OEM لحظر مفاتيح عامة معينة دون تحديث صورة قرص ذاكرة الوصول العشوائي الخاص بالجهاز.
تنسيق قائمة الإلغاء هو:
{
"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 متاحة بعد إنشاء المفتاح. راجع قسم إضافة المفتاح العمومي المقترن إلى قرص ذاكرة الوصول العشوائي للحصول على إرشادات لإنشاء مفتاح AVB العام من شهادة x509.
لتحويل شهادة x509 إلى تنسيق PEM:
$ openssl x509 -pubkey -noout -in oem_cert_pub.x509.pem > oem_cert_pub.pem
قم بتخطي هذه الخطوة إذا كانت الشهادة عبارة عن ملف PEM بالفعل.
أضف مفتاح Pubkey المقترن إلى قرص ذاكرة الوصول العشوائي
يجب وضع oem_cert.avbpubkey
ضمن /avb/*.avbpubkey
للتحقق من حزمة DSU الموقعة. أولاً، قم بتحويل المفتاح العام بتنسيق PEM إلى تنسيق المفتاح العام AVB:
$ avbtool extract_public_key --key oem_cert_pub.pem --output oem_cert.avbpubkey
ثم قم بتضمين المفتاح العام في قرص ذاكرة المرحلة الأولى مع الخطوات التالية.
قم بإضافة وحدة تم إنشاؤها مسبقًا لنسخ
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 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:
الطريقة الأولى: إعادة استخدام العناصر التي تم إنشاؤها بواسطة عملية توقيع AVB الأصلية لإنشاء حزمة DSU. هناك طريقة بديلة تتمثل في استخراج الصور الموقعة بالفعل من حزمة الإصدار واستخدام الصور المستخرجة لإنشاء ملف ZIP مباشرةً.
الطريقة الثانية: استخدم الأوامر التالية لتوقيع أقسام 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 بنقرة واحدة
افتراضيًا، يشير محمل DSU إلى البيانات الوصفية لصور GSI وهي https://...google.com/.../gsi-src.json
.
يمكن لمصنعي المعدات الأصلية (OEMs) استبدال القائمة عن طريق تحديد خاصية persist.sys.fflag.override.settings_dynamic_system.list
التي تشير إلى واصف JSON الخاص بهم. على سبيل المثال، قد توفر الشركة المصنعة للمعدات الأصلية (OEM) بيانات تعريف JSON تتضمن GSI بالإضافة إلى الصور الخاصة بشركة OEM مثل هذا:
{
"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"
},
}
من الممكن أن يقوم مصنع المعدات الأصلية (OEM) بتسلسل بيانات تعريف DSU المنشورة كما هو موضح في الشكل 7.
الشكل 7. تسلسل البيانات الوصفية DSU المنشورة