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

تنظيم صفحاتك في مجموعات يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.

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

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

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

تستخدِم التحديثات العملية التالية:

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

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

تعديلات المنطقة الزمنية (في الإصدارات من Android 8.1 إلى 9)

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

في نظامَي التشغيل 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 على رمز مصدر عام للمكونات المذكورة أعلاه، ويمكن لمصنعي الأجهزة الأصليين اختيار استخدامه بدون تعديل. رمز الاختبار: يُستخدَم هذا الرمز لتمكين المصنّعين الأصليّين للأجهزة من التحقّق تلقائيًا من أنّهم فعّلوا الميزة بشكل صحيح.

تركيب التوزيع

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

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

   الشكل 1: تحديثات التطبيقات المتعلّقة بالبيانات

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

   الشكل 2: بدء عملية البحث عن تحديث

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

     الشكل 3: تحديثات تطبيق البيانات، مع استدعاء RulesManagerService

   • يُجري التطبيق "البيانات" طلب بحث عن عنوان URL و مواصفات العمود المحدّدة جيدًا في ContentProvider للحصول على معلومات عن التوزيع.
     
     

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

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

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

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

الموثوقية

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

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

الأمان

عند تفعيله، يُجري رمز RulesManagerService في خادم النظام عدة عمليات فحص لضمان أمان استخدام النظام.

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

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

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

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

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

الإعداد

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

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

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

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

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

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

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

تضمين تطبيقَي Updater وData في صورة النظام

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

يجب توقيع تطبيق "المُحدِّث" باستخدام مفتاح النظام الأساسي وإدراجه كأي تطبيق نظام آخر. يتم تحديد الهدف في packages/apps/TimeZoneUpdater على أنّه TimeZoneUpdater. إنّ عملية تضمين تطبيقات البيانات تعتمد على المصنّع الأصلي للجهاز وتعتمد على الاسم المستهدَف الذي تم اختياره لملف prebuild.

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

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

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

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

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

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

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

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

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

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

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

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

يجب أن يتضمّن تطبيق "البيانات" استراتيجية إصدار مناسبة لضمان أن تتلقّى الأجهزة حِزم 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 لإصدارَي O-MR1 و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.

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

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