قواعد المناطق الزمنية

في نظام التشغيل Android 10، تم إيقاف آلية تعديل بيانات المنطقة الزمنية المستندة إلى حِزم APK (المتاحة في الإصدارَين 8.1 و9 من نظام التشغيل Android) واستبدالها بآلية تعديل الوحدات المستندة إلى APEX. لا يزال الإصدار من 8.1 إلى 13 من AOSP يتضمّن رمز النظام الأساسي اللازم للمصنّعين الأصليين للأجهزة لتفعيل التحديثات المستندة إلى حِزم APK، وبالتالي يمكن للأجهزة التي يتم ترقيتها إلى Android 10 أن تظل تتلقّى تحديثات بيانات المنطقة الزمنية التي يوفّرها الشركاء من خلال حِزمة APK. ومع ذلك، يجب عدم استخدام آلية تحديث حِزم APK على جهاز مخصّص للإنتاج يتلقّى أيضًا تحديثات الوحدات النمطية، لأنّ التحديث المستند إلى حِزم APK يحل محل التحديث المستند إلى APEX (أي أنّ الجهاز الذي تلقّى تحديثًا مستندًا إلى حِزم APK سيتجاهل التحديثات المستندة إلى APEX).

تعديلات المنطقة الزمنية (الإصدار 10 من نظام التشغيل Android والإصدارات الأحدث)

تتيح وحدة Time Zone Data المتوافقة مع الإصدار 10 من نظام التشغيل Android والإصدارات الأحدث تعديل التوقيت الصيفي والمناطق الزمنية على أجهزة Android، ما يؤدي إلى توحيد البيانات التي يمكن أن تتغيّر بشكل متكرّر لأسباب دينية وسياسية وجغرافية سياسية.

تتّبع التحديثات العملية التالية:

1. تُصدر هيئة IANA تحديثًا لقاعدة بيانات المناطق الزمنية استجابةً لتغيير حكومة واحدة أو أكثر لقاعدة منطقة زمنية في بلدانها.
2. تُعدّ Google أو شريك Android تحديثًا لوحدة بيانات المنطقة الزمنية (ملف APEX) يحتوي على المناطق الزمنية المعدَّلة.
3. ينزّل جهاز المستخدم النهائي التحديث، ثم يعيد تشغيله، ثم يطبّق التغييرات، وبعد ذلك، تحتوي بيانات المنطقة الزمنية للجهاز على بيانات المنطقة الزمنية الجديدة من التحديث.

لمزيد من التفاصيل حول الوحدات، يُرجى الاطّلاع على مكوّنات النظام النموذجية.

تحديثات المنطقة الزمنية (الإصدارات من 8.1 إلى 9 من نظام التشغيل Android)

ملاحظة: تمت إزالة ميزة آلية تعديل بيانات المنطقة الزمنية المستندة إلى حِزم 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/ (على سبيل المثال، بالنسبة إلى mktime، استدعاءات نظام localtime) الملف tzdata.
• يستخدم رمز مكتبة ICU4J/ICU4C في external/icu/ الملف icu .dat.

تتتبّع هذه المكتبات ملفات التراكب التي قد تكون موجودة في الدليل /data/misc/zoneinfo/current. من المتوقّع أن تحتوي ملفات التراكب على بيانات محسّنة لقواعد المناطق الزمنية، ما يتيح تحديث الأجهزة بدون تغيير /system.

تتحقّق مكونات نظام التشغيل Android التي تحتاج إلى بيانات قواعد المنطقة الزمنية من المواقع الجغرافية التالية أولاً:

• يستخدم الرمزان libcore/ وbionic/ نسخة /data من الملفين tzdata وtzlookup.xml.
• تستخدم رموز ICU4J/ICU4C الملفات في /data وتعود إلى ملفات /system للحصول على البيانات غير المتوفّرة (مثل التنسيقات والسلاسل المترجمة وغير ذلك).

ملفات التوزيع

تحتوي ملفات حزمة التوزيع .zip على ملفات البيانات اللازمة لتعبئة الدليل /data/misc/zoneinfo/current. تحتوي ملفات التوزيع أيضًا على بيانات وصفية تتيح للأجهزة رصد مشاكل تحديد الإصدار.

يعتمد تنسيق ملف التوزيع على إصدار Android لأنّ المحتوى يتغيّر حسب إصدار ICU ومتطلبات منصة Android والتغييرات الأخرى في الإصدار. يوفر نظام التشغيل Android ملفات توزيع لإصدارات Android المتوافقة مع كل تحديث من IANA (بالإضافة إلى تحديث ملفات نظام المنصة). لإبقاء أجهزتهم محدَّثة، يمكن لمصنّعي المعدات الأصلية استخدام ملفات التوزيع هذه أو إنشاء ملفاتهم الخاصة باستخدام شجرة مصدر Android (التي تحتوي على البرامج النصية والملفات الأخرى اللازمة لإنشاء ملفات التوزيع).

مكوّنات تعديل المنطقة الزمنية

يتضمّن تحديث قواعد المنطقة الزمنية نقل ملفات التوزيع إلى جهاز وتثبيت الملفات المضمّنة بشكل آمن. تتطلّب عملية النقل والتثبيت ما يلي:

• وظيفة خدمة النظام الأساسي (timezone.RulesManagerService)، وهي غير مفعّلة تلقائيًا على المصنّعين الأصليين للجهاز تفعيل الوظيفة من خلال الإعدادات. يتم تشغيل RulesManagerService في عملية خادم النظام، ويتم إعداد عمليات تعديل المنطقة الزمنية من خلال الكتابة إلى /data/misc/zoneinfo/staged. يمكن RulesManagerService أيضًا استبدال العمليات التي تم إعدادها مسبقًا أو حذفها.
• TimeZoneUpdater، وهو تطبيق نظام غير قابل للتحديث (يُعرف أيضًا باسم تطبيق "أداة التحديث"). على المصنّعين الأصليين للأجهزة تضمين هذا التطبيق في صورة النظام للأجهزة التي تستخدم الميزة.
• ‫OEM TimeZoneData، وهو تطبيق نظام قابل للتحديث (يُعرف أيضًا باسم تطبيق البيانات) ينقل ملفات التوزيع إلى الجهاز ويتيحها لتطبيق "أداة التحديث". يجب أن يضمِّن مصنّعو المعدات الأصلية هذا التطبيق في صورة النظام للأجهزة التي تستخدم هذه الميزة.
• ‫tzdatacheck، وهو ملف ثنائي مطلوب عند بدء التشغيل لضمان التشغيل الصحيح والآمن لتحديثات المنطقة الزمنية.

يحتوي شجر مصدر Android على رمز مصدر عام للمكوّنات المذكورة أعلاه، ويمكن لمصنّع المعدات الأصلية اختيار استخدامه بدون تعديل. يتم توفير رمز الاختبار لتمكين الشركات المصنّعة للأجهزة الأصلية من التحقّق تلقائيًا من أنّها فعّلت الميزة بشكل صحيح.

تثبيت توزيعة

تتضمّن عملية تثبيت توزيعة Linux الخطوات التالية:

1. يتم تحديث تطبيق البيانات من خلال تنزيله من متجر التطبيقات أو تحميله من مصدر خارجي. تراقب عملية خادم النظام (من خلال فئات timezone.RulesManagerServer/timezone.PackageTracker) أي تغييرات في اسم حزمة تطبيق البيانات الذي تم ضبطه والمخصّص لمصنّع المعدات الأصلية.
   
   

   الشكل 1. تحديثات تطبيق "البيانات"

2. تؤدي عملية خادم النظام إلى بدء عملية التحقّق من التحديث من خلال بث هدف محدّد باستخدام رمز مميّز فريد يُستخدَم مرة واحدة إلى تطبيق Updater. يتتبّع خادم النظام أحدث رمز مميّز تم إنشاؤه حتى يتمكّن من تحديد وقت اكتمال آخر عملية تحقّق بدأها، ويتم تجاهل أي رموز مميّزة أخرى.
   
   

   الشكل 2. بدء البحث عن تحديث

3. أثناء التحقّق من التحديث، ينفّذ تطبيق "أداة التحديث" المهام التالية:
   • يطلب هذا الإجراء حالة الجهاز الحالية من خلال استدعاء RulesManagerService.
     
     

     الشكل 3. تعديلات على تطبيق البيانات، يتم استدعاء RulesManagerService.

   • يستعلم عن تطبيق "البيانات" من خلال الاستعلام عن عنوان URL محدّد جيدًا خاص بـ ContentProvider ومواصفات الأعمدة للحصول على معلومات حول التوزيع.
     
     

     الشكل 4. تعديلات على تطبيق البيانات، والحصول على معلومات حول التوزيع

4. يتّخذ تطبيق "أداة التحديث" الإجراء المناسب استنادًا إلى المعلومات المتوفّرة لديه. تشمل الإجراءات المتاحة ما يلي:
   • طلب تثبيت تتم قراءة بيانات Distro من تطبيق Data ويتم تمريرها إلى RulesManagerService في خادم النظام. تعيد خدمة RulesManagerService التأكّد من أنّ إصدار تنسيق حزمة التوزيع والمحتوى مناسبان للجهاز، ثم تبدأ عملية التثبيت.
   • طلب إلغاء تثبيت التطبيق (هذا الإجراء نادر). على سبيل المثال، إذا تم إيقاف أو إلغاء تثبيت حزمة APK المعدَّلة في /data وعاد الجهاز إلى الإصدار المتوفّر في /system.
   • عدم اتّخاذ أي إجراء: يحدث هذا الخطأ عندما يُتبيّن أنّ توزيع تطبيق البيانات غير صالح.
   في جميع الحالات، يستدعي تطبيق Updater خدمة RulesManagerService باستخدام رمز التحقّق ليعرف خادم النظام أنّ عملية التحقّق قد اكتملت بنجاح.
   
   

   الشكل 5. اكتملت عملية التحقّق.

5. إعادة التشغيل وtzdatacheck: عند تشغيل الجهاز في المرة التالية، ينفّذ الملف الثنائي tzdatacheck أي عملية تم إعدادها. يمكن لتطبيق tzdatacheck الثنائي تنفيذ المهام التالية:
   • نفِّذ العملية المرحلية من خلال التعامل مع إنشاء ملفات /data/misc/zoneinfo/current و/أو استبدالها و/أو حذفها قبل أن تفتح مكونات النظام الأخرى الملفات وتبدأ في استخدامها.
   • تأكَّد من أنّ الملفات في /data صحيحة لإصدار النظام الأساسي الحالي، فقد لا يكون الأمر كذلك إذا تلقّى الجهاز تحديثًا للنظام وتم تغيير إصدار تنسيق التوزيع.
   • تأكَّد من أنّ إصدار قواعد IANA هو الإصدار نفسه أو إصدار أحدث من الإصدار الوارد في /system. ويحمي ذلك من أن يؤدي تحديث النظام إلى ترك الجهاز ببيانات أقدم لقواعد المناطق الزمنية من تلك المتوفرة في صورة /system.

الموثوقية

تتم عملية التثبيت الشاملة بشكل غير متزامن ويتم تقسيمها على ثلاث عمليات لنظام التشغيل. في أي وقت أثناء عملية التثبيت، قد ينقطع اتصال الجهاز بمصدر الطاقة أو تنفد مساحة القرص أو تحدث مشاكل أخرى، ما يؤدي إلى عدم اكتمال عملية التحقّق من التثبيت. في أفضل سيناريو لعدم النجاح، يُبلغ تطبيق Updater خادم النظام بأنّه لم ينجح. وفي أسوأ سيناريو لعدم النجاح، لا يتلقّى RulesManagerService أي طلب على الإطلاق.

للتعامل مع ذلك، يتتبّع رمز خادم النظام ما إذا كان قد تم إكمال عملية التحقّق من التحديث التي تم تشغيلها، وما هو رمز الإصدار الذي تم التحقّق منه آخر مرة لتطبيق Data. وعندما يكون الجهاز غير نشط ويتم شحنه، يمكن لرمز خادم النظام التحقّق من الحالة الحالية. وإذا رصدت عملية تحقّق غير مكتملة من التحديث أو إصدارًا غير متوقّع من Data App، سيتم تلقائيًا بدء عملية تحقّق من التحديث.

الأمان

عند تفعيل هذه الميزة، ينفّذ رمز RulesManagerService في خادم النظام عدة عمليات تحقّق للتأكّد من أنّ النظام آمن للاستخدام.

• تتسبّب المشاكل التي تشير إلى أنّ صورة النظام تم إعدادها بشكل غير صحيح في منع الجهاز من بدء التشغيل، وتشمل الأمثلة على ذلك إعدادًا غير صحيح لتطبيق "أداة التحديث" أو تطبيق "البيانات" أو عدم توفّر تطبيق "أداة التحديث" أو تطبيق "البيانات" في /system/priv-app.
• لا تمنع المشاكل التي تشير إلى تثبيت تطبيق Data سيئ تشغيل الجهاز، ولكنها تمنع بدء عملية التحقّق من التحديثات. وتشمل الأمثلة على ذلك عدم توفّر أذونات النظام المطلوبة أو عدم عرض تطبيق Data لـ ContentProvider على عنوان URI المتوقّع.

يتم فرض أذونات الملفات في أدلة /data/misc/zoneinfo باستخدام قواعد SELinux. وكما هو الحال مع أي حِزمة APK، يجب توقيع تطبيق Data باستخدام المفتاح نفسه المستخدَم لتوقيع الإصدار /system/priv-app. من المتوقّع أن يتضمّن تطبيق "البيانات" اسم حزمة ومفتاحًا مخصّصَين خاصَّين بمصنّع المعدات الأصلية.

دمج تعديلات المنطقة الزمنية

لتفعيل ميزة تعديل المنطقة الزمنية، عادةً ما يقوم المصنّعون الأصليون للأجهزة بما يلي:

• إنشاء تطبيق Data الخاص بهم
• تضمين تطبيقَي "أداة التحديث" و"البيانات" في إصدار صورة النظام.
• اضبط خادم النظام لتفعيل RulesManagerService.

الإعداد

قبل البدء، على الشركات المصنّعة للمعدات الأصلية مراجعة السياسة التالية واعتبارات ضمان الجودة والأمان:

• إنشاء مفتاح توقيع مخصّص لتطبيق "البيانات"
• وضع استراتيجية لإصدار وتحديد إصدارات تحديثات المناطق الزمنية لمعرفة الأجهزة التي سيتم تحديثها وكيفية التأكّد من أنّ التحديثات يتم تثبيتها فقط على الأجهزة التي تحتاج إليها على سبيل المثال، قد يريد مصنّعو المعدات الأصلية توفير تطبيق بيانات واحد لجميع أجهزتهم أو قد يختارون توفير تطبيقات بيانات مختلفة للأجهزة المختلفة. ويؤثّر هذا القرار في اختيار اسم الحزمة، وربما في رموز الإصدارات المستخدَمة، واستراتيجية ضمان الجودة.
• تحديد ما إذا كانوا يريدون استخدام بيانات المنطقة الزمنية المتوفّرة في نظام التشغيل Android من "مشروع Android مفتوح المصدر" (AOSP) أو إنشاء بياناتهم الخاصة

إنشاء تطبيق "بيانات"

يتضمّن مشروع AOSP جميع الرموز المصدر وقواعد الإنشاء اللازمة لإنشاء تطبيق "بيانات" في packages/apps/TimeZoneData، بالإضافة إلى تعليمات ونماذج أمثلة لـ AndroidManifest.xml والملفات الأخرى المتوفّرة في packages/apps/TimeZoneData/oem_template. تتضمّن نماذج الأمثلة كلاً من هدف الإنشاء لحزمة APK الخاصة بتطبيق Data وأهدافًا إضافية لإنشاء إصدارات تجريبية من تطبيق Data.

يمكن لمصنّعي المعدات الأصلية تخصيص تطبيق "البيانات" باستخدام الرمز والاسم والترجمات والتفاصيل الأخرى الخاصة بهم. ومع ذلك، بما أنّه لا يمكن تشغيل تطبيق "البيانات"، يظهر الرمز فقط في شاشة الإعدادات > التطبيقات.

من المفترض إنشاء تطبيق "البيانات" باستخدام إصدار tapas الذي ينتج حِزم APK مناسبة لإضافتها إلى صورة النظام (للإصدار الأوّلي) وتوقيعها وتوزيعها من خلال متجر تطبيقات (للتحديثات اللاحقة). لمزيد من التفاصيل حول استخدام tapas، يُرجى الاطّلاع على إنشاء تطبيق Data باستخدام tapas.

على الشركات المصنّعة للمعدات الأصلية تثبيت تطبيق "البيانات" مسبقًا في صورة نظام الجهاز في /system/priv-app. لتضمين حِزم APK مسبقة الإنشاء (التي يتم إنشاؤها من خلال عملية إنشاء tapas) في صورة النظام، يمكن لمصنّعي المعدات الأصلية نسخ ملفات الأمثلة في packages/apps/TimeZoneData/oem_template/data_app_prebuilt. تتضمّن نماذج التطبيقات أيضًا أهدافًا للإنشاء من أجل تضمين إصدارات تجريبية من تطبيق Data في مجموعات الاختبار.

تضمين تطبيقَي "أداة التحديث" و"البيانات" في صورة النظام

على المصنّعين الأصليين للأجهزة وضع حِزم APK لتطبيقَي Updater وData في الدليل /system/priv-app ضمن صورة النظام. لإجراء ذلك، يجب أن يتضمّن إصدار صورة النظام بشكل صريح استهدافات التطبيقين Updater وData المُنشأة مسبقًا.

يجب توقيع تطبيق Updater باستخدام مفتاح النظام الأساسي وتضمينه كتطبيق نظام آخر. يتم تحديد الهدف في packages/apps/TimeZoneUpdater على النحو TimeZoneUpdater. يتم تضمين تطبيق Data بشكل خاص بمصنّع المعدات الأصلية (OEM) ويعتمد على اسم الهدف الذي تم اختياره للإصدار المسبق.

ضبط خادم النظام

لتفعيل تعديلات المنطقة الزمنية، يمكن لمصنّعي المعدات الأصلية ضبط إعدادات خادم النظام من خلال إلغاء خصائص الإعدادات المحدّدة في frameworks/base/core/res/res/values/config.xml.

config_enableUpdateableTimeZoneRules

config_timeZoneRulesUpdateTrackingEnabled

config_timeZoneRulesDataPackage

config_timeZoneRulesUpdaterPackage

config_timeZoneRulesCheckTimeMillisAllowed

config_timeZoneRulesCheckRetryCount

يجب أن تكون عمليات إلغاء الإعدادات التلقائية في صورة النظام (وليس في صورة المورّد أو غيرها) لأنّ الجهاز الذي تم إعداده بشكل غير صحيح قد يرفض بدء التشغيل. إذا كانت عمليات إلغاء الإعدادات التلقائية في صورة المورّد، سيُعدّ التحديث إلى صورة نظام بدون تطبيق "البيانات" (أو مع أسماء حِزم مختلفة لتطبيق "البيانات"/تطبيق "أداة التحديث") عملية ضبط خاطئة.

اختبار مجموعات الاختبارات (xTS)

يشير xTS إلى أي مجموعة اختبار خاصة بمصنّع المعدات الأصلية تشبه مجموعات اختبار 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 الأساسية حِزمًا لتعديل الإصدارات في "مشروع Android مفتوح المصدر". يمكن لمصنّعي المعدات الأصلية الذين يستخدمون نظام Android الأساسي وملفات التوزيع الاستفادة من عمليات الدمج هذه واستخدامها لإنشاء إصدار جديد من تطبيق "البيانات"، ثم طرح الإصدار الجديد لتحديث الأجهزة في مرحلة الإنتاج.

بما أنّ تطبيقات البيانات تحتوي على ملفات توزيع مرتبطة بشكل وثيق بإصدارات Android، على مصنّعي المعدات الأصلية إنشاء إصدار جديد من تطبيق البيانات لكل إصدار Android متوافق يريد المصنّع تحديثه. على سبيل المثال، إذا أراد مصنّع المعدات الأصلية تقديم تحديثات للأجهزة التي تعمل بالإصدارات 8.1 و9 و10 من نظام التشغيل Android، عليه إكمال العملية ثلاث مرات.

الخطوة 1: تعديل ملفات بيانات النظام/المنطقة الزمنية والملفات الخارجية/ملفات بيانات ICU

في هذه الخطوة، يأخذ المصنّعون الأصليون للأجهزة عمليات الدمج الخاصة بنظام Android الأساسي system/timezone وexternal/icu من فروع الإصدار-dev في "مشروع Android المفتوح المصدر" ويطبّقون عمليات الدمج هذه على نسختهم من رمز مصدر 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 لتطبيق Data.

الخطوة 2: تعديل رمز إصدار تطبيق "البيانات"

في هذه الخطوة، تعدّل الشركات المصنّعة للأجهزة الأصلية رمز إصدار تطبيق "البيانات". يتم اختيار 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 (ومع ذلك، يجب أن تكون رموز إصدارات الاختبار أعلى من إصدار صورة النظام). للحصول على التفاصيل، راجِع مثال على مخطط استراتيجية رموز الإصدارات. وفي حال استخدام المخطط المثال أو مخطط مشابه، لن تحتاج إلى تعديل رموز إصدارات الاختبار لأنّه من المضمون أن تكون أعلى من رموز الإصدارات الفعلية.

الخطوة 3: إعادة الإنشاء والتوقيع والاختبار والإصدار

في هذه الخطوة، تعيد الشركات المصنّعة للأجهزة الأصلية إنشاء حِزمة APK باستخدام Tapas، وتوقّع حِزمة APK التي تم إنشاؤها، ثم تختبرها وتصدرها:

• بالنسبة إلى الأجهزة التي لم يتم طرحها بعد (أو عند إعداد تحديث نظام لجهاز تم طرحه)، أرسِل حِزم APK الجديدة في دليل Data app prebuilt للتأكّد من أنّ صورة النظام واختبارات xTS تتضمّن أحدث حِزم APK. على المصنّعين الأصليين للأجهزة اختبار عمل الملف الجديد بشكل صحيح (أي اجتيازه اختبارات CTS وأي اختبارات أخرى آلية أو يدوية خاصة بالمصنّع الأصلي للجهاز).
• بالنسبة إلى الأجهزة التي تم طرحها ولم تعُد تتلقّى تحديثات النظام، قد لا يتم طرح حِزم APK الموقَّعة إلا من خلال متجر تطبيقات.

يتحمّل مصنّعو المعدات الأصلية مسؤولية ضمان الجودة واختبار تطبيق "البيانات" المعدَّل على أجهزتهم قبل إصداره.

استراتيجية رمز إصدار تطبيق البيانات

يجب أن يتضمّن تطبيق Data إستراتيجية مناسبة للتحكّم في الإصدارات لضمان تلقّي الأجهزة حِزم APK الصحيحة. على سبيل المثال، إذا تم تلقّي تحديث للنظام يتضمّن حزمة APK أقدم من تلك التي تم تنزيلها من متجر التطبيقات، يجب الاحتفاظ بإصدار متجر التطبيقات.

يجب أن يتضمّن رمز إصدار حزمة APK المعلومات التالية:

• إصدار تنسيق حزمة التوزيع (رئيسي + ثانوي)
• رقم إصدار متزايد (غير شفاف)

في الوقت الحالي، يرتبط مستوى واجهة برمجة التطبيقات للمنصة ارتباطًا وثيقًا بإصدار تنسيق حزمة التوزيع، لأنّ كل مستوى من مستويات واجهة برمجة التطبيقات يرتبط عادةً بإصدار جديد من ICU (ما يجعل ملفات حزمة التوزيع غير متوافقة). في المستقبل، قد يغيّر نظام التشغيل Android ذلك، ما يتيح استخدام ملف حزمة توزيع على عدة إصدارات من منصة Android (ولن يتم استخدام مستوى واجهة برمجة التطبيقات في نظام ترميز إصدار تطبيق البيانات).

مثال على استراتيجية رمز الإصدار

يضمن نظام ترقيم الإصدارات هذا أن تحل إصدارات تنسيق التوزيع الأعلى محل إصدارات تنسيق التوزيع الأقل. يستخدم AndroidManifest.xml android:minSdkVersion للتأكّد من أنّ الأجهزة القديمة لا تتلقّى إصدارات بتنسيق توزيع أعلى من الذي يمكنها التعامل معه.

الشكل 6. مثال على استراتيجية رمز الإصدار

ويمكن تحسين طريقة عرض المخطط إذا تم استخدام النظام الثنائي بدلاً من النظام العشري، ولكن يتميّز هذا المخطط بإمكانية قراءته من قِبل الإنسان. في حال استنفاد نطاق الأرقام الكامل، قد يتغيّر اسم حزمة تطبيق "البيانات".

اسم الإصدار هو تمثيل يمكن للمستخدمين قراءته للتفاصيل، مثل 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 من نظام التشغيل Android O-MR1 وAndroid P. وبما أنّها أعلى عدديًا، فإنّها تحلّ محل الإصدارات السابقة من IANA أو مراجعات Android الخاصة بالإصدارات السابقة.
• يعرض المثالان 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 باستخدام tapas

يكون مصنّعو المعدات الأصلية مسؤولين عن إدارة معظم جوانب تطبيق Time Zone Data وضبط صورة النظام بشكل صحيح. من المفترض إنشاء تطبيق Data باستخدام إصدار tapas الذي ينتج حِزم APK مناسبة لإضافتها إلى صورة النظام (للإصدار الأوّلي) وتوقيعها وتوزيعها من خلال متجر تطبيقات (للتحديثات اللاحقة).

‫Tapas هو إصدار مخفّف من نظام إنشاء Android يستخدم شجرة مصدر مخفّفة لإنتاج إصدارات قابلة للتوزيع من التطبيقات. يجب أن يتعرّف مصنّعو المعدات الأصلية الذين يعرفون نظام الإصدار العادي من Android على ملفات الإصدار من إصدار منصة Android العادي.

إنشاء ملف البيان

يمكن عادةً الحصول على شجرة مصدر مخفَّضة باستخدام ملف بيان مخصّص يشير فقط إلى مشاريع Git التي يحتاجها نظام الإصدار ولإنشاء التطبيق. بعد اتّباع التعليمات الواردة في إنشاء تطبيق Data، يجب أن يكون لدى مصنّعي المعدات الأصلية مشروعا Git على الأقل خاصان بهم تم إنشاؤهما باستخدام ملفات النماذج ضمن packages/apps/TimeZoneData/oem_template:

• يحتوي أحد مشاريع Git على ملفات التطبيق، مثل ملف البيان وملفات الإنشاء المطلوبة لإنشاء ملف APK الخاص بالتطبيق (على سبيل المثال، vendor/oem/apps/TimeZoneData). يحتوي هذا المشروع أيضًا على قواعد إنشاء لحِزم APK التجريبية التي يمكن أن تستخدمها اختبارات xTS.
• يحتوي أحد مشاريع Git على حِزم APK الموقَّعة التي تم إنتاجها من خلال إصدار التطبيق ليتم تضمينها في إصدار صورة النظام واختبارات xTS.

تستفيد عملية إنشاء التطبيق من العديد من مشاريع Git الأخرى التي تتم مشاركتها مع عملية إنشاء النظام الأساسي أو التي تحتوي على مكتبات رموز برمجية مستقلة عن الشركة المصنّعة للجهاز الأصلي.

يحتوي مقتطف البيان التالي على الحد الأدنى من مشاريع 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 بغرض الاختبار. يمكن وضع هذه الملفات في دليل prebuilts لتضمينها في صورة النظام و/أو توزيعها من خلال متجر تطبيقات للأجهزة المتوافقة.