هل استخدمت Google ميزة A/B OTA على أي أجهزة؟
نعم. الاسم التسويقي لتحديثات اختبار أ/ب هو التحديثات السلسة. بدءًا من تشرين الأول (أكتوبر) 2016، تم شحن هواتف Pixel وPixel XL
مع ميزة "التحديث الثنائي"، وتستخدم جميع أجهزة Chromebook update_engine
عملية التنفيذ نفسها لميزة "التحديث الثنائي". إنّ تنفيذ رمز النظام الأساسي الضروري متاح للجميع في الإصدار 7.1 من Android
والإصدارات الأحدث.
ما هي مزايا قنوات البيع المباشر عبر الإنترنت (OTA) من النوع A/B؟
توفّر عمليات OTA من النوع A/B تجربة أفضل للمستخدم عند تلقّي التحديثات. تُظهر القياسات من تحديثات الأمان الشهرية أنّ هذه الميزة قد أثبتت نجاحها: اعتبارًا من أيار (مايو) 2017، يستخدم 95% من مالكي هواتف Pixel آخر تحديث للأمان بعد شهر مقارنةً بـ 87% من مستخدمي هواتف Nexus، ويحصل مستخدمو هواتف Pixel على التحديثات في وقت أقرب من مستخدمي هواتف Nexus. في حال تعذّر تحديث أجزاء من نظام التشغيل أثناء عملية التحديث عبر الهواء، لن يؤدي ذلك إلى عدم التمكّن من تشغيل الجهاز، إذ يحتفظ نظام Android بالقدرة على الرجوع إلى صورة النظام السابقة التي تعمل بشكل سليم إلى أن يتم تشغيل صورة النظام الجديدة بنجاح.
ما هو system_other؟
يتم تخزين التطبيقات في ملفات .apk، وهي في الواقع أرشيفات ZIP. يحتوي كل ملف APK .على ملف واحد أو أكثر من ملفات .dex التي تحتوي على رمز Dalvik البرمجي المتوافق مع الأجهزة الجوّالة. يتم تخزين ملف odex. (ملف .dex محسَّن) بشكل منفصل عن ملف .apk ويمكن أن يحتوي على رمز آلي خاص بالجهاز. إذا كان ملف odex .متاحًا، يمكن لنظام التشغيل Android تشغيل التطبيقات بسرعات مُجمَّعة مسبقًا بدون الحاجة إلى الانتظار إلى أن يتم تجميع الرمز البرمجي في كل مرة يتم فيها تشغيل التطبيق. ملفodix. ليس ضروريًا بشكلٍ مطلق: يمكن لنظام التشغيل Android تشغيل ملف .dex مباشرةً من خلال التفسير أو التجميع أثناء التشغيل (JIT)، ولكن يقدّم ملف .odex أفضل تركيبة من سرعة الإطلاق وسرعة التشغيل في حال توفّر مساحة.
مثال: بالنسبة إلى ملف installed-files.txt من جهاز Nexus 6P الذي يعمل بنظام التشغيل Android 7.1 ويبلغ إجمالي حجم صورة النظام 2628 ميغابايت (2755792836 بايت)، في ما يلي تفاصيل أكبر المساهمين في إجمالي حجم صورة النظام حسب نوع الملف:
| .odex | 1391770312 بايت | 50.5% |
| .apk | 846878259 بايت | 30.7% |
| .so (رمز C/C++ الأصلي) | 202162479 بايت | 7.3% |
| ملفات .oat أو صور .art | 163892188 بايت | 5.9% |
| خطوط | 38952361 بايت | 1.4% |
| بيانات لغة icu | 27468687 بايت | 0.9% |
تتشابه هذه الأرقام مع الأجهزة الأخرى أيضًا، لذا على أجهزة Nexus/Pixel، تشغل ملفات .odex
نصف مساحة قسم النظام تقريبًا. هذا يعني أنّه يمكننا مواصلة استخدام ext4 ولكن مع كتابة
ملفات .odex في القسم B في المصنع ثم نسخها إلى /data عند
التشغيل الأول. إنّ مساحة التخزين الفعلية المستخدَمة مع اختبار A/B في ext4 مطابقة لاختبار A/B في SquashFS، لأنّه إذا
استخدمنا SquashFS، كنا سنرسل ملفات .odex التي تم اختيارها مسبقًا على system_a بدلاً من
system_b.
هل يؤدي نسخ ملفات .odex إلى /data إلى فقدان المساحة المحفوظة في /system؟
إجابتك غير صحيحة. على هواتف Pixel، تستهلك التطبيقات عادةً معظم المساحة التي تشغلها ملفات .odex، والتي تكون عادةً
موجودة في /data. تتلقّى هذه التطبيقات تحديثات من Google Play، لذا لا يتم استخدام ملفَي .apk و .odex
في صورة النظام لمعظم فترة استخدام الجهاز. يمكن استبعاد هذه الملفات
بالكامل واستبدالها بملفات .odex صغيرة مستندة إلى الملف الشخصي عندما يستخدم المستخدم كل
تطبيق (وبالتالي لا تتطلب مساحة للتطبيقات التي لا يستخدمها المستخدم). لمعرفة التفاصيل، يُرجى الاطّلاع على محاضرة تطور الفن التي تم إجراؤها في مؤتمر Google
I/O لعام 2016.
إنّ المقارنة صعبة لعدة أسباب رئيسية:
-
كانت ملفات .odex للتطبيقات التي يُجري Google Play تحديثها دائمًا متوفّرة على
/dataبعد تلقّيها تحديثها الأول. - لا تحتاج التطبيقات التي لا يشغّلها المستخدم إلى ملف .odex على الإطلاق.
- يُنشئ التجميع المستنِد إلى الملف الشخصي ملفات odex .أصغر حجمًا من التجميع المُسبَق (لأنّه لا يحسِّن سوى الرموز البرمجية المهمة للأداء).
للحصول على تفاصيل عن خيارات الضبط المتاحة لمصنّعي المعدّات الأصلية، يُرجى الاطّلاع على ضبط ART.
ألا تتوفّر نسختان من ملفات .odex في /data؟
العملية أكثر تعقيدًا قليلاً. بعد كتابة صورة النظام الجديدة، يتم تشغيل الإصدار الجديد
من dex2oat على ملفات .dex الجديدة لإنشاء ملفات .odex الجديدة. ويحدث ذلك
عندما يكون النظام القديم لا يزال قيد التشغيل، لذا يكون ملف odex .القديم والجديد كلاهما في
/data في الوقت نفسه.
يستدعي الرمز البرمجي في OtaDexoptService (frameworks/base/+/main/services/core/java/com/android/server/pm/OtaDexoptService.java) getAvailableSpace قبل تحسين كل حزمة لتجنُّب ملء /data بشكل زائد. يُرجى العِلم أنّ المساحة المتوفّرة هنا لا تزال متحفظة: فهي تمثل مقدار
المساحة المتبقية قبل بلوغ الحدّ المعتاد لانخفاض مساحة النظام (يتم قياسها كنسبة مئوية
وعدد بايت). وبالتالي، إذا كان /data ممتلئًا، لن تكون هناك نسختان من
كل ملف .odex. يحتوي الرمز البرمجي نفسه أيضًا على BULK_DELETE_THRESHOLD: إذا اقترب الجهاز من ملء المساحة المتاحة (كما هو موضّح للتو)، تتم إزالة ملفات .odex التي تنتمي إلى التطبيقات
غير المستخدَمة. هذه حالة أخرى بدون نسختَين من كل ملف .odex.
في أسوأ الحالات، عندما يكون /data ممتلئًا بالكامل، ينتظر التحديث إلى أن تتم إعادة تشغيل
الجهاز للانتقال إلى النظام الجديد ولن يحتاج بعد ذلك إلى ملفات .odex للنظام القديم. يعالج SystemUI (frameworks/base/+/main/services/core/java/com/android/server/pm/PackageManagerService.java#7215) ذلك: بعد تشغيل النظام الجديد بنجاح، يمكن لـ PackageManager (installd) إزالة ملفات .odex التي استخدمها النظام القديم، ما يعيد الجهاز إلى حالته الثابتة التي تتوفّر فيها نسخة واحدة فقط.frameworks/native/+/main/cmds/installd/dexopt.cpp#2422
وبالتالي، على الرغم من أنّه من الممكن أن يحتوي /data على نسختَين من جميع ملفات .odex،
(أ) يكون ذلك مؤقتًا و (ب) لا يحدث إلا إذا كانت لديك مساحة خالية كبيرة على
/data على أي حال. لا تتوفّر سوى نسخة واحدة، باستثناء فترة التحديث. وكجزء من
الميزات العامة لتحسين أداء ART، لن يتم ملء /data بملفات odex .على الإطلاق (لأنّ ذلك قد يتسبب في مشكلة في نظام غير مزوّد بميزة A/B أيضًا).
ألا تؤدي كل عمليات الكتابة أو النسخ هذه إلى زيادة تآكل ذاكرة الفلاش؟
تتم إعادة كتابة جزء صغير فقط من ذاكرة الفلاش: يُكتب تحديث كامل لنظام Pixel حوالي 2.3 غيغابايت. (تتم أيضًا إعادة تجميع التطبيقات، ولكن هذا ينطبق أيضًا على التطبيقات التي لا تستخدم ميزة "A/B"). في العادة، كانت عمليات التحديث الكاملة عبر الهواء المستندة إلى الكتل تُسجِّل مقدارًا مشابهًا من البيانات، لذا من المفترض أن تكون معدّلات استهلاك ذاكرة الفلاش متشابهة.
هل يؤدي فلاش قسمَي نظام إلى زيادة وقت الفلاش من المصنع؟
لا، لم يزداد حجم صورة النظام في هواتف Pixel (لقد قسّمت المساحة على قسمين فقط).
هل يؤدي الاحتفاظ بملفات .odex على الجهاز B إلى إبطاء عملية إعادة التشغيل بعد إعادة الضبط على الإعدادات الأصلية؟
نعم. إذا كنت قد استخدمت جهازًا وتلقّيت تحديثًا من خلال شبكة الجوّال وأعدت ضبطه على الإعدادات الأصلية، ستكون عملية
إعادة التشغيل الأولى أبطأ من المعتاد (1 دقيقة و40 ثانية مقابل 40 ثانية على هاتف Pixel XL) لأنّه
سيتم فقدان ملفات .odex من الجهاز "ب" بعد تحديث OTA الأول، وبالتالي لا يمكن نسخها إلى
/data. هذا هو الخيار البديل.
من المفترض أن تكون عملية إعادة الضبط على الإعدادات الأصلية نادرة مقارنةً بعمليات التشغيل العادية، لذا فإنّ الوقت المستغرَق
ليس مهمًا. (لا يؤثّر ذلك في المستخدمين أو المراجعين الذين يحصلون على أجهزتهم من
المصنع، لأنّه في هذه الحالة يكون القسم B متاحًا). يعني استخدام المُجمِّع JIT أنّنا
لا نحتاج إلى إعادة تجميع كل شيء، لذا فإنّ الأمر ليس سيئًا كما قد تتصور. من المُمكن أيضًا
وضع علامة على التطبيقات على أنّها تتطلّب الترجمة المسبقة باستخدام
coreApp="true" في البيان: (frameworks/base/+/main/packages/SystemUI/AndroidManifest.xml#23). ويستخدم system_server هذا الإجراء حاليًا لأنّه لا يُسمح له باستخدام JIT لسبب
يتعلّق بالأمان.
هل يؤدي الاحتفاظ بملفات .odex في /data بدلاً من /system إلى إبطاء عملية إعادة التشغيل بعد التحديث عبر الهواء؟
لا، كما هو موضّح أعلاه، يتم تشغيل أداة dex2oat الجديدة عندما تكون صورة النظام القديمة لا تزال تعمل لأجل إنشاء الملفات التي سيحتاج إليها النظام الجديد. ولا يُعتبر التحديث متاحًا إلا بعد إكمال هذا العمل.
هل يمكننا (أو يجب علينا) شحن جهاز A/B بسعة 32 غيغابايت؟ 16 غيغابايت؟ 8 غيغابايت؟
تعمل سعة 32 غيغابايت بشكل جيد كما تبيّن على هواتف Pixel، ويعني حجم 320 ميغابايت من أصل 16 غيغابايت انخفاضًا بنسبة %2. وبالمثل، فإنّ 320 ميغابايت من 8 غيغابايت يمثّل انخفاضًا بنسبة %4. من الواضح أنّ اختبار A/B لن يكون الخيار المُقترَح على الأجهزة التي تبلغ سعتها 4 غيغابايت، لأنّ مساحة التخزين الإضافية التي تبلغ 320 ميغابايت تُمثّل% 10 تقريبًا من إجمالي المساحة المتاحة.
هل يتطلب AVB2.0 عمليات تحديث البرامج التلقائية عبر الإنترنت (OTA) لاختبار أ/ب؟
لا، فقد كان وضع التشغيل المتحقّق منه في Android يتطلّب دائمًا التحديثات المستندة إلى الحِزم، ولكن ليس بالضرورة تحديثات A/B.
هل تتطلّب عمليات تحديث البرامج التلقائية من النوع أ/ب استخدام AVB2.0؟
لا.
هل تؤدي تحديثات A/B عبر الهواء إلى إيقاف ميزة حماية AVB2.0 للرجوع إلى إصدار سابق؟
لا، هناك بعض الالتباس هنا لأنّه إذا تعذّر على نظام A/B التمهيد إلى ملف تعريف النظام الجديد، سيتم تلقائيًا التمهيد إلى ملف تعريف النظام "السابق" (بعد عدد من عمليات إعادة المحاولة التي يحدّدها مشغّل الإقلاع). ومع ذلك، فإنّ النقطة الرئيسية هنا هي أنّ "الإصدار السابق" في سياق التحديث بالتبديل بين الإصدارين لا يزال هو صورة النظام "الحالية". بعد أن يتم تشغيل الجهاز بنجاح باستخدام صورة جديدة، يتم تفعيل ميزة الحماية من الرجوع إلى الإصدار السابق لضمان عدم التمكّن من الرجوع إلى الإصدار السابق. ولكن إلى أن تتم عملية تشغيل الصورة الجديدة بنجاح، لن تُعتبر ميزة "الحماية من الرجوع إلى إصدار سابق" أنّها صورة النظام الحالية.
إذا كنت بصدد تثبيت تحديث أثناء تشغيل النظام، ألا يكون ذلك بطيئًا؟
في ما يتعلّق بالتحديثات غير المستندة إلى تقنية A/B، يكون الهدف هو تثبيت التحديث في أسرع وقت ممكن لأنّ المستخدم ينتظر التحديث ولا يمكنه استخدام جهازه أثناء تطبيقه. في ما يتعلّق بالتحديثات المستندة إلى اختبار أ/ب، ينطبق العكس، لأنّ المستخدم لا يزال يستخدم جهازه، لذا فإنّ الهدف هو الحد الأدنى من التأثير ، لذلك يكون التحديث بطيئًا عن قصد. من خلال منطق في برنامج Java لتعديل نظام التشغيل (الذي يُعرف لدى Google باسم GmsCore، وهو الحزمة الأساسية التي تقدّمها حِزم Google Mobile Services)، يحاول Android أيضًا اختيار وقت لا يستخدم فيه المستخدمون أجهزتهم على الإطلاق. تتيح المنصة إيقاف التحديث مؤقتًا أو استئنافه، ويمكن للعميل استخدام ذلك لإيقاف التحديث مؤقتًا إذا بدأ المستخدم استخدام الجهاز واستئنافه عندما يكون الجهاز غير نشط مرة أخرى.
هناك مرحلتان أثناء إجراء تحديث عبر الهواء، ويتم عرضهما بوضوح في واجهة المستخدم على أنّهما الخطوة 1 من 2 و الخطوة 2 من 2 أسفل شريط التقدم. تتوافق الخطوة 1 مع كتابة كتل البيانات، في حين أنّ الخطوة 2 هي عملية تجميع ملفات .dex مسبقًا. تختلف هاتان المرحلتان تمامًا من حيث تأثيرهما في الأداء. المرحلة الأولى هي عمليات الإدخال/الإخراج البسيطة. لا يتطلّب هذا الإجراء سوى موارد محدودة، مثل ذاكرة الوصول العشوائي ووحدة المعالجة المركزية وعمليات الإدخال/الإخراج، لأنّه لا يجري سوى نسخ الكتل ببطء.
تعمل المرحلة الثانية على تشغيل dex2oat لإنشاء ملف مُجمَّع مسبقًا لصورة النظام الجديدة. من الواضح أنّ هذه العملية لها حدود أقل وأقل وضوحًا لمتطلباتها لأنّها تُجمِّع تطبيقات فعلية. ومن الواضح أنّه يتطلّب الأمر جهدًا أكبر في تجميع تطبيق كبير ومعقد مقارنةً بتطبيق صغير وبسيط، في حين لا تتوفّر في المرحلة 1 أيّ وحدات تخزين أكبر أو أكثر تعقيدًا من غيرها.
تشبه هذه العملية عملية تثبيت Google Play لتحديث أحد التطبيقات في الخلفية قبل عرض إشعار تم تحديث 5 تطبيقات، كما كان يحدث منذ سنوات.
ماذا لو كان المستخدم في انتظار التحديث؟
لا يميز التنفيذ الحالي في GmsCore بين التحديثات التي يتم إجراؤها في الخلفية والتحديثات التي يبدأها المستخدم، ولكن قد يتم إجراء ذلك في المستقبل. في حال طلب المستخدم صراحةً تثبيت التحديث أو كان يشاهد شاشة مستوى تقدّم التحديث، سنمنح الأولوية لعملية التحديث على افتراض أنّه ينتظر بنشاط اكتمالها.
ماذا يحدث في حال تعذّر تطبيق تحديث؟
في حال تعذّر تطبيق تحديث غير من النوع A/B، كان المستخدم يبقى عادةً بدون جهاز قابل للاستخدام. وكان الاستثناء الوحيد هو إذا حدثت المشكلة قبل بدء أحد التطبيقات (مثلاً بسبب تعذّر إثبات صحة الحزمة). في حال تعذّر تطبيق تحديث باستخدام ميزة "التحديثات التجريبية"، لن يؤثّر ذلك في النظام الذي يعمل حاليًا. ويمكن إعادة محاولة إجراء التحديث لاحقًا.