این صفحه به شما نشان می‌دهد که چگونه پشتیبان‌گیری ابری و فرآیند انتقال دستگاه به دستگاه (D2D) را برای برنامه خود آزمایش کنید. آزمایش هر دوی این موارد با هر نسخه اصلی برنامه شما مهم است تا اطمینان حاصل شود که کاربران شما می‌توانند به استفاده از برنامه شما در دستگاه جدید ادامه دهند. در حالی که پشتیبان‌گیری و انتقال هر دو مشابه هستند، تفاوت‌های مهمی بین این دو در اندروید ۱۲ (سطح API ۳۱) و بالاتر وجود دارد - به ویژه اینکه انتقال محدودیت حجم داده بسیار بیشتری معادل ۲ گیگابایت دارد، در مقایسه با ۲ مگابایت برای پشتیبان‌گیری ابری.
این راهنما به شما نشان می‌دهد که چگونه می‌توانید هم پشتیبان‌گیری و بازیابی ابری و هم انتقال D2D را به طور کارآمد در طول چرخه توسعه آزمایش کنید.
نحوه‌ی آزمایش پشتیبان‌گیری‌ها
این بخش، بخش‌های مختلف چارچوب پشتیبان‌گیری اندروید و نحوه تعامل آنها با برنامه‌هایی که از پشتیبان‌گیری خودکار و پشتیبان‌گیری کلید-مقدار پشتیبانی می‌کنند را شرح می‌دهد. در طول مرحله توسعه برنامه، بیشتر سازوکار داخلی چارچوب انتزاعی است، بنابراین نیازی به دانستن این اطلاعات ندارید. با این حال، در طول مرحله آزمایش، درک این مفاهیم اهمیت بیشتری پیدا می‌کند.
نمودار زیر نحوه جریان داده‌ها را در طول پشتیبان‌گیری و بازیابی ابری نشان می‌دهد:
نمودار زیر نحوه جریان داده‌ها را در طول انتقال D2D نشان می‌دهد:
برخلاف تست پشتیبان‌گیری و بازیابی ابری، تست D2D به یک دستگاه مبدا و یک دستگاه مقصد برای کپی کردن از و به نیاز دارد.
سرویس مدیریت پشتیبان (Backup Manager Service) یک سرویس سیستمی اندروید است که عملیات پشتیبان‌گیری و بازیابی را هماهنگ و آغاز می‌کند. این سرویس از طریق رابط برنامه‌نویسی کاربردی (API) Backup Manager قابل دسترسی است.
در طول عملیات پشتیبان‌گیری، سرویس از برنامه شما برای داده‌های پشتیبان پرس‌وجو می‌کند و آن را به انتقال پشتیبان تحویل می‌دهد، که داده‌ها را در فضای ابری بایگانی می‌کند. در طول عملیات بازیابی، سرویس مدیریت پشتیبان، داده‌های پشتیبان را از انتقال پشتیبان بازیابی کرده و داده‌ها را به دستگاه بازیابی می‌کند. برای انتقال D2D، سرویس مدیریت پشتیبان از برنامه شما برای داده‌های پشتیبان پرس‌وجو می‌کند و آنها را مستقیماً به سرویس مدیریت پشتیبان در دستگاه جدید منتقل می‌کند، که آن را در برنامه شما بارگذاری می‌کند.
انتقال‌های پشتیبان، اجزای اندروید هستند که مسئول ذخیره و بازیابی داده‌های برنامه شما می‌باشند. یک دستگاه مبتنی بر اندروید می‌تواند هیچ یا چند انتقال پشتیبان داشته باشد، اما فقط یکی از آنها می‌تواند در یک زمان فعال باشد. انتقال‌های پشتیبان موجود به دلیل سفارشی‌سازی توسط سازندگان دستگاه و ارائه دهندگان خدمات، از دستگاهی به دستگاه دیگر متفاوت است. اکثر دستگاه‌های دارای قابلیت Google Play با انتقال‌های زیر عرضه می‌شوند:
- GMS Transport: انتقال پشتیبان ابری فعال در اکثر دستگاه‌ها، بخشی از سرویس‌های موبایل گوگل . این انتقال، داده‌ها را در سرویس پشتیبان‌گیری اندروید ذخیره می‌کند.
- انتقال D2D: این انتقال در مهاجرت D2D برای انتقال مستقیم داده‌ها از یک دستگاه به دستگاه دیگر استفاده می‌شود.
ابزارها
برای آزمایش عملیات پشتیبان‌گیری و بازیابی، باید کمی در مورد ابزارهای زیر بدانید:
-
adb: برای اجرای دستورات روی دستگاه یا شبیه‌ساز. -
bmgr: برای انجام عملیات مختلف پشتیبان‌گیری و بازیابی. -
logcat: برای مشاهده خروجی عملیات پشتیبان‌گیری و بازیابی.
تست پشتیبان گیری ابری
پشتیبان‌گیری و بازیابی ابری را می‌توان با استفاده از یک دستگاه واحد و با دنبال کردن مراحل این بخش انجام داد.
دستگاه یا شبیه‌ساز خود را برای پشتیبان‌گیری ابری آماده کنید
با انجام چک لیست زیر، دستگاه یا شبیه‌ساز خود را برای آزمایش پشتیبان‌گیری آماده کنید:
- برای پشتیبان‌گیری خودکار، بررسی کنید که از دستگاه یا شبیه‌ساز دارای اندروید ۶.۰ (سطح API ۲۳) یا بالاتر استفاده می‌کنید.
- برای پشتیبان‌گیری از کلید-مقدار، بررسی کنید که از دستگاه یا شبیه‌ساز با سیستم عامل اندروید ۲.۲ (سطح API ۸) یا بالاتر استفاده می‌کنید.
- برای تست پشتیبان‌گیری ابری، باید به اینترنت دسترسی داشته باشید.
- با یک حساب گوگل وارد دستگاه شوید و آن را به عنوان حساب پشتیبان در تنظیمات > گوگل > پشتیبان‌گیری تنظیم کنید.
برای آزمایش پشتیبان‌گیری ابری، یک پشتیبان‌گیری ابری را فعال کنید، سپس برنامه را حذف و دوباره نصب کنید. برای اینکه این مراحل قابل تکرار باشند، می‌توانید از اسکریپت زیر، 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"
مراحل آزمایش
- برنامه خود را باز کنید، وارد سیستم شوید و تمام تنظیمات را تغییر دهید.
- اسکریپت را اجرا کنید و نام بسته خود، مانند
test_cloud_backup.sh com.example.myappرا وارد کنید. - برنامه را دوباره باز کنید و تأیید کنید که به درستی کار می‌کند، در حالی که تمام داده‌ها حفظ شده‌اند.
شما نمی‌خواهید کاربرانتان نیازی به ورود به سیستم داشته باشند و تمام تنظیمات، پیشرفت و داده‌های برنامه آنها باید مانند قبل باشد. اگر نتایج آزمایش شما این معیارها را برآورده نمی‌کند، مطمئن شوید که پشتیبان‌گیری‌ها را به درستی پیکربندی کرده‌اید، بدون اینکه بخش‌های کلیدی داده‌ها را از قلم انداخته باشید، و همچنین بازیابی هرگونه داده ذخیره‌شده‌ای را که از پشتیبان‌گیری حذف کرده‌اید، مدیریت می‌کنید. مراحل ۱ تا ۳ را برای هر تکرار آزمایش تکرار کنید.
انتقال D2D را آزمایش کنید
جامع‌ترین روش برای آزمایش انتقال D2D، انتقال کل محتوای تلفن شما به یک دستگاه جدید با تنظیمات کارخانه و تأیید صحت عملکرد آن است. با این حال، اگر نیاز به تکرار چندین بار این فرآیند داشته باشید، این کار می‌تواند ناخوشایند و زمان‌بر باشد. این مراحل به شما نشان می‌دهد که چگونه بدون انجام مکرر تنظیمات کارخانه روی دستگاه، انتقال را با یک دستگاه شبیه‌سازی کنید.
دستگاه خود را برای آزمایش D2D آماده کنید
برای آزمایش انتقال D2D روی یک دستگاه، آن را به صورت زیر آماده کنید:
- دستگاه شما باید اندروید ۱۲ (سطح API 31) یا بالاتر را اجرا کند.
- برای آزمایش آخرین نسخه D2D، اندروید ۱۲ (سطح API 31) یا بالاتر را در برنامه خود هدف قرار دهید.
- اسکریپت زیر،
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"
مراحل آزمایش
- برنامه‌ای که می‌خواهید روی دستگاه تست کنید را نصب کنید.
- برنامه خود را باز کنید، وارد سیستم شوید و تنظیمات برنامه خود را تغییر دهید.
- اسکریپت را روی دستگاه خود اجرا کنید و نام بسته خود، مانند
test_d2d.sh com.example.myappرا به آن ارسال کنید. - وقتی اسکریپت کامل شد، برنامه را روی دستگاه باز کنید و تأیید کنید که به درستی کار می‌کند، در حالی که تمام داده‌ها حفظ شده‌اند.
شما نمی‌خواهید کاربرانتان نیازی به ورود به سیستم داشته باشند و تمام تنظیمات، پیشرفت و داده‌های برنامه آنها باید مانند قبل از اجرای اسکریپت نمایش داده شود. اگر نتایج آزمایش شما این معیارها را برآورده نمی‌کند، مطمئن شوید که انتقال را به درستی پیکربندی کرده‌اید، بدون اینکه بخش‌های کلیدی داده را از قلم انداخته باشید، و همچنین بازیابی هرگونه داده ذخیره شده‌ای را که از انتقال حذف کرده‌اید، مدیریت می‌کنید. مراحل ۲ تا ۴ را برای هر تکرار آزمایش تکرار کنید.
رفع مشکل پشتیبان گیری و بازیابی
این بخش به شما کمک می‌کند تا برخی از مشکلات رایج را برطرف کنید.
سهمیه حمل و نقل از حد مجاز فراتر رفت
پیام‌های زیر در 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
به تفاوت مهر زمانی در خروجی لاگ توجه کنید. این خطا معمولاً زمانی رخ می‌دهد که برنامه شما از پیکربندی 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 اجرا کنید و سپس دوباره سعی کنید پشتیبان‌گیری را انجام دهید.
متدهای برنامه فراخوانی نمی‌شوند
از آنجا که Auto Backup برنامه شما را با کلاس پایه Application اجرا می‌کند، ممکن است متدهای راه‌اندازی برنامه شما فراخوانی نشوند. Auto Backup هیچ یک از activityهای برنامه شما را نیز اجرا نمی‌کند، بنابراین اگر برنامه شما در یک activity راه‌اندازی شود، ممکن است با خطا مواجه شوید. برای کسب اطلاعات بیشتر، Implement 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 خودتان را پیاده‌سازی کرده‌اید ، احتمالاً به این معنی است که هیچ داده یا فایلی به نسخه پشتیبان اضافه نکرده‌اید.