ساختن بسته‌های OTA

می‌توانید از ابزار ota_from_target_files ارائه‌شده در build/make/tools/releasetools برای ساختن بسته‌های OTA کامل و افزایشی برای دستگاه‌هایی که از به‌روزرسانی‌های سیستم A/B یا به‌روزرسانی‌های سیستم غیر A/B استفاده می‌کنند استفاده کنید. این ابزار فایل target-files.zip تولیدشده توسط سیستم ساخت Android را به‌عنوان ورودی می‌گیرد.

برای دستگاه‌های دارای Android 11 یا بالاتر، می‌توانید یک بسته OTA برای چندین دستگاه با SKUهای مختلف بسازید. انجام این کار مستلزم پیکربندی دستگاه‌های هدف برای استفاده از اثر انگشت‌های پویا و به‌روزرسانی فراداده OTA برای افزودن نام دستگاه و اثر انگشت در ورودی‌های پیش‌شرط و پس‌شرط است.

‫Android 8.0 بسته‌های OTA مبتنی بر فایل را برای دستگاه‌های غیر A/B منسوخ کرد، که باید به‌جای آن از بسته‌های OTA مبتنی بر بلوک استفاده کنند. برای تولید بسته‌های OTA مبتنی بر بلوک یا دستگاه‌های دارای Android نسخه ۷.x یا پایین‌تر، گزینه --block را به پارامتر ota_from_target_files ارسال کنید.

ساختن به‌روزرسانی‌های کامل

به‌روزرسانی کامل بسته OTA است که حاوی وضعیت نهایی کامل دستگاه (سیستم، بوت، و پارتیشن‌های بازیابی) است. تا زمانی که دستگاه قابلیت دریافت و اعمال بسته را داشته باشد، بسته می‌تواند ساخت را صرف‌نظر از وضعیت فعلی دستگاه نصب کند. برای مثال، فرمان‌های زیر از ابزارهای انتشار برای ساختن بایگانی target-files.zip برای دستگاه tardis استفاده می‌کنند.

. build/envsetup.sh && lunch tardis-eng
mkdir dist_output
make dist DIST_DIR=dist_output

‫make dist بسته OTA کامل (در $OUT) می‌سازد. فایل .zip حاصل شامل همه موارد لازم برای ساختن بسته‌های OTA برای دستگاه tardis است. همچنین می‌توانید ota_from_target_files را به‌عنوان باینری پایتون بسازید و آن را برای ساختن بسته‌های کامل یا افزایشی فراخوانی کنید.

ota_from_target_files dist_output/tardis-target_files.zip ota_update.zip

مسیر ota_from_target_files در $PATH راه‌اندازی شده است و باینری پایتون حاصل در دایرکتوری out/ قرار دارد.

ota_update.zip اکنون آماده ارسال به دستگاه‌های آزمایشی است (همه چیز با کلید آزمایشی امضا شده است). برای دستگاه‌های کاربر، کلیدهای خصوصی خودتان را همان‌طور که در امضای ساختارها برای انتشار توضیح داده شده است تولید و استفاده کنید.

ساختن به‌روزرسانی‌های فزاینده

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

بسته به‌روزرسانی افزایشی را فقط می‌توانید در دستگاه‌هایی نصب کنید که ساخت منبع استفاده‌شده در ساخت بسته را داشته باشند. برای ساختن به‌روزرسانی افزایشی، به فایل target_files.zip از ساخت قبلی (ساختی که می‌خواهید از آن به‌روزرسانی کنید) و همچنین فایل target_files.zip از ساخت جدید نیاز دارید. برای مثال، فرمان‌های زیر از ابزارهای انتشار برای ساختن به‌روزرسانی افزایشی برای دستگاه tardis استفاده می‌کنند.

ota_from_target_files -i PREVIOUS-tardis-target_files.zip dist_output/tardis-target_files.zip incremental_ota_update.zip

این ساخت بسیار شبیه به ساخت قبلی است و بسته به‌روزرسانی افزایشی (incremental_ota_update.zip) بسیار کوچک‌تر از به‌روزرسانی کامل مربوطه است (حدود ۱ مگابایت به‌جای ۶۰ مگابایت).

بسته افزایشی را فقط برای دستگاه‌هایی توزیع کنید که دقیقاً همان ساخت قبلی را اجرا می‌کنند که به‌عنوان نقطه شروع بسته افزایشی استفاده شده است. باید تصاویر را در PREVIOUS-tardis-target_files.zip یا PREVIOUS-tardis-img.zip (هر دو با make dist ساخته شده‌اند و باید با fastboot update فلش شوند) فلش کنید، نه تصاویر موجود در دایرکتوری PRODUCT_OUT (ساخته‌شده با make، که با fastboot flashall فلش خواهد شد). تلاش برای نصب بسته افزایشی در دستگاهی با ساختار دیگر منجر به خطای نصب می‌شود. وقتی نصب ناموفق باشد، دستگاه در همان وضعیت کاری باقی می‌ماند (سیستم قدیمی را اجرا می‌کند)؛ بسته قبل‌از دست زدن به فایل‌ها، وضعیت قبلی همه فایل‌هایی را که به‌روزرسانی می‌کند درستی‌سنجی می‌کند، بنابراین دستگاه در وضعیت نیمه‌به‌روزرسانی‌شده رها نمی‌شود.

برای ارائه بهترین تجربه کاربری، به‌ازای هر ۳ تا ۴ به‌روزرسانی افزایشی، یک به‌روزرسانی کامل ارائه دهید. این کار به کاربران کمک می‌کند با جدیدترین نسخه همگام شوند و از نصب طولانی مجموعه‌ای از به‌روزرسانی‌های افزایشی جلوگیری کنند.

ساختن بسته‌های OTA برای چندین واحد نگهداری کالا

Android 11 یا بالاتر از استفاده از یک بسته OTA برای چندین دستگاه با SKU مختلف پشتیبانی می‌کند. انجام این کار مستلزم پیکربندی دستگاه‌های هدف برای استفاده از اثر انگشت پویا و به‌روزرسانی فراداده OTA (بااستفاده از ابزارهای OTA) برای گنجاندن نام دستگاه و اثر انگشت در ورودی‌های شرایط قبل و بعد است.

درباره واحدهای نگهداری موجودی

قالب «واحد نگهداری کالا» گونه‌ای از مقادیر پارامتر ساخت ترکیبی است و معمولاً زیرمجموعه‌ای اعلام‌نشده از پارامترهای build_fingerprint کنونی است. سازندگان تجهیزات اصلی می‌توانند از هر ترکیبی از پارامترهای ساخت تأییدشده CDD برای یک SKU استفاده کنند و همچنین از یک تصویر واحد برای آن SKUها استفاده کنند. برای مثال، «واحد نگهداری کالا» زیر دارای چندین گونه است:

SKU = <product><device><modifierA><modifierB><modifierC>

• modifierA سطح دستگاه است (مثل Pro، Premium، یا Plus)
• ‫modifierB تنوع سخت‌افزاری است (مثل رادیو)
• modifierC منطقه است که می‌تواند عمومی باشد (مانند NA،‏ EMEA، یا CHN) یا مختص کشور یا زبان باشد (مانند JPN،‏ ENG، یا CHN)

بسیاری از «سازندگان اصلی محصول» از یک تصویر واحد برای چندین واحد نگهداری کالا استفاده می‌کنند، سپس نام محصول نهایی و اثر انگشت دستگاه را در زمان اجرا پس‌از راه‌اندازی دستگاه استخراج می‌کنند. این فرایند فرایند توسعه پلاتفرم را ساده می‌کند و به دستگاه‌هایی با سفارشی‌سازی‌های جزئی اما نام‌های محصول متفاوت امکان می‌دهد تصاویر مشترک (مثل tardis و tardispro) را هم‌رسانی کنند.

استفاده از اثر انگشت پویا

اثر انگشت زنجیره‌ای تعریف‌شده از پارامترهای ساخت است، مانند ro.product.brand، ro.product.name، و ro.product.device. اثر انگشت دستگاه از اثر انگشت پارتیشن سیستم مشتق می‌شود و به‌عنوان شناسه یکتای تصاویر (و بایت‌ها) درحال اجرا در دستگاه استفاده می‌شود. برای ایجاد اثر انگشت پویا، از منطق پویا در فایل build.prop دستگاه استفاده کنید تا مقدار متغیرهای بوت‌لودر را در زمان بوت دستگاه دریافت کنید، سپس از آن داده‌ها برای ایجاد اثر انگشت پویا برای آن دستگاه استفاده کنید.

برای مثال، برای استفاده از اثر انگشت پویا برای دستگاه‌های tardis و tardispro، فایل‌های زیر را همان‌طور که در زیر نشان داده شده است به‌روز کنید.

• فایل odm/etc/build_std.prop را به‌روزرسانی کنید تا حاوی خط زیر باشد.

  ro.odm.product.device=tardis
  

• فایل odm/etc/build_pro.prop را به‌روزرسانی کنید تا حاوی خط زیر باشد.

  ro.odm.product.device=tardispro
  

• فایل odm/etc/build.prop را به‌روز کنید تا شامل خطوط زیر باشد.

  ro.odm.product.device=tardis
  import /odm/etc/build_${ro.boot.product.hardware.sku}.prop
  

این خطوط به‌صورت پویا نام دستگاه، اثر انگشت، و ro.build.fingerprint مقادیر را براساس مقدار دارایی ro.boot.product.hardware.sku بارکننده (که فقط خواندنی است) تنظیم می‌کنند.

به‌روزرسانی فراداده بسته OTA

بسته OTA حاوی فایل فراداده (META-INF/com/android/metadata) است که بسته را توصیف می‌کند، ازجمله پیش‌شرط و پس‌شرط بسته OTA. برای مثال، کد زیر فایل ابرداده برای بسته OTA است که دستگاه tardis را هدف‌یابی می‌کند.

post-build=google/tardis/tardis:11/RP1A.200521.001/6516341:userdebug/dev-keys
post-build-incremental=6516341
post-sdk-level=30
post-security-patch-level=2020-07-05
post-timestamp=1590026334
pre-build=google/tardis/tardis:11/RP1A.200519.002.A1/6515794:userdebug/dev-keys
pre-build-incremental=6515794
pre-device=tardis

مقادیر pre-device، pre-build-incremental، و pre-build وضعیت موردنیاز دستگاه را قبل‌از نصب بسته OTA تعریف می‌کنند. مقادیر post-build-incremental و post-build وضعیتی را که انتظار می‌رود دستگاه پس‌از نصب بسته OTA داشته باشد تعریف می‌کنند. مقادیر فیلدهای pre- و post- از دارایی‌های ساخت مربوطه زیر استخراج می‌شود.

• مقدار pre-device از ویژگی ساخت ro.product.device مشتق شده است.
• مقادیر pre-build-incremental و post-build-incremental از خصوصیت ساخت ro.build.version.incremental استخراج شده است.
• مقادیر pre-build و post-build از دارایی ساخت ro.build.fingerprint استخراج می‌شوند.

در دستگاه‌هایی که Android 11 یا بالاتر دارند، می‌توانید از پرچم --boot_variable_file در ابزارهای OTA برای مشخص کردن مسیر فایلی استفاده کنید که حاوی مقادیر متغیرهای زمان اجرا است که در ایجاد اثر انگشت پویای دستگاه استفاده می‌شود. سپس از این داده‌ها برای به‌روزرسانی فراداده OTA استفاده می‌شود تا نام دستگاه و اثر انگشت در شرایط pre- و post- (بااستفاده از نویسه خط عمودی | به‌عنوان جداکننده) گنجانده شود. پرچم --boot_variable_file دارای نحو و شرح زیر است.

• نحو: --boot_variable_file <path>
• شرح: مسیری را به فایلی که حاوی مقادیر ممکن ro.boot.* ویژگی است مشخص می‌کند. برای محاسبه اثر انگشت‌های زمان اجرای احتمالی هنگامی که برخی‌از ویژگی‌های ro.product.* توسط عبارت وارد کردن لغو می‌شوند، استفاده می‌شود. این فایل انتظار دارد که در هر خط یک دارایی وجود داشته باشد و هر خط دارای قالب زیر باشد: prop_name=value1,value2.

برای مثال، وقتی دارایی ro.boot.product.hardware.sku=std,pro باشد، فراداده OTA برای دستگاه‌های tardis و tardispro به‌صورت زیر است.

post-build=google/tardis/tardis:11/<suffix>|google/tardis/tardispro:11/<suffix>
pre-build=google/tardis/tardis:11/<suffix>|google/tardis/tardispro:11/<suffix>
pre-device=tardis|tardispro

برای پشتیبانی از این عملکرد در دستگاه‌های دارای Android 10، به پیاده‌سازی مرجع مراجعه کنید. این فهرست تغییرات به‌صورت شرطی دستورات import را در فایل build.prop تجزیه می‌کند، که باعث می‌شود لغوهای دارایی شناسایی شوند و در فراداده OTA نهایی منعکس شوند.