الأسئلة الشائعة

هل استخدمت Google A/B OTAs على أي أجهزة؟

نعم. الاسم التسويقي لتحديثات A/B هو التحديثات السلسة . يتم شحن هواتف Pixel وPixel XL اعتبارًا من أكتوبر 2016 مع A/B، وتستخدم جميع أجهزة Chromebook نفس تنفيذ update_engine لـ A/B. إن تنفيذ كود النظام الأساسي الضروري متاح للعامة في Android 7.1 والإصدارات الأحدث.

لماذا تعتبر وكالات السفر عبر الإنترنت A/B أفضل؟

توفر A/B OTAs تجربة أفضل للمستخدم عند تلقي التحديثات. تظهر قياسات التحديثات الأمنية الشهرية أن هذه الميزة قد أثبتت نجاحها بالفعل: اعتبارًا من مايو 2017، يقوم 95% من مالكي Pixel بتشغيل آخر تحديث أمني بعد شهر مقارنة بـ 87% من مستخدمي Nexus، ويقوم مستخدمو Pixel بالتحديث في وقت أقرب من مستخدمي Nexus. لم يعد الفشل في تحديث الكتل أثناء OTA يؤدي إلى عدم تشغيل الجهاز؛ وإلى أن يتم تشغيل صورة النظام الجديد بنجاح، يحتفظ Android بالقدرة على الرجوع إلى صورة نظام العمل السابقة.

كيف أثر A/B على أحجام أقسام البكسل لعام 2016؟

يحتوي الجدول التالي على تفاصيل حول تكوين A/B للشحن مقابل التكوين غير A/B الذي تم اختباره داخليًا:

تتطلب تحديثات A/B زيادة قدرها 320 ميجابايت فقط في الفلاش، مع توفير 32 ميجابايت من إزالة قسم الاسترداد وحفظ 100 ميجابايت أخرى عن طريق إزالة قسم ذاكرة التخزين المؤقت. يؤدي هذا إلى موازنة تكلفة الأقسام B لمحمل التشغيل وقسم التمهيد وقسم الراديو. تضاعف حجم قسم البائع (الغالبية العظمى من زيادة الحجم). تبلغ صورة نظام Pixel A/B نصف حجم الصورة الأصلية للنظام غير A/B.

بالنسبة لمتغيرات Pixel A/B وغير A/B التي تم اختبارها داخليًا (يتم شحن A/B فقط)، اختلفت المساحة المستخدمة بمقدار 320 ميجابايت فقط. أما على الأجهزة التي تبلغ سعتها 32 غيغابايت، فتبلغ هذه النسبة أقل بقليل من 1%. بالنسبة لجهاز 16 جيجا بايت، سيكون هذا أقل من 2%، وبالنسبة لجهاز 8 جيجا بايت تقريبًا 4% (بافتراض أن جميع الأجهزة الثلاثة لها نفس صورة النظام).

لماذا لم تستخدم SquashFS؟

لقد جربنا SquashFS لكننا لم نتمكن من تحقيق الأداء المطلوب لجهاز متطور. نحن لا نستخدم SquashFS أو نوصي به للأجهزة المحمولة.

وبشكل أكثر تحديدًا، وفر SquashFS حوالي 50% من حجم قسم النظام، ولكن الغالبية العظمى من الملفات التي تم ضغطها جيدًا كانت ملفات .odex المترجمة مسبقًا. كانت لتلك الملفات نسب ضغط عالية جدًا (تقترب من 80%)، لكن نسبة الضغط لبقية قسم النظام كانت أقل بكثير. بالإضافة إلى ذلك، أثار SquashFS في Android 7.0 مخاوف الأداء التالية:

• يحتوي Pixel على فلاش سريع جدًا مقارنة بالأجهزة السابقة ولكن ليس عددًا كبيرًا من دورات وحدة المعالجة المركزية الاحتياطية، لذا فإن قراءة عدد أقل من وحدات البايت من الفلاش ولكن الحاجة إلى المزيد من وحدة المعالجة المركزية للإدخال/الإخراج كانت بمثابة عنق الزجاجة المحتمل.
• إن تغييرات الإدخال/الإخراج التي تؤدي أداءً جيدًا على معيار اصطناعي يتم تشغيله على نظام غير مُحمل لا تعمل أحيانًا بشكل جيد في حالات الاستخدام الواقعية في ظل التحميل الواقعي (مثل التشفير على Nexus 6).
• أظهرت المقارنة المعيارية تراجعات بنسبة 85% في بعض الأماكن.

مع تطور SquashFS وإضافة ميزات لتقليل تأثير وحدة المعالجة المركزية (مثل القائمة البيضاء للملفات التي يتم الوصول إليها بشكل شائع والتي لا ينبغي ضغطها)، سنستمر في تقييمها وتقديم توصيات إلى الشركات المصنعة للأجهزة.

كيف قمت بتخفيض حجم قسم النظام إلى النصف بدون SquashFS؟

يتم تخزين التطبيقات في ملفات apk.، وهي في الواقع أرشيفات ZIP. يحتوي كل ملف .apk بداخله على واحد أو أكثر من ملفات .dex التي تحتوي على رمز Dalvik الثانوي المحمول. يوجد ملف .odex (.dex المُحسّن) بشكل منفصل عن ملف .apk ويمكن أن يحتوي على رمز الجهاز الخاص بالجهاز. في حالة توفر ملف ‎.odex، يستطيع Android تشغيل التطبيقات بسرعات مجمعة مسبقًا دون الحاجة إلى انتظار تجميع التعليمات البرمجية في كل مرة يتم فيها تشغيل التطبيق. ملف .odex ليس ضروريًا تمامًا: يمكن لنظام Android تشغيل كود .dex مباشرة عبر الترجمة الفورية أو التحويل البرمجي في الوقت المناسب (JIT)، ولكن ملف .odex يوفر أفضل مزيج من سرعة التشغيل وسرعة وقت التشغيل إذا المساحة متاحة.

مثال: بالنسبة لملف files.txt المثبت من جهاز Nexus 6P الذي يعمل بنظام التشغيل Android 7.1 بحجم صورة نظام إجمالي يبلغ 2628 ميجابايت (2755792836 بايت)، يكون تقسيم أكبر المساهمين في الحجم الإجمالي لصورة النظام حسب نوع الملف كما يلي:

تتشابه هذه الأرقام مع الأجهزة الأخرى أيضًا، لذلك على أجهزة Nexus/Pixel، تشغل ملفات .odex نصف قسم النظام تقريبًا. هذا يعني أنه يمكننا الاستمرار في استخدام ext4 ولكن نكتب ملفات .odex إلى القسم B في المصنع ثم ننسخها إلى /data عند التمهيد الأول. التخزين الفعلي المستخدم مع ext4 A/B مطابق لـ SquashFS A/B، لأنه إذا استخدمنا SquashFS لكنا قد قمنا بشحن ملفات .odex المختارة مسبقًا إلى system_a بدلاً من system_b.

ألا يعني نسخ ملفات .odex إلى /data أن المساحة المحفوظة على /system مفقودة على /data؟

ليس تماما. على Pixel، معظم المساحة التي تشغلها ملفات .odex مخصصة للتطبيقات، والتي توجد عادةً على /data . تأخذ هذه التطبيقات تحديثات Google Play، لذا لا يتم استخدام ملفات .apk و.odex الموجودة على صورة النظام طوال معظم عمر الجهاز. يمكن استبعاد هذه الملفات بالكامل واستبدالها بملفات .odex صغيرة تعتمد على الملف الشخصي عندما يستخدم المستخدم فعليًا كل تطبيق (وبالتالي لا يتطلب مساحة للتطبيقات التي لا يستخدمها المستخدم). لمزيد من التفاصيل، ارجع إلى حديث Google I/O 2016 حول تطور الفن .

المقارنة صعبة لعدة أسباب رئيسية:

• تحتوي التطبيقات التي يتم تحديثها بواسطة Google Play دائمًا على ملفات .odex الخاصة بها على /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 الخاصة بالنظام القديم. يتعامل PackageManager مع هذا: ( frameworks/base/+/main/services/core/java/com/android/server/pm/PackageManagerService.java#7215 ). بعد نجاح تشغيل النظام الجديد، يمكن لـ installd ( frameworks/native/+/main/cmds/installd/dexopt.cpp#2422 ) إزالة ملفات .odex التي كان يستخدمها النظام القديم، مما يعيد الجهاز إلى الحالة الثابتة حيث توجد نسخة واحدة فقط.

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

ألا تزيد كل هذه الكتابة/النسخ من تآكل الفلاش؟

تتم إعادة كتابة جزء صغير فقط من الفلاش: يكتب التحديث الكامل لنظام Pixel حوالي 2.3 جيجا بايت. (يتم أيضًا إعادة ترجمة التطبيقات، ولكن هذا ينطبق أيضًا على التطبيقات غير A/B.) تقليديًا، كتبت وكالات السفر عبر الإنترنت الكاملة المستندة إلى الكتلة كمية مماثلة من البيانات، لذا يجب أن تكون معدلات تآكل الفلاش متشابهة.

هل يؤدي تفليش قسمين من أقسام النظام إلى زيادة وقت تفليش المصنع؟

لا. لم يزد البكسل في حجم صورة النظام (لقد قام فقط بتقسيم المساحة عبر قسمين).

ألا يجعل الاحتفاظ بملفات .odex على B عملية إعادة التشغيل بعد إعادة ضبط بيانات المصنع بطيئة؟

نعم. إذا كنت قد استخدمت جهازًا بالفعل، وأخذت OTA، وقمت بإعادة ضبط بيانات المصنع، فستكون عملية إعادة التشغيل الأولى أبطأ مما كانت ستكون عليه بخلاف ذلك (1m40s مقابل 40s على Pixel XL) لأنه سيتم فقدان ملفات .odex من B بعد أول OTA وبالتالي لا يمكن نسخه إلى /data . هذه هي المقايضة.

يجب أن تكون إعادة ضبط بيانات المصنع عملية نادرة بالمقارنة مع التمهيد العادي، لذا فإن الوقت المستغرق أقل أهمية. (لا يؤثر هذا على المستخدمين أو المراجعين الذين يحصلون على أجهزتهم من المصنع، لأنه في هذه الحالة يكون القسم B متاحًا.) استخدام مترجم JIT يعني أننا لسنا بحاجة إلى إعادة ترجمة كل شيء ، لذا فهو ليس سيئًا مثلك. قد تعتقد. من الممكن أيضًا وضع علامة على التطبيقات على أنها تتطلب تجميعًا مسبقًا باستخدام coreApp="true" في البيان: ( frameworks/base/+/main/packages/SystemUI/AndroidManifest.xml#23 ). يتم استخدام هذا حاليًا بواسطة system_server لأنه غير مسموح به لـ JIT لأسباب أمنية.

ألا يؤدي الاحتفاظ بملفات .odex على /data بدلاً من /system إلى جعل عملية إعادة التشغيل بعد OTA بطيئة؟

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

هل (يجب) أن نقوم بشحن جهاز 32 جيجا بايت A/B؟ 16 جيجا؟ 8 جيجا؟

يعمل 32 جيجا بايت بشكل جيد كما تم إثباته على Pixel، و320 ميجا بايت من 16 جيجا بايت يعني انخفاضًا بنسبة 2%. وبالمثل، 320 ميجا بايت من أصل 8 جيجا بايت بتخفيض قدره 4%. من الواضح أن A/B لن يكون الخيار الموصى به على الأجهزة المزودة بـ 4GiB، حيث إن الحمل الزائد الذي يبلغ 320 ميجابايت يمثل 10% تقريبًا من إجمالي المساحة المتاحة.

هل يتطلب AVB2.0 وكالات A/B عبر الإنترنت؟

لا. يتطلب Android Verified Boot دائمًا تحديثات قائمة على الحظر، ولكن ليس بالضرورة تحديثات A/B.

هل تتطلب وكالات السفر عبر الإنترنت A/B AVB2.0؟

لا.

هل تؤدي وكالات السفر عبر الإنترنت A/B إلى كسر حماية التراجع الخاصة بـ AVB2.0؟

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

إذا كنت تقوم بتثبيت تحديث أثناء تشغيل النظام، أليس هذا بطيئًا؟

مع التحديثات غير A/B، الهدف هو تثبيت التحديث في أسرع وقت ممكن لأن المستخدم ينتظر وغير قادر على استخدام أجهزته أثناء تطبيق التحديث. أما مع تحديثات A/B، فالعكس هو الصحيح؛ نظرًا لأن المستخدم لا يزال يستخدم أجهزته، فإن الهدف هو أقل قدر ممكن من التأثير، لذلك يكون التحديث بطيئًا بشكل متعمد. من خلال المنطق في عميل تحديث نظام Java (والذي بالنسبة لشركة Google هو GmsCore، الحزمة الأساسية المقدمة من GMS)، يحاول Android أيضًا اختيار الوقت الذي لا يستخدم فيه المستخدمون أجهزتهم على الإطلاق. تدعم المنصة إيقاف/استئناف التحديث مؤقتًا، ويمكن للعميل استخدام ذلك لإيقاف التحديث مؤقتًا إذا بدأ المستخدم في استخدام الجهاز واستئنافه عندما يكون الجهاز خاملاً مرة أخرى.

هناك مرحلتان أثناء الحصول على OTA، كما هو موضح بوضوح في واجهة المستخدم كخطوة 1 من 2 والخطوة 2 من 2 أسفل شريط التقدم. تتوافق الخطوة 1 مع كتابة كتل البيانات، بينما تقوم الخطوة 2 بالتجميع المسبق لملفات .dex. تختلف هاتان المرحلتان تمامًا من حيث تأثير الأداء. المرحلة الأولى هي الإدخال/الإخراج البسيط. وهذا يتطلب القليل من الموارد (ذاكرة الوصول العشوائي (RAM) ووحدة المعالجة المركزية (CPU) والإدخال/الإخراج) لأنه يقوم فقط بنسخ الكتل ببطء.

تقوم المرحلة الثانية بتشغيل dex2oat لتجميع صورة النظام الجديد مسبقًا. من الواضح أن هذا له حدود أقل وضوحًا لمتطلباته لأنه يجمع التطبيقات الفعلية. ومن الواضح أن تجميع تطبيق كبير ومعقد يتطلب الكثير من العمل مقارنةً بتطبيق صغير وبسيط؛ بينما في المرحلة الأولى لا توجد كتل قرص أكبر أو أكثر تعقيدًا من غيرها.

تشبه العملية عندما يقوم Google Play بتثبيت تحديث التطبيق في الخلفية قبل عرض إشعار تحديث التطبيقات الخمسة ، كما حدث لسنوات.

ماذا لو كان المستخدم ينتظر التحديث بالفعل؟

لا يميز التطبيق الحالي في GmsCore بين تحديثات الخلفية والتحديثات التي يبدأها المستخدم ولكنه قد يفعل ذلك في المستقبل. في حالة طلب المستخدم صراحةً تثبيت التحديث أو مشاهدته لشاشة تقدم التحديث، فسنعطي الأولوية لعمل التحديث على افتراض أنه ينتظر انتهاء التحديث فعليًا.

ماذا يحدث إذا فشل تطبيق التحديث؟

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

ما هي الأنظمة الموجودة على الشريحة (SoCs) التي تدعم A/B؟

اعتبارًا من 15-03-2017، لدينا المعلومات التالية:

للحصول على تفاصيل حول الجداول الزمنية، راجع جهات اتصال SoC الخاصة بك. بالنسبة لـ SoCs غير المذكورة أعلاه، تواصل مع SoC الخاص بك مباشرة.