نقطة تفتيش بيانات المستخدمين

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

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

التأثير في المستخدم

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

آلية العمل

وظيفة نقطة التفتيش في أنظمة الملفات المختلفة

بالنسبة إلى نظام الملفات F2FS، تضيف أداة UDC وظيفة نقطة التحقق إلى ‎4.20 Linux kernel في الإصدار العلني وتضيفها إلى جميع النوى الشائعة المتوافقة مع الأجهزة التي تعمل بنظام التشغيل Android 10.

بالنسبة إلى أنظمة الملفات الأخرى، يستخدم UDC جهازًا افتراضيًا لمخطِّط الأجهزة يُسمى dm_bow لتوفير وظيفة نقطة التحكّم. يقع dm_bow بين الجهاز ونظام الملفات. عند تثبيت أحد الأقسام، يتم إصدار نسخة مما يؤدي إلى إصدار نظام الملفات أوامر القطع في جميع الأجزاء الحرة. يرصد dm_bow هذه المقاطع ويستخدمها لإعداد قائمة حظر مجانية. بعد ذلك، يتم إرسال عمليات القراءة والكتابة إلى الجهاز بدون تعديل، ولكن قبل السماح بإجراء عملية كتابة، يتم الاحتفاظ بنسخة احتياطية من البيانات المطلوبة لاستعادتها في قطعة بيانات فارغة.

عملية نقطة التفتيش

عند تركيب قسم يتضمّن العلامة checkpoint=fs/block، يطلب Android restoreCheckpoint من محرك الأقراص للسماح للجهاز باستعادة أي نقطة تفتيش حالية. تستدعي الدالة init بعد ذلك الدالة needsCheckpoint لتحديد ما إذا كان الجهاز في حالة أداة تحميل التشغيل A/B أو قد ضبط عدد محاولات إعادة التحديث . إذا كان أيّ منهما صحيحًا، يُطلِق Android createCheckpoint لإضافة علامات mount أو إنشاء جهاز dm_bow.

بعد تركيب القسم، يتم استدعاء رمز نقطة الفحص لإصدار عمليات القطع. بعد ذلك، تستمر عملية التحميل كالمعتاد. في الخطوة LOCKED_BOOT_COMPLETE، يُطلِق Android الطلب commitCheckpoint لتأكيد نقطة التحقّق الحالية ويستمر التحديث كالمعتاد.

إدارة مفاتيح Keymaster

تُستخدَم مفاتيح Keymaster لتشفير الجهاز أو لأغراض أخرى. لإدارة هذه المفاتيح، يؤخّر Android طلبات حذف المفاتيح إلى أن يتم تأكيد نقطة التحقّق.

مراقبة الحالة الصحية

يتحقق برنامج الصحة الخفي من توفّر مساحة كافية على القرص لإنشاء نقطة تفتيش. يتوفّر برنامج Health الخفي في cp_healthDaemon في Checkpoint.cpp.

يشتمل البرنامج الخفي للصحة على السلوكيات التالية التي يمكن ضبطها:

• ro.sys.cp_msleeptime: تتحكَّم في عدد مرات فحص الجهاز لاستخدام القرص.
• ro.sys.cp_min_free_bytes: يتحكّم هذا الخيار في الحدّ الأدنى للقيمة التي يبحث عنها البرنامج الخفي للصحة.
• ‫ro.sys.cp_commit_on_full: تتحكم هذه القيمة في ما إذا كان الخادم الدائم لرصد حالة الجهاز يعيد تشغيل الجهاز أو يُجري عملية تسجيل لنقطة التفتيش ويواصل العمل عندما يكون القرص ممتلئًا.

واجهات برمجة تطبيقات نقطة التحقق

تستخدم ميزة "الوصول غير المصرّح به" واجهات برمجة تطبيقات Checkpoint. بالنسبة إلى واجهات برمجة التطبيقات الأخرى التي تستخدمها Universal Data Catalog، يُرجى الاطّلاع على IVold.aidl.

void startCheckpoint(int retry)

لإنشاء نقطة تفتيش

يستدعي إطار العمل هذه الطريقة عندما يكون جاهزًا لبدء تحديث. يتم إنشاء نقطة التحقق قبل بدء أنظمة الملفات التي تم وضع علامة عليها، مثل userdata، في وضع القراءة/الكتابة بعد إعادة التشغيل. إذا كان عدد مرات إعادة المحاولة موجبًا، ستتعامل واجهة برمجة التطبيقات مع عمليات إعادة المحاولة للتتبُّع، وتستدعي أداة التعديل needsRollback للتحقّق ممّا إذا كان من الضروري العودة إلى التحديث. إذا كان عدد عمليات إعادة المحاولة هو -1، تُحيل واجهة برمجة التطبيقات الأمر إلى تقييم أداة التمهيد في وضع A/B.

لا يتم استدعاء هذه الطريقة عند إجراء تحديث أ/ب عادي.

void commitChanges()

تُجري التغييرات.

يستدعي إطار العمل هذه الطريقة بعد إعادة التشغيل عندما تكون التغييرات جاهزة للإتمام. يتمّ تنفيذ هذا الإجراء قبل كتابة البيانات (مثل الصور والفيديوهات والرسائل القصيرة وتلقّي إشعار من الخادم) في userdata وقبل BootComplete.

إذا لم يكن هناك تحديث نشط تم وضع علامة عليه، لن يكون لهذه الطريقة أي تأثير.

abortChanges()

فرض إعادة التشغيل والعودة إلى النقطة المرجعية. يتخلّى عن جميع تعديلات بيانات المستخدمين منذ أول عملية إعادة تشغيل.

يستدعي إطار العمل هذه الطريقة بعد إعادة التشغيل ولكن قبل commitChanges. يتمّ خفض retry_counter عند استدعاء هذه الطريقة. يتم توليد إدخالات السجلّ.

bool needsRollback()

لتحديد ما إذا كان من الضروري التراجع عن التغييرات

على الأجهزة غير المزوّدة بنقاط تفتيش، يتم عرض القيمة false. على أجهزة نقاط التفتيش، يتم عرض true أثناء عملية التشغيل بدون نقطة تفتيش.

تنفيذ رمز UDC

التنفيذ المرجعي

للاطّلاع على مثال حول كيفية تنفيذ إطار UDC، يمكنك الانتقال إلى dm-bow.c. وللاطّلاع على مستندات إضافية عن الميزة، يُرجى الاطّلاع على dm-bow.txt.

ضبط إعدادات الجهاز

في on fs، في ملف init.hardware.rc، تأكَّد من توفُّر ما يلي:

mount_all /vendor/etc/fstab.${ro.boot.hardware.platform} --early

في on late-fs، في ملف init.hardware.rc، تأكَّد من توفُّر ما يلي:

mount_all /vendor/etc/fstab.${ro.boot.hardware.platform} --late

في ملف fstab.hardware، تأكَّد من أنّ /data تم وضع علامة عليه كـ latemount.

/dev/block/bootdevice/by-name/userdata              /data              f2fs
noatime,nosuid,nodev,discard,reserve_root=32768,resgid=1065,fsync_mode=nobarrier
latemount,wait,check,fileencryption=ice,keydirectory=/metadata/vold/metadata_encryption,quota,formattable,sysfs_path=/sys/devices/platform/soc/1d84000.ufshc,reservedsize=128M,checkpoint=fs

إضافة قسم للبيانات الوصفية

يتطلب UDC قسمًا للبيانات الوصفية لتخزين عدد مرات إعادة المحاولة و المفاتيح غير المخصّصة لبرنامج التمهيد. يمكنك إعداد قسم للبيانات الوصفية وتثبيته مبكرًا على /metadata.

في ملف fstab.hardware، تأكَّد من وضع علامة earlymount أو first_stage_mount على /metadata.

/dev/block/by-name/metadata           /metadata           ext4
noatime,nosuid,nodev,discard,sync
wait,formattable,first_stage_mount

يجب تهيئة التقسيم على جميع الأصفار.

أضِف الأسطر التالية إلى BoardConfig.mk:

BOARD_USES_METADATA_PARTITION := true
BOARD_ROOT_EXTRA_FOLDERS := existing_folders metadata

تحديث الأنظمة

أنظمة F2FS

بالنسبة إلى الأنظمة التي تستخدم F2FS لتنسيق البيانات، تأكَّد من أنّ إصدار F2FS يتوافق مع نقاط التحقق. لمزيد من المعلومات، يُرجى الاطّلاع على وظائف نقاط التفتيش في أنظمة الملفات المختلفة.

أضِف العلامة checkpoint=fs إلى قسم <fs_mgr_flags> في ملف fstab للجهاز الذي تم تثبيته في /data.

الأنظمة غير المستندة إلى تنسيق الملفات الثنائي

بالنسبة إلى الأنظمة غير المستندة إلى F2FS، يجب تفعيل dm-bow في إعدادات kernel.

أضِف العلامة checkpoint=block إلى قسم <fs_mgr_flags> في ملف fstab للجهاز الذي تم تثبيته في /data.

التحقّق من السجلات

يتم إنشاء إدخالات السجلّ عند استدعاء واجهات برمجة التطبيقات Checkpoint API.

التحقُّق

لاختبار عملية تنفيذ UDC، عليك تنفيذ VtsKernelCheckpointTest مجموعة من اختبارات VTS .