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

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

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

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

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

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

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

بدون ضغط

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

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

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

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

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

مع الضغط

عند استخدام ميزة الضغط، تحتاج عملية التحديث عبر الهواء الكاملة إلى لقطة شاشة تبلغ نسبتها ‎70% تقريبًا من حجم نظام التشغيل:

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

على سبيل المثال، لنفترض أنّ هناك جهازًا تم ضبطه باستخدام ميزة "التصغير الافتراضي"، وحجمه الأصلي هو 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

وبالتالي، من المفترض أن يتضمّن هذا الجهاز قسمًا بسعة 9.2 غيغابايت super.

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

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

بدون ضغط

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

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

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

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

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

مع الضغط

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

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

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

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

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

المحاذير

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

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

احتساب الحجم

للعثور على قيمة FinalDessertSize في الأمثلة أعلاه، أضِف أحجام كل القسمت الديناميكية معًا. صور الأقسام الديناميكية في نظام التشغيل 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 وأحدث صورة super لاحتساب معدّل النمو.