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

الروبوت 10 يستنكر الوقت آلية تحديث البيانات المنطقة على أساس APK (متوفرة في أندرويد 8.1 وأندرويد 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 والبيانات

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

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

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

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

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

ملفات Distro

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

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

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

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

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

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

تركيب Distro

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

  1. يتم تحديث التطبيق البيانات من خلال تحميل التطبيق تخزين أو sideload. عملية الخادم النظام (من خلال timezone.RulesManagerServer/timezone.PackageTracker الطبقات) ساعات لإجراء تغييرات في تكوين، OEM محددة، البيانات اسم الحزمة التطبيق.

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

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

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

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

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

مصداقية

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

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

حماية

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

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

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

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

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

  • قم بإنشاء تطبيق البيانات الخاص بهم.
  • قم بتضمين تطبيقي المحدث والبيانات في بنية صورة النظام.
  • قم بتكوين خادم النظام لتمكين 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 دليل صورة النظام. للقيام بذلك ، يجب أن تتضمن بنية صورة النظام بشكل صريح تطبيق 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 يحتوي على بنية الدليل عينة بما في ذلك اختبارات في Tradefed مثل XTS جناح. كما هو الحال مع أدلة القوالب الأخرى ، من المتوقع أن يقوم مصنعي المعدات الأصلية بالنسخ والتخصيص حسب احتياجاتهم.
  • packages/apps/TimeZoneData/oem_template/data_app_prebuilt يحتوي على التكوين وقت الإنشاء لإدراج ملفات APK للاختبار بنيت قبل المطلوبة من قبل الاختبار.

إنشاء تحديثات المنطقة الزمنية

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

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

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

في هذه الخطوة، مصنعي المعدات الأصلية تأخذ يرتكب الأسهم الروبوت ل system/timezone و external/icu من فروع الإفراج -dev في AOSP وتنطبق تلك يرتكب إلى النسخة الخاصة بهم من شفرة المصدر الروبوت.

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

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

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

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

إنشاء البيان

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

  • ويتضمن مشروع بوابة واحدة ملفات التطبيقات مثل الظاهر وملفات البناء اللازمة لإنشاء ملف 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" />

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

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

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

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