بناء حزم OTA

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

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

تم إيقاف تشغيل حزم OTA المستندة إلى الملفات من Android 8.0 للأجهزة غير 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 كثنائي Python واستدعائها لإنشاء حزم إما كاملة أو متزايدة.

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

حول SKUs

تنسيق 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 الوصفية النهائية.