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

«به‌روزرسانی‌های سیستم پویا» (DSU) به شما امکان می‌دهد تصویر سیستم Android بسازید که کاربران بتوانند آن را از اینترنت بارگیری کنند و بدون خطر خراب شدن تصویر سیستم فعلی، آن را امتحان کنند. این سند نحوه پشتیبانی از DSU را شرح می‌دهد.

الزامات هسته

برای الزامات هسته، پیاده‌سازی پارتیشن‌های پویا را ببینید.

علاوه‌براین، DSU برای درستی‌سنجی تصویر سیستم Android به ویژگی هسته device-mapper-verity (dm-verity) متکی است. بنابراین باید پیکربندی‌های هسته زیر را فعال کنید:

• CONFIG_DM_VERITY=y
• CONFIG_DM_VERITY_FEC=y

الزامات پارتیشن

از Android 11، «واحد خدمات پویا» برای استفاده از سیستم فایل F2FS یا ext4 به /data پارتیشن نیاز دارد. ‫F2FS عملکرد بهتری دارد و توصیه می‌شود، اما تفاوت آن ناچیز است.

در اینجا چند نمونه از مدت زمان به‌روزرسانی سیستم پویا در دستگاه Pixel آورده شده است:

• استفاده از F2FS:
  • ‫۱۰۹ ثانیه، ۸ گیگابایت کاربر، ۸۶۷ مگابایت سیستم، نوع سیستم فایل: F2FS: رمزگذاری=aes-256-xts:aes-256-cts
  • ‫۱۰۴ ثانیه، کاربر ۸ گیگابایتی، سیستم ۸۶۷ مگابایتی، نوع سیستم فایل: F2FS: رمزگذاری=ice
• استفاده از ext4:
  • ‫۱۳۵ ثانیه، کاربر ۸ گیگابایتی، سیستم ۸۶۷ مگابایتی، نوع سیستم فایل: ext4: رمزگذاری=aes-256-xts:aes-256-cts

اگر در پلاتفرم شما خیلی بیشتر طول می‌کشد، بهتر است بررسی کنید که آیا پرچم نصب حاوی پرچمی است که باعث می‌شود نوشتن «همگام‌سازی» شود یا نه، یا می‌توانید پرچم «ناهمگام» را به‌طور صریح مشخص کنید تا عملکرد بهتری داشته باشید.

بخش metadata (۱۶ مگابایت یا بیشتر) برای ذخیره داده‌های مربوط به تصاویر نصب‌شده لازم است. باید درطول نصب مرحله اول نصب شود.

پارتیشن userdata باید از سیستم فایل F2FS یا ext4 استفاده کند. هنگام استفاده از F2FS، همه وصله‌های مربوط به F2FS موجود در هسته مشترک Android را اضافه کنید.

DSU با هسته/مشترک ۴.۹ توسعه و آزمایش شده است. توصیه می‌شود برای این ویژگی از هسته ۴.۹ و بالاتر استفاده کنید.

رفتار لایه انتزاع سخت‌افزار فروشنده

Weaver HAL

Weaver HAL تعداد ثابتی از جایگاه‌ها را برای ذخیره کردن کلیدهای کاربر ارائه می‌دهد. DSU دو جای کلید اضافی مصرف می‌کند. اگر یک OEM دارای Weaver HAL باشد، باید جای کافی برای تصویر سیستم عمومی (GSI) و تصویر میزبان داشته باشد.

لایه انتزاع سخت‌افزار Gatekeeper

Gatekeeper HAL باید از مقادیر بزرگ USER_ID پشتیبانی کند، زیرا GSI شناسه‌های کاربری را با ‎+۱۰۰۰۰۰۰ به HAL منتقل می‌کند.

درستی‌سنجی راه‌اندازی

اگر می‌خواهید از راه‌اندازی تصاویر GSI توسعه‌دهنده در حالت قفل‌شده بدون غیرفعال کردن راه‌اندازی درستی‌سنجی‌شده پشتیبانی کنید، کلیدهای GSI توسعه‌دهنده را با افزودن خط زیر به فایل device/<device_name>/device.mk اضافه کنید:

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

محافظت دربرابر عقب‌گرد

هنگام استفاده از «به‌روزرسانی سیستم پویا»، تصویر سیستم Android بارگیری‌شده باید جدیدتر از تصویر سیستم فعلی در دستگاه باشد. این کار با مقایسه سطح وصله امنیتی در توصیف‌کننده ویژگی AVB راه‌اندازی درستی‌سنجی‌شده Android (AVB) هر دو تصویر سیستم انجام می‌شود: Prop: com.android.build.system.security_patch -> '2019-04-05'.

برای دستگاه‌هایی که از AVB استفاده نمی‌کنند، سطح وصله امنیتی تصویر سیستم فعلی را با bootloader در cmdline هسته یا bootconfig قرار دهید: androidboot.system.security_patch=2019-04-05.

الزامات سخت‌افزاری

وقتی نمونه DSU را راه‌اندازی می‌کنید، دو فایل موقت اختصاص داده می‌شود:

• یک پارتیشن منطقی برای ذخیره GSI.img (۱ تا ۱٫۵ گیگابایت)
• یک پارتیشن /data خالی ۸ گیگابایتی به‌عنوان جعبه امن برای اجرای GSI

توصیه می‌کنیم قبل‌از راه‌اندازی نمونه «به‌روزرسانی سیستم پویا»، حداقل ۱۰ گیگابایت فضای آزاد رزرو کنید. DSU از تخصیص از کارت SD نیز پشتیبانی می‌کند. وقتی کارت SD وجود داشته باشد، این کارت بالاترین اولویت را برای تخصیص دارد. پشتیبانی از کارت SD برای دستگاه‌های کم‌مصرف که ممکن است حافظه داخلی کافی نداشته باشند بسیار مهم است. وقتی کارت SD وجود دارد، مطمئن شوید که به‌عنوان حافظه داخلی تنظیم نشده باشد. «فضای کار اختصاصی» از کارت‌های SD اقتباس‌شده پشتیبانی نمی‌کند.

میاناهای کاربری دردسترس

می‌توانید «به‌روزرسانی پویای سیستم» را بااستفاده از adb، برنامه OEM، یا بارکننده «به‌روزرسانی پویای سیستم» با یک کلیک (در 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 است:

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 یک میانای برنامه‌سازی کاربردی سیستم است، نمی‌توانید برنامه را با میانای برنامه‌سازی کاربردی کیت توسعه نرم‌افزار معمولی بسازید و نمی‌توانید آن را در Google Play منتشر کنید. هدف این برنامه:

1. فهرست تصاویر و نشانی وب مربوطه را با طرح‌واره تعریف‌شده توسط فروشنده واکشی کنید.
2. تصاویر موجود در فهرست را با دستگاه مطابقت دهید و تصاویر سازگار را برای انتخاب کاربر نشان دهید.

3. ‫DynamicSystemClient.start را به‌این‌صورت فراخوانی کنید:

   DynamicSystemClient aot = new DynamicSystemClient(...)
      aot.start(
           ...URL of the selected image...,
           ...uncompressed size of the selected image...);
   
   

نشانی وب به فایل تصویر سیستم فشرده‌شده با 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

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

شکل ۲. پیشرفت نصب تصویر DSU

به‌طور پیش‌فرض، بارکننده DSU یک توصیفگر JSON را که حاوی تصاویر GSI است بار می‌کند. بخش‌های زیر نحوه ساختن بسته‌های DSU امضاشده توسط سازنده اصلی و بار کردن آن‌ها از بارکننده DSU را نشان می‌دهد.

پرچم ویژگی

ویژگی DSU تحت پرچم ویژگی settings_dynamic_android قرار دارد. قبل‌از استفاده از DSU، مطمئن شوید پرچم ویژگی مربوطه فعال باشد.

شکل ۳. فعال کردن پرچم ویژگی

واسط کاربر پرچم ویژگی ممکن است در دستگاهی که ساخت کاربر را اجرا می‌کند دردسترس نباشد. در این مورد، به‌جای آن از فرمان adb استفاده کنید:

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

تصاویر سیستم میزبان فروشنده در GCE (اختیاری)

یکی از مکان‌های ذخیره‌سازی ممکن برای تصاویر سیستم، فضای ذخیره‌سازی Google Compute Engine (GCE) است. سرپرست نسخه پخش از کنسول ذخیره‌سازی GCP برای افزودن/حذف/تغییر تصویر سیستم منتشرشده استفاده می‌کند.

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

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

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

DSU چندبخشی در فایل ZIP

از Android 11، «واحد سیستم پویا» می‌تواند بیش‌از یک پارتیشن داشته باشد. برای مثال، می‌تواند علاوه‌بر system.img، حاوی product.img باشد. وقتی دستگاه راه‌اندازی می‌شود، مرحله اول init پارتیشن‌های DSU نصب‌شده را شناسایی می‌کند و وقتی DSU نصب‌شده فعال می‌شود، پارتیشن درون‌دستگاهی را به‌طور موقت جایگزین می‌کند. بسته DSU ممکن است حاوی پارتیشنی باشد که پارتیشن متناظری در دستگاه ندارد.

شکل ۵. فرایند DSU با چند پارتیشن

DSU امضاشده توسط سازنده اصلی محصول

برای اطمینان از اینکه همه تصاویر درحال اجرا در دستگاه ازسوی سازنده دستگاه مجوز دارند، همه تصاویر درون بسته DSU باید امضا شوند. برای مثال، فرض کنید بسته DSU وجود دارد که حاوی دو تصویر پارتیشن مانند زیر است:

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

هم system.img و هم product.img باید قبل‌از اینکه در فایل ZIP قرار داده شوند با کلید سازنده تجهیزات اصلی امضا شوند. روش معمول استفاده از الگوریتم نامتقارن است، برای مثال، RSA، که در آن از کلید خصوصی برای امضای بسته و از کلید عمومی برای درستی‌سنجی آن استفاده می‌شود. اولین ramdisk مرحله باید شامل کلید عمومی جفت‌سازی باشد، برای مثال، /avb/*.avbpubkey. اگر دستگاه ازقبل AVB را پذیرفته باشد، روال امضای موجود کافی خواهد بود. بخش‌های زیر فرایند امضا کردن را نشان می‌دهد و جایگاه کلید عمومی AVB را که برای تأیید تصاویر در بسته DSU استفاده می‌شود برجسته می‌کند.

توصیف‌گر JSON مربوط به DSU

توصیف‌کننده 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 را با مشخصه شرایط خدمات تعیین‌شده انتخاب می‌کند، چارگوش گفتگوی نشان‌داده‌شده در شکل ۶ باز می‌شود و از توسعه‌دهنده می‌خواهد قبل‌از نصب بسته DSU، شرایط خدمات را بپذیرد.

  

  شکل ۶. چارگوش گفتگوی شرایط خدمات

برای اطلاع، در اینجا یک توصیفگر 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 (فهرست سیاه کلید) از نشانی وب HTTPS، کلیدهای به‌خطر افتاده را مسدود کنید.

فهرست ابطال کلید DSU شامل فهرستی از کلیدهای عمومی AVB ابطال‌شده است. درطول نصب DSU، کلیدهای عمومی داخل تصویرهای DSU با فهرست لغو اعتبار سنجی می‌شوند. اگر مشخص شود که تصاویر حاوی کلید عمومی باطل‌شده است، فرایند نصب DSU متوقف می‌شود.

نشانی وب فهرست ابطال کلید باید نشانی وب 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 استفاده می‌کنند بتوانند فهرست سیاه کلید خودشان را ارائه و نگهداری کنند. این کار روشی را برای سازنده اصلی محصول فراهم می‌کند تا کلیدهای عمومی خاصی را بدون به‌روزرسانی تصویر دیسک حافظه دستگاه مسدود کند.

قالب فهرست ابطال به‌صورت زیر است:

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

این بخش نحوه انجام چندین رویه پیکربندی «واحد انتخاب پویا» را شرح می‌دهد.

تولید جفت کلید جدید

برای تولید جفت کلید خصوصی/عمومی RSA در قالب .pem (برای مثال، با اندازه ۲۰۴۸ بیت)، از دستور openssl استفاده کنید:

$ 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، بخش افزودن کلید عمومی جفت‌سازی به ramdisk را ببینید.

برای تبدیل گواهینامه x509 به قالب PEM:

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

اگر گواهینامه ازقبل فایل PEM است، از این مرحله رد شوید.

کلید عمومی جفت‌سازی را به ramdisk اضافه کنید

oem_cert.avbpubkey باید زیر /avb/*.avbpubkey قرار داده شود تا بسته DSU امضاشده تأیید شود. ابتدا کلید عمومی را در قالب PEM به قالب کلید عمومی AVB تبدیل کنید:

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

سپس کلید عمومی را با مراحل زیر در دیسک مجازی مرحله اول اضافه کنید.

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 در توصیفگر 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 به فراداده تصاویر GSI که https://...google.com/.../gsi-src.json است اشاره می‌کند.

تولیدکنندگان اصلی سخت‌افزار می‌توانند با تعریف کردن ویژگی 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"
      },

}

سازنده تجهیزات اصلی می‌تواند فراداده DSU منتشرشده را به‌صورت زنجیره‌ای، همان‌طور که در «شکل ۷» نشان داده شده است، پیوند دهد.

شکل ۷. زنجیره‌سازی فراداده‌های منتشرشده DSU