بناء حزم OTA

يمكنك استخدام أداة ota_from_target_files المتوفرة في build/make/tools/releasetools لإنشاء حزم OTA كاملة ومتزايدة للأجهزة التي تستخدم تحديثات نظام A/B أو تحديثات نظام غير A/B . تأخذ الأداة الملف target-files.zip الذي ينتجه نظام إنشاء Android كمدخل.

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

قام Android 8.0 بإهمال حزم OTA المستندة إلى الملفات للأجهزة غير A/B، والتي يجب بدلاً من ذلك استخدام حزم OTA المستندة إلى الكتلة . لإنشاء حزم OTA قائمة على الكتلة أو أجهزة تعمل بنظام التشغيل Android 7.x أو أقل، قم بتمرير خيار --block إلى المعلمة ota_from_target_files .

بناء التحديثات الكاملة

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

. build/envsetup.sh && lunch tardis-eng
mkdir dist_output
make dist DIST_DIR=dist_output

make dist بإنشاء حزمة OTA كاملة (في $OUT ). يحتوي ملف .zip الناتج على كل ما يلزم لإنشاء حزم OTA لجهاز tardis . يمكنك أيضًا إنشاء ملفات ota_from_target_files كثنائي بيثون واستدعائها لإنشاء حزم كاملة أو تزايدية.

ota_from_target_files dist_output/tardis-target_files.zip ota_update.zip

تم إعداد مسار ota_from_target_files في $PATH ، ويوجد ملف python الثنائي الناتج في الدليل out/ .

ota_update.zip جاهز الآن لإرساله إلى أجهزة الاختبار (تم توقيع كل شيء باستخدام مفتاح الاختبار). بالنسبة لأجهزة المستخدم، قم بإنشاء واستخدام مفاتيحك الخاصة كما هو مفصل في إصدارات التوقيع للإصدار .

بناء التحديثات المتزايدة

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

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

ota_from_target_files -i PREVIOUS-tardis-target_files.zip dist_output/tardis-target_files.zip incremental_ota_update.zip

هذا الإصدار مشابه جدًا للإصدار السابق، وحزمة التحديث التزايدي ( incremental_ota_update.zip ) أصغر بكثير من التحديث الكامل المقابل (حوالي 1 ميجابايت بدلاً من 60 ميجابايت).

قم بتوزيع حزمة تزايدية فقط على الأجهزة التي تعمل تمامًا على نفس البنية السابقة المستخدمة كنقطة بداية للحزمة التزايدية. يجب عليك وميض الصور في PREVIOUS-tardis-target_files.zip أو PREVIOUS-tardis-img.zip (كلاهما مبنيان باستخدام make dist ، ليتم وميضهما باستخدام fastboot update )، بدلاً من تلك الموجودة ضمن دليل PRODUCT_OUT (المبني باستخدام make ، والذي سيتم وميضه باستخدام fastboot flashall ). تؤدي محاولة تثبيت الحزمة التزايدية على جهاز به إصدار آخر إلى حدوث خطأ في التثبيت. عندما يفشل التثبيت، يظل الجهاز في نفس حالة العمل (يعمل بالنظام القديم)؛ تتحقق الحزمة من الحالة السابقة لجميع الملفات التي تقوم بتحديثها قبل لمسها، بحيث لا يبقى الجهاز في حالة نصف ترقية.

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

إنشاء حزم OTA لوحدات SKU المتعددة

يدعم Android 11 أو الإصدارات الأحدث استخدام حزمة OTA واحدة لأجهزة متعددة ذات وحدات SKU مختلفة. يتطلب القيام بذلك تكوين الأجهزة المستهدفة لاستخدام بصمات الأصابع الديناميكية وتحديث بيانات تعريف OTA (باستخدام أدوات OTA) لتضمين اسم الجهاز وبصمة الإصبع في إدخالات الشرط المسبق واللاحق.

حول وحدات SKU

يعد تنسيق SKU بمثابة اختلاف في قيم معلمات البناء المدمجة وعادةً ما يكون مجموعة فرعية غير معلنة من معلمات build_fingerprint الحالية. يمكن لمصنعي المعدات الأصلية استخدام أي مجموعة من معلمات البناء المعتمدة من CDD لـ SKU أثناء استخدام صورة واحدة أيضًا لوحدات SKU هذه. على سبيل المثال، يحتوي SKU التالي على أشكال متعددة:

SKU = <product><device><modifierA><modifierB><modifierC>

• modifierA هو مستوى الجهاز (مثل Pro أو Premium أو Plus)
• modifierB هو نوع الأجهزة (مثل الراديو)
• modifierC هي المنطقة التي يمكن أن تكون عامة (مثل NA أو EMEA أو CHN ) أو خاصة ببلد أو لغة معينة (مثل JPN أو ENG أو CHN)

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

استخدم بصمات الأصابع الديناميكية

بصمة الإصبع عبارة عن سلسلة محددة من معلمات البناء مثل ro.product.brand و ro.product.name و ro.product.device . يتم اشتقاق بصمة الجهاز من بصمة قسم النظام ويتم استخدامها كمعرف فريد للصور (والبايتات) التي تعمل على الجهاز. لإنشاء بصمة ديناميكية ، استخدم المنطق الديناميكي في ملف build.prop الخاص بالجهاز للحصول على قيمة متغيرات أداة تحميل التشغيل في وقت تشغيل الجهاز، ثم استخدم تلك البيانات لإنشاء بصمة ديناميكية لهذا الجهاز.

على سبيل المثال، لاستخدام بصمات الأصابع الديناميكية لأجهزة tardis و tardispro ، قم بتحديث الملفات التالية كما هو موضح أدناه.

• قم بتحديث الملف odm/etc/build_std.prop ليحتوي على السطر التالي.

  ro.odm.product.device=tardis
  

• قم بتحديث الملف odm/etc/build_pro.prop ليحتوي على السطر التالي.

  ro.odm.product.device=tardispro
  

• قم بتحديث الملف odm/etc/build.prop ليحتوي على الأسطر التالية.

  ro.odm.product.device=tardis
  import /odm/etc/build_${ro.boot.product.hardware.sku}.prop
  

تقوم هذه الأسطر بتعيين اسم الجهاز وبصمة الإصبع وقيم ro.build.fingerprint ديناميكيًا استنادًا إلى قيمة خاصية أداة تحميل التشغيل ro.boot.product.hardware.sku (وهي للقراءة فقط).

تحديث البيانات التعريفية لحزمة OTA

تحتوي حزمة OTA على ملف بيانات وصفية ( META-INF/com/android/metadata ) يصف الحزمة، بما في ذلك الشرط المسبق والشرط اللاحق لحزمة OTA. على سبيل المثال، التعليمة البرمجية التالية هي ملف البيانات التعريفية لحزمة OTA التي تستهدف جهاز tardis .

post-build=google/tardis/tardis:11/RP1A.200521.001/6516341:userdebug/dev-keys
post-build-incremental=6516341
post-sdk-level=30
post-security-patch-level=2020-07-05
post-timestamp=1590026334
pre-build=google/tardis/tardis:11/RP1A.200519.002.A1/6515794:userdebug/dev-keys
pre-build-incremental=6515794
pre-device=tardis

تحدد قيم pre-device ، وما pre-build-incremental ، وما pre-build الحالة التي يجب أن يتمتع بها الجهاز قبل أن تتمكن من تثبيت حزمة OTA. تحدد قيم post-build-incremental وقيم post-build الحالة التي من المتوقع أن يتمتع بها الجهاز بعد تثبيت حزمة OTA. يتم اشتقاق قيم الحقول pre- post- من خصائص البناء المقابلة التالية.

• يتم اشتقاق قيمة pre-device من خاصية البناء ro.product.device .
• يتم اشتقاق قيم pre-build-incremental وقيم post-build-incremental من خاصية البناء ro.build.version.incremental .
• يتم اشتقاق قيم pre-build وما post-build من خاصية البناء ro.build.fingerprint .

على الأجهزة التي تعمل بنظام التشغيل Android 11 أو الإصدارات الأحدث، يمكنك استخدام علامة --boot_variable_file في أدوات OTA لتحديد مسار إلى ملف يحتوي على قيم متغيرات وقت التشغيل المستخدمة في إنشاء البصمة الديناميكية للجهاز. يتم بعد ذلك استخدام البيانات لتحديث بيانات تعريف OTA لتضمين اسم الجهاز وبصمة الإصبع في الشروط pre- post- (باستخدام حرف الأنبوب | كمحدد). تحتوي علامة --boot_variable_file على الصيغة والوصف التاليين.

• بناء الجملة: --boot_variable_file <path>
• الوصف: يحدد مسارًا إلى ملف يحتوي على القيم المحتملة لخصائص ro.boot.* . يُستخدم لحساب بصمات وقت التشغيل المحتملة عندما يتم تجاوز بعض خصائص ro.product.* بواسطة عبارة الاستيراد. يتوقع الملف خاصية واحدة في كل سطر حيث يكون لكل سطر التنسيق التالي: prop_name=value1,value2 .

على سبيل المثال، عندما تكون الخاصية هي ro.boot.product.hardware.sku=std,pro ، فإن بيانات تعريف OTA لأجهزة tardis و tardispro تكون كما هو موضح أدناه.

post-build=google/tardis/tardis:11/<suffix>|google/tardis/tardispro:11/<suffix>
pre-build=google/tardis/tardis:11/<suffix>|google/tardis/tardispro:11/<suffix>
pre-device=tardis|tardispro

لدعم هذه الوظيفة على الأجهزة التي تعمل بنظام Android 10، راجع التنفيذ المرجعي . تقوم قائمة التغيير هذه بتحليل بيانات import في ملف build.prop بشكل مشروط، مما يتيح التعرف على تجاوزات الخاصية وانعكاسها في بيانات تعريف OTA النهائية.