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

يعمل 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 U وما بعده ولا يمكن العثور عليها في شفرة المصدر. يجب على الشركاء الانتقال بشكل كامل إلى الوحدة النمطية Time Zone Mainline.

في 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 .
• ICU4J / ICU4C كود مكتبة external/icu/ يستخدم ملف icu .dat .

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

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

• libcore/ و bionic/ code تستخدم نسخة /data من ملفات tzdata و tzlookup.xml .
• يستخدم رمز ICU4J / ICU4C الملفات الموجودة في /data والرجوع إلى /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.
   
   

   

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

   

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

     

   • يستعلم عن تطبيق البيانات عن طريق الاستعلام عن محدد مواقع URL محدد جيدًا ومواصفات العمود للحصول على معلومات حول التوزيعة.
     
     

     

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

   

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

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

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

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

config_timeZoneRulesUpdateTrackingEnabled

config_timeZoneRulesDataPackage

config_timeZoneRulesUpdaterPackage

config_timeZoneRulesCheckTimeMillisAllowed

config_timeZoneRulesCheckRetryCount

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

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

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

اسم الإصدار هو تمثيل للتفاصيل يمكن قراءته ، على سبيل المثال: major=001,minor=001,iana=2017a, revision=1,respin=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.

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

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

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

إنشاء البيان

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

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