قوانین منطقه زمانی

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 را پشتیبانی می‌کند و داده‌هایی را استاندارد می‌کند که می‌توانند اغلب به دلایل مذهبی، سیاسی و ژئوپلیتیک تغییر کنند.

به روز رسانی ها از فرآیند زیر استفاده می کنند:

1. IANA یک به روز رسانی برای پایگاه داده منطقه زمانی منتشر می کند در پاسخ به تغییر یک یا چند دولت در قوانین منطقه زمانی در کشورهای خود، به روز رسانی را منتشر می کند.
2. Google یا شریک Android یک به‌روزرسانی ماژول داده منطقه زمانی (فایل APEX) حاوی مناطق زمانی به‌روزرسانی شده را آماده می‌کند.
3. دستگاه کاربر نهایی به‌روزرسانی را دانلود می‌کند، راه‌اندازی مجدد می‌شود، سپس تغییرات را اعمال می‌کند و پس از آن، داده‌های منطقه زمانی دستگاه حاوی داده‌های منطقه زمانی جدید از به‌روزرسانی است.

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

به‌روزرسانی‌های منطقه زمانی (اندروید 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

فرآیند نصب توزیع شامل مراحل زیر است:

1. برنامه داده از طریق بارگیری فروشگاه برنامه یا بارگذاری جانبی به روز می شود. فرآیند سرور سیستم (از طریق کلاس‌های timezone.RulesManagerServer/timezone.PackageTracker ) تغییرات را در نام بسته برنامه داده پیکربندی‌شده، ویژه OEM مشاهده می‌کند.
   
   

   

2. فرآیند سرور سیستم با پخش یک هدف هدفمند با یک نشانه منحصر به فرد و یکبار مصرف در برنامه Updater، یک بررسی به روز رسانی را آغاز می کند. سرور سیستم آخرین توکنی را که تولید کرده است پیگیری می‌کند تا بتواند تعیین کند آخرین بررسی که راه‌اندازی کرده چه زمانی تکمیل شده است. هر توکن دیگری نادیده گرفته می شود.
   
   

   

3. در طول بررسی به‌روزرسانی ، برنامه Updater وظایف زیر را انجام می‌دهد:
   • با فراخوانی RulesManagerService وضعیت فعلی دستگاه را پرس و جو می کند.
     
     

     

   • برنامه Data را با پرس و جو از یک URL کاملاً تعریف شده ContentProvider و مشخصات ستون جستجو می کند تا اطلاعاتی در مورد توزیع دریافت کند.
     
     

     

4. اپلیکیشن Updater بر اساس اطلاعاتی که دارد، اقدام مناسب را انجام می دهد. اقدامات موجود عبارتند از:
   • درخواست نصب کنید داده های توزیع از برنامه Data خوانده می شود و به RulesManagerService در سرور سیستم ارسال می شود. RulesManagerService مجدداً تأیید می‌کند که نسخه و محتوای قالب توزیع برای دستگاه مناسب است و نصب را مرحله‌بندی می‌کند.
   • درخواست حذف نصب کنید (این نادر است). برای مثال، اگر APK به‌روزرسانی‌شده در /data در حال غیرفعال کردن یا حذف نصب باشد و دستگاه به نسخه موجود در /system .
   • هیچ کاری نکن زمانی رخ می دهد که توزیع برنامه داده نامعتبر باشد.
   در همه موارد، برنامه Updater با علامت چک با RulesManagerService تماس می گیرد تا سرور سیستم بداند که بررسی کامل و موفقیت آمیز است.
   
   

   

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

config_timeZoneRulesUpdateTrackingEnabled

config_timeZoneRulesDataPackage

config_timeZoneRulesUpdaterPackage

config_timeZoneRulesCheckTimeMillisAllowed

config_timeZoneRulesCheckRetryCount

لغو تنظیمات باید در تصویر سیستم باشد (نه فروشنده یا موارد دیگر) زیرا یک دستگاه پیکربندی نادرست می تواند از بوت شدن خودداری کند. اگر لغو تنظیمات در تصویر فروشنده بود، به‌روزرسانی به یک تصویر سیستمی بدون برنامه داده (یا با نام‌های بسته برنامه برنامه/به‌روزرسانی مختلف داده) یک پیکربندی نادرست در نظر گرفته می‌شود.

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

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

نام نسخه نمایشی از جزئیات قابل خواندن توسط انسان است، به عنوان مثال: major=001,minor=001,iana=2017a, revision=1,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 برای آزمایش تولید می‌کند. این فایل ها را می توان برای گنجاندن در تصویر سیستم در دایرکتوری از پیش ساخته شده قرار داد و/یا از طریق یک فروشگاه برنامه برای دستگاه های سازگار توزیع کرد.