به روز رسانی های پویا سیستم

به روز رسانی سیستم پویا (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

بافنده 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 منتشر کنید. هدف این برنامه:

  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 با یک کلیک

اندروید 11 لودر DSU را با یک کلیک معرفی می‌کند که در تنظیمات توسعه‌دهنده ظاهری است.

راه اندازی لودر DSU

شکل 1. راه اندازی لودر DSU

هنگامی که توسعه‌دهنده روی دکمه DSU Loader کلیک می‌کند، یک توصیفگر از پیش پیکربندی‌شده DSU JSON را از وب دریافت می‌کند و همه تصاویر قابل اجرا را در منوی شناور نمایش می‌دهد. یک تصویر را برای شروع نصب DSU انتخاب کنید و پیشرفت در نوار اعلان نشان داده می شود.

پیشرفت نصب تصویر 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 برای افزودن/حذف/تغییر تصویر سیستم منتشر شده استفاده می کند.

تصاویر باید دسترسی عمومی داشته باشند، همانطور که در اینجا نشان داده شده است:

دسترسی عمومی در GCE

شکل 4. دسترسی عمومی در GCE

روش عمومی کردن یک مورد در اسناد Google Cloud موجود است.

DSU چند پارتیشن در فایل ZIP

با شروع اندروید 11، DSU می تواند بیش از یک پارتیشن داشته باشد. به عنوان مثال، علاوه بر system.img می‌تواند حاوی product.img باشد. هنگامی که دستگاه بوت می شود، مرحله اول پارتیشن های DSU نصب شده را شناسایی می کند و زمانی که 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_version 10 و برای اندروید 11، os_version 11 است. هنگامی که این ویژگی مشخص می شود، باید برابر یا بزرگتر از ویژگی سیستم 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 با مراحل زیر قرار دهید.

  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 است. قبل از قرار دادن آن در توصیفگر 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 نشان داده شده است، زنجیره ای کند.

متاداده DSU منتشر شده زنجیره ای

شکل 7. زنجیره ای کردن ابرداده های منتشر شده DSU