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

‫Android 10 سازوکار به‌روزرسانی داده‌های منطقه زمانی مبتنی بر APK (دردسترس در Android 8.1 و Android 9) را منسوخ می‌کند و آن را با سازوکار به‌روزرسانی واحد مبتنی بر APEX جایگزین می‌کند. نسخه‌های AOSP از ۸.۱ تا ۱۳ همچنان شامل کد پلاتفرم لازم برای فعال کردن به‌روزرسانی‌های مبتنی بر APK توسط تولیدکنندگان تجهیزات اصلی است، بنابراین دستگاه‌هایی که به Android 10 ارتقا می‌یابند همچنان می‌توانند به‌روزرسانی‌های داده‌های منطقه زمانی ارائه‌شده توسط شریک را ازطریق APK دریافت کنند. بااین‌حال، نباید از سازوکار به‌روزرسانی APK در دستگاه تولیدی که به‌روزرسانی‌های واحد را نیز دریافت می‌کند استفاده شود، زیرا به‌روزرسانی مبتنی بر APK جایگزین به‌روزرسانی مبتنی بر APEX می‌شود (یعنی دستگاهی که به‌روزرسانی APK دریافت کرده است به‌روزرسانی‌های مبتنی بر APEX را نادیده می‌گیرد).

به‌روزرسانی‌های منطقه زمانی (Android 10 و بالاتر)

واحد «داده‌های منطقه زمانی» که در Android 10 و نسخه‌های بالاتر پشتیبانی می‌شود، ساعت تابستانی (DST) و مناطق زمانی را در دستگاه‌های Android به‌روزرسانی می‌کند و داده‌هایی را که ممکن است به‌دلایل مذهبی، سیاسی، و ژئوپلیتیک به‌طور مکرر تغییر کنند استانداردسازی می‌کند.

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

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

برای جزئیات مربوط به ماژول‌ها، اجزای سیستم مدولار را ببینید.

یادداشت‌های منسوخ شدن

‫Android ارائه وصله‌های منطقه زمانی Android 10 را در اوت ۲۰۲۶ متوقف کرد و TZDB 2026c آخرین وصله بود. «تولیدکنندگان تجهیزات اصلی» این گزینه را دارند که پشتیبانی از Android 10 را ادامه دهند.

به‌روزرسانی‌های منطقه زمانی (Android 8.1 تا 9)

توجه: ویژگی سازوکار به‌روزرسانی داده‌های منطقه زمانی مبتنی بر APK از Android 14 به‌بعد کاملاً برداشته شده است و در کد منبع وجود ندارد. شرکا باید به‌طور کامل به منطقه زمانی واحد Mainline منتقل شوند.

در Android 8.1 و Android 9، سازندگان اصلی محصول می‌توانند از سازوکار مبتنی بر APK برای ارسال داده‌های به‌روزشده قوانین منطقه زمانی به دستگاه‌ها بدون نیاز به به‌روزرسانی سیستم استفاده کنند. این سازوکار به کاربران امکان می‌دهد به‌روزرسانی‌ها را به‌موقع دریافت کنند (و درنتیجه عمر مفید دستگاه Android را افزایش می‌دهد) و به شرکای Android امکان می‌دهد به‌روزرسانی‌های منطقه زمانی را مستقل از به‌روزرسانی‌های تصویر سیستم آزمایش کنند.

تیم کتابخانه‌های اصلی Android فایل‌های داده لازم را برای به‌روزرسانی قوانین منطقه زمانی در دستگاه Android ارائه می‌دهد. سازندگان تجهیزات اصلی می‌توانند هنگام ایجاد به‌روزرسانی‌های منطقه زمانی برای دستگاه‌هایشان، از این فایل‌های داده استفاده کنند یا درصورت تمایل فایل‌های داده خودشان را ایجاد کنند. در همه موارد، سازندگان تجهیزات اصلی کنترل تضمین کیفیت/آزمایش، زمان‌بندی، و راه‌اندازی به‌روزرسانی‌های قانون منطقه زمانی را برای دستگاه‌های پشتیبانی‌شده خود حفظ می‌کنند.

کد منبع و داده‌های منطقه زمانی Android

همه دستگاه‌های Android خام، حتی آن‌هایی که از این ویژگی استفاده نمی‌کنند، به داده‌های قوانین منطقه زمانی نیاز دارند و باید با مجموعه پیش‌فرضی از داده‌های قوانین منطقه زمانی در پارتیشن /system عرضه شوند. سپس کد از کتابخانه‌های زیر در درخت منبع Android از این داده‌ها استفاده می‌کند:

• کد مدیریت‌شده از libcore/ (برای مثال، java.util.TimeZone) از tzdata و tzlookup.xml فایل استفاده می‌کند.
• کد کتابخانه بومی در bionic/ (برای مثال، برای فراخوانی‌های سیستم localtime 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

فایل‌های Distro .zip حاوی فایل‌های داده‌ای هستند که برای پر کردن فهرست راهنمای /data/misc/zoneinfo/current لازم است. فایل‌های توزیع همچنین حاوی فراداده‌هایی هستند که به دستگاه‌ها امکان می‌دهد مشکلات نسخه‌بندی را تشخیص دهند.

قالب فایل توزیع به نسخه Android وابسته است زیرا محتوا با نسخه ICU، الزامات پلاتفرم Android، و دیگر تغییرات نسخه تغییر می‌کند. ‫Android برای نسخه‌های پخش پشتیبانی‌شده Android برای هر به‌روزرسانی IANA (علاوه‌بر به‌روزرسانی فایل‌های سیستم پلاتفرم) فایل‌های توزیع ارائه می‌دهد. برای به‌روز نگه داشتن دستگاه‌هایشان، تولیدکنندگان تجهیزات اصلی می‌توانند از این فایل‌های توزیع استفاده کنند یا بااستفاده از درخت منبع Android (که حاوی دستورگان‌ها و فایل‌های موردنیاز برای تولید فایل‌های توزیع است) فایل‌های توزیع خودشان را ایجاد کنند.

عناصر به‌روزرسانی منطقه زمانی

به‌روزرسانی قوانین منطقه زمانی شامل انتقال فایل‌های توزیع به دستگاه و نصب ایمن فایل‌های موجود در آن است. انتقال و نصب به موارد زیر نیاز دارد:

• عملکرد سرویس پلاتفرم (timezone.RulesManagerService)، که به‌طور پیش‌فرض غیرفعال است. سازندگان اصلی محصول باید این عملکرد را ازطریق پیکربندی فعال کنند. ‫RulesManagerService در فرایند سرور سیستم اجرا می‌شود و عملیات به‌روزرسانی منطقه زمانی را با نوشتن در /data/misc/zoneinfo/staged مرحله‌بندی می‌کند. RulesManagerService همچنین می‌تواند عملیات‌های ازپیش آماده‌شده را جایگزین یا حذف کند.
• TimeZoneUpdater، برنامه سیستمی غیرقابل به‌روزرسانی (معروف به برنامه «به‌روزرسان»). سازندگان اصلی محصول باید این برنامه را در تصویر سیستم دستگاه‌هایی که از این ویژگی استفاده می‌کنند بگنجانند.
• سازنده اصلی محصول TimeZoneData، برنامه سیستم قابل‌به‌روزرسانی (یا برنامه داده) که فایل‌های توزیع را به دستگاه منتقل می‌کند و آن‌ها را دردسترس برنامه «به‌روزرسان» قرار می‌دهد. سازندگان اصلی محصول باید این برنامه را در تصویر سیستم دستگاه‌هایی که از این ویژگی استفاده می‌کنند قرار دهند.
• ‫tzdatacheck، یک دودویی زمان راه‌اندازی برای عملکرد صحیح و ایمن به‌روزرسانی‌های منطقه زمانی لازم است.

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

نصب توزیع

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

1. برنامه داده ازطریق بارگیری از فروشگاه برنامه یا بارگیری جانبی به‌روز شده باشد. فرایند سرور سیستم (ازطریق timezone.RulesManagerServer/timezone.PackageTracker کلاس) تغییرات نام بسته برنامه «داده» پیکربندی‌شده و مختص سازنده اصلی محصول را زیر نظر دارد.
   
   

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

2. فرایند سرور سیستم بررسی به‌روزرسانی را راه‌اندازی می‌کند با پخش کردن هدفمندی با یک نشان یک‌بارمصرف منحصربه‌فرد برای «برنامه به‌روزرسان». سرور سیستم جدیدترین نشانی را که تولید کرده است پیگیری می‌کند تا بتواند تعیین کند جدیدترین بررسی‌ای که راه‌اندازی کرده است چه زمانی تکمیل شده است؛ هر نشان دیگری نادیده گرفته می‌شود.
   
   

   شکل ۲. بررسی به‌روزرسانی را راه‌اندازی کنید.

3. درحین بررسی به‌روزرسانی، برنامه «به‌روزرسان» کارهای زیر را انجام می‌دهد:
   • با فراخوانی RulesManagerService، وضعیت فعلی دستگاه را جستجو می‌کند.
     
     

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

   • با پُرسمان کردن نشانی وب ContentProvider و مشخصات ستون به‌خوبی تعریف‌شده، از برنامه «داده‌ها» پُرسمان می‌کند تا اطلاعات مربوط به توزیع را دریافت کند.
     
     

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

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

   شکل ۵. بررسی تکمیل شد.

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

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

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

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

امنیت

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

• مشکلاتی که نشان‌دهنده پیکربندی بد تصویر سیستم هستند مانع راه‌اندازی دستگاه می‌شوند؛ برای مثال، پیکربندی بد برنامه «به‌روزرسان» یا «داده» یا نبود برنامه «به‌روزرسان» یا «داده» در /system/priv-app.
• مشکلاتی که نشان می‌دهد برنامه «داده» بدی نصب شده است مانع از راه‌اندازی دستگاه نمی‌شود، اما مانع از راه‌اندازی بررسی به‌روزرسانی می‌شود؛ برای مثال، نداشتن اجازه‌های سیستم موردنیاز یا اینکه برنامه «داده» ContentProvider را در URI موردانتظار نشان نمی‌دهد.

اجازه‌های فایل برای دایرکتوری‌های /data/misc/zoneinfo بااستفاده از قوانین SELinux اعمال می‌شود. مانند هر APK، برنامه Data باید با همان کلیدی امضا شود که برای امضای نسخه /system/priv-app استفاده شده است. انتظار می‌رود برنامه «داده» نام بسته و کلید اختصاصی و خاص سازنده اصلی محصول داشته باشد.

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

برای فعال کردن ویژگی به‌روزرسانی منطقه زمانی، سازندگان اصلی محصول معمولاً:

• برنامه «داده» خودشان را ایجاد کنند.
• برنامه‌های Updater و Data را در ساخت تصویر سیستم اضافه کنید.
• سرور سیستم را پیکربندی کنید تا RulesManagerService را فعال کند.

آماده‌سازی

تولیدکنندگان تجهیزات اصلی باید قبل‌از شروع، خط‌مشی زیر، تضمین کیفیت، و ملاحظات امنیتی را مرور کنند:

• برای برنامه «داده» خود کلید امضای مختص برنامه اختصاصی ایجاد کنند.
• برای به‌روزرسانی‌های منطقه زمانی، استراتژی انتشار و نسخه‌بندی ایجاد کنید تا متوجه شوید کدام دستگاه‌ها به‌روزرسانی می‌شوند و چگونه می‌توانند مطمئن شوند به‌روزرسانی‌ها فقط روی دستگاه‌هایی که به آن‌ها نیاز دارند نصب می‌شود. برای مثال، تولیدکنندگان تجهیزات اصلی ممکن است بخواهند یک برنامه «داده» برای همه دستگاه‌هایشان داشته باشند یا ممکن است انتخاب کنند برنامه‌های «داده» مختلفی برای دستگاه‌های مختلف داشته باشند. این تصمیم بر انتخاب نام بسته، احتمالاً کدهای نسخه استفاده‌شده، و استراتژی تضمین کیفیت تأثیر می‌گذارد.
• ببینید می‌خواهند از داده‌های منطقه زمانی Android استاندارد از AOSP استفاده کنند یا داده‌های خودشان را ایجاد کنند.

ایجاد برنامه داده

AOSP شامل همه کد منبع و قوانین ساخت موردنیاز برای ایجاد برنامه «داده» در packages/apps/TimeZoneData، با دستورالعمل‌ها و الگوهای نمونه برای AndroidManifest.xml و فایل‌های دیگر واقع در packages/apps/TimeZoneData/oem_template است. الگوهای نمونه شامل هم هدف ساخت برای فایل APK برنامه «داده‌های واقعی» و اهداف اضافی برای ایجاد نسخه‌های آزمایشی برنامه «داده‌ها» است.

تولیدکنندگان تجهیزات اصلی می‌توانند برنامه «داده‌ها» را با نماد، نام، ترجمه‌ها، و جزئیات دیگر خودشان سفارشی‌سازی کنند. بااین‌حال، چون برنامه Data را نمی‌توان راه‌اندازی کرد، نماد آن فقط در صفحه تنظیمات > برنامه‌ها نشان داده می‌شود.

برنامه Data برای ساخته شدن با ساخت tapas درنظر گرفته شده است که فایل‌های APK مناسب برای اضافه شدن به تصویر سیستم (برای انتشار اولیه) را تولید می‌کند و ازطریق فروشگاه برنامه (برای به‌روزرسانی‌های بعدی) امضا و توزیع می‌شود. برای جزئیات بیشتر درباره استفاده از tapas، به ساختن برنامه داده بااستفاده از tapas مراجعه کنید.

تولیدکنندگان اصلی تجهیزات باید برنامه Data را که ازقبل در تصویر سیستم دستگاه ساخته شده است در /system/priv-app نصب کنند. برای گنجاندن APKهای ازپیش‌ساخته‌شده (تولیدشده توسط فرایند ساخت tapas) در تصویر سیستم، سازندگان اصلی محصول می‌توانند فایل‌های نمونه را در packages/apps/TimeZoneData/oem_template/data_app_prebuilt کپی کنند. الگوهای نمونه همچنین شامل هدف‌های ساخت برای افزودن نسخه‌های آزمایشی برنامه «داده‌ها» در مجموعه‌های آزمایشی است.

برنامه‌های «به‌روزرسان» و «داده‌ها» را در تصویر سیستم بگنجانید

سازندگان اصلی محصول باید فایل‌های APK برنامه «به‌روزرسان» و «داده» را در /system/priv-app فهرستگان تصویر سیستم قرار دهند. برای انجام این کار، ساخت تصویر سیستم باید صریحاً شامل اهداف ازپیش‌ساخته‌شده برنامه «به‌روزرسان» و برنامه «داده» باشد.

برنامه «به‌روزرسان» باید با کلید پلاتفرم امضا شود و مانند هر برنامه سیستم دیگری اضافه شود. هدف در packages/apps/TimeZoneUpdater به‌عنوان TimeZoneUpdater تعریف شده است. افزودن برنامه «داده» مختص سازنده تجهیزات اصلی است و به نام هدفی که برای پیش‌ساخت انتخاب شده است بستگی دارد.

پیکربندی سرور سیستم

برای فعال کردن به‌روزرسانی‌های منطقه زمانی، سازندگان اصلی محصول می‌توانند سرور سیستم را با لغو کردن ویژگی‌های پیکربندی تعریف‌شده در 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). تولیدکنندگان تجهیزات اصلی که چنین مجموعه‌های آزمایشی دارند می‌توانند آزمون‌های به‌روزرسانی منطقه زمانی Android را که در مکان‌های زیر ارائه شده است اضافه کنند:

• packages/apps/TimeZoneData/testing/xts شامل کد موردنیاز برای آزمایش کارکردی خودکارشده پایه است.
• ‫packages/apps/TimeZoneData/oem_template/xts حاوی نمونه‌ای از ساختار دایرکتوری برای افزودن آزمایش‌ها به مجموعه xTS شبیه Tradefed است. مانند سایر دایرکتوری‌های الگو، انتظار می‌رود «تولیدکنندگان تجهیزات اصلی» آن‌ها را کپی و مطابق با نیازهایشان سفارشی‌سازی کنند.
• packages/apps/TimeZoneData/oem_template/data_app_prebuilt حاوی پیکربندی زمان ساخت برای افزودن فایل‌های APK آزمایشی پیش‌ساخته موردنیاز آزمایش است.

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

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

چون برنامه‌های «داده» حاوی فایل‌های توزیع هستند که ارتباط نزدیکی با نسخه‌های Android دارند، تولیدکنندگان تجهیزات اصلی باید نسخه جدیدی از برنامه «داده» را برای هر نسخه Android پشتیبانی‌شده‌ای که تولیدکننده تجهیزات اصلی می‌خواهد به‌روز کند ایجاد کنند. برای مثال، اگر یک سازنده تجهیزات اصلی بخواهد برای دستگاه‌های Android نسخه ۸.۱، ۹، و ۱۰ به‌روزرسانی ارائه دهد، باید این فرایند را سه بار تکمیل کند.

مرحله ۱: به‌روزرسانی فایل‌های داده سیستم/منطقه زمانی و خارجی/icu

در این مرحله، OEMها ثبت‌های Android خام را برای system/timezone و external/icu از شاخه‌های توسعه نسخه پخش در AOSP می‌گیرند و آن ثبت‌ها را در نسخه خودشان از کد منبع Android اعمال می‌کنند.

وصله AOSP سیستم/منطقه زمانی حاوی فایل‌های به‌روزشده در system/timezone/input_data و system/timezone/output_data است. تولیدکنندگان تجهیزات اصلی که نیاز به انجام اصلاحات محلی بیشتر دارند می‌توانند فایل‌های ورودی را تغییر دهند و سپس از فایل‌ها در system/timezone/input_data و external/icu برای تولید فایل‌ها در output_data استفاده کنند.

مهم‌ترین فایل system/timezone/output_data/distro/distro.zip است که هنگام ساخت APK برنامه داده به‌طور خودکار اضافه می‌شود.

مرحله ۲: به‌روزرسانی کد نسخه برنامه «داده»

در این مرحله، «تولیدکنندگان تجهیزات اصلی» کد نسخه برنامه «داده» را به‌روزرسانی می‌کنند. ساختار به‌طور خودکار distro.zip را انتخاب می‌کند، اما نسخه جدید برنامه «داده» باید کد نسخه جدیدی داشته باشد تا به‌عنوان نسخه جدید شناخته شود و برای جایگزین کردن برنامه «داده» پیش‌بارگذاری‌شده یا برنامه «داده» نصب‌شده روی دستگاه ازطریق به‌روزرسانی قبلی استفاده شود.

هنگام ساختن برنامه «داده‌ها» بااستفاده از فایل‌های کپی‌شده از 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 پیدا کنید (بااین‌حال، کدهای نسخه آزمایشی باید بالاتر از نسخه تصویر سیستم باشد). برای جزئیات، طرح استراتژی کد نسخه نمونه را ببینید؛ اگر طرح نمونه یا طرحی مشابه استفاده شود، کدهای نسخه آزمایشی نیازی به به‌روزرسانی ندارند زیرا تضمین می‌شود که بالاتر از کدهای نسخه واقعی باشند.

مرحله ۳: بازسازی، امضا، آزمایش، و انتشار

در این مرحله، سازندگان تجهیزات اصلی بااستفاده از tapas فایل APK را بازسازی می‌کنند، فایل APK تولیدشده را امضا می‌کنند، سپس فایل APK را آزمایش و منتشر می‌کنند:

• برای دستگاه‌های منتشرنشده (یا هنگام آماده کردن به‌روزرسانی سیستم برای دستگاه منتشرشده)، فایل‌های APK جدید را در پوشه ازپیش ساخته‌شده برنامه «داده‌ها» ارسال کنید تا مطمئن شوید تصویر سیستم و آزمایش‌های xTS جدیدترین فایل‌های APK را دارند. تولیدکنندگان اصلی سخت‌افزار باید آزمایش کنند که فایل جدید به‌درستی کار می‌کند (یعنی CTS و هرگونه آزمایش خودکار و دستی مختص تولیدکننده اصلی سخت‌افزار را با موفقیت می‌گذراند).
• برای دستگاه‌های عرضه‌شده‌ای که دیگر به‌روزرسانی‌های سیستم را دریافت نمی‌کنند، APK امضاشده ممکن است فقط ازطریق فروشگاه برنامه عرضه شود.

تولیدکنندگان تجهیزات اصلی مسئولیت تضمین کیفیت و آزمایش برنامه «داده» به‌روزشده در دستگاه‌هایشان را قبل‌از انتشار برعهده دارند.

راهبرد کد نسخه برنامه داده

برنامه «داده‌ها» باید استراتژی نسخه‌بندی مناسبی داشته باشد تا مطمئن شود دستگاه‌ها فایل‌های APK صحیح را دریافت می‌کنند. برای مثال، اگر به‌روزرسانی سیستمی دریافت شود که حاوی APK قدیمی‌تر از APK بارگیری‌شده از فروشگاه برنامه باشد، نسخه فروشگاه برنامه باید حفظ شود.

کد نسخه APK باید شامل اطلاعات زیر باشد:

• نسخه قالب توزیع (اصلی + فرعی)
• شماره نسخه افزایشی (مبهم)

درحال‌حاضر، سطح میانای برنامه‌سازی کاربردی پلتفرم با نسخه قالب توزیع همبستگی قوی دارد زیرا هر سطح میانای برنامه‌سازی کاربردی معمولاً با نسخه جدیدی از ICU مرتبط است (که فایل‌های توزیع را ناسازگار می‌کند). در آینده، Android ممکن است این را تغییر دهد تا یک فایل توزیع بتواند در چندین نسخه پلاتفرم Android کار کند (و سطح API در طرح کد نسخه برنامه داده استفاده نمی‌شود).

استراتژی کد نسخه نمونه

این طرح شماره‌گذاری نسخه مثال تضمین می‌کند که نسخه‌های قالب توزیع بالاتر جایگزین نسخه‌های قالب توزیع پایین‌تر شوند. AndroidManifest.xml از android:minSdkVersion استفاده می‌کند تا مطمئن شود دستگاه‌های قدیمی نسخه‌هایی با قالب توزیع بالاتر از آنچه می‌توانند مدیریت کنند دریافت نمی‌کنند.

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

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

نام نسخه نمایشی قابل‌خواندن برای انسان از جزئیات است، برای مثال: major=001,minor=001,iana=2017a, revision=1,respin=2. مثال‌ها در جدول زیر نشان داده شده است.

• مثال‌های ۱ و ۲ دو نسخه APK را برای همان نسخه IANA 2017a با نسخه‌های اصلی قالب متفاوت نشان می‌دهند. ۲ ازنظر عددی بالاتر از ۱ است، که برای اطمینان از اینکه دستگاه‌های جدیدتر نسخه‌های قالب بالاتر را دریافت می‌کنند لازم است. ‫minSdkVersion تضمین می‌کند که نسخه P به دستگاه‌های O ارائه نشود.
• مثال ۳ یک بازبینی/اصلاح برای ۱ است و ازنظر عددی بالاتر از ۱ است.
• مثال‌های ۴ و ۵ نسخه‌های 2017b را برای O-MR1 و P نشان می‌دهند. ازآنجایی‌که این نسخه‌ها ازنظر عددی بالاتر هستند، جایگزین نسخه‌های قبلی IANA/بازبینی‌های Android از پیشینیان مربوطه خود می‌شوند.
• مثال‌های ۶ و ۷ نسخه‌های انتشار 2018a را برای O-MR1 و P نشان می‌دهند.
• مثال ۸ استفاده از Y را برای جایگزینی کامل طرح Y=0 نشان می‌دهد.
• مثال ۹ استفاده از فاصله باقی‌مانده بین ۳ و ۴ را برای بازچرخاندن apk نشان می‌دهد.

ازآنجایی‌که هر دستگاه با یک APK پیش‌فرض و با نسخه مناسب در تصویر سیستم ارسال می‌شود، هیچ خطری برای نصب نسخه O-MR1 روی دستگاه P وجود ندارد زیرا شماره نسخه آن کمتر از نسخه تصویر سیستم P است. دستگاهی که نسخه O-MR1 در آن نصب شده است (/data) و سپس به‌روزرسانی سیستم به P را دریافت می‌کند، از نسخه /system به‌جای نسخه O-MR1 در /data استفاده می‌کند زیرا نسخه P همیشه بالاتر از هر برنامه‌ای است که برای O-MR1 درنظر گرفته شده است.

ساختن برنامه «داده» بااستفاده از tapas

تولیدکنندگان اصلی تجهیزات مسئول مدیریت اکثر جنبه‌های برنامه «داده‌های» منطقه زمانی و پیکربندی صحیح تصویر سیستم هستند. برنامه «داده‌ها» باید با ساختار tapas ساخته شود که فایل‌های APK مناسب برای اضافه شدن به تصویر سیستم (برای انتشار اولیه) تولید می‌کند و ازطریق فروشگاه برنامه (برای به‌روزرسانی‌های بعدی) امضا و توزیع می‌شود.

Tapas نسخه ساده‌شده سیستم ساخت Android است که از درخت منبع کاهش‌یافته برای تولید نسخه‌های توزیع‌پذیر برنامه‌ها استفاده می‌کند. «تولیدکنندگان تجهیزات اصلی» که با سیستم ساخت Android معمولی آشنا هستند باید فایل‌های ساخت را از ساخت پلاتفرم Android معمولی تشخیص دهند.

ایجاد مانیفست

درخت منبع کاهش‌یافته معمولاً با فایل مانیفست سفارشی به‌دست می‌آید که فقط به پروژه‌های Git موردنیاز سیستم ساخت و برای ساختن برنامه ارجاع می‌دهد. پس‌از دنبال کردن دستورالعمل‌های ایجاد برنامه داده، سازندگان اصلی محصول باید حداقل دو پروژه Git مختص سازنده اصلی محصول داشته باشند که بااستفاده از فایل‌های الگو در packages/apps/TimeZoneData/oem_template ایجاد شده است:

• یک پروژه Git حاوی فایل‌های برنامه مانند مانیفست و فایل‌های ساخت موردنیاز برای ایجاد فایل APK برنامه (برای مثال، vendor/oem/apps/TimeZoneData) است. این پروژه همچنین حاوی قوانین ساخت برای فایل‌های APK آزمایشی است که می‌توانند توسط آزمایش‌های xTS استفاده شوند.
• یک پروژه Git حاوی فایل‌های APK امضاشده تولیدشده توسط ساخت برنامه برای گنجاندن در ساخت تصویر سیستم و آزمایش‌های xTS است.

ساختمان برنامه از چندین پروژه Git دیگر که با ساختار پلاتفرم هم‌رسانی می‌شوند یا حاوی کتابخانه‌های کد مستقل از OEM هستند بهره می‌برد.

تکه مانیفست زیر حاوی حداقل مجموعه پروژه‌های Git موردنیاز برای پشتیبانی از ساخت O-MR1 برنامه «داده‌های منطقه زمانی» است. سازندگان تجهیزات اصلی باید پروژه‌های Git مختص سازندگان تجهیزات اصلی خود (که معمولاً شامل پروژه‌ای است که حاوی گواهینامه امضا است) را به این مانیفست اضافه کنند و می‌توانند شاخه‌های مختلف را براساس آن پیکربندی کنند.

   <!-- 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

پس‌از ایجاد درخت منبع، ساخت tapas را بااستفاده از فرمان‌های زیر فراخوانی کنید:

source build/envsetup.sh
tapas
make -j30 showcommands dist TARGET_BUILD_APPS='TimeZoneData TimeZoneData_test1 TimeZoneData_test2'  TARGET_BUILD_VARIANT=userdebug

ساخت موفقیت‌آمیز فایل‌هایی را در دایرکتوری out/dist برای آزمایش تولید می‌کند. این فایل‌ها را می‌توان در فهرست راهنمای پیش‌ساخته‌ها قرار داد تا در تصویر سیستم گنجانده شوند و/یا ازطریق فروشگاه برنامه برای دستگاه‌های سازگار توزیع شوند.