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

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

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

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

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

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

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

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

المشكلة: لا تضمن أنظمة الملفات ترتيب الملفات عند طلب قائمة الملفات في دليل، على الرغم من أنها عادةً ما تكون هي نفسها في عملية الدفع نفسها. أدوات مثل تعمل ميزة ls على ترتيب النتائج تلقائيًا، ولكن يتم استخدام دالة حرف البدل في الطلبات مثل حيث لا يتم الترتيب بين find و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. للحصول على التفاصيل، راجع CL: 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. أدى ذلك إلى إزالة المعرف الفريد/GID والطابع الزمني الممتد لنظام Unix من ملف ZIP.

أداة جديدة، ziptime (تتوفر في /platform/build/+/main/tools/ziptime/) إلى إعادة ضبط الطوابع الزمنية العادية في عناوين ملفات ZIP. للحصول على التفاصيل، يُرجى الرجوع إلى ملفّ README

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

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

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

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

الحل: أزِل رقم الإصدار من سلسلة إصدار APK.

أمثلة:

تفعيل عملية احتساب صحة البيانات على الجهاز

في حال اختيار dm-verity على جهازك، فستلتقط أدوات OTA إعدادات الصحّة تلقائيًا تعمل على تفعيل احتساب الحقيقة على الجهاز فقط يسمح هذا الإجراء باحتساب وحدات الحقيقة على نظام 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 هما دليلان أساسيان يحتويان على الهدف المستخرج. الملفات لكل إصدار.

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

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

عند إجراء تحديث عبر الهواء العادي A/B من خلال Virtual A/B، يمكن أن يؤدي إدخال/إخراج غير ضروري إلى زيادة كبيرة في مساحة التخزين المطلوبة لتخزين لقطة النسخ عند الكتابة. في تحديث غير A/B عبر الهواء، يؤدي تحريك الكتل البرمجية للحصول على يساهم تحديث التحديث عبر الهواء في وقت التحديث بسبب زيادة وحدات الإدخال والإخراج بسبب نقل الكتل.

لمعالجة هذه المشكلة، وسّعت Google في الإصدار 7.0 من نظام التشغيل Android أداة 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

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

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

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