تقليل حجم التحديثات عبر الهواء

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

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

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

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

  • استخدام ZSTD، وهي خوارزمية ضغط عامة بدون فقدان البيانات للصور الكاملة في تحديثات الأجهزة غير من النوع أ/ب. يمكن تخصيص ZSTD للحصول على نسب ضغط أعلى عن طريق زيادة مستوى الضغط. يتم ضبط مستوى الضغط أثناء إنشاء التحديث الهوائي ويمكن ضبطه عن طريق تمرير العلامة --vabc_compression_param=zstd,$COMPRESSION_LEVEL
  • زيادة حجم نافذة الضغط المستخدَمة أثناء التحديث الهوائي يمكن ضبط الحد الأقصى لحجم نافذة الضغط عن طريق تخصيص مَعلمة الإصدار في ملف .mk للجهاز. يتم ضبط هذا المتغيّر على PRODUCT_VIRTUAL_AB_COMPRESSION_FACTOR := 262144
  • استخدام أداة Puffin لإعادة الضغط، وهي أداة تصحيح حتمية لتدفقات deflate تتعامل مع وظائف الضغط والاختلاف لإنشاء تحديثات عبر اتصال لاسلكي من النوع أ/ب.
  • تغييرات في استخدام أداة إنشاء الاختلافات، مثل طريقة استخدام مكتبة bsdiff لضغط رموز التصحيح. في Android 9 والإصدارات الأحدث، تختار الأداة bsdiff خوارزمية الضغط التي ستقدّم أفضل نتائج ضغط لرمز التصحيح.
  • أدت التحسينات التي تم إدخالها على update_engine إلى تقليل الذاكرة المستخدَمة عند تطبيق رموز التصحيح لتحديثات الأجهزة من النوع أ/ب.

تتناول الأقسام التالية المشاكل المختلفة التي تؤثر في أحجام تحديثات التحديث الهوائي وحلولها، وأمثلة على تنفيذها في AOSP.

ترتيب الملفات

المشكلة: لا تضمن أنظمة الملفات ترتيب الملفات عند طلب قائمة بالملفات في دليل، على الرغم من أنّها عادةً ما تكون نفسها عند إجراء عملية سحب نفسها. ترتّب أدوات مثل ls النتائج تلقائيًا، ولكن وظيفة أحرف البدل المستخدَمة في أوامر مثل as find and make لا ترتّب النتائج. قبل استخدام هذه الأدوات، عليك ترتيب النتائج.

الحلّ: عند استخدام أدوات مثل find و make مع وظيفة أحرف البدل، عليك ترتيب نتائج هذه الأوامر قبل استخدام ها. عند استخدام $(wildcard) أو $(shell find) في Android.mk ملفات، عليك ترتيبها أيضًا. ترتّب بعض الأدوات، مثل Java، الإدخالات، لذا قبل ترتيب الملفات، تأكَّد من أنّ الأداة التي تستخدمها لم تفعل ذلك من قبل.

أمثلة: تم إصلاح العديد من الحالات في نظام التصميم الأساسي باستخدام ماكرو all-*-files-under المضمّن، الذي يتضمّن all-cpp-files-under (لأنّ العديد من التعريفات كانت موزّعة في ملفات makefiles أخرى). لمعرفة التفاصيل، يُرجى الرجوع إلى ما يلي:

دليل الإصدار

المشكلة: يمكن أن يؤدي تغيير الدليل الذي يتم فيه إنشاء العناصر إلى اختلاف الملفات الثنائية. معظم المسارات في إصدار Android هي مسارات نسبية، لذا لا يمثّل __FILE__ في C/C++ مشكلة. ومع ذلك، ترمز رموز تصحيح الأخطاء إلى اسم المسار الكامل تلقائيًا، ويتم إنشاء .note.gnu.build-id من تجزئة الملف الثنائي الذي تم إزالة أجزاء منه، لذا سيتغيّر إذا تغيّرت رموز تصحيح الأخطاء.

الحلّ: يجعل AOSP الآن مسارات تصحيح الأخطاء نسبية. لمعرفة التفاصيل، يُرجى الرجوع إلى طلب تغيير الرمز البرمجي: https://android.googlesource.com/platform/build/+/6a66a887baadc9eb3d0d60e26f748b8453e27a02.

الطوابع الزمنية

المشكلة: تؤدي الطوابع الزمنية في ناتج الإصدار إلى تغييرات غير ضرورية في الملفات. من المرجّح أن يحدث ذلك في المواقع التالية:

  • ماكرو __DATE__/__TIME__/__TIMESTAMP__ في رمز C أو C++ البرمجي
  • الطوابع الزمنية المضمّنة في الأرشيفات المستندة إلى zip

الحلول/الأمثلة: لإزالة الطوابع الزمنية من ناتج الإصدار، استخدِم التعليمات الواردة أدناه في __DATE__/__TIME__/__TIMESTAMP__ في C/C++. و الطوابع الزمنية المضمّنة في الأرشيفات.

__DATE__/__TIME__/__TIMESTAMP__ في C/C++

تنتج هذه الماكرو دائمًا نتائج مختلفة للإصدارات المختلفة، لذا لا تستخدِمها. في ما يلي بعض الخيارات لإزالة هذه الماكرو:

الطوابع الزمنية المضمّنة في الأرشيفات (zip وjar)

في Android 7.0، تم إصلاح مشكلة الطوابع الزمنية المضمّنة في أرشيفات zip عن طريق إضافة -X إلى جميع استخدامات الأمر zip أدى ذلك إلى إزالة رقم تعريف المستخدم/رقم تعريف المجموعة الخاصين بالمنشئ والطابع الزمني الموسّع لنظام Unix من ملف zip.

تعيد أداة جديدة، هي ziptime (الموجودة في /platform/build/+/android17-release/tools/ziptime/)، ضبط الطوابع الزمنية العادية في عناوين zip. لمعرفة التفاصيل، يُرجى الرجوع إلى ملف README.

تضبط أداة signapk الطوابع الزمنية لملفات APK التي قد تختلف حسب المنطقة الزمنية للخادم. لمعرفة التفاصيل، يُرجى الرجوع إلى طلب تغيير الرمز البرمجي https://android.googlesource.com/platform/build/+/6c41036bcf35fe39162b50d27533f0f3bfab3028.

تضبط أداة signapk الطوابع الزمنية لملفات APK التي قد تختلف حسب المنطقة الزمنية للخادم. لمعرفة التفاصيل، يُرجى الرجوع إلى طلب تغيير الرمز البرمجي https://android.googlesource.com/platform/build/+/6c41036bcf35fe39162b50d27533f0f3bfab3028.

سلاسل الإصدار

المشكلة: غالبًا ما كانت سلاسل إصدار APK تتضمّن BUILD_NUMBER مضافًا إلى إصداراتها المرمّزة. حتى إذا لم يتغيّر أي شيء آخر في ملف APK، سيظل ملف APK مختلفًا نتيجةً لذلك.

الحلّ: عليك إزالة رقم الإصدار من سلسلة إصدار APK.

أمثلة:

تفعيل عملية التحقّق من التكامل على الجهاز فقط

إذا كانت ميزة dm-verity مفعّلة على جهازك، ستختار أدوات التحديث الهوائي تلقائيًا إعدادات التحقّق من التكامل وتفعّل عملية التحقّق من التكامل على الجهاز. يسمح ذلك بحساب كتل التحقّق من التكامل على أجهزة Android ، بدلاً من تخزينها كبايتات أولية في حزمة التحديث الهوائي. يمكن أن تستخدِم كتل التحقّق من التكامل حوالي 16 ميغابايت لقسم بسعة 2 غيغابايت.

ومع ذلك، قد يستغرق حساب التحقّق من التكامل على الجهاز فقط وقتًا طويلاً. على وجه التحديد، يمكن أن يستغرق رمز تصحيح الأخطاء الأمامي وقتًا طويلاً. على أجهزة Pixel، يستغرق ذلك عادةً ما يصل إلى 10 دقائق. على الأجهزة المنخفضة الإمكانات، قد يستغرق ذلك وقتًا أطول. إذا أردت إيقاف عملية التحقّق من التكامل على الجهاز فقط ولكن مع الاستمرار في تفعيل ميزة dm-verity، يمكنك فعل ذلك عن طريق تمرير --disable_fec_computation إلى أداة ota_from_target_files عند إنشاء تحديث عبر اتصال لاسلكي. تؤدي هذه العلامة إلى إيقاف عملية التحقّق من التكامل على الجهاز فقط أثناء التحديثات الهوائية. يقلّل ذلك من وقت تثبيت التحديث الهوائي، ولكنه يزيد من حجم حزمة التحديث الهوائي. إذا لم تكن ميزة dm-verity مفعّلة على جهازك، لن يكون لتمرير هذه العلامة أي تأثير.

أدوات إصدار متسقة

المشكلة: يجب أن تكون الأدوات التي تنشئ الملفات المثبَّتة متسقة (يجب أن ينتج عن أي إدخال معيّن الناتج نفسه دائمًا).

الحلول/الأمثلة: كانت هناك حاجة إلى إجراء تغييرات في أدوات الإصدار التالية:

استخدام أداة مقارنة الإصدارات

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

  • التغييرات المتوقّعة في ناتج الإصدار (على سبيل المثال، بسبب تغيير رقم الإصدار)
  • التغييرات الناتجة عن المشاكل المعروفة في نظام التصميم الحالي

لاستخدام أداة مقارنة الإصدارات، شغِّل الأمر التالي:

target_files_diff.py dir1 dir2

dir1 وdir2 هما الدليلان الأساسيان اللذان يحتويان على ملفات الهدف المستخرَجة لكل إصدار.

الحفاظ على اتساق تخصيص الكتل

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

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

لمعالجة هذه المشكلة، وسّعت Google في Android 7.0 أداة make_ext4fs للحفاظ على اتساق تخصيص الكتل بين الإصدارات. تقبل أداة make_ext4fs علامة اختيارية هي -d base_fs تحاول تخصيص الملفات للكتل نفسها عند إنشاء صورة ext4. يمكنك استخراج ملفات ربط الكتل (مثل ملفات الخريطة base_fs) من ملف zip لملفات الهدف لإصدار سابق. لكل ext4 قسم، هناك ملف .map في دليل IMAGES (على سبيل المثال، يتطابق IMAGES/system.map مع قسم system). يمكن بعد ذلك تسجيل ملفات base_fs هذه وتحديدها من خلال PRODUCT_<partition>_BASE_FS_PATH، كما في هذا المثال: 

  PRODUCT_SYSTEM_BASE_FS_PATH := path/to/base_fs_files/base_system.map
  PRODUCT_SYSTEM_EXT_BASE_FS_PATH := path/to/base_fs_files/base_system_ext.map
  PRODUCT_VENDOR_BASE_FS_PATH := path/to/base_fs_files/base_vendor.map
  PRODUCT_PRODUCT_BASE_FS_PATH := path/to/base_fs_files/base_product.map
  PRODUCT_ODM_BASE_FS_PATH := path/to/base_fs_files/base_odm.map

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

تجنُّب تحديث التطبيقات

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