Android 10 مکانیسم بهروزرسانی داده منطقه زمانی مبتنی بر APK (موجود در Android 8.1 و Android 9) را منسوخ میکند و مکانیزم بهروزرسانی ماژول مبتنی بر APEX را جایگزین آن میکند. AOSP همچنان کد پلتفرم لازم را برای OEMها برای فعال کردن بهروزرسانیهای مبتنی بر APK درج میکند، بنابراین دستگاههایی که به Android 10 ارتقا مییابند همچنان میتوانند بهروزرسانیهای داده منطقه زمانی ارائهشده توسط شریک را از طریق APK دریافت کنند. با این حال، مکانیسم بهروزرسانی APK نباید در دستگاه تولیدی استفاده شود که بهروزرسانیهای ماژول را نیز دریافت میکند، زیرا بهروزرسانی مبتنی بر APK جایگزین بهروزرسانی مبتنی بر APEX میشود (یعنی دستگاهی که یک بهروزرسانی APK دریافت کرده، بهروزرسانیهای مبتنی بر APEX را نادیده میگیرد. ).
به روز رسانی منطقه زمانی (اندروید 10 و بالاتر)
ماژول داده منطقه زمانی در Android 10 و بالاتر بهروزرسانیهای ساعت تابستانی (DST) و مناطق زمانی در دستگاههای Android را پشتیبانی میکند و دادههایی را استاندارد میکند که میتوانند اغلب به دلایل مذهبی، سیاسی و ژئوپلیتیک تغییر کنند.
به روز رسانی ها از فرآیند زیر استفاده می کنند:
- IANA یک به روز رسانی برای پایگاه داده منطقه زمانی منتشر می کند در پاسخ به تغییر یک یا چند دولت در قوانین منطقه زمانی در کشورهای خود، به روز رسانی را منتشر می کند.
- Google یا شریک Android یک بهروزرسانی ماژول داده منطقه زمانی (فایل APEX) حاوی مناطق زمانی بهروزرسانی شده را آماده میکند.
- دستگاه کاربر نهایی بهروزرسانی را دانلود میکند، راهاندازی مجدد میشود، سپس تغییرات را اعمال میکند و پس از آن، دادههای منطقه زمانی دستگاه حاوی دادههای منطقه زمانی جدید از بهروزرسانی است.
برای جزئیات بیشتر در مورد ماژول ها، به اجزای سیستم مدولار مراجعه کنید.
بهروزرسانیهای منطقه زمانی (اندروید 8.1–9)
در Android 8.1 و Android 9، OEM ها می توانند از مکانیزم مبتنی بر APK برای ارسال داده های به روز شده قوانین منطقه زمانی به دستگاه ها بدون نیاز به به روز رسانی سیستم استفاده کنند. این مکانیسم کاربران را قادر میسازد تا بهروزرسانیها را دریافت کنند (در نتیجه طول عمر مفید دستگاه اندرویدی را افزایش میدهد) و شرکای Android را قادر میسازد تا بهروزرسانیهای منطقه زمانی را مستقل از بهروزرسانیهای تصویر سیستم آزمایش کنند.
تیم کتابخانههای هسته اندروید فایلهای دادهای لازم را برای بهروزرسانی قوانین منطقه زمانی در یک دستگاه اندروید موجود فراهم میکند. OEM ها می توانند هنگام ایجاد به روز رسانی منطقه زمانی برای دستگاه های خود از این فایل های داده استفاده کنند یا در صورت تمایل می توانند فایل های داده خود را ایجاد کنند. در همه موارد، OEMها کنترل بر تضمین کیفیت/آزمایش، زمانبندی و راهاندازی بهروزرسانیهای قوانین منطقه زمانی را برای دستگاههای پشتیبانیشده خود حفظ میکنند.
کد منبع و داده منطقه زمانی اندروید
همه دستگاههای اندرویدی موجود، حتی آنهایی که از این ویژگی استفاده نمیکنند، به دادههای قوانین منطقه زمانی نیاز دارند و باید با مجموعه پیشفرض دادههای قوانین منطقه زمانی در پارتیشن /system
ارسال شوند. سپس این داده ها توسط کدهایی از کتابخانه های زیر در درخت منبع Android استفاده می شود:
- کد مدیریت شده از
libcore/
(به عنوان مثال،java.util.TimeZone
) از فایل هایtzdata
وtzlookup.xml
استفاده می کند. - کد کتابخانه بومی در
bionic/
(مثلاً برایmktime
، تماسهای سیستم محلی) از فایلtzdata
استفاده میکند. - کد کتابخانه ICU4J/ICU4C در
external/icu/
از فایل icu.dat
استفاده می کند.
این کتابخانه ها فایل های همپوشانی را که ممکن است در دایرکتوری /data/misc/zoneinfo/current
وجود داشته باشند را پیگیری می کنند. انتظار میرود فایلهای همپوشانی حاوی دادههای قوانین منطقه زمانی بهبودیافته باشند، بنابراین دستگاهها را قادر میسازد بدون تغییر /system
بهروزرسانی شوند.
اجزای سیستم Android که به دادههای قانون منطقه زمانی نیاز دارند ابتدا مکانهای زیر را بررسی کنند:
-
libcore/
وbionic/
از کپی/data
فایلهایtzdata
وtzlookup.xml
استفاده میکنند. - کد ICU4J/ICU4C از فایلهای موجود در
/data
میکند و برای دادههایی که وجود ندارد (برای قالبها، رشتههای محلی و غیره) به فایلهای/system
برمیگردد.
فایل های توزیع
فایلهای .zip
Distro حاوی فایلهای دادهای هستند که برای پر کردن دایرکتوری /data/misc/zoneinfo/current
لازم است. فایلهای توزیع همچنین حاوی متادیتا هستند که به دستگاهها اجازه میدهد مشکلات نسخهسازی را شناسایی کنند.
فرمت فایل توزیع به نسخه اندروید وابسته است زیرا محتویات با نسخه ICU، الزامات پلتفرم اندروید و سایر تغییرات انتشار تغییر میکنند. Android برای هر بهروزرسانی IANA (علاوه بر بهروزرسانی فایلهای سیستم پلتفرم)، فایلهای توزیعی را برای نسخههای Android پشتیبانیشده ارائه میکند. برای به روز نگه داشتن دستگاه های خود، OEM ها می توانند از این فایل های توزیع استفاده کنند یا با استفاده از درخت منبع Android (که حاوی اسکریپت ها و سایر فایل های مورد نیاز برای تولید فایل های توزیع است) فایل های خود را ایجاد کنند.
اجزای به روز رسانی منطقه زمانی
به روز رسانی قوانین منطقه زمانی شامل انتقال فایل های توزیع به یک دستگاه و نصب ایمن فایل های موجود در آن است. انتقال و نصب به موارد زیر نیاز دارد:
- عملکرد سرویس پلت فرم (
timezone.RulesManagerService
)، که به طور پیش فرض غیرفعال است. OEM ها باید عملکرد را از طریق پیکربندی فعال کنند.RulesManagerService
در فرآیند سرور سیستم اجرا می شود و عملیات به روز رسانی منطقه زمانی را با نوشتن در/data/misc/zoneinfo/staged
بندی می کند.RulesManagerService
همچنین می تواند عملیات های از قبل مرحله بندی شده را جایگزین یا حذف کند. -
TimeZoneUpdater
، یک برنامه سیستمی غیرقابل بهروزرسانی (معروف به برنامه Updater ). OEM ها باید این برنامه را در تصویر سیستم دستگاه هایی که از این ویژگی استفاده می کنند قرار دهند. - OEM
TimeZoneData
، یک برنامه سیستمی قابل بهروزرسانی (معروف به برنامه داده ) که فایلهای توزیعی را به دستگاه حمل میکند و آنها را برای برنامه Updater در دسترس قرار میدهد. OEM ها باید این برنامه را در تصویر سیستم دستگاه هایی که از این ویژگی استفاده می کنند قرار دهند. -
tzdatacheck
، یک باینری بوت زمان لازم برای عملکرد صحیح و ایمن بهروزرسانیهای منطقه زمانی.
درخت منبع Android حاوی کد منبع عمومی برای مؤلفههای فوق است که OEM میتواند بدون تغییر استفاده کند. کد آزمایشی ارائه شده است تا OEM ها را قادر سازد تا به طور خودکار بررسی کنند که ویژگی را به درستی فعال کرده اند.
نصب Distro
فرآیند نصب توزیع شامل مراحل زیر است:
- برنامه داده از طریق بارگیری فروشگاه برنامه یا بارگذاری جانبی به روز می شود. فرآیند سرور سیستم (از طریق کلاسهای
timezone.RulesManagerServer/timezone.PackageTracker
) تغییرات را در نام بسته برنامه داده پیکربندیشده، ویژه OEM مشاهده میکند.شکل 1. به روز رسانی برنامه های داده - فرآیند سرور سیستم با پخش یک هدف هدفمند با یک نشانه منحصر به فرد و یکبار مصرف در برنامه Updater، یک بررسی به روز رسانی را آغاز می کند. سرور سیستم آخرین توکنی را که تولید کرده است پیگیری میکند تا بتواند تعیین کند آخرین بررسی که راهاندازی کرده چه زمانی تکمیل شده است. هر توکن دیگری نادیده گرفته می شود.
شکل 2. بررسی به روز رسانی ماشه - در طول بررسی بهروزرسانی ، برنامه Updater وظایف زیر را انجام میدهد:
- با فراخوانی RulesManagerService وضعیت فعلی دستگاه را پرس و جو می کند.
شکل 3. به روز رسانی برنامه داده ها، با فراخوانی RulesManagerService - برنامه Data را با پرس و جو از یک URL کاملاً تعریف شده ContentProvider و مشخصات ستون جستجو می کند تا اطلاعاتی در مورد توزیع دریافت کند.
شکل 4. بهروزرسانیهای برنامه داده، اطلاعاتی درباره توزیع دریافت کنید
- با فراخوانی RulesManagerService وضعیت فعلی دستگاه را پرس و جو می کند.
- اپلیکیشن Updater بر اساس اطلاعاتی که دارد، اقدام مناسب را انجام می دهد. اقدامات موجود عبارتند از:
- درخواست نصب کنید داده های توزیع از برنامه Data خوانده می شود و به RulesManagerService در سرور سیستم ارسال می شود. RulesManagerService مجدداً تأیید میکند که نسخه و محتوای قالب توزیع برای دستگاه مناسب است و نصب را مرحلهبندی میکند.
- درخواست حذف نصب کنید (این نادر است). برای مثال، اگر APK بهروزرسانیشده در
/data
در حال غیرفعال کردن یا حذف نصب باشد و دستگاه به نسخه موجود در/system
. - هیچ کاری نکن زمانی رخ می دهد که توزیع برنامه داده نامعتبر باشد.
شکل 5. بررسی کامل - راه اندازی مجدد و tzdatacheck. هنگامی که دستگاه بعدی بوت می شود، باینری tzdatacheck هر عملیات مرحله ای را اجرا می کند. باینری tzdatacheck می تواند وظایف زیر را انجام دهد:
- عملیات مرحلهای را با مدیریت ایجاد، جایگزینی و/یا حذف فایلهای
/data/misc/zoneinfo/current
قبل از باز شدن سایر اجزای سیستم و شروع به استفاده از فایلها، اجرا کنید. - بررسی کنید که فایلهای موجود در
/data
برای نسخه پلتفرم فعلی صحیح باشند، که اگر دستگاه بهتازگی بهروزرسانی سیستم را دریافت کرده باشد و نسخه قالب توزیع تغییر کرده باشد، ممکن است اینطور نباشد. - مطمئن شوید که نسخه قوانین IANA مشابه یا جدیدتر از نسخه موجود در
/system
باشد. این کار در برابر بهروزرسانی سیستم که دستگاه را با دادههای قوانین منطقه زمانی قدیمیتر از آنچه در تصویر/system
موجود است، حفظ میکند.
- عملیات مرحلهای را با مدیریت ایجاد، جایگزینی و/یا حذف فایلهای
قابلیت اطمینان
فرآیند نصب انتها به انتها ناهمزمان است و در سه فرآیند سیستم عامل تقسیم می شود. در هر مرحله از نصب، دستگاه ممکن است برق را از دست بدهد، فضای دیسک تمام شود، یا با مشکلات دیگری مواجه شود که باعث می شود بررسی نصب کامل نشود. در بهترین حالت ناموفق، برنامه Updater به سرور سیستم اطلاع می دهد که ناموفق بوده است. در بدترین حالت ناموفق، RulesManagerService اصلاً تماسی دریافت نمی کند.
برای رسیدگی به این موضوع، کد سرور سیستم پیگیری میکند که آیا بررسی بهروزرسانی آغاز شده تکمیل شده است یا خیر و آخرین کد نسخه بررسیشده برنامه داده چیست. هنگامی که دستگاه بیکار است و در حال شارژ است، کد سرور سیستم می تواند وضعیت فعلی را بررسی کند. اگر بررسی بهروزرسانی ناقص یا نسخه غیرمنتظره برنامه داده را پیدا کند، بهطور خودبهخود بررسی بهروزرسانی را آغاز میکند.
امنیت
وقتی فعال باشد، کد RulesManagerService در سرور سیستم چندین بررسی را انجام می دهد تا مطمئن شود که سیستم برای استفاده ایمن است.
- مشکلاتی که نشان دهنده پیکربندی نامناسب تصویر سیستم است، مانع از بوت شدن دستگاه می شود. مثالها شامل پیکربندی بد بهروزرسانی یا برنامه داده یا نبودن برنامه بهروزرسانی یا داده در
/system/priv-app
است. - مشکلاتی که نشان می دهد یک برنامه داده بد نصب شده است، از بوت شدن دستگاه جلوگیری نمی کند، اما از شروع بررسی به روز رسانی جلوگیری می کند. مثالها شامل فقدان مجوزهای سیستم مورد نیاز است یا برنامه Data یک ContentProvider را در URI مورد انتظار نمایش نمیدهد.
مجوزهای فایل برای دایرکتوری /data/misc/zoneinfo
با استفاده از قوانین SELinux اعمال می شود. مانند هر APK دیگری، برنامه Data باید با همان کلیدی که برای امضای نسخه /system/priv-app
استفاده میشود، امضا شود. انتظار می رود که برنامه Data دارای یک نام و کلید بسته اختصاصی و OEM باشد.
یکپارچه سازی به روز رسانی منطقه زمانی
برای فعال کردن ویژگی به روز رسانی منطقه زمانی، OEM ها معمولا:
- برنامه داده خود را ایجاد کنید.
- برنامه های Updater و Data را در ساخت تصویر سیستم قرار دهید.
- سرور سیستم را برای فعال کردن RulesManagerService پیکربندی کنید.
مهیا کردن
قبل از شروع، OEM ها باید خط مشی، تضمین کیفیت و ملاحظات امنیتی زیر را بررسی کنند:
- یک کلید امضای اختصاصی برای برنامه Data آنها ایجاد کنید.
- یک استراتژی انتشار و نسخهسازی برای بهروزرسانیهای منطقه زمانی ایجاد کنید تا بفهمید کدام دستگاهها قرار است بهروزرسانی شوند و چگونه میتوانند اطمینان حاصل کنند که بهروزرسانیها فقط روی دستگاههایی که به آنها نیاز دارند نصب میشوند. به عنوان مثال، OEM ها ممکن است بخواهند یک برنامه داده واحد برای همه دستگاه های خود داشته باشند یا ممکن است برنامه های داده متفاوتی را برای دستگاه های مختلف داشته باشند. این تصمیم بر انتخاب نام بسته، احتمالاً کدهای نسخه استفاده شده و استراتژی QA تأثیر می گذارد.
- بدانید که آیا آنها میخواهند از دادههای منطقه زمانی Android موجود در AOSP استفاده کنند یا خودشان ایجاد کنند.
ایجاد اپلیکیشن دیتا
AOSP شامل تمام کد منبع و قوانین ساخت مورد نیاز برای ایجاد یک برنامه داده در packages/apps/TimeZoneData
، با دستورالعملها و نمونههای الگو برای AndroidManifest.xml
و سایر فایلهای موجود در packages/apps/TimeZoneData/oem_template
است. الگوهای نمونه شامل هم یک هدف ساخت برای APK برنامه داده واقعی و هم اهداف اضافی برای ایجاد نسخههای آزمایشی برنامه داده است.
OEM ها می توانند برنامه Data را با نماد، نام، ترجمه ها و سایر جزئیات شخصی سازی کنند. با این حال، از آنجایی که برنامه Data نمی تواند راه اندازی شود، نماد فقط در صفحه تنظیمات > برنامه ها ظاهر می شود.
برنامه Data قرار است با ساخت تاپاس ساخته شود که فایلهای APK مناسب برای افزودن به تصویر سیستم (برای نسخه اولیه) و امضا و توزیع از طریق فروشگاه برنامه (برای بهروزرسانیهای بعدی) تولید میکند. برای جزئیات بیشتر در مورد استفاده از tapas، به ساخت برنامه داده با استفاده از tapas مراجعه کنید.
OEM ها باید برنامه داده را که از پیش ساخته شده در تصویر سیستم یک دستگاه در /system/priv-app
کنند. برای گنجاندن فایلهای APK از پیش ساخته شده (تولید شده توسط فرآیند ساخت تاپاس) در تصویر سیستم، OEMها میتوانند فایلهای نمونه را در packages/apps/TimeZoneData/oem_template/data_app_prebuilt
. الگوهای نمونه همچنین شامل اهداف ساخت برای گنجاندن نسخههای آزمایشی برنامه Data در مجموعههای آزمایشی هستند.
از جمله برنامه های Updater و Data در تصویر سیستم
OEMها باید APKهای بهروزرسانیکننده و برنامه داده را در فهرست /system/priv-app
تصویر سیستم قرار دهند. برای انجام این کار، ساخت تصویر سیستم باید به صراحت شامل برنامه Updater و اهداف از پیش ساخته شده برنامه Data باشد.
برنامه Updater باید با کلید پلتفرم امضا شده و مانند سایر برنامه های سیستمی گنجانده شود. هدف در packages/apps/TimeZoneUpdater
به عنوان TimeZoneUpdater
تعریف شده است. گنجاندن برنامه Data مختص OEM است و به نام هدف انتخاب شده برای پیش ساخت بستگی دارد.
پیکربندی سرور سیستم
برای فعال کردن بهروزرسانیهای منطقه زمانی، OEMها میتوانند سرور سیستم را با نادیده گرفتن ویژگیهای پیکربندی تعریفشده در frameworks/base/core/res/res/values/config.xml
پیکربندی کنند.
ویژگی | شرح | لغو مورد نیاز است؟ |
---|---|---|
config_enableUpdateableTimeZoneRules | برای فعال کردن RulesManagerService باید روی true تنظیم شود. | آره |
config_timeZoneRulesUpdateTrackingEnabled | باید روی true تنظیم شود تا سیستم به تغییرات برنامه Data گوش دهد. | آره |
config_timeZoneRulesDataPackage | نام بسته برنامه داده خاص OEM. | آره |
config_timeZoneRulesUpdaterPackage | برای برنامه پیشفرض Updater پیکربندی شده است. تغییر را فقط در صورت ارائه یک اجرای برنامه Updater متفاوت انجام دهید. | خیر |
config_timeZoneRulesCheckTimeMillisAllowed | زمان مجاز بین شروع بررسی بهروزرسانی توسط RulesManagerService و پاسخ نصب، حذف یا انجام هیچ کاری. پس از این مرحله، ممکن است یک محرک قابلیت اطمینان خود به خود ایجاد شود. | خیر |
config_timeZoneRulesCheckRetryCount | تعداد بررسیهای بهروزرسانی ناموفق متوالی قبل از اینکه RulesManagerService تولید بیشتر را متوقف کند مجاز است. | خیر |
لغو تنظیمات باید در تصویر سیستم باشد (نه فروشنده یا موارد دیگر) زیرا یک دستگاه پیکربندی نادرست می تواند از بوت شدن خودداری کند. اگر لغو تنظیمات در تصویر فروشنده بود، بهروزرسانی به یک تصویر سیستمی بدون برنامه داده (یا با نامهای بسته برنامه برنامه/بهروزرسانی مختلف داده) یک پیکربندی نادرست در نظر گرفته میشود.
تست xTS
xTS به هر مجموعه آزمایشی خاص OEM اشاره دارد که شبیه مجموعههای تست استاندارد Android با استفاده از Tradefed (مانند CTS و VTS) است. OEM هایی که چنین مجموعه های آزمایشی دارند می توانند آزمایش های به روز رسانی منطقه زمانی Android ارائه شده در مکان های زیر را اضافه کنند:
-
packages/apps/TimeZoneData/testing/xts
شامل کدهای مورد نیاز برای تست عملکردی خودکار است. -
packages/apps/TimeZoneData/oem_template/xts
شامل یک ساختار فهرست نمونه برای گنجاندن آزمایشها در مجموعه xTS مانند Tradefed است. مانند سایر فهرست های قالب، انتظار می رود OEM ها کپی کرده و مطابق با نیاز خود سفارشی کنند. -
packages/apps/TimeZoneData/oem_template/data_app_prebuilt
شامل پیکربندی زمان ساخت برای شامل کردن فایلهای APK آزمایشی از پیش ساخته شده مورد نیاز آزمایش است.
ایجاد به روز رسانی منطقه زمانی
هنگامی که IANA مجموعه جدیدی از قوانین منطقه زمانی را منتشر می کند، تیم کتابخانه های هسته اندروید وصله هایی را برای به روز رسانی نسخه ها در AOSP ایجاد می کند. OEM هایی که از سیستم اندروید موجود و فایل های توزیع استفاده می کنند، می توانند این تعهدات را دریافت کنند، از آنها برای ایجاد نسخه جدیدی از برنامه Data خود استفاده کنند، سپس نسخه جدید را برای به روز رسانی دستگاه های خود در حال تولید منتشر کنند.
از آنجایی که برنامههای داده حاوی فایلهای توزیعی هستند که نزدیک به نسخههای Android مرتبط هستند، OEMها باید نسخه جدیدی از برنامه Data را برای هر نسخه Android پشتیبانیشدهای که یک OEM میخواهد بهروزرسانی کند، ایجاد کنند. به عنوان مثال، اگر یک OEM بخواهد بهروزرسانیهایی را برای دستگاههای اندروید 8.1، 9 و 10 ارائه کند، باید این فرآیند را سه بار تکمیل کند.
مرحله 1: به روز رسانی سیستم/منطقه زمانی و فایل های داده خارجی/icu
در این مرحله، OEMها تعهدات Android را برای system/timezone
و external/icu
از شاخههای انتشار -dev در AOSP ذخیره میکنند و آن تعهدات را در کپی کد منبع Android خود اعمال میکنند.
پچ AOSP system/zone حاوی فایل های به روز شده در system/timezone/input_data
و system/timezone/output_data
است. OEM هایی که نیاز به اصلاحات محلی اضافی دارند می توانند فایل های ورودی را تغییر دهند سپس از فایل ها در system/timezone/input_data
و external/icu
برای تولید فایل ها در output_data
استفاده کنند.
مهمترین فایل system/timezone/output_data/distro/distro.zip
است که بهطور خودکار هنگام ساخت APK برنامه داده اضافه میشود.
مرحله 2: به روز رسانی کد نسخه برنامه Data
در این مرحله، OEM ها کد نسخه برنامه Data را به روز می کنند. بیلد بهطور خودکار distro.zip
را انتخاب میکند، اما نسخه جدید برنامه Data باید کد نسخه جدیدی داشته باشد تا بهعنوان جدید شناخته شود و برای جایگزینی یک برنامه داده از پیش بارگذاریشده یا یک برنامه داده نصبشده در دستگاه با بهروزرسانی قبلی استفاده شود.
هنگام ساختن برنامه Data با استفاده از فایلهای کپیشده از package/apps/TimeZoneData/oem_template/data_app
، میتوانید کد نسخه/نام نسخه اعمال شده روی APK را در Android.mk
بیابید:
TIME_ZONE_DATA_APP_VERSION_CODE := TIME_ZONE_DATA_APP_VERSION_NAME :=
ورودی های مشابه را می توان در testing/Android.mk
یافت (البته، کدهای نسخه آزمایشی باید بالاتر از نسخه تصویر سیستم باشند). برای جزئیات، به مثال طرح استراتژی کد نسخه مراجعه کنید. اگر از طرح مثال یا طرحی مشابه استفاده شود، کدهای نسخه آزمایشی نیازی به به روز رسانی ندارند زیرا تضمین می شود که بالاتر از کدهای نسخه واقعی هستند.
مرحله 3: بازسازی، امضا، آزمایش و انتشار
در این مرحله، OEM ها APK را با استفاده از tapas بازسازی می کنند، APK تولید شده را امضا می کنند، سپس APK را آزمایش و آزاد می کنند:
- برای دستگاههای منتشرنشده (یا هنگام آمادهسازی بهروزرسانی سیستم برای دستگاه منتشرشده)، فایلهای APK جدید را در فهرست راهنمای از پیش ساخته شده برنامه «داده» ارسال کنید تا مطمئن شوید که تصویر سیستم و آزمایشهای xTS دارای آخرین APK هستند. OEM ها باید آزمایش کنند که فایل جدید به درستی کار می کند (یعنی CTS و هر تست خودکار و دستی خاص OEM را گذرانده است).
- برای دستگاههای منتشر شده که دیگر بهروزرسانیهای سیستم را دریافت نمیکنند، APK امضاشده ممکن است فقط از طریق فروشگاه برنامه منتشر شود.
OEM ها مسئول تضمین کیفیت و آزمایش برنامه داده به روز شده در دستگاه های خود قبل از انتشار هستند.
استراتژی کد نسخه برنامه داده
برنامه Data باید یک استراتژی نسخهسازی مناسب داشته باشد تا مطمئن شود دستگاهها فایلهای APK صحیح را دریافت میکنند. به عنوان مثال، اگر بهروزرسانی سیستمی دریافت میشود که حاوی یک APK قدیمیتر از APK دانلود شده از فروشگاه برنامه است، نسخه فروشگاه برنامه باید حفظ شود.
کد نسخه APK باید شامل اطلاعات زیر باشد:
- نسخه با فرمت Distro (ماژور + جزئی)
- یک شماره نسخه در حال افزایش (مادر).
در حال حاضر، سطح API پلت فرم به شدت با نسخه فرمت توزیع مرتبط است زیرا هر سطح API معمولاً با نسخه جدیدی از ICU مرتبط است (که باعث ناسازگاری فایل های توزیع می شود). در آینده، Android ممکن است این مورد را تغییر دهد تا یک فایل توزیع بتواند در چندین نسخه پلتفرم اندروید کار کند (و سطح API در طرح کد نسخه برنامه داده استفاده نمیشود).
استراتژی کد نسخه نمونه
این نمونه طرح شماره نسخه سازی تضمین می کند که نسخه های با فرمت توزیع بالاتر جایگزین نسخه های با فرمت توزیع پایین تر می شوند. AndroidManifest.xml
از android:minSdkVersion
استفاده میکند تا اطمینان حاصل کند که دستگاههای قدیمی نسخههایی با فرمت توزیع بالاتر از توانشان را دریافت نمیکنند.

مثال | ارزش | هدف |
---|---|---|
Y | رزرو شده است | به طرحهای جایگزین/آزمایش APK در آینده اجازه میدهد. در ابتدا (به طور ضمنی) 0 است. از آنجایی که نوع زیربنایی یک نوع int 32 بیتی امضا شده است، این طرح تا دو تجدید نظر در طرح شماره گذاری آینده را پشتیبانی می کند. |
01 | نسخه اصلی | نسخه اصلی 3 رقمی اعشاری را ردیابی می کند. فرمت توزیع از 3 رقم اعشاری پشتیبانی می کند اما در اینجا فقط از 2 رقم استفاده می شود. با توجه به افزایش عمده مورد انتظار در هر سطح API، بعید است به 100 برسد. نسخه اصلی 1 معادل API سطح 27 است. |
1 | نسخه فرمت مینور | نسخه فرمت جزئی 3 رقمی اعشاری را ردیابی می کند. فرمت توزیع از 3 رقم اعشاری پشتیبانی می کند اما در اینجا فقط از 1 رقم استفاده می شود. بعید است به 10 برسد. |
ایکس | رزرو شده است | برای نسخه های تولیدی 0 است (و ممکن است برای APK های آزمایشی متفاوت باشد). |
ZZZZZ | شماره نسخه مات | اعداد اعشاری در صورت تقاضا تخصیص داده می شود. شامل شکاف هایی است تا در صورت لزوم به روزرسانی های بینابینی انجام شود. |
اگر به جای اعشاری از دودویی استفاده می شد، این طرح می توانست بهتر بسته بندی شود، اما این طرح دارای مزیت قابل خواندن برای انسان است. اگر محدوده اعداد کامل تمام شود، نام بسته برنامه Data می تواند تغییر کند.
نام نسخه نمایشی از جزئیات قابل خواندن توسط انسان است، به عنوان مثال: major=001,minor=001,iana=2017a, revision=1,respin=2
. نمونه هایی در جدول زیر نشان داده شده است.
# | کد نسخه | minSdkVersion | {نسخه فرمت اصلی}،{نسخه فرمت جزئی}،{نسخه قوانین ایانا}،{نسخه} |
---|---|---|---|
1 | 11000010 | O-MR1 | major=001,minor=001,iana=2017a, revision=1 |
2 | 21000010 | پ | major=002,minor=001,iana=2017a, revision=1 |
3 | 11000020 | O-MR1 | major=001,minor=001,iana=2017a, revision=2 |
4 | 11000030 | O-MR1 | major=001,minor=001,iana=2017b, revision=1 |
5 | 21000020 | پ | major=002,minor=001,iana=2017b, revision=1 |
6 | 11000040 | O-MR1 | major=001,minor=001,iana=2018a, revision=1 |
7 | 21000030 | پ | major=002,minor=001,iana=2018a, revision=1 |
8 | 1123456789 | - | - |
9 | 11000021 | O-MR1 | major=001,minor=001,iana=2017a, revision=2,respin=2 |
- مثالهای 1 و 2 دو نسخه APK را برای همان نسخه IANA 2017a با نسخههای اصلی متفاوت نشان میدهند. 2 از نظر عددی بالاتر از 1 است، که برای اطمینان از اینکه دستگاه های جدیدتر نسخه های با فرمت بالاتر را دریافت می کنند، لازم است. minSdkVersion تضمین می کند که نسخه P برای دستگاه های O عرضه نمی شود.
- مثال 3 یک بازبینی/اصلاح برای 1 است و از نظر عددی بالاتر از 1 است.
- مثالهای 4 و 5 نسخههای 2017b را برای O-MR1 و P نشان میدهند. از نظر عددی بالاتر، آنها جایگزین نسخههای قبلی IANA/نسخههای اندروید نسخههای قبلی مربوطه خود میشوند.
- مثالهای 6 و 7 نسخههای 2018a را برای O-MR1 و P نشان میدهند.
- مثال 8 استفاده از Y را برای جایگزینی کامل طرح Y=0 نشان می دهد.
- مثال 9 استفاده از فاصله بین 3 و 4 را برای چرخش مجدد apk نشان می دهد.
از آنجایی که هر دستگاه با یک APK پیشفرض و با نسخه مناسب در تصویر سیستم ارسال میشود، هیچ خطری برای نصب نسخه O-MR1 روی دستگاه P وجود ندارد، زیرا شماره نسخه آن کمتر از نسخه تصویر سیستم P است. دستگاهی با نسخه O-MR1 نصب شده در /data
که سپس بهروزرسانی سیستم را به P دریافت میکند، از نسخه /system
در اولویت نسخه O-MR1 در /data
میکند، زیرا نسخه P همیشه بالاتر از هر برنامه در نظر گرفته شده برای O- است. MR1.
ساخت اپلیکیشن Data با استفاده از تاپاس
OEM ها مسئول مدیریت بیشتر جنبه های برنامه داده منطقه زمانی و پیکربندی صحیح تصویر سیستم هستند. برنامه Data قرار است با ساخت تاپاس ساخته شود که فایلهای APK مناسب برای افزودن به تصویر سیستم (برای نسخه اولیه) و امضا و توزیع از طریق فروشگاه برنامه (برای بهروزرسانیهای بعدی) تولید میکند.
Tapas یک نسخه باریک از سیستم ساخت اندروید است که از درخت منبع کاهش یافته برای تولید نسخه های قابل توزیع برنامه ها استفاده می کند. OEM هایی که با سیستم ساخت عادی اندروید آشنا هستند باید فایل های ساخت را از ساخت پلتفرم معمولی اندروید تشخیص دهند.
ایجاد مانیفست
درخت منبع کاهش یافته معمولاً با یک فایل مانیفست سفارشی به دست می آید که فقط به پروژه های Git مورد نیاز سیستم ساخت و برای ساخت برنامه اشاره دارد. پس از پیروی از دستورالعملهای ایجاد یک برنامه داده ، OEMها باید حداقل دو پروژه Git خاص OEM با استفاده از فایلهای الگو در packages/apps/TimeZoneData/oem_template
:
- پروژه One Git حاوی فایلهای برنامه مانند مانیفست و فایلهای ساخت مورد نیاز برای ایجاد فایل APK برنامه است (به عنوان مثال
vendor/ oem /apps/TimeZoneData
). این پروژه همچنین حاوی قوانین ساخت برای فایلهای APK آزمایشی است که میتوانند توسط آزمایشهای xTS استفاده شوند. - پروژه One Git حاوی فایلهای APK امضا شدهای است که توسط ساخت برنامه برای گنجاندن در ساخت تصویر سیستم و آزمایشهای xTS تولید شدهاند.
ساخت اپلیکیشن از چندین پروژه Git دیگر استفاده می کند که با پلتفرم بیلد به اشتراک گذاشته شده اند یا شامل کتابخانه های کد مستقل از OEM هستند.
قطعه مانیفست زیر حاوی حداقل مجموعه ای از پروژه های Git است که برای پشتیبانی از ساخت O-MR1 برنامه داده منطقه زمانی لازم است. OEM ها باید پروژه های Git خاص OEM خود را (که معمولاً شامل پروژه ای است که حاوی گواهی امضا است) را به این مانیفست اضافه کنند و ممکن است شاخه های مختلفی را بر اساس آن پیکربندی کنند.
<!-- Tapas Build --> <project path="build" name="platform/build"> <copyfile src="core/root.mk" dest="Makefile" /> </project> <project path="prebuilts/build-tools" name="platform/prebuilts/build-tools" clone-depth="1" /> <project path="prebuilts/go/linux-x86" name="platform/prebuilts/go/linux-x86" clone-depth="1" /> <project path="build/blueprint" name="platform/build/blueprint" /> <project path="build/kati" name="platform/build/kati" /> <project path="build/soong" name="platform/build/soong"> <linkfile src="root.bp" dest="Android.bp" /> <linkfile src="bootstrap.bash" dest="bootstrap.bash" /> </project> <!-- SDK for system / public API stubs --> <project path="prebuilts/sdk" name="platform/prebuilts/sdk" clone-depth="1" /> <!-- App source --> <project path="system/timezone" name="platform/system/timezone" /> <project path="packages/apps/TimeZoneData" name="platform/packages/apps/TimeZoneData" /> <!-- Enable repohooks --> <project path="tools/repohooks" name="platform/tools/repohooks" revision="master" clone_depth="1" /> <repo-hooks in-project="platform/tools/repohooks" enabled-list="pre-upload" />
اجرای تاپاس بیلد
پس از ایجاد درخت منبع، بیلد tapas را با استفاده از دستورات زیر فراخوانی کنید:
source build/envsetup.sh
tapas
make -j30 showcommands dist TARGET_BUILD_APPS='TimeZoneData TimeZoneData_test1 TimeZoneData_test2' TARGET_BUILD_VARIANT=userdebug
یک ساخت موفق، فایلهایی را در دایرکتوری out/dist
برای آزمایش تولید میکند. این فایل ها را می توان برای گنجاندن در تصویر سیستم در دایرکتوری از پیش ساخته شده قرار داد و/یا از طریق یک فروشگاه برنامه برای دستگاه های سازگار توزیع کرد.