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

من المهم تحديد حجم قسم 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)

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

مع ضغط

باستخدام الضغط، تحتاج عملية تحديث البرامج عبر الأثير (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 أمرًا بسيطًا.

بدون ضغط

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

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

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