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

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

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

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

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

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

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

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

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

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

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

• GMS Transport: התעבורה הפעילה של הגיבוי בענן ברוב המכשירים, כחלק מ-Google Mobile Services. התהליך הזה מאחסן את הנתונים בשירות הגיבוי של Android.
• תעבורת 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

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

שיטות של אפליקציות לא נקראות

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