בדיקת הגיבוי והשחזור

בדף הזה מוסבר איך לבדוק את הגיבויים בענן ואת תהליך ההעברה ממכשיר למכשיר (D2D) באפליקציה. חשוב לבדוק את שניהם בכל גרסה ראשית של האפליקציה כדי לוודא שהמשתמשים יוכלו להמשיך להשתמש באפליקציה במכשיר חדש. הגיבוי וההעברה דומים, אבל יש הבדלים חשובים ביניהם ב-Android מגרסה 12 (רמת API‏ 31) ואילך. ההבדל הבולט ביותר הוא שההעברה כוללת מגבלת גודל נתונים גדולה בהרבה, של 2GB, לעומת 25MB בגיבוי בענן.

במדריך הזה נסביר איך אפשר לבדוק בצורה יעילה את הגיבוי והשחזור בענן ואת ההעברה ממכשיר למכשיר (D2D) במהלך מחזור הפיתוח.

איך בודקים את הגיבויים

בקטע הזה מתוארים רכיבים שונים במסגרת הגיבוי של Android, והאופן שבו הם פועלים עם אפליקציות שתומכות בגיבוי אוטומטי ובגיבוי של מפתחות וערכים. בשלב פיתוח האפליקציה, רוב הרכיבים הפנימיים של המסגרת מנותקים, כך שאין צורך לדעת את המידע הזה. עם זאת, במהלך שלב הבדיקה, הבנת המושגים האלה הופכת לחשובה יותר.

בתרשים הבא מוסבר איך מתבצע תהליך הגיבוי והשחזור של הנתונים בענן. למטרות בדיקה, אפשר להשתמש באותו מכשיר לגיבוי בענן ולשחזור.

התרשים הבא ממחיש איך הנתונים זורמים במהלך העברה D2D:

בניגוד לבדיקות של גיבוי ושחזור בענן, לבדיקות D2D נדרשים מכשיר מקור ומכשיר יעד להעתקה ממנו וממנו.

Backup Manager Service הוא שירות מערכת של Android שמארגן ומפעיל פעולות גיבוי ושחזור. אפשר לגשת לשירות דרך API של Backup Manager.

במהלך פעולת הגיבוי, השירות שולח שאילתה לאפליקציה לגבי נתוני הגיבוי, ואז מעביר אותם לכלי להעברת הגיבוי, שמאחסן את הנתונים בענן. במהלך פעולת השחזור, שירות מנהל הגיבויים מאחזר את נתוני הגיבוי מהתעבורה של הגיבוי ומשחזר את הנתונים למכשיר. בהעברה מסוג D2D, שירות מנהל הגיבוי שולח לאפליקציה שאלות לגבי נתוני הגיבוי ומעביר אותם ישירות לשירות מנהל הגיבוי במכשיר החדש, שמטעין אותם באפליקציה.

כלי העברה של גיבויים הם רכיבים של Android שאחראים לאחסון ולאחזור של נתוני האפליקציות. במכשיר Android יכול להיות אפס או יותר אמצעי גיבוי, אבל אפשר לסמן רק אחת מההעברות האלה כפעילות. סוגי התעבורה של הגיבויים משתנים ממכשיר למכשיר, בגלל התאמות אישיות של יצרני המכשירים וספקי השירות, אבל רוב המכשירים שתומכים ב-Google Play כוללים את סוגי התעבורה הבאים:

• GMS Transport: התחבורה הפעילה של הגיבוי בענן ברוב המכשירים, חלק מ-Google Mobile Services. כלי התעבורה הזה מאחסן נתונים ב-Android Backup Service.
• תעבורת D2D: התעבורה הזו משמשת להעברת נתונים ישירות ממכשיר אחד למכשיר אחר במסגרת העברה מסוג D2D.

כלים

כדי לבדוק את פעולות הגיבוי והשחזור, צריך לדעת קצת על הכלים הבאים.

• adb: להרצת פקודות במכשיר או במהדמ.
• bmgr: כדי לבצע פעולות שונות של גיבוי ושחזור.
• logcat: כדי לראות את הפלט של פעולות הגיבוי והשחזור.

בדיקת הגיבוי בענן

אפשר לבצע גיבוי ושחזור בענן באמצעות מכשיר אחד בלבד. לשם כך, פועלים לפי השלבים שמפורטים בקטע הזה.

הכנת המכשיר או האמולטור לגיבויים בענן

כדי להכין את המכשיר או את המהדר למבדק הגיבוי, צריך לבצע את הפעולות הבאות ברשימת המשימות הבאה:

1. בגיבוי אוטומטי, ודאו שאתם משתמשים במכשיר או באמולטור עם Android מגרסה 6.0 (רמת API 23) ואילך.
2. לגיבוי של ערך מפתח, צריך לוודא שמשתמשים במכשיר או באמולטור עם Android מגרסה 2.2 (רמת API 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 (רמת API ‏31) ואילך.
2. כדי לבדוק את הגרסה האחרונה של D2D, צריך לטרגט את האפליקציה ל-Android 12 (רמת API ‏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, ואז לנסות שוב.

Timeout waiting for agent

ההודעה הבאה ב-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

שימו לב להבדל בחותמת הזמן בפלט היומן. השגיאה הזו מתרחשת בדרך כלל כשהאפליקציה משתמשת בהגדרה של multidex בלי 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 ומנסים לבצע שוב את הגיבוי.

לא בוצעה קריאה ל-methods של האפליקציה

מכיוון שהאפליקציה מופעלת על ידי הגיבוי האוטומטי עם סיווג בסיס של 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 משלכם, סביר להניח שלא הוספתם נתונים או קבצים לגיבוי.