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

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

به‌روزرسانی‌های منطقه زمانی (اندروید ۱۰ و بالاتر)

ماژول داده‌های منطقه زمانی که در اندروید ۱۰ و بالاتر پشتیبانی می‌شود، زمان تابستانی (DST) و مناطق زمانی را در دستگاه‌های اندروید به‌روزرسانی می‌کند و داده‌هایی را که می‌توانند به دلایل مذهبی، سیاسی و ژئوپلیتیکی مرتباً تغییر کنند، استانداردسازی می‌کند.

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

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

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

به‌روزرسانی‌های منطقه زمانی (اندروید ۸.۱ تا ۹)

توجه: ویژگی مکانیسم به‌روزرسانی داده‌های منطقه زمانی مبتنی بر APK از اندروید ۱۴ به بعد کاملاً حذف شده است و در کد منبع یافت نمی‌شود. شرکا باید به‌طور کامل به ماژول Time Zone Mainline مهاجرت کنند.

در اندروید ۸.۱ و اندروید ۹، تولیدکنندگان اصلی تجهیزات (OEM) می‌توانند از یک مکانیزم مبتنی بر APK برای ارسال داده‌های به‌روز شده قوانین منطقه زمانی به دستگاه‌ها بدون نیاز به به‌روزرسانی سیستم استفاده کنند. این مکانیزم کاربران را قادر می‌سازد تا به‌روزرسانی‌های به‌موقع را دریافت کنند (و در نتیجه طول عمر مفید یک دستگاه اندرویدی را افزایش دهند) و شرکای اندروید را قادر می‌سازد تا به‌روزرسانی‌های منطقه زمانی را مستقل از به‌روزرسانی‌های تصویر سیستم آزمایش کنند.

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

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

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

• کد مدیریت‌شده از libcore/ (برای مثال، java.util.TimeZone ) از فایل‌های tzdata و tzlookup.xml استفاده می‌کند.
• کد کتابخانه بومی در bionic/ (برای مثال، برای فراخوانی‌های سیستمی mktime و localtime) از فایل tzdata استفاده می‌کند.
• کد کتابخانه ICU4J/ICU4C در external/icu/ از فایل .dat استفاده می‌کند.

این کتابخانه‌ها فایل‌های همپوشانی که ممکن است در دایرکتوری /data/misc/zoneinfo/current وجود داشته باشند را ردیابی می‌کنند. انتظار می‌رود فایل‌های همپوشانی حاوی داده‌های بهبود یافته‌ی قوانین منطقه‌ی زمانی باشند، در نتیجه امکان به‌روزرسانی دستگاه‌ها بدون تغییر /system فراهم می‌شود.

اجزای سیستم اندروید که به داده‌های قوانین منطقه زمانی نیاز دارند، ابتدا مکان‌های زیر را بررسی می‌کنند:

• کدهای libcore/ و bionic/ از کپی /data فایل‌های tzdata و tzlookup.xml استفاده می‌کنند.
• کد ICU4J/ICU4C از فایل‌های موجود در /data ‎ استفاده می‌کند و برای داده‌هایی که موجود نیستند (برای فرمت‌ها، رشته‌های محلی‌شده و غیره) به /system files‎ برمی‌گردد.

فایل‌های توزیع‌شده

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

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

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

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

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

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

نصب توزیع

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

امنیت

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

• مشکلاتی که نشان‌دهنده‌ی پیکربندی نادرست سیستم ایمیج هستند، مانع از بوت شدن دستگاه می‌شوند؛ از جمله می‌توان به پیکربندی نادرست برنامه‌ی Updater یا Data یا قرار نداشتن برنامه‌ی Updater یا Data در /system/priv-app اشاره کرد.
• مشکلاتی که نشان می‌دهند یک برنامه‌ی داده‌ی معیوب نصب شده است، مانع از بوت شدن دستگاه نمی‌شوند، اما از فعال شدن بررسی به‌روزرسانی جلوگیری می‌کنند؛ از جمله می‌توان به مواردی مانند فقدان مجوزهای سیستمی مورد نیاز یا عدم نمایش ContentProvider توسط برنامه‌ی داده در آدرس اینترنتی مورد نظر اشاره کرد.

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

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

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

• برنامه داده خودشان را ایجاد کنند.
• برنامه‌های Updater و Data را در ساخت ایمیج سیستم لحاظ کنید.
• سرور سیستم را طوری پیکربندی کنید که RulesManagerService را فعال کند.

آماده سازی

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

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

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

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

تولیدکنندگان اصلی تجهیزات (OEM) می‌توانند برنامه داده (Data) را با آیکون، نام، ترجمه‌ها و سایر جزئیات دلخواه خود سفارشی کنند. با این حال، از آنجایی که برنامه داده قابل اجرا نیست، آیکون آن فقط در صفحه تنظیمات > برنامه‌ها (Settings > Apps) ظاهر می‌شود.

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

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

برنامه‌های Updater و Data را در تصویر سیستم قرار دهید

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

برنامه‌ی به‌روزرسانی باید با کلید پلتفرم امضا شده و مانند هر برنامه‌ی سیستمی دیگری در آن گنجانده شود. هدف در packages/apps/TimeZoneUpdater به عنوان TimeZoneUpdater تعریف شده است. گنجاندن برنامه‌ی داده مختص 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) اشاره دارد که مشابه مجموعه‌های تست استاندارد اندروید با استفاده از Tradefed (مانند CTS و VTS) است. تولیدکنندگان اصلی (OEM) که چنین مجموعه‌های تستی دارند، می‌توانند تست‌های به‌روزرسانی منطقه زمانی اندروید ارائه شده در مکان‌های زیر را اضافه کنند:

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

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

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

در این مرحله، تولیدکنندگان اصلی تجهیزات (OEM) کامیت‌های اندروید اصلی برای system/timezone و external/icu را از شاخه‌های release -dev در AOSP می‌گیرند و آن کامیت‌ها را روی کپی خود از کد منبع اندروید اعمال می‌کنند.

پچ AOSP مربوط به system/timezone شامل فایل‌های به‌روزرسانی‌شده در 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 برنامه Data اضافه می‌شود.

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

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

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

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

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

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

تولیدکنندگان اصلی تجهیزات (OEM) مسئول تضمین کیفیت و آزمایش برنامه داده به‌روزرسانی‌شده روی دستگاه‌های خود قبل از انتشار هستند.

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

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

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

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

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

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

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

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

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

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

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

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

ساخت اپلیکیشن داده با استفاده از tapas

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

تاپاس (Tapas) یک نسخه سبک‌تر از سیستم ساخت اندروید است که از یک درخت منبع کوچک‌تر برای تولید نسخه‌های قابل توزیع برنامه‌ها استفاده می‌کند. تولیدکنندگان اصلی تجهیزات (OEM) که با سیستم ساخت معمولی اندروید آشنا هستند، باید فایل‌های ساخت را از ساخت معمولی پلتفرم اندروید تشخیص دهند.

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

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

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

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

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

   <!-- Tapas Build -->
    <project
        path="build"
        name=">platform/<build"
        copyfile src="core/r>oot.m<k" >dest=<"Makefile" /
    /project
    project
        path="prebuilts/build-tools"
        name="pl>atfor<m/prebuilts/build-tools"
        clone-depth="1" /
    project
        path="prebuilts/go/linux-x8>6&quo<t;
        name="platform/prebuilts/go/linux-x86"
        clone-depth=>"<;1" /
    project
        path="build/blueprint"
      >  nam<e="platform/build/blueprint" /
    project
        path=&quo>t;build/k<ati"
        name="platform/buil>d/kati&qu<ot; /
    project
        path="build/soong">;
   <     nam>e=&quo<t;platform/build/soong"
        lin>kfile< src="root.bp" dest="Android.bp" /
        linkfile src="bootstrap.bash&quo>t; de<st="bootstra>p.bas<h" /
    /project

    !-- SDK for system / public API stubs --
    project>
    <    path="prebuilts/sdk"
        name="platform/prebuilts/sdk"
        clone-depth>=&quo<t;1" /
    !-- App> sour<ce --
    project
        path="system/timezone"
        name="platform/system/timezone" /
    project
     >   pa<th="packages/apps/TimeZoneData"
        name="platform/packages/apps/TimeZone>Data" /
    !-- 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 برای آزمایش ایجاد می‌کند. این فایل‌ها را می‌توان در دایرکتوری prebuilts قرار داد تا در تصویر سیستم گنجانده شوند و/یا از طریق یک فروشگاه برنامه برای دستگاه‌های سازگار توزیع شوند.