يعد تغيير حجم القسم super
بشكل صحيح أمرًا مهمًا لقابلية تحديث الجهاز. ويؤثر الحجم بشكل مباشر على عدد التحديثات التي يمكن للجهاز تلقيها وعدد المستخدمين الذين يمكنهم إجراء هذه التحديثات بنجاح.
هناك بعض المتغيرات الهامة التي يجب مراعاتها. الأول هو حجم المصنع ، وهو حجم جميع الأقسام الديناميكية عند وميض الجهاز لأول مرة. والثاني هو معدل النمو ، وهي النسبة المئوية لحجم نظام التشغيل الذي يزيد على مدار عمر الجهاز القابل للتحديث بالكامل.
بالإضافة إلى ذلك، يمكن لأجهزة A/B الافتراضية استخدام المساحة على /data
أثناء التحديث، ويجب أخذ ذلك في الاعتبار عند تحديد super
. إذا كانت هناك حاجة إلى مساحة كبيرة جدًا على /data
، فإن بعض المستخدمين غير قادرين (أو غير راغبين) في إجراء التحديث. ومع ذلك، إذا كان من المعروف أن معظم المستخدمين لديهم نسبة معينة من المساحة الفارغة، فيمكن للأجهزة أن تطرح هذه المساحة بشكل مريح من super
. أو يمكن للأجهزة أن تضمن عدم الحاجة /data
أبدًا، وذلك ببساطة عن طريق جعلها كبيرة super
بما يكفي.
فيما يلي بعض النماذج للمساعدة في توجيه حجم القسم super
بناءً على هذه المتغيرات.
الاعتماد على / البيانات
يشجع Virtual 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)
وبالتالي، يجب أن يحتوي هذا الجهاز على قسم super
11 جيجابايت.
مع الضغط
مع الضغط، يحتاج OTA الكامل إلى لقطة تبلغ حوالي 70% من حجم نظام التشغيل:
FinalDessertSize = FactorySize + (FactorySize * ExpectedGrowth) FinalOTASnapshotSize = FinalDessertSize * 0.7 Super = Max(FinalDessertUpdate, FinalDessertSize + FinalOTASnapshotSize - AllowedUserdataUse)
على سبيل المثال، ضع في اعتبارك جهازًا تم تكوينه باستخدام ضغط 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
على سبيل المثال، لنأخذ بعين الاعتبار جهاز A/B افتراضي بحجم مصنع يبلغ 4 جيجابايت ونمو متوقع بنسبة 50%. للتأكد من أن هذا الجهاز لا يستخدم أبدًا /data
للقطات عبر الهواء، ستبدو حساباته كما يلي:
FinalDessertSize = 4GB + (4GB * 0.5) = 6GB Super = FinalDessertSize * 2 = 12GB
وبالتالي، يجب أن يحتوي هذا الجهاز على قسم super
12 جيجابايت.
مع الضغط
بالنسبة لجهاز A/B الظاهري مع الضغط:
FinalDessertSize = FactorySize + (FactorySize * ExpectedGrowth) FinalOTASnapshotSize = FinalDessertSize * 0.7 Super = FinalDessertSize + FinalOTASnapshotSize
على سبيل المثال، ضع في اعتبارك جهاز ضغط A/B افتراضي بحجم مصنع يبلغ 4 جيجابايت ونمو متوقع بنسبة 50%. للتأكد من أن هذا الجهاز لا يستخدم أبدًا /data
للقطات عبر الهواء، ستبدو حساباته كما يلي:
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، فإن الضغط الإضافي من Virtual 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
الأقدم والأحدث لحساب النمو.