إنشاء حِزم OTA

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

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

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

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

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

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

ينشئ make dist حزمة كاملة عبر الهواء (في $OUT). ملف .zip الناتج يحتوي على كل ما يلزم لإنشاء حزم عبر الهواء لجهاز 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 جاهزًا الآن لإرساله إلى الأجهزة الاختبارية (يتم توقيع كل شيء باستخدام مفتاح الاختبار). بالنسبة إلى أجهزة المستخدمين، يمكنك إنشاء مفاتيحك الخاصة واستخدامها كـ بالتفصيل في إصدارات توقيع الإصدار.

إنشاء تحديثات تدريجية

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

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

إنشاء حزم التحديث عبر الهواء لرموز تخزين تعريفية متعددة

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

لمحة عن رموز التخزين التعريفية

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

SKU = <product><device><modifierA><modifierB><modifierC>
  • modifierA هو مستوى الجهاز (مثل Pro أو Premium أو Plus)
  • modifierB هو تنوع الأجهزة (مثل راديو)
  • modifierC هي المنطقة، التي يمكن أن تكون عامة. (مثل أمريكا الشمالية أو أوروبا والشرق الأوسط وأفريقيا أو الصين ) أو ملفات خاصة بكل بلد أو لغة (مثل اليابان، ENG أو CHN)

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

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

على سبيل المثال، عندما تكون الخاصية ro.boot.product.hardware.sku=std,pro، تظهر البيانات الوصفية عبر الهواء لجهازَي 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. ، الذي يتيح التعرّف على إلغاءات الخصائص وإظهارها في البيانات الوصفية النهائية عبر اتصال لاسلكي.