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

يعمل Android 10 على إبطال آلية تحديث بيانات المنطقة الزمنية المستندة إلى APK (المتوفرة في Android 8.1 و Android 9) واستبدالها بآلية تحديث للوحدة المستندة إلى APEX . يستمر AOSP في تضمين رمز النظام الأساسي الضروري لمصنعي المعدات الأصلية لتمكين التحديثات المستندة إلى 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)

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

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

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

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

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

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

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

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

ملفات Distro

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

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

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

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

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

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

تركيب Distro

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

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

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

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

      Call RulesManagerService
      الشكل 3. تحديثات تطبيق البيانات ، استدعاء RulesManagerService
    • يستعلم عن تطبيق البيانات عن طريق الاستعلام عن عنوان URL محدد جيدًا ومواصفات العمود للحصول على معلومات حول التوزيعة.

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

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

الموثوقية

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

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

حماية

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

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

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

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

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

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

خطة

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

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

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

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

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

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

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

بما في ذلك تطبيقات المحدث والبيانات في صورة النظام

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

يجب توقيع تطبيق 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
تم تكوينه لتطبيق Updater الافتراضي. التغيير فقط عند توفير تطبيق مختلف لتطبيق Updater. لا
config_timeZoneRulesCheckTimeMillisAllowed
يُسمح بالوقت بين فحص التحديث الذي يتم تشغيله بواسطة RulesManagerService واستجابة التثبيت أو إلغاء التثبيت أو عدم القيام بأي شيء. بعد هذه النقطة ، قد يتم إنشاء مشغل موثوقية تلقائي. لا
config_timeZoneRulesCheckRetryCount
عدد عمليات التحقق من التحديث المتسلسلة غير الناجحة المسموح بها قبل أن تتوقف RulesManagerService عن إنشاء المزيد. لا

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

اختبار xTS

يشير 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 تحتوي على تكوين وقت 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 :=

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

الخطوة الثالثة: إعادة البناء والتوقيع والاختبار والإفراج

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

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

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

إستراتيجية كود إصدار تطبيق البيانات

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

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

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

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

# كود الإصدار الإصدار minSdk {إصدار التنسيق الرئيسي} ، {إصدار التنسيق الثانوي} ، {إصدار قواعد IANA} ، {المراجعة}
1 11000010 O-MR1 رئيسي = 001 ، ثانوي = 001 ، iana = 2017a ، مراجعة = 1
2 21000010 ص رئيسي = 002 ، ثانوي = 001 ، iana = 2017a ، مراجعة = 1
3 11000020 O-MR1 رئيسي = 001 ، ثانوي = 001 ، iana = 2017a ، مراجعة = 2
4 11000030 O-MR1 رئيسي = 001 ، ثانوي = 001 ، iana = 2017 ب ، مراجعة = 1
5 21000020 ص رئيسي = 002 ، ثانوي = 001 ، iana = 2017 ب ، مراجعة = 1
6 11000040 O-MR1 رئيسي = 001 ، ثانوي = 001 ، iana = 2018a ، مراجعة = 1
7 21000030 ص رئيسي = 002 ، ثانوي = 001 ، iana = 2018a ، مراجعة = 1
8 1123456789 - -
9 11000021 O-MR1 رئيسي = 001 ، ثانوي = 001 ، iana = 2017a ، مراجعة = 2 ، ريبين = 2
  • يُظهر المثالان 1 و 2 إصدارين لملف APK لنفس إصدار 2017a من IANA بإصدارات تنسيقات رئيسية مختلفة. 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.

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

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

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

إنشاء البيان

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

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

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

يحتوي مقتطف البيان التالي على الحد الأدنى من مجموعة مشاريع 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="master"
        clone_depth="1" />
    <repo-hooks
        in-project="platform/tools/repohooks"
        enabled-list="pre-upload" />

تشغيل بناء تاباس

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

0 درهم

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