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

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

الزامات هسته

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

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

• CONFIG_DM_VERITY=y
• CONFIG_DM_VERITY_FEC=y

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

از اندروید ۱۱ به بعد، DSU برای استفاده از سیستم فایل F2FS یا ext4 به پارتیشن /data نیاز دارد. F2FS عملکرد بهتری دارد و توصیه می‌شود، اما تفاوت آن نباید ناچیز باشد.

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

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

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

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

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

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

رفتار فروشنده HAL

ویور هال

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

دروازه‌بان هال

Gatekeeper HAL باید از مقادیر بزرگ USER_ID پشتیبانی کند، زیرا GSI، UIDها را به میزان +1000000 به HAL آفست می‌دهد.

بوت را تأیید کنید

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

$(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 هسته قرار دهید یا با bootloader به صورت androidboot.system.security_patch=2019-04-05 bootconfig را اجرا کنید.

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

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

• یک پارتیشن منطقی برای ذخیره GSI.img (1~1.5 G)
• یک پارتیشن /data خالی ۸ گیگابایتی به عنوان sandbox برای اجرای 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 معمولی بسازید و نمی‌توانید آن را در گوگل پلی منتشر کنید. هدف این برنامه:

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

اندروید ۱۱ قابلیت بارگذاری DSU با یک کلیک را معرفی می‌کند که در تنظیمات توسعه‌دهندگان به صورت frontend وجود دارد.

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

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

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

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

پرچم ویژه

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

شکل ۳. فعال کردن feature flag

ممکن است رابط کاربری feature flag در دستگاهی که نسخه user build را اجرا می‌کند، در دسترس نباشد. در این صورت، به جای آن از دستور adb استفاده کنید:

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

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

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

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

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

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

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

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

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

DSU امضا شده توسط OEM

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

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

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

توصیفگر DSU JSON

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

{
    "include": ["https://.../gsi-release/gsi-src.json"]
}

دوم، از image primitive برای توصیف بسته‌های DSU منتشر شده استفاده می‌شود. در داخل image primitive چندین ویژگی وجود دارد:

• ویژگی‌های name و details رشته‌هایی هستند که در کادر محاوره‌ای برای انتخاب توسط کاربر نشان داده می‌شوند.

• ویژگی‌های cpu_api ، vndk و os_version برای بررسی سازگاری استفاده می‌شوند که در بخش بعدی توضیح داده شده‌اند.

• ویژگی اختیاری pubkey کلید عمومی را توصیف می‌کند که با کلید مخفی مورد استفاده برای امضای بسته DSU جفت می‌شود. وقتی این کلید مشخص شود، سرویس DSU می‌تواند بررسی کند که آیا دستگاه، کلید مورد استفاده برای تأیید بسته DSU را دارد یا خیر. این کار از نصب یک بسته DSU ناشناخته، به عنوان مثال نصب یک DSU امضا شده توسط OEM-A روی دستگاهی که توسط OEM-B ساخته شده است، جلوگیری می‌کند.

• ویژگی اختیاری tos به یک فایل متنی اشاره می‌کند که شرایط خدمات مربوط به بسته DSU مربوطه را شرح می‌دهد. وقتی یک توسعه‌دهنده یک بسته DSU را با ویژگی شرایط خدمات مشخص شده انتخاب می‌کند، کادر محاوره‌ای نشان داده شده در شکل 6 باز می‌شود و از توسعه‌دهنده می‌خواهد قبل از نصب بسته 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 یک عدد صحیح اختیاری است که نسخه اندروید را مشخص می‌کند. به عنوان مثال، برای اندروید ۱۰، os_version 10 و برای اندروید ۱۱، os_version 11 است. وقتی این ویژگی مشخص می‌شود، باید برابر یا بزرگتر از ویژگی سیستم ro.system.build.version.release باشد. این بررسی برای جلوگیری از بوت شدن یک تصویر GSI اندروید ۱۰ روی دستگاه فروشنده اندروید ۱۱ استفاده می‌شود که در حال حاضر پشتیبانی نمی‌شود. بوت شدن یک تصویر GSI اندروید ۱۱ روی دستگاه اندروید ۱۰ مجاز است.

• vndk یک آرایه اختیاری است که تمام VNDK های موجود در بسته DSU را مشخص می‌کند. وقتی مشخص می‌شود، بارگذار DSU بررسی می‌کند که آیا عدد استخراج شده از ویژگی سیستم ro.vndk.version شامل شده است یا خیر.

لغو کلیدهای DSU برای امنیت

در موارد بسیار نادر، زمانی که جفت کلید RSA مورد استفاده برای امضای تصاویر DSU به خطر بیفتد، ramdisk باید در اسرع وقت به‌روزرسانی شود تا کلید به خطر افتاده حذف شود. علاوه بر به‌روزرسانی پارتیشن بوت، می‌توانید کلیدهای به خطر افتاده را با استفاده از یک لیست ابطال کلید DSU (لیست سیاه کلید) از یک URL 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 منتشر شده توسط گوگل است. این رشته منبع می‌تواند همپوشانی و سفارشی‌سازی شود، به طوری که تولیدکنندگان اصلی تجهیزات (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 کلید لغو شده است، در قالبی که در بخش تولید کلید عمومی 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، به بخش افزودن کلید عمومی جفت‌سازی به ramdisk مراجعه کنید.

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

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

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

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

برای تأیید بسته DSU امضا شده، باید کلید oem_cert.avbpubkey در مسیر /avb/*.avbpubkey قرار گیرد. ابتدا، کلید عمومی با فرمت 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 را در توصیفگر 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 از یکی از این روش‌ها استفاده کنید:

• روش ۱: استفاده مجدد از مصنوعات ایجاد شده توسط فرآیند امضای 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 است.

تولیدکنندگان اصلی تجهیزات (OEM) می‌توانند با تعریف ویژگی persist.sys.fflag.override.settings_dynamic_system.list که به توصیف‌گر JSON خودشان اشاره می‌کند، لیست را بازنویسی کنند. برای مثال، یک تولیدکننده اصلی تجهیزات (OEM) ممکن است فراداده 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"
      },

}

همانطور که در شکل 7 نشان داده شده است، یک تولیدکننده تجهیزات اصلی (OEM) می‌تواند فراداده‌های DSU منتشر شده را زنجیره‌ای کند.

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