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

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

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

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

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

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

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

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

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

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

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

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

• تفاعلات اختيار القسم (الفتحات) ، وبرنامج update_engine الخفي ، ومحمل الإقلاع (كما هو موضح أدناه)
• عملية الإنشاء وإنشاء حزمة تحديث OTA (الموصوفة في تنفيذ تحديثات 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/ . سيتمكن المستخدمون الذين لديهم معرف مجموعة السجل من الوصول إلى سجلات نظام الملفات.

تفاعلات Bootloader

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

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

حياة تحديث أ / ب

تبدأ عملية التحديث عندما تكون حزمة 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 . سيتم تمييز جميع الملفات الموجودة في القسم المثبت الجديد بـ 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 ، وإعداد إذن الوصول قبل إعادة تشغيل الجهاز ، وحذف الملف المستخرج بعد بدء تشغيل النظام بنجاح في الإصدار الجديد.