میتوانید از ابزار ota_from_target_files ارائهشده در build/make/tools/releasetools برای ساخت بستههای OTA کامل و افزایشی برای دستگاههایی که از بهروزرسانیهای سیستم A/B یا بهروزرسانیهای سیستم غیرA/B استفاده میکنند استفاده کنید. این ابزار فایل target-files.zip تولید شده توسط سیستم ساخت اندروید را به عنوان ورودی می گیرد.
برای دستگاههای دارای Android 11 یا بالاتر، میتوانید یک بسته OTA برای چندین دستگاه با SKUهای مختلف بسازید. انجام این کار مستلزم پیکربندی دستگاههای هدف برای استفاده از اثر انگشت پویا و بهروزرسانی فراداده OTA برای گنجاندن نام دستگاه و اثر انگشت در ورودیهای پیش و پس از شرایط است.
Android 8.0 بستههای OTA مبتنی بر فایل را برای دستگاههای غیرA/B منسوخ کرد، که در عوض باید از بستههای OTA مبتنی بر بلوک استفاده کنند. برای تولید بستههای OTA مبتنی بر بلوک یا دستگاههای دارای Android 7.x یا پایینتر، گزینه --block را به پارامتر ota_from_target_files منتقل کنید.
به روز رسانی کامل بسازید
به روز رسانی کامل یک بسته OTA است که شامل کل وضعیت نهایی دستگاه (سیستم، بوت و پارتیشن های بازیابی) است. تا زمانی که دستگاه قادر به دریافت و اعمال بسته باشد، بسته می تواند بدون توجه به وضعیت فعلی دستگاه، بیلد را نصب کند. برای مثال، دستورات زیر از ابزارهای انتشار برای ساخت آرشیو target-files.zip برای دستگاه tardis استفاده می کنند.
. build/envsetup.sh && lunch tardis-engmkdir dist_outputmake 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 اکنون آماده ارسال به دستگاه های آزمایشی است (همه چیز با کلید تست امضا شده است). برای دستگاههای کاربر، کلیدهای خصوصی خود را همانطور که در Signing builds برای انتشار توضیح داده شده است، تولید و استفاده کنید.
بروزرسانی های افزایشی بسازید
به روز رسانی افزایشی یک بسته 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 ) بسیار کوچکتر از به روز رسانی کامل مربوطه است (حدود 1 مگابایت به جای 60 مگابایت).
یک بسته افزایشی را فقط برای دستگاههایی توزیع کنید که دقیقاً همان ساخت قبلی مورد استفاده به عنوان نقطه شروع بسته افزایشی را اجرا میکنند. باید تصاویر را در PREVIOUS-tardis-target_files.zip یا PREVIOUS-tardis-img.zip (هر دو با make dist ساخته شده اند، تا با fastboot update فلش شوند)، به جای تصاویر زیر فهرست PRODUCT_OUT (ساخته شده با make ، که با fastboot flashall فلش می شود) فلش کنید. تلاش برای نصب بسته افزایشی بر روی دستگاهی با چند ساخت دیگر منجر به خطای نصب می شود. هنگامی که نصب با شکست مواجه می شود، دستگاه در همان حالت کار باقی می ماند (در حال اجرای سیستم قدیمی). بسته، وضعیت قبلی همه فایلهایی را که بهروزرسانی میکند، قبل از لمس آنها تأیید میکند، بنابراین دستگاه در حالت نیمه ارتقا یافته قرار نمیگیرد.
برای بهترین تجربه کاربری، به ازای هر ۳ تا ۴ بهروزرسانی افزایشی، یک بهروزرسانی کامل ارائه دهید. این به کاربران کمک میکند تا آخرین نسخه را دریافت کنند و از نصب طولانی بهروزرسانیهای افزایشی اجتناب کنند.
بسته های OTA برای SKU های متعدد بسازید
Android 11 یا بالاتر از استفاده از یک بسته OTA برای چندین دستگاه با SKU های مختلف پشتیبانی می کند. انجام این کار مستلزم پیکربندی دستگاههای مورد نظر برای استفاده از اثر انگشت پویا و بهروزرسانی فراداده OTA (با استفاده از ابزار OTA) برای گنجاندن نام دستگاه و اثر انگشت در ورودیهای شرایط قبل و بعد است.
درباره SKU ها
قالب یک SKU تغییری از مقادیر پارامترهای ساخت ترکیبی است و معمولاً یک زیرمجموعه اعلام نشده از پارامترهای build_fingerprint فعلی است. OEM ها می توانند از هر ترکیبی از پارامترهای ساخت تایید شده توسط CDD برای SKU استفاده کنند و در عین حال از یک تصویر واحد برای آن SKU ها نیز استفاده کنند. به عنوان مثال، SKU زیر دارای چندین تنوع است:
SKU = <product><device><modifierA><modifierB><modifierC>
-
modifierAسطح دستگاه است (مانند Pro، Premium یا Plus) -
modifierBتغییر سخت افزاری است (مانند رادیو) -
modifierCناحیه ای است که می تواند عمومی باشد (مانند NA، EMEA، یا CHN) یا مختص کشور یا زبان (مانند JPN، ENG، یا CHN)
بسیاری از OEM ها از یک تصویر برای چندین SKU استفاده می کنند، سپس نام محصول نهایی و اثر انگشت دستگاه را در زمان اجرا پس از بوت شدن دستگاه استخراج می کنند. این فرآیند فرآیند توسعه پلتفرم را ساده میکند و دستگاههایی با سفارشیسازیهای جزئی اما نامهای محصول متفاوت را قادر میسازد تا تصاویر مشترک (مانند 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.incrementalbuild مشتق شده اند. - مقادیر
pre-buildوpost-buildاز ویژگیro.build.fingerprintbuild مشتق شده اند.
در دستگاههای دارای Android 11 یا بالاتر، میتوانید از پرچم --boot_variable_file در ابزار OTA برای تعیین مسیری به فایلی استفاده کنید که حاوی مقادیر متغیرهای زمان اجرا مورد استفاده در ایجاد اثر انگشت پویا دستگاه است. سپس از دادهها برای بهروزرسانی فراداده OTA استفاده میشود تا نام دستگاه و اثر انگشت را در شرایط pre- و post- (با استفاده از کاراکتر لوله | بهعنوان جداکننده) شامل شود. پرچم --boot_variable_file دارای نحو و توضیحات زیر است.
- نحو:
--boot_variable_file <path> - توضیحات: مسیری به فایلی که حاوی مقادیر احتمالی خواص
ro.boot.*است را مشخص می کند. زمانی که برخی از ویژگیهایro.product.*توسط دستور import لغو میشوند، برای محاسبه اثر انگشت احتمالی زمان اجرا استفاده میشود. فایل انتظار دارد یک ویژگی در هر خط که در آن هر خط دارای فرمت زیر باشد: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 فراهم میکند.