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

Android 10 مکانیسم به‌روزرسانی داده منطقه زمانی مبتنی بر APK (موجود در Android 8.1 و Android 9) را منسوخ می‌کند و مکانیزم به‌روزرسانی ماژول مبتنی بر APEX را جایگزین آن می‌کند. AOSP 8.1 تا 13 همچنان شامل کد پلتفرم لازم برای 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)

توجه: ویژگی مکانیزم به‌روزرسانی داده منطقه زمانی مبتنی بر APK به طور کامل از اندروید 14 به بعد حذف شده است و در کد منبع یافت نمی‌شود. شرکا باید به طور کامل به ماژول خط اصلی منطقه زمانی مهاجرت کنند.

در Android 8.1 و Android 9، OEM ها می توانند از مکانیزم مبتنی بر APK برای ارسال داده های به روز شده قوانین منطقه زمانی به دستگاه ها بدون نیاز به به روز رسانی سیستم استفاده کنند. این مکانیسم به کاربران امکان می‌دهد به‌روزرسانی‌های به‌موقع را دریافت کنند (در نتیجه طول عمر مفید دستگاه Android را افزایش می‌دهد) و شرکای 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 برمی‌گردند.

فایل های توزیع

فایل‌های Distro .zip حاوی فایل‌های داده‌ای هستند که برای پر کردن دایرکتوری /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 مشاهده می‌کند.
   
   

   شکل 1. به روز رسانی برنامه های داده.

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

   شکل 2. بررسی به روز رسانی ماشه.

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

     شکل 3. به روز رسانی برنامه داده، با فراخوانی RulesManagerService.

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

     شکل 4. به‌روزرسانی‌های برنامه داده، اطلاعاتی درباره توزیع دریافت کنید.

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

   شکل 5. بررسی کامل.

5. راه اندازی مجدد و tzdatacheck. هنگامی که دستگاه بعدی بوت می شود، باینری tzdatacheck هر عملیات مرحله ای را اجرا می کند. باینری tzdatacheck می تواند وظایف زیر را انجام دهد:
   • عملیات مرحله‌ای را با مدیریت ایجاد، جایگزینی و/یا حذف فایل‌های /data/misc/zoneinfo/current قبل از باز شدن سایر اجزای سیستم و شروع به استفاده از فایل‌ها، اجرا کنید.
   • بررسی کنید که فایل‌های موجود در /data برای نسخه پلتفرم کنونی صحیح باشند، که اگر دستگاه به‌تازگی به‌روزرسانی سیستم را دریافت کرده باشد و نسخه قالب توزیع تغییر کرده باشد، ممکن است اینطور نباشد.
   • مطمئن شوید که نسخه قوانین IANA مشابه یا جدیدتر از نسخه موجود در /system باشد. این امر در برابر به‌روزرسانی سیستم که دستگاهی را با داده‌های قوانین منطقه زمانی قدیمی‌تر از آنچه در تصویر /system موجود است، حفظ می‌کند.

قابلیت اطمینان

فرآیند نصب انتها به انتها ناهمزمان است و در سه فرآیند سیستم عامل تقسیم می شود. در هر مرحله از نصب، دستگاه ممکن است برق را از دست بدهد، فضای دیسک تمام شود، یا با مشکلات دیگری مواجه شود که باعث می شود بررسی نصب کامل نشود. در بهترین حالت ناموفق، برنامه Updater به سرور سیستم اطلاع می دهد که ناموفق بوده است. در بدترین حالت ناموفق، سرویس RulesManager هیچ تماسی دریافت نمی کند.

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

امنیت

هنگامی که فعال است، کد RulesManagerService در سرور سیستم چندین بررسی را انجام می دهد تا مطمئن شود که سیستم برای استفاده ایمن است.

• مشکلاتی که نشان دهنده پیکربندی نامناسب تصویر سیستم است، مانع از بوت شدن دستگاه می شود. به عنوان مثال می‌توان به پیکربندی بد به‌روزرسانی یا برنامه داده یا نبودن برنامه Updater یا Data در /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 مراجعه کنید.

توجه: امضای ایمن فایل‌های APK و مدیریت کلید خارج از محدوده این مقاله است.

OEM ها باید برنامه Data را که از پیش ساخته شده در تصویر سیستم یک دستگاه در /system/priv-app نصب کنند. برای گنجاندن APKهای از پیش ساخته شده (تولید شده توسط فرآیند ساخت tapas) در تصویر سیستم، 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 پیکربندی شده است. فقط در صورت ارائه یک اجرای برنامه به روز رسانی متفاوت، تغییر دهید.	خیر
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 آزمایشی از پیش ساخته شده مورد نیاز آزمایش است.

توجه: راه اندازی یک مجموعه آزمایشی خاص OEM خارج از محدوده این مقاله است.

ایجاد به روز رسانی منطقه زمانی

وقتی IANA مجموعه جدیدی از قوانین منطقه زمانی را منتشر می‌کند، تیم کتابخانه‌های هسته Android وصله‌هایی را برای به‌روزرسانی نسخه‌ها در AOSP ایجاد می‌کند. OEM هایی که از سیستم اندروید موجود و فایل های توزیع استفاده می کنند می توانند این تعهدات را دریافت کنند، از آنها برای ایجاد نسخه جدیدی از برنامه Data خود استفاده کنند، سپس نسخه جدید را برای به روز رسانی دستگاه های خود در حال تولید منتشر کنند.

توجه: مراحل زیر نحوه به‌روزرسانی فایل‌های داده پایه را در تصویر /system که هنگام تهیه تصویر کارخانه یا به‌روزرسانی‌های سیستم مورد نیاز است، توضیح نمی‌دهد. این فرآیند همچنین فایل توزیع را برای درج در برنامه Data تولید می کند. برای دستورالعمل‌های مربوط به به‌روزرسانی فایل‌های پلتفرم، به /system/timezone/README.android مراجعه کنید.

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

شکل 6. نمونه استراتژی کد نسخه.

مثال	ارزش	هدف
Y	رزرو شده است	به طرح‌های جایگزین/آزمایش APK در آینده اجازه می‌دهد. در ابتدا (به طور ضمنی) 0 است. از آنجایی که نوع زیربنایی یک نوع int 32 بیتی امضا شده است، این طرح تا دو تجدید نظر در طرح شماره گذاری آینده را پشتیبانی می کند.
01	نسخه اصلی	نسخه اصلی 3 رقمی اعشاری را ردیابی می کند. فرمت توزیع از 3 رقم اعشاری پشتیبانی می کند اما در اینجا فقط از 2 رقم استفاده می شود. با توجه به افزایش عمده مورد انتظار در هر سطح API، بعید است به 100 برسد. نسخه اصلی 1 معادل سطح API 27 است.
1	نسخه فرمت مینور	نسخه فرمت جزئی 3 رقمی اعشاری را ردیابی می کند. فرمت توزیع از 3 رقم اعشاری پشتیبانی می کند اما در اینجا فقط از 1 رقم استفاده می شود. بعید است به 10 برسد.
X	رزرو شده است	برای نسخه‌های تولیدی ۰ است (و ممکن است برای فایل‌های 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="main"
        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 برای آزمایش تولید می‌کند. این فایل ها را می توان در دایرکتوری از پیش ساخته شده برای گنجاندن در تصویر سیستم قرار داد و/یا از طریق یک فروشگاه برنامه برای دستگاه های سازگار توزیع کرد.