बैकअप लेने और उसे वापस लाने की सुविधा की अपने-आप होने वाली जांच

जब उपयोगकर्ता कोई नया डिवाइस सेट अप करते हैं या आपके ऐप्लिकेशन को फिर से इंस्टॉल करते हैं, तो Android आपके ऐप्लिकेशन का डेटा वापस ला सकता है. इसके लिए, क्लाउड बैकअप या डिवाइस-से-डिवाइस ट्रांसफ़र का इस्तेमाल किया जाता है. अगर बैकअप के नियमों में ज़रूरी डेटा शामिल नहीं किया जाता है या आपका ऐप्लिकेशन, वापस लाए गए डेटा का इस्तेमाल नहीं कर पाता है, तो उपयोगकर्ताओं की सेटिंग और प्रोग्रेस मिट जाती है. हालांकि, उन्हें कोई गड़बड़ी नहीं दिखती.

अपने-आप बैकअप लेने और उसे वापस लाने की सुविधा की जांच करने से, आपको ऐप्लिकेशन रिलीज़ करने से पहले ही इन समस्याओं का पता चल जाता है. ये JUnit 5 टेस्ट होते हैं, जो आपकी डेवलपमेंट मशीन पर चलते हैं. साथ ही, Android डीबग ब्रिज (एडीबी) के ज़रिए कनेक्ट किए गए डिवाइसों को कंट्रोल करते हैं. हर टेस्ट, किसी डिवाइस पर ऐप्लिकेशन का डेटा सेव करता है. साथ ही, Android बैकअप फ़्रेमवर्क के ज़रिए ऐप्लिकेशन का बैक अप लेता है और उसे वापस लाता है. इसके बाद, यह जांच करता है कि डेटा सुरक्षित है या नहीं. अपने मॉड्यूल की बिल्ड फ़ाइल में, Android Gradle प्लगिन (AGP) टेस्ट सुइट के तौर पर टेस्ट कॉन्फ़िगर किए जाते हैं.

यह कैसे काम करता है

बैकअप लेने और उसे रीस्टोर करने की सुविधा के टेस्ट सुइट के दो हिस्से होते हैं, जो एक साथ काम करते हैं:

• होस्ट टेस्ट, JUnit 5 टेस्ट होते हैं. ये आपकी डेवलपमेंट मशीन पर चलते हैं. वे हर डिवाइस के लिए BackupRestoreController का इस्तेमाल करते हैं, ताकि डेटा को सीड किया जा सके, आपके ऐप्लिकेशन का बैक अप लिया जा सके, उसे वापस लाया जा सके, और नतीजों की जांच की जा सके.
• डिवाइस ऐक्शन ऐसी क्लास होती हैं जो BackupDeviceAction को लागू करती हैं. ये आपके ऐप्लिकेशन की प्रोसेस में डिवाइस पर चलते हैं. इसलिए, ये आपके ऐप्लिकेशन के कोड के ज़रिए डेटा को पढ़ और लिख सकते हैं. होस्ट, क्लास के नाम से डिवाइस की कार्रवाइयों को टेस्ट करता है.

सूट को चलाने पर, एजीपी आपके ऐप्लिकेशन और एक टेस्ट APK को बनाता है. इस APK में, आपके डिवाइस की कार्रवाइयां शामिल होती हैं. हर टेस्ट से पहले, टेस्ट फ़्रेमवर्क हर उस डिवाइस पर दोनों APK इंस्टॉल करता है जिसका इस्तेमाल टेस्ट के लिए किया जाता है. इसके बाद, आपके ऐप्लिकेशन का डेटा मिटा देता है.

पहले से मौजूद स्टोरेज के टाइप

इस टेबल में StorageDomain के सबक्लास की सूची दी गई है. इनकी मदद से, डिवाइस ऐक्शन लिखे बिना डेटा को सीड और उसकी पुष्टि की जा सकती है:

DataStore फ़ाइलों जैसे अन्य डेटा की जांच करने के लिए, डिवाइस की कार्रवाइयां लिखें.

यात्रा के साधन

हर बैकअप के लिए, BackupTransportMode वैल्यू का इस्तेमाल किया जाता है. यहां दी गई टेबल में, यात्रा के उन साधनों की सूची दी गई है जिनके लिए यह सुविधा उपलब्ध है:

LOCAL को इसके साथ काम करने वाले किसी भी डिवाइस पर इस्तेमाल किया जा सकता है. क्लाउड और डिवाइस-टू-डिवाइस मोड, Android Studio में ऐप्लिकेशन के डेटा का बैकअप लें कार्रवाई की तरह ही बैकअप बनाते हैं: बैकअप को अपलोड करने या किसी दूसरे डिवाइस पर भेजने के बजाय, आपके डेवलपमेंट मशीन में सेव किया जाता है. क्लाउड और डिवाइस-टू-डिवाइस मोड के लिए, डिवाइस पर Google Play services और आपके ऐप्लिकेशन का डीबग करने लायक बिल्ड होना ज़रूरी है. अगर बैकअप के नियम क्लाइंट-साइड एन्क्रिप्शन पर निर्भर करते हैं, तो दोनों क्लाउड मोड की जांच करें.

ज़रूरी शर्तें

ऑटोमैटिक बैकअप और रीस्टोर टेस्टिंग का इस्तेमाल करने के लिए, पक्का करें कि आपका एनवायरमेंट इन ज़रूरी शर्तों को पूरा करता हो:

• Gradle का वर्शन 9.6.0 या इसके बाद का वर्शन.
• JDK का वर्शन 17 या इसके बाद का वर्शन.
• Android 12 (एपीआई लेवल 31) या इसके बाद के वर्शन पर चलने वाला कोई डिवाइस या एम्युलेटर, जो adb से कनेक्ट हो. दो डिवाइसों के बीच ट्रांसफ़र की जांच करने के लिए, दो डिवाइस कनेक्ट करें.

इनके साथ काम करता है

यहां दी गई टेबल में, ऑटोमेटेड बैकअप और रीस्टोर की जांच के लिए, ज़रूरी और सुझाए गए वर्शन दिए गए हैं:

AGP के हर झलक वाले वर्शन के लिए, Android Studio का मिलता-जुलता झलक वाला वर्शन ज़रूरी है. ज़्यादा जानकारी के लिए, एजीपी की झलक देखें.

अपना प्रोजेक्ट सेट अप करना

अपने ऐप्लिकेशन मॉड्यूल में बैकअप और रीस्टोर टेस्ट सुइट जोड़ने के लिए, यह तरीका अपनाएं:

एक्सपेरिमेंटल फ़्लैग चालू करें

अपने प्रोजेक्ट की gradle.properties फ़ाइल में, टेस्ट सुइट और बैकअप टेस्ट चालू करें:

android.experimental.testSuiteSupport=true
android.experimental.enableBackupTest=true

टेस्ट सुइट के बारे में जानकारी देना

अपने ऐप्लिकेशन मॉड्यूल की build.gradle.kts फ़ाइल में, testOptions ब्लॉक में बैकअप टेस्ट सुइट का एलान करें:

android {
    testOptions {
        backupTests {
            create("backupTest")
        }
    }
}

इस उदाहरण में, सुइट का नाम backupTest है. इससे source set डायरेक्ट्री और Gradle टास्क के नाम तय होते हैं. इन वैकल्पिक प्रॉपर्टी की मदद से, सुइट को पसंद के मुताबिक बनाया जा सकता है:

• AGP, सुइट में androidx.test.backup लाइब्रेरी के जिस वर्शन को जोड़ता है उसे सेट करने के लिए, backupTestLibraryVersion का इस्तेमाल करें. जैसे, "1.0.0-alpha02". इस प्रॉपर्टी को शामिल करना ज़रूरी नहीं है. अगर इसे शामिल नहीं किया जाता है, तो AGP, AGP वर्शन के आधार पर डिफ़ॉल्ट लाइब्रेरी वर्शन पर वापस आ जाता है.
• targetVariants का इस्तेमाल करके, उन बिल्ड वैरिएंट के बारे में बताएं जिनकी जांच सुइट करता है. जैसे, targetVariants.add("demoDebug"). इस प्रॉपर्टी को शामिल करना ज़रूरी नहीं है. अगर आपने इसे शामिल नहीं किया है, तो सुइट आपके मॉड्यूल के testBuildType के वैरिएंट की जांच करता है. यह डिफ़ॉल्ट रूप से debug होता है. हमारा सुझाव है कि आप डीबग करने लायक वैरिएंट की जांच करें. इसकी वजह यह है कि क्लाउड और डिवाइस-टू-डिवाइस ट्रांसपोर्ट मोड के लिए, डीबग करने लायक ऐप्लिकेशन की ज़रूरत होती है.

AGP, होस्ट टेस्ट में होस्ट लाइब्रेरी, androidx.test.backup:backup-host, और JUnit 5 जोड़ता है. यह डिवाइस लाइब्रेरी, androidx.test.backup:backup, को टेस्ट APK में जोड़ता है और टेस्ट APK के इंस्ट्रुमेंटेशन रनर को सेट करता है.

अन्य डिपेंडेंसी जोड़ने के लिए, सुइट के hostJar और testApk ब्लॉक का इस्तेमाल करें. उदाहरण के लिए, अगर आपको होस्ट टेस्ट में Truth का इस्तेमाल करना है, तो इसे hostJar ब्लॉक में जोड़ें:

create("backupTest") {
    hostJar {
        dependencies {
            implementation("com.google.truth:truth:1.4.2")
        }
    }
}

सोर्स सेट बनाना

सुइट के नाम से मैच करने वाली सोर्स सेट डायरेक्ट्री बनाएं:

• होस्ट टेस्ट को src/{suiteName}/test/kotlin/ में रखें.
• डिवाइस की कार्रवाइयों को src/{suiteName}/androidTest/kotlin/ में डालें.

उदाहरण के लिए, backupTest नाम का सुइट, इस डायरेक्ट्री स्ट्रक्चर का इस्तेमाल करता है:

app/src/backupTest/
├── androidTest/
│   └── kotlin/com/example/myapp/ThemeActions.kt
└── test/
    └── kotlin/com/example/myapp/SettingsBackupTest.kt

बैकअप कॉन्फ़िगरेशन की जांच करना

टेस्ट, उस डेटा का बैक अप लेते हैं और उसे वापस लाते हैं जो आपके ऐप्लिकेशन के बैकअप कॉन्फ़िगरेशन में शामिल होता है. पक्का करें कि आपके ऐप्लिकेशन के लिए बैकअप की सुविधा चालू हो. साथ ही, आपके बैकअप के नियमों में वह डेटा शामिल हो जिसकी जांच की जा रही है.

बैकअप लेने और रीस्टोर करने की सुविधा के लिए टेस्ट लिखना

सुइट के test सोर्स सेट में होस्ट टेस्ट लिखें. हर टेस्ट क्लास के लिए, दो एनोटेशन की ज़रूरत होती है:

• @ExtendWith(BackupRestoreExtension::class), टेस्ट के लिए कनेक्ट किए गए डिवाइस उपलब्ध कराता है.
• @BackupRestoreConfig(applicationId = "..."), टेस्ट किए जा रहे ऐप्लिकेशन का ऐप्लिकेशन आईडी सेट करता है. जिस वैरिएंट की जांच करनी है उसका ऐप्लिकेशन आईडी इस्तेमाल करें. इसमें कोई भी applicationIdSuffix शामिल है.

टेस्ट का हर तरीका, इस्तेमाल किए जाने वाले हर डिवाइस के लिए BackupRestoreController पैरामीटर तय करता है.

पहले से मौजूद स्टोरेज टाइप की जांच करना

बिल्ट-इन स्टोरेज टाइप की जांच करने के लिए, runBackupRestoreFlow को कॉल करें. इसके साथ ही, सीड करने के लिए डेटा, बैकअप फ़ाइल के लिए डायरेक्ट्री, और ट्रांसपोर्ट मोड भी दें. यह तरीका, डिवाइस पर ये चरण पूरे करता है:

1. हर स्टोरेज डोमेन को सीड करता है.
2. ऐप्लिकेशन को बंद करता है.
3. इससे ऐप्लिकेशन का बैक अप लिया जाता है.
4. यह कुकी, ऐप्लिकेशन का डेटा मिटाती है.
5. यह कुकी, बैकअप को वापस लाती है.
6. यह पुष्टि करता है कि हर स्टोरेज डोमेन में सीड वैल्यू मौजूद है.

अगर कोई चरण पूरा नहीं होता है, तो यह तरीका एक अपवाद दिखाता है. इससे टेस्ट पूरा नहीं हो पाता. यहां दिए गए उदाहरण में, लोकल बैकअप ट्रांसपोर्ट का इस्तेमाल करके SharedPreferences कुंजी, SQLite पंक्ति, और इंटरनल फ़ाइल की जांच की गई है:

package com.example.myapp

import androidx.test.backup.host.BackupRestoreConfig
import androidx.test.backup.host.BackupRestoreController
import androidx.test.backup.host.BackupRestoreExtension
import androidx.test.backup.host.BackupTransportMode
import androidx.test.backup.host.StorageDomain
import java.nio.file.Path
import kotlinx.coroutines.runBlocking
import org.junit.jupiter.api.Test
import org.junit.jupiter.api.extension.ExtendWith
import org.junit.jupiter.api.io.TempDir

@ExtendWith(BackupRestoreExtension::class)
@BackupRestoreConfig(applicationId = "com.example.myapp")
class SettingsBackupTest {

    @Test
    fun settingsSurviveBackupAndRestore(
        device: BackupRestoreController,
        @TempDir outputDir: Path,
    ): Unit = runBlocking {
        device.runBackupRestoreFlow(
            storages = listOf(
                StorageDomain.Preference(
                    prefName = "settings",
                    key = "theme",
                    value = "dark",
                ),
                StorageDomain.Database(
                    dbName = "notes.db",
                    table = "notes",
                    primaryKeyCol = "id",
                    primaryKeyVal = 1,
                    columnValues = mapOf("title" to "Groceries"),
                ),
                StorageDomain.TextFile(
                    path = "drafts/note.txt",
                    content = "Buy milk",
                ),
            ),
            outputDir = outputDir,
            mode = BackupTransportMode.LOCAL,
        )
    }
}

स्टोरेज डोमेन तय करते समय इन बातों का ध्यान रखें:

• Preference का नाम, SharedPreferences फ़ाइल के नाम पर रखा जाता है. हालांकि, इसमें .xml एक्सटेंशन शामिल नहीं होता.
• TextFile और BinaryFile, आपके ऐप्लिकेशन के filesDir के हिसाब से रिलेटिव पाथ को हल करते हैं.
• Database, SQL की मदद से पंक्ति लिखता है. साथ ही, अगर टेबल मौजूद नहीं है, तो TEXT कॉलम वाली टेबल बनाता है. अगर आपका ऐप्लिकेशन Room का इस्तेमाल करता है, तो हमारा सुझाव है कि आप डिवाइस ऐक्शन की मदद से डेटाबेस के कॉन्टेंट की जांच करें. ये ऐक्शन, आपके DAO का इस्तेमाल करते हैं, ताकि डेटाबेस में वह स्कीमा हो जो Room को चाहिए.

डिवाइस की कार्रवाइयां सेव करने की अनुमति दें

ऐसे डेटा को सीड या उसकी पुष्टि करने के लिए जो पहले से मौजूद स्टोरेज टाइप में शामिल नहीं है, सुइट के androidTest सोर्स सेट में डिवाइस की कार्रवाइयां लिखें. डिवाइस की कोई कार्रवाई, BackupDeviceAction को लागू करती है और दो मेंबर को बदलती है:

• डेटा को सीड करने वाली कार्रवाई के लिए, phase को BackupDeviceAction.PHASE_POPULATE पर सेट करें. इसके अलावा, डेटा की जांच करने वाली कार्रवाई के लिए, को BackupDeviceAction.PHASE_VERIFY पर सेट करें.
• अपने ऐप्लिकेशन के Context और होस्ट टेस्ट के आर्ग्युमेंट के साथ कार्रवाई को चलाने के लिए, execute को लागू करें. BackupDeviceActionResult.success या BackupDeviceActionResult.failure फ़ैक्ट्री मेथड से बनाया गया नतीजा दिखाएं और failure को गड़बड़ी का मैसेज भेजें.

execute मेथड, आपके ऐप्लिकेशन की प्रोसेस में बैकग्राउंड थ्रेड पर चलता है. इसलिए, यह तब तक ब्लॉक हो सकता है, जब तक डेटा को पढ़ने और लिखने की प्रोसेस पूरी नहीं हो जाती.

यहां दिए गए उदाहरण में, थीम की सेटिंग को सीड और उसकी पुष्टि की गई है. ऐप्लिकेशन, इस सेटिंग को Preferences DataStore की मदद से सेव करता है. ऐप्लिकेशन, अपने मुख्य सोर्स सेट में DataStore को इस तरह से तय करता है:

// In app/src/main/kotlin/com/example/myapp/Settings.kt
package com.example.myapp

import android.content.Context
import androidx.datastore.preferences.core.stringPreferencesKey
import androidx.datastore.preferences.preferencesDataStore

val Context.settingsDataStore by preferencesDataStore(name = "settings")
val THEME_KEY = stringPreferencesKey("theme")

डिवाइस पर की जाने वाली कार्रवाइयों के लिए, एक जैसी परिभाषाओं का इस्तेमाल किया जाता है:

// In app/src/backupTest/androidTest/kotlin/com/example/myapp/ThemeActions.kt
package com.example.myapp

import android.content.Context
import androidx.datastore.preferences.core.edit
import androidx.test.backup.BackupDeviceAction
import androidx.test.backup.BackupDeviceActionArgs
import androidx.test.backup.BackupDeviceActionResult
import kotlinx.coroutines.flow.first
import kotlinx.coroutines.runBlocking

class SeedThemeAction : BackupDeviceAction {
    override val phase = BackupDeviceAction.PHASE_POPULATE

    override fun execute(
        context: Context,
        args: BackupDeviceActionArgs,
    ): BackupDeviceActionResult {
        val theme = args["theme"]
            ?: return BackupDeviceActionResult.failure("Missing theme argument")
        runBlocking {
            context.settingsDataStore.edit { it[THEME_KEY] = theme }
        }
        return BackupDeviceActionResult.success()
    }
}

class VerifyThemeAction : BackupDeviceAction {
    override val phase = BackupDeviceAction.PHASE_VERIFY

    override fun execute(
        context: Context,
        args: BackupDeviceActionArgs,
    ): BackupDeviceActionResult {
        val expected = args["theme"]
        val actual = runBlocking {
            context.settingsDataStore.data.first()[THEME_KEY]
        }
        return if (actual == expected) {
            BackupDeviceActionResult.success()
        } else {
            BackupDeviceActionResult.failure("Expected $expected, found $actual")
        }
    }
}

होस्ट टेस्ट में डेटा वापस भेजने के लिए, success तरीके में मैप पास करें. होस्ट किया गया टेस्ट, BackupActionResult.Success.data से मैप को पढ़ता है.

फ़्लो के हर चरण को चलाएं

डिवाइस की कार्रवाइयों का इस्तेमाल करने या फ़्लो को पसंद के मुताबिक बनाने के लिए, हर चरण को खुद कॉल करें. नीचे दिए गए होस्ट टेस्ट में, क्लाउड बैकअप और रीस्टोर से जुड़ी पिछली कार्रवाई को डिवाइस पर किया जाता है:

package com.example.myapp

import androidx.test.backup.host.BackupActionResult
import androidx.test.backup.host.BackupRestoreConfig
import androidx.test.backup.host.BackupRestoreController
import androidx.test.backup.host.BackupRestoreExtension
import androidx.test.backup.host.BackupTransportMode
import java.nio.file.Path
import kotlinx.coroutines.runBlocking
import org.junit.jupiter.api.Test
import org.junit.jupiter.api.extension.ExtendWith
import org.junit.jupiter.api.fail
import org.junit.jupiter.api.io.TempDir

const val SEED_THEME = "com.example.myapp.SeedThemeAction"
const val VERIFY_THEME = "com.example.myapp.VerifyThemeAction"

@ExtendWith(BackupRestoreExtension::class)
@BackupRestoreConfig(applicationId = "com.example.myapp")
class ThemeBackupTest {

    @Test
    fun themeSurvivesCloudBackup(
        device: BackupRestoreController,
        @TempDir outputDir: Path,
    ): Unit = runBlocking {
        val args = mapOf("theme" to "dark")
        device.runOnDevice(SEED_THEME, args).assertSuccess()

        device.stopApp()
        val backupFile = device.performBackup(
            BackupTransportMode.CLOUD_ENCRYPTED,
            outputDir,
        )
        device.clearAppData()
        device.performRestore(backupFile)

        device.runOnDevice(VERIFY_THEME, args).assertSuccess()
    }
}

fun BackupActionResult.assertSuccess() {
    if (this is BackupActionResult.Failure) fail(errorMessage)
}

जब डिवाइस पर कोई कार्रवाई नहीं हो पाती है, तो runOnDevice अपवाद दिखाने के बजाय BackupActionResult.Failure दिखाता है. इसलिए, नतीजा देखें. अगर अन्य चरण पूरे नहीं होते हैं, तो एक अपवाद दिखता है.

डिवाइसों के बीच ट्रांसफ़र की सुविधा को टेस्ट करना

दो डिवाइसों के बीच ट्रांसफ़र की जांच करने के लिए, हर डिवाइस के लिए BackupRestoreController पैरामीटर का एलान करें. सोर्स डिवाइस पर ऐप्लिकेशन का बैक अप लें. इसके बाद, टारगेट डिवाइस पर बैकअप फ़ाइल को वापस लाएं. यहां दिए गए उदाहरण में, पिछले उदाहरण के कॉन्सटेंट और assertSuccess हेल्पर का फिर से इस्तेमाल किया गया है:

package com.example.myapp

import androidx.test.backup.host.BackupRestoreConfig
import androidx.test.backup.host.BackupRestoreController
import androidx.test.backup.host.BackupRestoreExtension
import androidx.test.backup.host.BackupTransportMode
import androidx.test.backup.host.Device
import java.nio.file.Path
import kotlinx.coroutines.runBlocking
import org.junit.jupiter.api.Test
import org.junit.jupiter.api.extension.ExtendWith
import org.junit.jupiter.api.io.TempDir

@ExtendWith(BackupRestoreExtension::class)
@BackupRestoreConfig(applicationId = "com.example.myapp")
class ThemeTransferTest {

    @Test
    fun themeTransfersToNewDevice(
        @Device(role = "source") source: BackupRestoreController,
        @Device(role = "target") target: BackupRestoreController,
        @TempDir outputDir: Path,
    ): Unit = runBlocking {
        val args = mapOf("theme" to "dark")
        source.runOnDevice(SEED_THEME, args).assertSuccess()
        source.stopApp()
        val backupFile = source.performBackup(
            BackupTransportMode.DEVICE_TO_DEVICE,
            outputDir,
        )

        target.clearAppData()
        target.performRestore(backupFile)
        target.runOnDevice(VERIFY_THEME, args).assertSuccess()
    }
}

@Device की role वैल्यू एक ऐसा लेबल है जिससे टेस्ट को पढ़ना आसान हो जाता है. इससे इस बात पर कोई असर नहीं पड़ता कि किसी डिवाइस को कौनसा पैरामीटर मिलता है. अगर सिर्फ़ एक डिवाइस कनेक्ट है, तो दोनों पैरामीटर उस डिवाइस का इस्तेमाल करते हैं. साथ ही, टेस्ट में एक ही डिवाइस पर ट्रांसफ़र करने की प्रोसेस को सिम्युलेट किया जाता है. टारगेट के डेटा को मिटाने से यह पक्का हो जाता है कि वापस लाया गया डेटा, बैकअप से लिया गया है.

डिवाइस चुनें

डिफ़ॉल्ट रूप से, टेस्ट फ़्रेमवर्क ऑनलाइन डिवाइसों को सीरियल नंबर के हिसाब से क्रम में लगाता है. साथ ही, उन्हें पोज़िशन के हिसाब से BackupRestoreController पैरामीटर असाइन करता है. उदाहरण के लिए, टेस्ट के तरीके का पहला पैरामीटर पहले डिवाइस को और दूसरा पैरामीटर दूसरे डिवाइस को मिलता है. अगर किसी पोज़िशन के लिए कोई डिवाइस नहीं है, तो पैरामीटर को पहला डिवाइस मिलता है. पोजीशन से जुड़े पैरामीटर में, तरीके के सभी पैरामीटर शामिल होते हैं. इसलिए, डिवाइस के पैरामीटर को अन्य पैरामीटर से पहले सेट करें. जैसे, @TempDir. ANDROID_SERIAL एनवायरमेंट वैरिएबल का असर, डिवाइस असाइनमेंट पर नहीं पड़ता.

डिवाइस चुनने के लिए, @Device की serial या api वैल्यू सेट करें या जेवीएम सिस्टम प्रॉपर्टी सेट करें. सिस्टम प्रॉपर्टी को @Device वैल्यू के ऊपर प्राथमिकता दी जाती है. यहां दी गई टेबल में, सिस्टम की उन प्रॉपर्टी की सूची दी गई है जो काम करती हैं:

कमांड लाइन से टेस्ट चलाने पर, इन प्रॉपर्टी को -D के साथ पास करें. प्रॉपर्टी, चलाए जाने वाले हर टेस्ट पर लागू होती हैं. इसलिए, सिर्फ़ उन टेस्ट को चलाने के लिए --tests विकल्प का इस्तेमाल करें जिनकी ज़रूरत है. उदाहरण के लिए, यहां दिया गया कमांड ThemeTransferTest को चलाता है. इसमें emulator-5554 को सोर्स डिवाइस और emulator-5556 को टारगेट डिवाइस के तौर पर इस्तेमाल किया जाता है:

./gradlew :app:testDebugBackupTestDefaultTestSuite --tests "com.example.myapp.ThemeTransferTest" -Dandroidx.test.backup.device.serials=emulator-5554,emulator-5556

टेस्ट के बीच ऐप्लिकेशन का डेटा सेव रखना

हर टेस्ट से पहले, टेस्ट फ़्रेमवर्क हर उस डिवाइस पर आपके ऐप्लिकेशन का डेटा मिटा देता है जिसका इस्तेमाल टेस्ट के लिए किया जाता है. किसी टेस्ट क्लास या तरीके के लिए इसे बंद करने के लिए, उसे @Isolation(IsolationPolicy.MANUAL) के साथ एनोटेट करें.

Java में टेस्ट लिखना

BackupRestoreController तरीके, Kotlin के निलंबित किए जा सकने वाले फ़ंक्शन हैं. अगर आपको Java में होस्ट टेस्ट लिखने हैं, तो हर तरीके के Async वैरिएंट का इस्तेमाल करें. जैसे, runBackupRestoreFlowAsync, जो ListenableFuture दिखाता है.

बैकअप लेने और उसे रीस्टोर करने से जुड़े टेस्ट चलाना

AGP, सुइट के टेस्ट किए जाने वाले हर वैरिएंट के लिए एक Gradle टास्क बनाता है. इसका नाम test{Variant}{SuiteName}DefaultTestSuite होता है. debug के वैरिएंट के ख़िलाफ़ backupTest सुइट चलाने के लिए, अपने डिवाइसों को कनेक्ट करें और यह टास्क चलाएं:

./gradlew :app:testDebugBackupTestDefaultTestSuite

check, test, और connectedCheck टास्क, बैकअप और रीस्टोर करने वाले टेस्ट सुइट को नहीं चलाते. इसलिए, सुइट के टास्क को अलग से चलाएं.

किसी एक टेस्ट क्लास या तरीके को चलाने के लिए, --tests विकल्प का इस्तेमाल करें:

./gradlew :app:testDebugBackupTestDefaultTestSuite --tests "com.example.myapp.ThemeBackupTest"

टेस्ट रिपोर्ट की जांच करना

टेस्ट रन पूरा होने के बाद, एजीपी {module}/build/reports/tests/{taskName}/index.html पर एचटीएमएल टेस्ट रिपोर्ट जनरेट करता है, जैसे कि app/build/reports/tests/testDebugBackupTestDefaultTestSuite/index.html.

आम तौर पर होने वाली समस्याएं और सीमाएं

अपने-आप बैकअप लेने और उसे वापस पाने की सुविधा की टेस्टिंग में, ये समस्याएं और सीमाएं होती हैं:

• Android Studio में टेस्ट सुइट की सुविधा फ़िलहाल उपलब्ध नहीं है. ऐसा हो सकता है कि कोड एडिटर, टेस्ट सुइट की सोर्स फ़ाइलों में रेफ़रंस से जुड़ी ऐसी गड़बड़ियां दिखाए जिन्हें ठीक नहीं किया जा सका है. ऐसा तब भी हो सकता है, जब आपका प्रोजेक्ट सही तरीके से कॉन्फ़िगर किया गया हो. इसके बजाय, Gradle का इस्तेमाल करके कमांड लाइन से, बैकअप और रीस्टोर करने की जांच बनाएं और चलाएं.
• टेस्ट सिर्फ़ उन डिवाइसों और एम्युलेटर पर चलते हैं जो adb के ज़रिए आपकी डेवलपमेंट मशीन से कनेक्ट होते हैं. Firebase टेस्ट लैब का इस्तेमाल नहीं किया जा सकता.
• टेस्ट से, ऐप्लिकेशन का डेटा मिट जाता है. साथ ही, इस्तेमाल किए गए डिवाइसों पर बैकअप की सेटिंग बदल जाती हैं. हमारा सुझाव है कि आप टेस्टिंग के लिए अलग से डिवाइस इस्तेमाल करें.

हर रिलीज़ में किए गए बदलावों के लिए, बैकअप और वापस लाने की टेस्टिंग से जुड़े रिलीज़ नोट्स देखें.