به روز رسانی سیستم پویا (DSU) به شما امکان می دهد یک تصویر سیستم اندرویدی بسازید که کاربران می توانند آن را از اینترنت دانلود کرده و بدون خطر خراب کردن تصویر فعلی سیستم امتحان کنند. این سند نحوه پشتیبانی از DSU را توضیح می دهد.
الزامات هسته
برای نیازهای هسته به پیاده سازی پارتیشن های پویا مراجعه کنید.
علاوه بر این، DSU برای تأیید تصویر سیستم اندروید به ویژگی هسته دستگاه-mapper-verity (dm-verity) متکی است. بنابراین باید تنظیمات هسته زیر را فعال کنید:
-
CONFIG_DM_VERITY=y -
CONFIG_DM_VERITY_FEC=y
الزامات پارتیشن
با شروع اندروید 11، DSU برای استفاده از سیستم فایل F2FS یا ext4 به پارتیشن /data نیاز دارد. F2FS عملکرد بهتری ارائه می دهد و توصیه می شود، اما تفاوت باید ناچیز باشد.
در اینجا چند نمونه از مدت زمان به‌روزرسانی پویا سیستم با دستگاه Pixel آمده است:
- استفاده از F2FS:
- 109s، کاربر 8G، سیستم 867M، نوع سیستم فایل: F2FS: encryption=aes-256-xts:aes-256-cts
- 104s، کاربر 8G، سیستم 867M، نوع سیستم فایل: F2FS: encryption=ice
- استفاده از ext4:
- 135s، کاربر 8G، سیستم 867M، نوع سیستم فایل: ext4: encryption=aes-256-xts:aes-256-cts
اگر در پلتفرم شما زمان زیادی طول می کشد، ممکن است بخواهید بررسی کنید که پرچم mount حاوی پرچمی است که باعث نوشتن "همگام سازی" می شود یا خیر، یا می توانید یک پرچم "async" را به صراحت مشخص کنید تا عملکرد بهتری داشته باشید.
پارتیشن metadata (16 مگابایت یا بزرگتر) برای ذخیره داده های مربوط به تصاویر نصب شده مورد نیاز است. باید در مرحله اول نصب شود.
پارتیشن userdata باید از سیستم فایل F2FS یا ext4 استفاده کند. هنگام استفاده از F2FS، تمام وصله های مربوط به F2FS موجود در هسته مشترک Android را اضافه کنید.
DSU با kernel/common 4.9 توسعه و آزمایش شد. توصیه می شود برای این ویژگی از کرنل 4.9 و بالاتر استفاده کنید.
رفتار هال فروشنده
بافنده HAL
بافنده HAL تعداد ثابتی اسلات برای ذخیره کلیدهای کاربر فراهم می کند. DSU دو اسلات کلید اضافی را مصرف می کند. اگر یک OEM دارای یک HAL بافنده باشد، باید شکاف های کافی برای یک تصویر سیستم عمومی (GSI) و یک تصویر میزبان داشته باشد.
دروازه بان HAL
Gatekeeper HAL باید از مقادیر بزرگ USER_ID پشتیبانی کند، زیرا GSI UIDها را به HAL با +1000000 جبران می کند.
بوت را تأیید کنید
اگر می‌خواهید از بوت کردن تصاویر GSI برنامه‌نویس در حالت قفل بدون غیرفعال کردن بوت تأیید شده پشتیبانی کنید، با افزودن خط زیر به device/<device_name>/device.mk کلیدهای Developer GSI را اضافه کنید:
$(call inherit-product, $(SRC_TARGET_DIR)/product/developer_gsi_keys.mk)
حفاظت برگشتی
هنگام استفاده از DSU، تصویر سیستم اندروید دانلود شده باید جدیدتر از تصویر سیستم فعلی در دستگاه باشد. این کار با مقایسه سطوح وصله امنیتی در توصیفگر ویژگی AVB Android Verified Boot (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 G) - یک پارتیشن 8 گیگابایتی خالی
/dataبه عنوان جعبه ایمنی برای اجرای GSI
توصیه می کنیم قبل از راه اندازی نمونه DSU حداقل 10 گیگابایت فضای خالی را رزرو کنید. DSU همچنین از تخصیص از کارت SD پشتیبانی می کند. وقتی کارت SD وجود دارد، بیشترین اولویت را برای تخصیص دارد. پشتیبانی از کارت SD برای دستگاه های کم مصرف که ممکن است حافظه داخلی کافی نداشته باشند بسیار مهم است. وقتی کارت SD وجود دارد، مطمئن شوید که مورد استفاده قرار نگرفته است. DSU از کارت های SD پذیرفته شده پشتیبانی نمی کند.
پیشانی های موجود
می‌توانید DSU را با استفاده از adb ، یک برنامه OEM یا بارکننده DSU با یک کلیک (در اندروید ۱۱ یا بالاتر) راه‌اندازی کنید.
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 API 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 یک API سیستم است، نمی‌توانید برنامه را با API معمولی 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
لودر DSU با یک کلیک
اندروید 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. دسترسی عمومی در GCE
روش عمومی کردن یک مورد در اسناد Google Cloud موجود است.
DSU چند پارتیشن در فایل ZIP
با شروع اندروید 11، DSU می تواند بیش از یک پارتیشن داشته باشد. به عنوان مثال، علاوه بر system.img می‌تواند حاوی product.img باشد. هنگامی که دستگاه بوت می شود، مرحله اول پارتیشن های DSU نصب شده را شناسایی init کند و زمانی که DSU نصب شده فعال است، پارتیشن روی دستگاه را به طور موقت جایگزین می کند. بسته DSU ممکن است حاوی پارتیشنی باشد که پارتیشن مربوطه روی دستگاه نداشته باشد.
شکل 5. فرآیند DSU با پارتیشن های متعدد
DSU با امضای OEM
برای اطمینان از اینکه تمام تصاویر در حال اجرا بر روی دستگاه توسط سازنده دستگاه مجاز هستند، تمام تصاویر موجود در بسته DSU باید امضا شوند. به عنوان مثال، فرض کنید یک بسته DSU وجود دارد که شامل دو تصویر پارتیشن مانند زیر است:
dsu.zip {
- system.img
- product.img
}
هر دو system.img و product.img باید قبل از قرار دادن در فایل ZIP توسط کلید OEM امضا شوند. روش معمول استفاده از یک الگوریتم نامتقارن است، به عنوان مثال، RSA، که در آن از کلید مخفی برای امضای بسته و از کلید عمومی برای تأیید آن استفاده می شود. ramdisk مرحله اول باید شامل کلید عمومی تجزیه و تحلیل باشد، برای مثال /avb/*.avbpubkey . اگر دستگاه قبلاً AVB را پذیرفته باشد، روش امضای موجود کافی خواهد بود. بخش‌های زیر فرآیند امضا را نشان می‌دهند و محل قرارگیری pubkey 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یک عدد صحیح اختیاری است که نسخه اندروید را مشخص می کند. به عنوان مثال، برای اندروید 10،os_version10و برای اندروید 11،os_version11است. هنگامی که این ویژگی مشخص می شود، باید برابر یا بزرگتر از ویژگی سیستمro.system.build.version.releaseباشد. این بررسی برای جلوگیری از بوت شدن یک تصویر Android 10 GSI در یک دستگاه فروشنده Android 11 استفاده می شود که در حال حاضر پشتیبانی نمی شود. بوت کردن یک تصویر Android 11 GSI در دستگاه 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 است. این رشته منبع را می توان روی هم قرار داد و سفارشی کرد، به طوری که OEM هایی که از ویژگی DSU استفاده می کنند می توانند لیست سیاه کلید خود را تهیه و حفظ کنند. این روشی را برای OEM فراهم می کند تا کلیدهای عمومی خاصی را بدون به روز رسانی تصویر 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 از کلید ابطال شده است، در قالبی که در بخش تولید بخش pubkey 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، به بخش افزودن pubkey جفت‌سازی به بخش ramdisk مراجعه کنید.
برای تبدیل یک گواهی 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
سپس کلید عمومی را در مرحله اول 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
ویژگی AVB pubkey را در توصیفگر JSON ایجاد کنید
oem_cert.avbpubkey در فرمت باینری کلید عمومی AVB است. قبل از قرار دادن آن در توصیفگر JSON، از SHA-1 برای خواندن آن استفاده کنید:
$ 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 با یک کلیک را سفارشی کنید
به طور پیش‌فرض، بارگذار DSU به ابرداده تصاویر GSI اشاره می‌کند که https://...google.com/.../gsi-src.json است.
OEM ها می توانند لیست را با تعریف ویژگی 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