اختبار عملية "الاحتفاظ بنسخة احتياطية من البيانات واستعادتها"

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

يوضِّح لك هذا الدليل كيفية اختبار النسخ الاحتياطي على السحابة الإلكترونية واستعادتها ونقلها بكفاءة طوال دورة التطوير.

آلية عمل اختبار النسخ الاحتياطية

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

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

تدفق بيانات إطار عمل الاحتفاظ بنسخة احتياطية

يوضِّح المخطّط التالي كيفية تدفق البيانات أثناء عملية النقل من جهاز إلى جهاز.

تدفق بيانات إطار عمل النقل

على عكس اختبار النسخ الاحتياطي واستعادة البيانات على السحابة الإلكترونية، يتطلب اختبار D2D جهازًا مصدرًا وجهازًا مستهدفًا للنسخ من وإلى الجهازَين.

خدمة مدير النسخ الاحتياطي هي خدمة نظام Android تنظم وتبدأ عمليات النسخ الاحتياطي والاستعادة. يمكن الوصول إلى الخدمة من خلال واجهة برمجة التطبيقات Backup Manager.

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

عمليات نقل النسخ الاحتياطي هي إحدى مكونات Android المسؤولة عن تخزين بيانات التطبيق واستردادها. يمكن ألا تحتوي أي وسائل نقل احتياطية على أي جهاز يعمل بنظام التشغيل Android أو أكثر، ولكن يمكن وضع علامة نشطة على إحدى وسائل النقل هذه فقط. تختلف عمليات النقل الاحتياطية المتاحة من جهاز لآخر، وذلك بسبب التخصيصات التي تجريها الشركات المصنّعة للأجهزة ومقدّمو الخدمة، ولكن معظم الأجهزة المفعَّلة في Google Play يتم شحنها باستخدام وسائل النقل التالية:

  • GMS Transport: وهو نقل النسخ الاحتياطي النشط على السحابة الإلكترونية على معظم الأجهزة، وهو جزء من خدمات Google للأجهزة الجوّالة. وتؤدي عملية النقل هذه إلى تخزين البيانات في Android Backup Service.
  • النقل من جهاز إلى آخر: يُستخدم هذا النقل في نقل البيانات من جهاز إلى آخر (D2D) لنقل البيانات مباشرةً من جهاز إلى آخر.

الأدوات

لاختبار عمليات النسخ الاحتياطي والاستعادة، يجب معرفة بعض المعلومات عن الأدوات التالية.

  • adb: لتشغيل الأوامر على الجهاز أو المحاكي
  • bmgr: لتنفيذ عمليات متنوعة للنسخ الاحتياطي والاستعادة
  • logcat: للاطّلاع على مخرجات عمليات النسخ الاحتياطي والاستعادة

اختبار النسخ الاحتياطي على السحابة الإلكترونية

يمكن إجراء عمليات الاحتفاظ بنسخة احتياطية على السحابة الإلكترونية واستعادتها باستخدام جهاز واحد من خلال اتّباع الخطوات الواردة في هذا القسم.

إعداد جهازك أو برنامج المحاكاة للاحتفاظ بنُسخ احتياطية على السحابة الإلكترونية

عليك إعداد جهازك أو المحاكي لاختبار النسخ الاحتياطي من خلال قائمة التحقق التالية:

  1. بالنسبة إلى التحميل التلقائي، تحقق من أنك تستخدم جهازًا أو محاكيًا يعمل بنظام التشغيل Android 6.0 (المستوى 23 من واجهة برمجة التطبيقات) أو إصدار أحدث.
  2. بالنسبة إلى الاحتفاظ بنسخة احتياطية من قيمة المفتاح، يُرجى التأكّد من استخدام جهاز أو محاكي يعمل بالإصدار 2.2 من Android (المستوى 8 من واجهة برمجة التطبيقات) أو بإصدار أحدث.
  3. يجب أن يكون لديك اتصال بالإنترنت لاختبار عملية الاحتفاظ بنسخة احتياطية على السحابة الإلكترونية.
  4. سجِّل الدخول إلى الجهاز باستخدام حساب Google وعيِّنه كحساب النسخ الاحتياطي في الإعدادات -> Google -> الاحتفاظ بنسخة احتياطية.

لاختبار النسخ الاحتياطي على السحابة الإلكترونية، شغِّل نسخة احتياطية مخزَّنة على السحابة الإلكترونية، ثم ألغِ تثبيت التطبيق وأعِد تثبيته. لتكرار هذه الخطوات، يمكنك استخدام النص البرمجي التالي: test_cloud_backup.sh، الذي يحتفظ بنسخة احتياطية من تطبيقك وينزّل حزمة APK محليًا ويلغيها ويعيد تثبيت حزمة APK:

#!/bin/bash -eu
: "${1?"Usage: $0 package name"}"

# Initialize and create a backup
adb shell bmgr enable true
adb shell bmgr transport com.android.localtransport/.LocalTransport | grep -q "Selected transport" || (echo "Error: error selecting local transport"; exit 1)
adb shell settings put secure backup_local_transport_parameters 'is_encrypted=true'
adb shell bmgr backupnow "$1" | grep -F "Package $1 with result: Success" || (echo "Backup failed"; exit 1)

# Uninstall and reinstall the app to clear the data and trigger a restore
apk_path_list=$(adb shell pm path "$1")
OIFS=$IFS
IFS=$'\n'
apk_number=0
for apk_line in $apk_path_list
do
    (( ++apk_number ))
    apk_path=${apk_line:8:1000}
    adb pull "$apk_path" "myapk${apk_number}.apk"
done
IFS=$OIFS
adb shell pm uninstall --user 0 "$1"
apks=$(seq -f 'myapk%.f.apk' 1 $apk_number)
adb install-multiple -t --user 0 $apks

# Clean up
adb shell bmgr transport com.google.android.gms/.backup.BackupTransportService
rm $apks

echo "Done"

خطوات الاختبار

  1. افتح التطبيق وسجِّل الدخول وعدِّل جميع الإعدادات.
  2. شغِّل النص البرمجي، مع إدخال اسم الحزمة، مثل test_cloud_backup.sh com.example.myapp
  3. أعد فتح التطبيق وتحقق من أنه يعمل بشكل صحيح، مع الاحتفاظ بجميع البيانات.

أنت لا تريد أن يحتاج المستخدمون إلى تسجيل الدخول، ويجب أن تكون جميع الإعدادات والتقدم وبيانات التطبيق كما كانت من قبل. إذا كانت نتائج الاختبار لا تفي بهذه المعايير، فتأكد من تهيئة النسخ الاحتياطية بشكل صحيح، بدون حذف الأجزاء الرئيسية من البيانات، وأنك تتعامل أيضًا مع إعادة إنشاء أي بيانات مخبأة تم استبعادها من النسخة الاحتياطية. كرر الخطوات من 1 إلى 3 لكل تكرار للاختبار.

اختبار عملية النقل من جهاز إلى آخر

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

تحضير الجهاز لاختبار D2D

لاختبار النقل باستخدام D2D على جهاز واحد، يمكنك إعداده على النحو التالي:

  1. يجب أن يعمل جهازك بنظام التشغيل Android 12 (المستوى 31 لواجهة برمجة التطبيقات) أو إصدار أحدث.
  2. لاختبار أحدث إصدار من D2D، استهدف إصدار Android 12 (المستوى 31 من واجهة برمجة التطبيقات) أو إصدار أحدث في تطبيقك.
  3. أنشئ النص البرمجي التالي، test_d2d.sh، لدعم تكرار الاختبار:
#!/bin/bash -eu
: "${1?"Usage: $0 package name"}"

# Initialize and create a backup
adb shell bmgr enable true
adb shell settings put secure backup_enable_d2d_test_mode 1
adb shell bmgr transport com.google.android.gms/.backup.migrate.service.D2dTransport
adb shell bmgr init com.google.android.gms/.backup.migrate.service.D2dTransport
adb shell bmgr list transports | grep -q -F "  * com.google.android.gms/.backup.migrate.service.D2dTransport" || (echo "Failed to select and initialize backup transport"; exit 1)
adb shell bmgr backupnow "$1" | grep -F "Package $1 with result: Success" || (echo "Backup failed"; exit 1)

# Uninstall and reinstall the app to clear the data and trigger a restore
apk_path_list=$(adb shell pm path "$1")
OIFS=$IFS
IFS=$'\n'
apk_number=0
for apk_line in $apk_path_list
do
    (( ++apk_number ))
    apk_path=${apk_line:8:1000}
    adb pull "$apk_path" "myapk${apk_number}.apk"
done
IFS=$OIFS
adb shell pm uninstall --user 0 "$1"
adb shell bmgr transport com.google.android.gms/.backup.BackupTransportService
apks=$(seq -f 'myapk%.f.apk' 1 $apk_number)
adb install-multiple -t --user 0 $apks

# Clean up
adb shell bmgr init com.google.android.gms/.backup.migrate.service.D2dTransport
adb shell settings put secure backup_enable_d2d_test_mode 0
adb shell bmgr transport com.google.android.gms/.backup.BackupTransportService
rm $apks

echo "Done"

خطوات الاختبار

  1. ثبِّت التطبيق الذي تريد اختباره على الجهاز.
  2. افتح التطبيق وسجِّل الدخول وعدِّل إعدادات التطبيق.
  3. شغِّل النص البرمجي على جهازك، مع إدخال اسم الحزمة، مثل test_d2d.sh com.example.myapp.
  4. عند اكتمال النص البرمجي، افتح التطبيق على الجهاز وتحقق من أنه يعمل بشكل صحيح، مع الاحتفاظ بجميع البيانات.

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

تحديد مشاكل الاحتفاظ بنسخة احتياطية والاستعادة وحلّها

يساعدك هذا القسم على تحديد بعض المشاكل الشائعة وحلّها.

تم تجاوز حصة النقل

تشير الرسائل التالية في Logcat إلى أنّ تطبيقك قد تجاوز حصة النقل:

I/PFTBT: Transport rejected backup of <PACKAGE>, skipping

--- or ---

I/PFTBT: Transport quota exceeded for package: <PACKAGE>

يُرجى تقليل مقدار بيانات الاحتفاظ بنسخة احتياطية ثم إعادة المحاولة. على سبيل المثال، تأكَّد من تخزين البيانات في دليل ذاكرة التخزين المؤقت فقط في دليل ذاكرة التخزين المؤقت لتطبيقك، لأنّ دليل ذاكرة التخزين المؤقت ليس مضمَّنًا في النُسخ الاحتياطية.

لا يمكن الاحتفاظ بنسخة احتياطية كاملة من البيانات

تشير الرسالة التالية في Logcat إلى تعذُّر عملية النسخ الاحتياطي بالكامل بسبب عدم حدوث أي عملية نسخ احتياطي لقيمة المفتاح على الجهاز حتى الآن:

I/BackupManagerService: Full backup not currently possible -- key/value backup
not yet run?

يمكنك تشغيل نسخة احتياطية من قيمة المفتاح باستخدام الأمر bmgr run، ثم إعادة المحاولة.

انتهاء المهلة في انتظار موظّف الدعم

تشير الرسالة التالية في Logcat إلى أنّ تشغيل تطبيقك للاحتفاظ بنسخة احتياطية يستغرق أكثر من 10 ثوانٍ:

12-05 18:59:02.033  1910  2251 D BackupManagerService:
    awaiting agent for ApplicationInfo{5c7cde0 com.your.app.package}
12-05 18:59:12.117  1910  2251 W BackupManagerService:
    Timeout waiting for agent ApplicationInfo{5c7cde0 com.your.app.package}
12-05 18:59:12.117  1910  2251 W BackupManagerService:
    Can't find backup agent for com.your.app.package

لاحظ اختلاف الطابع الزمني في إخراج السجلّ. يحدث هذا الخطأ عادةً عندما يستخدم تطبيقك إعداد متعدد الوسائط بدون ProGuard.

حساب النسخ الاحتياطي غير مهيأ

تشير الرسائل التالية في Logcat إلى إيقاف عملية النسخ الاحتياطي بسبب عدم إعداد مجموعة بيانات النسخ الاحتياطي:

01-31 14:32:45.698 17280 17292 I Backup: [GmsBackupTransport] Try to backup for
an uninitialized backup account.
01-31 14:32:45.699  1043 18255 W PFTBT: Transport failed; aborting backup: -1001
01-31 14:32:45.699  1043 18255 I PFTBT: Full backup completed with status: -1000

شغل مدير النسخ الاحتياطي باستخدام الأمر adb shell bmgr run، ثم حاول إجراء النسخ الاحتياطي مرة أخرى.

طُرق التطبيق التي لم يتم طلبها

نظرًا لأن ميزة "الاحتفاظ التلقائي بنسخة احتياطية" تُشغِّل تطبيقك بالفئة الأساسية Application، قد لا يتم استدعاء طرق إعداد التطبيق. لا تُشغِّل ميزة التحميل التلقائي أيًا من أنشطة تطبيقك، لذا قد ترى أخطاءً إذا تم إعداد تطبيقك في نشاط ما. للمزيد من المعلومات، يُرجى الاطّلاع على تنفيذ BackupAgent.

وعلى النقيض، تُشغِّل ميزة "الاحتفاظ بنسخة احتياطية ذات قيمة أساسية" تطبيقك مع أي فئة فرعية Application تُعلن عنها في ملف بيان التطبيق.

ما مِن بيانات للاحتفاظ بنسخة احتياطية منها

تشير الرسائل التالية في Logcat إلى أنّ تطبيقك لا يتضمّن بيانات للاحتفاظ بنسخة احتياطية منها:

I Backup  : [FullBackupSession] Package com.your.app.package doesn't have any backup data.

--- or ---

I Backup  : [D2dTransport] Package com.your.app.package doesn't have any backup data.

إذا نفذت BackupAgent بنفسك، هذا يعني على الأرجح أنك لم تضف أي بيانات أو ملفات إلى النسخة الاحتياطية.