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

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

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

ملاحظات حول الإيقاف النهائي

توقّف نظام التشغيل Android عن توفير حِزم تصحيح المنطقة الزمنية لنظام Android 10 في أغسطس 2026، وكانت حزمة التصحيح الأخيرة هي TZDB 2026c. يمكن لمصنّعي المعدات الأصلية مواصلة توفير الدعم للإصدار 10 من نظام التشغيل Android.

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

ملاحظة: تمت إزالة ميزة آلية تعديل بيانات المنطقة الزمنية المستندة إلى حِزم APK بالكامل من نظام Android 14 والإصدارات الأحدث، ولا يمكن العثور عليها في رمز المصدر. على الشركاء نقل بياناتهم بالكامل إلى وحدة المنطقة الزمنية في Mainline.

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

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

رمز المصدر والبيانات الخاصة بالمنطقة الزمنية في Android

تحتاج جميع أجهزة Android العادية، حتى تلك التي لا تستخدم هذه الميزة، إلى بيانات قواعد المنطقة الزمنية، ويجب أن يتم شحنها مع مجموعة تلقائية من بيانات قواعد المنطقة الزمنية في القسم /system. يتم بعد ذلك استخدام هذه البيانات من خلال الرمز البرمجي من المكتبات التالية في شجرة المصدر لنظام Android:

• يستخدم الرمز البرمجي المُدار من libcore/ (مثل java.util.TimeZone) ملفات tzdata وtzlookup.xml.
• يستخدم رمز المكتبة المجمّعة من رموز برمجية أصلية في bionic/ (على سبيل المثال، بالنسبة إلى mktime، طلبات النظام المحلية) الملف tzdata.
• يستخدم رمز مكتبة ICU4J/ICU4C في external/icu/ الملف icu .dat.

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

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

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

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

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

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

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

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

• وظيفة خدمة النظام الأساسي (timezone.RulesManagerService)، وهي غير مفعّلة تلقائيًا على المصنّعين الأصليين للجهاز تفعيل الوظيفة من خلال الإعدادات. تعمل RulesManagerService في عملية خادم النظام وتنفّذ عمليات تعديل المنطقة الزمنية من خلال الكتابة إلى /data/misc/zoneinfo/staged. يمكن RulesManagerService أيضًا استبدال العمليات التي تم إعدادها مسبقًا أو حذفها.
• TimeZoneUpdater، وهو تطبيق نظام غير قابل للتحديث (يُعرف أيضًا باسم تطبيق "أداة التحديث"). على المصنّعين الأصليين للأجهزة تضمين هذا التطبيق في صورة النظام للأجهزة التي تستخدم الميزة.
• ‫OEM TimeZoneData، وهو تطبيق نظام قابل للتحديث (يُعرف أيضًا باسم تطبيق البيانات) ينقل ملفات التوزيع إلى الجهاز ويتيحها لتطبيق Updater. يجب أن تضمّن الشركات المصنّعة للمعدات الأصلية هذا التطبيق في صورة النظام للأجهزة التي تستخدم هذه الميزة.
• ‫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.
   • عدم اتّخاذ أي إجراء: يحدث هذا الخطأ عندما يُتبيّن أنّ توزيع تطبيق Data غير صالح.
   في جميع الحالات، يطلب تطبيق 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 جميع الرموز المصدر وقواعد الإنشاء اللازمة لإنشاء تطبيق Data في 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. يتم تضمين تطبيق "البيانات" بشكل خاص بمصنّع المعدات الأصلية، ويعتمد ذلك على اسم الهدف الذي تم اختياره للإصدار المسبق.

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

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

config_enableUpdateableTimeZoneRules

config_timeZoneRulesUpdateTrackingEnabled

config_timeZoneRulesDataPackage

config_timeZoneRulesUpdaterPackage

config_timeZoneRulesCheckTimeMillisAllowed

config_timeZoneRulesCheckRetryCount

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

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

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

الخطوة 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 لتطبيق "البيانات".

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