تحديد حجم القسم الفائق

من المهم تحديد حجم قسم super بشكل صحيح لضمان إمكانية تحديث الجهاز. يؤثر الحجم بشكل مباشر في عدد التحديثات التي يمكن للجهاز تلقّيها وعدد المستخدمين الذين يمكنهم تلقّي هذه التحديثات بنجاح.

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

بالإضافة إلى ذلك، يمكن لأجهزة Virtual A/B استخدام مساحة على /data أثناء التحديث، ويجب أخذ ذلك في الاعتبار عند تحديد حجم super. إذا كانت المساحة المطلوبة كبيرة جدًا على /data، لن يتمكّن بعض المستخدمين من تثبيت التحديث (أو لن يرغبوا في ذلك). ومع ذلك، إذا كان معروفًا أنّ معظم المستخدمين لديهم نسبة مئوية من المساحة الحرة، يمكن للأجهزة أن تطرح هذه المساحة من super بسهولة. أو يمكن للأجهزة ضمان عدم الحاجة إلى /data مطلقًا، وذلك ببساطة عن طريق جعل super كبيرًا بما يكفي.

في ما يلي بعض النماذج التي تساعد في توجيه عملية تحديد حجم أقسام super استنادًا إلى هذه المتغيرات.

الاعتماد على /data

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

بدون ضغط

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

  FinalDessertSize = FactorySize + (FactorySize * ExpectedGrowth)
  Super = Max(FinalDessertUpdate, FinalDessertSize * 2 - AllowedUserdataUse)

على سبيل المثال، لنفترض أنّ لديك جهازًا يعمل بنظام التشغيل Virtual A/B وتبلغ مساحته المتوفرة عند إعداده 4 غيغابايت، ومن المتوقّع أن تزيد المساحة بنسبة %50، وأنّ معظم المستخدمين لديهم مساحة خالية تبلغ 1 غيغابايت (أو أنّهم على استعداد لإخلاء مساحة تصل إلى 1 غيغابايت لإجراء تحديث). بالنسبة إلى هذا الجهاز، يمكن تحديد حجم super على النحو التالي:

  FinalDessertSize = 4GB + (4GB * 0.5) = 6GB
  Super = Max(6GB, 6GB * 2 - 1GB) = Max(6GB, 11GB)

وبالتالي، يجب أن يتضمّن هذا الجهاز قسمًا بحجم 11 غيغابايت super.

مع ضغط

باستخدام الضغط، تحتاج عملية تحديث عبر الأثير (OTA) كاملة إلى لقطة بحجم% 70 تقريبًا من حجم نظام التشغيل:

  FinalDessertSize = FactorySize + (FactorySize * ExpectedGrowth)
  FinalOTASnapshotSize = FinalDessertSize * 0.7
  Super = Max(FinalDessertUpdate, FinalDessertSize + FinalOTASnapshotSize - AllowedUserdataUse)

على سبيل المثال، لنفترض أنّ هناك جهازًا تم إعداده باستخدام ضغط Virtual A/B، وبحجم مصنع يبلغ 4 غيغابايت، ونسبة نمو متوقّعة تبلغ %50، ومعرفة أنّ جميع المستخدمين تقريبًا لديهم مساحة خالية تبلغ 1 غيغابايت (أو أنّهم على استعداد لتوفير مساحة تصل إلى 1 غيغابايت لإجراء تحديث). بالنسبة إلى هذا الجهاز، يمكن تحديد حجم super على النحو التالي: 

  FinalDessertSize = 4GB + (4GB * 0.5) = 6GB
  FinalOTASnapshotSize = 6GB * 0.7 = 4.2GB
  Super = Max(6GB, 6GB + 4.2GB - 1GB) = Max(6GB, 9.2GB) = 9.2GB

وبالتالي، يجب أن يحتوي هذا الجهاز على قسم super بسعة 9.2 غيغابايت.

بدون الاعتماد على /data

إذا كنت تريد إجراء تحديثات عبر الأثير لا تتطلّب أبدًا مساحة لإنشاء لقطة على /data، فإنّ تحديد حجم super يكون بسيطًا.

بدون ضغط

بالنسبة إلى جهاز A/B افتراضي بدون ضغط أو جهاز A/B عادي:

  FinalDessertSize = FactorySize + (FactorySize * ExpectedGrowth)
  Super = FinalDessertSize * 2

على سبيل المثال، لنفترض أنّ لديك جهازًا يعمل بنظام التشغيل Virtual A/B ويبلغ حجمه الأصلي 4 غيغابايت ومن المتوقّع أن يزداد حجمه بنسبة %50. لضمان عدم استخدام هذا الجهاز /data مطلقًا للحصول على لقطات عبر اتصال لاسلكي، ستكون عملية الحساب كما يلي:

  FinalDessertSize = 4GB + (4GB * 0.5) = 6GB
  Super = FinalDessertSize * 2 = 12GB

وبالتالي، يجب أن يتضمّن هذا الجهاز قسمًا بحجم 12 غيغابايت super.

مع ضغط

بالنسبة إلى جهاز Virtual A/B مع ضغط:

  FinalDessertSize = FactorySize + (FactorySize * ExpectedGrowth)
  FinalOTASnapshotSize = FinalDessertSize * 0.7
  Super = FinalDessertSize + FinalOTASnapshotSize

على سبيل المثال، لنفترض أنّ لديك جهازًا يستخدم ضغط Virtual A/B بحجم مصنع يبلغ 4 غيغابايت ونسبة نمو متوقّعة تبلغ %50. لضمان عدم استخدام هذا الجهاز /data مطلقًا للحصول على لقطات OTA، ستكون عملية الحساب كما يلي:

  FinalDessertSize = 4GB + (4GB * 0.5) = 6GB
  FinalOTASnapshotSize = 6GB * 0.7 = 4.2GB
  Super = 6GB + 4.2GB = 10.2GB

وبالتالي، يجب أن يحتوي هذا الجهاز على قسم super بسعة 10.2 غيغابايت.

المحاذير

قد يكون من المغري ملاحظة أنّه إذا كان حجم المصنع 4 غيغابايت، وكان التحديث النهائي 5 غيغابايت، يجب أن يكون حجم super 9 غيغابايت بدلاً من 10 غيغابايت. ومع ذلك، إذا كان حجم التحديث الأول والتحديث الأخير 5 غيغابايت، قد لا تكون المساحة المتوفّرة في super كافية للتحديث الأخير. تفترض الصيغ أعلاه أنّ نمو الأقسام يمكن أن يحدث في أي وقت. قد تكون المساحة المطلوبة لتطبيق التحديث النهائي هي نفسها المساحة المطلوبة لتطبيق التحديث الأول.

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

احتساب الحجم

للعثور على قيمة FactorySize في الأمثلة السابقة، اجمع أحجام جميع الأقسام الديناميكية معًا. صور الأقسام الديناميكية في AOSP هي:

  • system.img
  • vendor.img
  • product.img
  • system_ext.img
  • vendor_dlkm.img
  • system_dlkm.img

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

يمكن أيضًا حساب أحجام الأقسام من حزمة OTA. يؤدي ذلك أيضًا إلى تقدير حجم اللقطة في اختبار A/B الافتراضي لكل قسم:

  python3 system/update_engine/scripts/payload_info.py path/to/ota-package.zip

أو يمكنك استخدام أداة تحليل OTA. لا تحمّل هذه الأداة أي ملفات، بل تحلّل حِزم OTA على الجهاز.

للعثور على قيمة ExpectedGrowth، استخدِم جهازًا تم إصداره سابقًا. استخدِم صورة super الأقدم والأحدث لاحتساب النمو.