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

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

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

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

    تحديثات تطبيقات البيانات

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

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

    بدء التحديث

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

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

      استدعاء خدمة RulesManager

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

الموثوقية

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

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

الأمان

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

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

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

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

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

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

الإعداد

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

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

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

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

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

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

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

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

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

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

إعداد خادم النظام

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

الخاصية الوصف هل تريد الإلغاء؟ 
config_enableUpdateableTimeZoneRules
 يجب ضبطها على true لتفعيل RulesManagerService. نعم 
config_timeZoneRulesUpdateTrackingEnabled
 يجب ضبط القيمة على true ليطّلع النظام على التغييرات على تطبيق البيانات. نعم 
config_timeZoneRulesDataPackage
 اسم حزمة تطبيق البيانات الخاص بالمصنّع الأصلي للجهاز. نعم 
config_timeZoneRulesUpdaterPackage
 تم إعداده لتطبيق أداة التحديث التلقائي. التغيير فقط عند توفير طريقة تنفيذ مختلفة لتطبيق المحدث. لا 
config_timeZoneRulesCheckTimeMillisAllowed
 الوقت المسموح به بين تشغيل البحث عن التحديثات من خلال القواعدManagerService وتثبيت أو إلغاء تثبيت أو عدم اتخاذ أي إجراء. بعد عند هذه النقطة، قد يتم إنشاء مشغل موثوقية تلقائي. لا 
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 الذي يريد المصنّع الأصلي للجهاز تحديثه. على سبيل المثال، إذا أراد المصنّع الأصلي للجهاز توفير تحديثات للإصدارات 8.1 و9 و10 من Android الأجهزة، يجب عليهم إكمال العملية ثلاث مرات.

الخطوة 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: تعديل رمز إصدار تطبيق البيانات

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

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

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

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

إنشاء تطبيق Data باستخدام المقبلات الإسبانية

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

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

إنشاء البيان

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

استمتِع ببناء المقبلات الإسبانية

بعد إنشاء شجرة المصدر، استدعِ بنية تاباس. باستخدام الأوامر التالية:

source build/envsetup.sh
tapas
make -j30 showcommands dist TARGET_BUILD_APPS='TimeZoneData TimeZoneData_test1 TimeZoneData_test2'  TARGET_BUILD_VARIANT=userdebug

يؤدي الإصدار الناجح إلى إنشاء ملفات في دليل out/dist لـ اختبار الفرضية. يمكن وضع هذه الملفات في الدليل المُنشأ مسبقًا لتضمينها في صورة النظام و/أو توزيعها من خلال متجر تطبيقات للحصول على الأجهزة.