تحديثات نظام A/B (سلسة).

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

لمزيد من المعلومات حول تحديثات نظام A/B وكيفية عملها، راجع اختيار القسم (الفتحات) .

توفر تحديثات نظام A/B المزايا التالية:

• يمكن إجراء تحديثات عبر الهواء أثناء تشغيل النظام، دون مقاطعة المستخدم. يمكن للمستخدمين الاستمرار في استخدام أجهزتهم أثناء OTA - فترة التوقف الوحيدة أثناء التحديث هي عند إعادة تشغيل الجهاز في قسم القرص المحدث.
• بعد التحديث، لا تستغرق عملية إعادة التشغيل وقتًا أطول من عملية إعادة التشغيل العادية.
• إذا فشل تطبيق OTA (على سبيل المثال، بسبب فلاش سيئ)، فلن يتأثر المستخدم. سيستمر المستخدم في تشغيل نظام التشغيل القديم، ويكون للعميل الحرية في إعادة محاولة التحديث.
• إذا تم تطبيق تحديث عبر الهواء ولكن فشل التمهيد، فسيتم إعادة تشغيل الجهاز مرة أخرى إلى القسم القديم وسيظل قابلاً للاستخدام. العميل حر في إعادة محاولة التحديث.
• تؤثر أي أخطاء (مثل أخطاء الإدخال/الإخراج) على مجموعة الأقسام غير المستخدمة فقط ويمكن إعادة المحاولة. تصبح مثل هذه الأخطاء أيضًا أقل احتمالًا نظرًا لأن حمل الإدخال/الإخراج منخفض بشكل متعمد لتجنب تدهور تجربة المستخدم.
• يمكن بث التحديثات إلى أجهزة A/B، مما يلغي الحاجة إلى تنزيل الحزمة قبل تثبيتها. البث يعني أنه ليس من الضروري أن يكون لدى المستخدم مساحة خالية كافية لتخزين حزمة التحديث على /data أو /cache .
• لم يعد قسم ذاكرة التخزين المؤقت يُستخدم لتخزين حزم التحديث عبر الهواء، لذلك ليست هناك حاجة للتأكد من أن قسم ذاكرة التخزين المؤقت كبير بما يكفي للتحديثات المستقبلية.
• يضمن dm-verity أن يقوم الجهاز بتشغيل صورة غير تالفة. إذا لم يتم تشغيل الجهاز بسبب مشكلة سيئة في OTA أو dm-verity، فيمكن إعادة تشغيل الجهاز إلى صورة قديمة. (لا يتطلب التشغيل الذي تم التحقق منه لنظام Android تحديثات A/B.)

حول تحديثات نظام A/B

تتطلب تحديثات A/B إجراء تغييرات على كل من العميل والنظام. ومع ذلك، لا ينبغي لخادم حزمة OTA أن يتطلب تغييرات: لا يزال يتم تقديم حزم التحديث عبر HTTPS. بالنسبة للأجهزة التي تستخدم البنية الأساسية لـ OTA من Google، تتم جميع تغييرات النظام في AOSP، ويتم توفير رمز العميل من خلال خدمات Google Play. سيتمكن مصنعو المعدات الأصلية الذين لا يستخدمون البنية التحتية لـ OTA الخاصة بـ Google من إعادة استخدام رمز نظام AOSP ولكن سيتعين عليهم توفير عملائهم.

بالنسبة لمصنعي المعدات الأصلية الذين يقومون بتوريد عملائهم، يحتاج العميل إلى:

• قرر متى يجب عليك إجراء التحديث. نظرًا لأن تحديثات A/B تحدث في الخلفية، فإنها لم تعد يتم إجراؤها بواسطة المستخدم. لتجنب إزعاج المستخدمين، يوصى بجدولة التحديثات عندما يكون الجهاز في وضع الصيانة الخامل، مثل الليل، وعلى شبكة Wi-Fi. ومع ذلك، يمكن لعميلك استخدام أي استدلالات تريدها.
• تحقق من خوادم حزمة OTA الخاصة بك وحدد ما إذا كان هناك تحديث متاح أم لا. يجب أن يكون هذا في الغالب نفس رمز العميل الحالي لديك، باستثناء أنك ستحتاج إلى الإشارة إلى أن الجهاز يدعم A/B. (يتضمن برنامج Google أيضًا زر التحقق الآن للمستخدمين للتحقق من آخر تحديث.)
• اتصل بـ update_engine باستخدام عنوان URL HTTPS لحزمة التحديث الخاصة بك، على افتراض توفر واحدة. سيقوم update_engine بتحديث الكتل الأولية الموجودة على القسم غير المستخدم حاليًا أثناء تدفق حزمة التحديث.
• قم بالإبلاغ عن نجاحات التثبيت أو فشله لخوادمك، بناءً على رمز نتيجة update_engine . إذا تم تطبيق التحديث بنجاح، فسيقوم update_engine بإخبار أداة تحميل التشغيل بالتمهيد إلى نظام التشغيل الجديد في عملية إعادة التشغيل التالية. سيعود برنامج تحميل التشغيل إلى نظام التشغيل القديم إذا فشل نظام التشغيل الجديد في التمهيد، لذلك لا يلزم القيام بأي عمل من العميل. إذا فشل التحديث، فيجب على العميل أن يقرر متى (وما إذا كان) سيحاول مرة أخرى، بناءً على رمز الخطأ التفصيلي. على سبيل المثال، يمكن للعميل الجيد أن يدرك أن حزمة OTA جزئية ("مختلفة") قد فشلت ويحاول تجربة حزمة OTA كاملة بدلاً من ذلك.

اختياريا، يمكن للعميل:

• إظهار إشعار يطلب من المستخدم إعادة التشغيل. إذا كنت تريد تنفيذ سياسة يتم فيها تشجيع المستخدم على التحديث بشكل روتيني، فيمكن إضافة هذا الإشعار إلى عميلك. إذا لم يطالب العميل المستخدمين، فسيحصل المستخدمون على التحديث في المرة التالية التي يقومون فيها بإعادة التشغيل على أي حال. (يحتوي عميل Google على تأخير قابل للتكوين لكل تحديث.)
• اعرض إشعارًا يخبر المستخدمين ما إذا كانوا قد قاموا بالتمهيد إلى إصدار جديد من نظام التشغيل أو ما إذا كان من المتوقع منهم القيام بذلك ولكنهم عادوا إلى إصدار نظام التشغيل القديم. (عميل Google لا يفعل ذلك عادةً).

من ناحية النظام، تؤثر تحديثات نظام A/B على ما يلي:

• اختيار القسم (الفتحات)، وبرنامج update_engine ، وتفاعلات أداة تحميل التشغيل (الموصوفة أدناه)
• عملية البناء وإنشاء حزمة تحديث عبر الهواء (موضحة في تنفيذ تحديثات A/B )

اختيار القسم (الفتحات)

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

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

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

تحديث المحرك الخفي

تستخدم تحديثات نظام A/B برنامجًا خفيًا في الخلفية يسمى update_engine لإعداد النظام للتمهيد إلى إصدار جديد ومحدث. يمكن لهذا البرنامج الخفي تنفيذ الإجراءات التالية:

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

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

تحديث مصدر المحرك

يقع مصدر update_engine في system/update_engine . يتم تقسيم ملفات A/B OTA dexopt بين installd ومدير الحزم:

• frameworks/native/cmds/installd/ ota* يتضمن البرنامج النصي لما بعد التثبيت، والملف الثنائي لـ chroot، والاستنساخ المثبت الذي يستدعي dex2oat، والبرنامج النصي لنقل القطع الأثرية بعد OTA، وملف rc لبرنامج النقل النصي.
• frameworks/base/services/core/java/com/android/server/pm/OtaDexoptService.java (بالإضافة إلى OtaDexoptShellCommand ) هو مدير الحزم الذي يقوم بإعداد أوامر dex2oat للتطبيقات.

للحصول على مثال عملي، راجع /device/google/marlin/device-common.mk .

تحديث سجلات المحرك

بالنسبة لإصدارات Android 8.x والإصدارات الأقدم، يمكن العثور على سجلات update_engine في logcat وفي تقرير الأخطاء. لإتاحة سجلات update_engine في نظام الملفات، قم بتصحيح التغييرات التالية في الإصدار الخاص بك:

• تغيير 486618
• تغيير 529080
• تغيير 529081
• تغيير 534660
• تغيير 594637

تقوم هذه التغييرات بحفظ نسخة من أحدث سجل لـ update_engine في /data/misc/update_engine_log/update_engine. YEAR - TIME . بالإضافة إلى السجل الحالي، يتم حفظ السجلات الخمسة الأحدث ضمن /data/misc/update_engine_log/ . سيتمكن المستخدمون الذين لديهم معرف مجموعة السجل من الوصول إلى سجلات نظام الملفات.

تفاعلات أداة تحميل التشغيل

يتم استخدام boot_control HAL بواسطة update_engine (وربما شياطين أخرى) لإرشاد أداة تحميل التشغيل إلى ما سيتم التمهيد منه. تتضمن أمثلة السيناريوهات الشائعة والحالات المرتبطة بها ما يلي:

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

دعم التحديث المتدفق

لا تحتوي أجهزة المستخدم دائمًا على مساحة كافية على /data لتنزيل حزمة التحديث. نظرًا لعدم رغبة مصنعي المعدات الأصلية أو المستخدمين في إضاعة المساحة على قسم /cache ، يذهب بعض المستخدمين بدون تحديثات لأن الجهاز ليس لديه مكان لتخزين حزمة التحديث. لمعالجة هذه المشكلة، أضاف Android 8.0 دعمًا لتدفق تحديثات A/B التي تكتب الكتل مباشرة إلى القسم B أثناء تنزيلها، دون الحاجة إلى تخزين الكتل على /data . لا تحتاج تحديثات دفق A/B إلى أي مساحة تخزين مؤقتة تقريبًا وتتطلب مساحة تخزين كافية لحوالي 100 كيلو بايت من البيانات الوصفية.

لتمكين دفق التحديثات في Android 7.1، اختر التصحيحات التالية:

• السماح بإلغاء طلب حل الوكيل
• إصلاح إنهاء النقل أثناء حل الوكلاء
• إضافة اختبار وحدة لـ TerminateTransfer بين النطاقات
• تنظيف RetryTimeoutCallback()

هذه التصحيحات مطلوبة لدعم دفق تحديثات A/B في Android 7.1 والإصدارات الأحدث سواء باستخدام Google Mobile Services (GMS) أو أي عميل تحديث آخر.

حياة تحديث A/B

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

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

بعد توفر الحمولة، تكون عملية التحديث كما يلي:

ما بعد التثبيت

بالنسبة لكل قسم يتم تحديد خطوة ما بعد التثبيت فيه، يقوم update_engine بتثبيت القسم الجديد في موقع محدد وتنفيذ البرنامج المحدد في OTA بالنسبة إلى القسم المثبت. على سبيل المثال، إذا تم تعريف برنامج ما بعد التثبيت على أنه usr/bin/postinstall في قسم النظام، فسيتم تثبيت هذا القسم من الفتحة غير المستخدمة في موقع ثابت (مثل /postinstall_mount ) و /postinstall_mount/usr/bin/postinstall يتم تنفيذ أمر /postinstall_mount/usr/bin/postinstall .

لكي ينجح التثبيت اللاحق، يجب أن تكون النواة القديمة قادرة على:

• قم بتحميل تنسيق نظام الملفات الجديد . لا يمكن تغيير نوع نظام الملفات ما لم يكن هناك دعم له في النواة القديمة، بما في ذلك تفاصيل مثل خوارزمية الضغط المستخدمة في حالة استخدام نظام ملفات مضغوط (أي SquashFS).
• فهم تنسيق برنامج ما بعد التثبيت للقسم الجديد . إذا كنت تستخدم تنسيقًا ثنائيًا قابلاً للتنفيذ والربط (ELF)، فيجب أن يكون متوافقًا مع النواة القديمة (على سبيل المثال، برنامج جديد 64 بت يعمل على نواة قديمة 32 بت إذا تحولت البنية من إصدارات 32 إلى 64 بت). ما لم يُطلب من المُحمل ( ld ) استخدام مسارات أخرى أو إنشاء ملف ثنائي ثابت، فسيتم تحميل المكتبات من صورة النظام القديم، وليس من الصورة الجديدة.

على سبيل المثال، يمكنك استخدام برنامج shell النصي كبرنامج ما بعد التثبيت الذي يتم تفسيره بواسطة ثنائي shell الخاص بالنظام القديم باستخدام #! في الجزء العلوي)، ثم قم بإعداد مسارات المكتبة من البيئة الجديدة لتنفيذ برنامج ثنائي أكثر تعقيدًا بعد التثبيت. وبدلاً من ذلك، يمكنك تشغيل خطوة ما بعد التثبيت من قسم أصغر مخصص لتمكين تحديث تنسيق نظام الملفات في قسم النظام الرئيسي دون حدوث مشكلات في التوافق مع الإصدارات السابقة أو تحديثات أولية؛ سيسمح هذا للمستخدمين بالتحديث مباشرة إلى أحدث إصدار من صورة المصنع.

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

يتم تشغيل برنامج ما بعد التثبيت المحدد في سياق postinstall SELinux. سيتم وضع علامة على جميع الملفات الموجودة في القسم المثبت الجديد بـ postinstall_file ، بغض النظر عن سماتها بعد إعادة التشغيل في هذا النظام الجديد. لن تؤثر التغييرات التي يتم إجراؤها على سمات SELinux في النظام الجديد على خطوة ما بعد التثبيت. إذا كان برنامج ما بعد التثبيت يحتاج إلى أذونات إضافية، فيجب إضافتها إلى سياق ما بعد التثبيت.

بعد إعادة التشغيل

بعد إعادة التشغيل، يقوم update_verifier بتشغيل فحص التكامل باستخدام dm-verity. يبدأ هذا الفحص قبل zygote لتجنب قيام خدمات Java بإجراء أي تغييرات لا رجعة فيها من شأنها أن تمنع التراجع الآمن. أثناء هذه العملية، قد يقوم برنامج bootloader وkernel أيضًا بتشغيل عملية إعادة التشغيل إذا اكتشف التمهيد الذي تم التحقق منه أو dm-verity أي تلف. بعد اكتمال عملية التحقق، يقوم update_verifier بوضع علامة على نجاح التمهيد.

سوف يقرأ update_verifier فقط الكتل المدرجة في /data/ota_package/care_map.txt ، والتي تم تضمينها في حزمة A/B OTA عند استخدام كود AOSP. يقوم عميل تحديث نظام Java، مثل GmsCore، باستخراج care_map.txt ، وإعداد إذن الوصول قبل إعادة تشغيل الجهاز، وحذف الملف المستخرج بعد تشغيل النظام بنجاح في الإصدار الجديد.