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

يتجاهل Android 10 آلية تحديث بيانات المنطقة الزمنية المستندة إلى APK (المتوفرة في Android 8.1 وAndroid 9) ويستبدلها بآلية تحديث الوحدة المستندة إلى 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 وما بعده ولا يمكن العثور عليها في الكود المصدري. يجب على الشركاء الانتقال بشكل كامل إلى وحدة Time Zone Mainline.

في 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 للبيانات غير الموجودة (للتنسيقات والسلاسل المترجمة وما إلى ذلك).

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

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

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

مكونات تحديث المنطقة الزمنية

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

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

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

تركيب توزيعة

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

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

    تحديثات تطبيق البيانات
    الشكل 1. تحديثات تطبيق البيانات
  2. تقوم عملية خادم النظام بتشغيل فحص التحديث عن طريق بث غرض مستهدف برمز مميز فريد يستخدم مرة واحدة إلى تطبيق Updater. يتتبع خادم النظام أحدث رمز مميز تم إنشاؤه حتى يتمكن من تحديد وقت اكتمال آخر فحص تم تشغيله؛ يتم تجاهل أي رموز أخرى.

    تحديث الزناد
    الشكل 2. التحقق من التحديث الزناد
  3. أثناء التحقق من التحديث ، يقوم تطبيق Updater بالمهام التالية:
    • يستعلم عن حالة الجهاز الحالية عن طريق استدعاء RulesManagerService.

      استدعاء 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 .

مصداقية

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

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

حماية

عند التمكين، يقوم رمز RulesManagerService الموجود في خادم النظام بإجراء عدة فحوصات للتأكد من أن النظام آمن للاستخدام.

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

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

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

لتمكين ميزة تحديث المنطقة الزمنية، يقوم مصنعو المعدات الأصلية عادةً بما يلي:

  • إنشاء تطبيق البيانات الخاص بهم.
  • قم بتضمين تطبيقات Updater وData في بنية صورة النظام.
  • قم بتكوين خادم النظام لتمكين 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 الخاصة بتطبيق Updater and Data في الدليل /system/priv-app الخاص بصورة النظام. وللقيام بذلك، يجب أن يتضمن إنشاء صورة النظام بشكل صريح أهدافًا تم إنشاؤها مسبقًا لتطبيق Updater وتطبيق Data.

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

تكوين خادم النظام

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

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

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

اختبار اكس تي اس

يشير xTS إلى أي مجموعة اختبار خاصة بـ OEM تشبه مجموعات اختبار 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 مدعوم يرغب المصنع في تحديثه. على سبيل المثال، إذا أراد مصنع المعدات الأصلية (OEM) توفير تحديثات لأجهزة Android 8.1 و9 و10، فيجب عليه إكمال العملية ثلاث مرات.

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

في هذه الخطوة، يقوم مصنعو المعدات الأصلية بتقييم التزامات Android system/timezone external/icu من فروع الإصدار -dev في 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 الجديدة في دليل تطبيق البيانات الذي تم إنشاؤه مسبقًا للتأكد من أن صورة النظام واختبارات xTS تحتوي على أحدث ملفات APK. يجب على مصنعي المعدات الأصلية اختبار ما إذا كان الملف الجديد يعمل بشكل صحيح (أي أنه يجتاز CTS وأي اختبارات تلقائية ويدوية خاصة بشركة OEM).
  • بالنسبة للأجهزة التي تم إصدارها والتي لم تعد تتلقى تحديثات النظام، قد يتم إصدار APK الموقع فقط من خلال متجر التطبيقات.

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

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

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

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

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

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

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

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

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

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

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

# رمز الإصدار minSdkVersion {إصدار التنسيق الرئيسي}،{إصدار التنسيق الثانوي}،{إصدار قواعد IANA}،{المراجعة}
1 11000010 يا-MR1 رئيسي = 001، قاصر = 001، إيانا = 2017 أ، المراجعة = 1
2 21000010 ص رئيسي = 002، قاصر = 001، إيانا = 2017 أ، المراجعة = 1
3 11000020 يا-MR1 رئيسي = 001، قاصر = 001، إيانا = 2017 أ، المراجعة = 2
4 11000030 يا-MR1 رئيسي=001، قاصر=001،يانا=2017ب،مراجعة=1
5 21000020 ص رئيسي = 002، قاصر = 001، إيانا = 2017 ب، المراجعة = 1
6 11000040 يا-MR1 رئيسي = 001، قاصر = 001، إيانا = 2018 أ، المراجعة = 1
7 21000030 ص رئيسي = 002، قاصر = 001، إيانا = 2018 أ، المراجعة = 1
8 1123456789 - -
9 11000021 يا-MR1 رئيسي = 001، قاصر = 001، إيانا = 2017 أ، المراجعة = 2، الرد = 2
  • يوضح المثالان 1 و2 إصداري APK لنفس إصدار IANA لعام 2017 أ مع إصدارات تنسيق رئيسية مختلفة. 2 أعلى عدديًا من 1، وهو أمر ضروري لضمان حصول الأجهزة الأحدث على إصدارات التنسيق الأعلى. يضمن minSdkVersion عدم توفير الإصدار P لأجهزة O.
  • المثال 3 عبارة عن مراجعة/إصلاح للرقم 1 وهو أعلى عدديًا من 1.
  • يوضح المثالان 4 و5 إصدارات 2017ب لـ 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.

بناء تطبيق البيانات باستخدام المقبلات

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

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

إنشاء البيان

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

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

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

يحتوي مقتطف البيان التالي على الحد الأدنى من مجموعة مشاريع Git اللازمة لدعم إنشاء O-MR1 لتطبيق بيانات المنطقة الزمنية. يجب على مصنعي المعدات الأصلية إضافة مشاريع Git الخاصة بـ OEM (والتي تتضمن عادةً مشروعًا يحتوي على شهادة التوقيع) إلى هذا البيان، ويمكنهم تكوين فروع مختلفة وفقًا لذلك.

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