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

يوقف نظام التشغيل 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.

      اتصل بخدمة RulesManagerService.

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

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

      الحصول على معلومات عن التوزيع

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

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

    اكتملت عملية التحقّق

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

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

الموثوقية

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

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

الأمان

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

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

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

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

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

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

الإعداد

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

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

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

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

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

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

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

الخاصية الوصف هل تريد الإلغاء؟ 
config_enableUpdateableTimeZoneRules
 يجب ضبطه على true لتفعيل RulesManagerService. نعم 
config_timeZoneRulesUpdateTrackingEnabled
 		يجب ضبطه على true لجعل النظام يستمع إلى التغييرات في تطبيق "البيانات". نعم 
config_timeZoneRulesDataPackage
 اسم حزمة تطبيق "البيانات" الخاص بالمصنّع الأصلي للجهاز نعم 
config_timeZoneRulesUpdaterPackage
 تم إعداده لتطبيق "أداة التحديث" التلقائي. لا يتم تغيير هذا الإعداد إلا عند تقديم عملية تنفيذ مختلفة لتطبيق "أداة التحديث". لا 
config_timeZoneRulesCheckTimeMillisAllowed
 		الوقت المسموح به بين بدء عملية التحقّق من التحديث من قِبل ‎fomentedRulesManagerService ووقت تلقّي ردّ بشأن التثبيت أو إلغاء التثبيت أو عدم اتّخاذ أي إجراء بعد هذه النقطة، قد يتم إنشاء عامل تشغيل موثوقية تلقائي. لا 
config_timeZoneRulesCheckRetryCount
 عدد عمليات التحقّق التسلسلية غير الناجحة من التحديثات المسموح بها قبل أن تتوقّف معالجة RulesManagerService عن إنشاء المزيد لا

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

اختبار 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 من فرعَي تطوير الإصدار في 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 إعادة إنشاء ملف APK باستخدام المقبلات الإسبانية، ويوقِّعون ملف APK الذي تم إنشاؤه، ثم يختبرون حزمة APK وإصدارها:

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

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

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

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

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

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

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

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

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

التحقّق من الإصدار

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

مثال القيمة الغرض
س تم الحجز السماح بتوفير مخططات بديلة أو حِزم APK اختبارية في المستقبل يكون القيمة مبدئيًا (بشكل ضمني) 0. ولأن النوع الأساسي هو نوع int من نوع 32 بت مُوقَّعة، فإن هذا النظام يتيح استخدام ما يصل إلى مراجعتين مستقبليتين لمخطط الترقيم.
01 رقم الإصدار الرئيسي للتنسيق تتبُّع الإصدار الرئيسي للتنسيق المكوّن من 3 أرقام عشرية يتيح تنسيق التوزيع استخدام 3 أرقام عشرية، ولكن يتم استخدام رقمَين فقط هنا. من غير المرجّح أن يصل عدد الطلبات إلى 100 نظرًا للزيادة الكبيرة المتوقّعة لكل مستوى من مستويات واجهة برمجة التطبيقات. يعادل الإصدار الرئيسي 1 المستوى 27 لواجهة برمجة التطبيقات.
1 الإصدار الثانوي للتنسيق تتبُّع الإصدار الثانوي بالتنسيق المكوّن من 3 أرقام عشرية يتيح تنسيق التوزيع استخدام 3 أرقام عشرية، ولكن يتم استخدام رقم واحد فقط هنا. من غير المرجّح أن يتم الوصول إلى 10.
X تم الحجز يكون 0 لإصدارات الإنتاج (وقد يختلف لإصدارات APK الاختبارية).
ZZZZZ رقم إصدار غير معروف رقم عشري يتم تخصيصه عند الطلب. تتضمّن فواصل للسماح بإجراء تعديلات على الإعلانات البينية إذا لزم الأمر.

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

واسم النسخة هو تمثيل للتفاصيل يمكن للمستخدمين قراءته، مثل: major=001,minor=001,iana=2017a, revision=1,respin=2. تظهر الأمثلة في الجدول التالي.

# رمز الإصدار إصدار minSdkVersion {إصدار التنسيق الرئيسي}،{إصدار التنسيق الثانوي}،{إصدار قواعد IANA}،{Revision}
1 11000010 O-MR1 major=001,minor=001,iana=2017a,revision=1
2 21000010 P major=002,minor=001,iana=2017a,revision=1
3 11000020 O-MR1 major=001,minor=001,iana=2017a,revision=2
4 11000030 O-MR1 major=001,minor=001,iana=2017b,revision=1
5 21000020 P Central=002,minor=001,iana=2017b,revision=1
6 11000040 O-MR1 major=001,minor=001,iana=2018a,revision=1
7 21000030 P major=002,minor=001,iana=2018a,revision=1
8 1123456789 - -
9 11000021 O-MR1 major=001,minor=001,iana=2017a,revision=2,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 هو إصدار مُبسَّط من نظام ملف APK لنظام التشغيل 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 بغرض الاختبار. يمكن وضع هذه الملفات في دليل "التطبيقات المُسبقة الإنشاء" لتضمينها في صورة النظام و/أو توزيعها من خلال متجر تطبيقات للأجهزة المتوافقة.