O Google usa tecnologia de IA na tradução de conteúdos para seu idioma de preferência. As traduções com IA podem ter erros.

Teste automatizado de backup e restauração

Quando os usuários configuram um novo dispositivo ou reinstalam seu app, o Android pode restaurar os dados do app usando um backup na nuvem ou uma transferência entre dispositivos. Se as regras de backup deixarem de fora dados importantes ou se o app não puder usar os dados restaurados, os usuários vão perder as configurações e o progresso sem ver um erro.

Os testes automatizados de backup e restauração ajudam a detectar esses problemas antes de lançar o app. Eles são testes do JUnit 5 que são executados na máquina de desenvolvimento e controlam os dispositivos conectados pelo Android Debug Bridge (adb). Cada teste propaga dados do app em um dispositivo, faz backup e restaura o app usando o framework de backup do Android e, em seguida, verifica se os dados estão intactos. Configure os testes como um pacote de testes do Plug-in do Android para Gradle (AGP) no arquivo de build do módulo.

Como funciona

Um pacote de testes de backup e restauração tem duas partes que funcionam juntas:

Os testes de host são testes do JUnit 5 executados na sua máquina de desenvolvimento. Eles usam um BackupRestoreController para cada dispositivo para propagar dados, fazer backup e restaurar o app e verificar os resultados.
As ações do dispositivo são classes que implementam BackupDeviceAction. Eles são executados no processo do app no dispositivo, para que possam ler e gravar dados pelo próprio código do app. Os testes de host chamam ações do dispositivo pelo nome da classe.

Quando você executa o pacote, o AGP cria seu app e um APK de teste que contém as ações no dispositivo. O framework de teste instala os dois APKs em cada dispositivo usado pelos testes e limpa os dados do app antes de cada teste.

Tipos de armazenamento integrado

A tabela a seguir lista as subclasses StorageDomain que permitem propagar e verificar dados sem escrever ações no dispositivo:

Domínio de armazenamento	Dados
`StorageDomain.Preference`	Uma chave em um arquivo `SharedPreferences`.
`StorageDomain.Database`	Uma linha em uma tabela de banco de dados SQLite.
`StorageDomain.TextFile`	Um arquivo de texto no armazenamento interno do app.
`StorageDomain.BinaryFile`	Um arquivo binário no armazenamento interno do app.

Para testar outros dados, como arquivos do DataStore, escreva ações do dispositivo.

Meios de transporte

Cada backup usa um valor BackupTransportMode. A tabela a seguir lista os meios de transporte disponíveis:

Modo	Cenário
`LOCAL`	Um backup para o transporte de backup local do dispositivo. Os dados de backup permanecem no dispositivo.
`CLOUD_ENCRYPTED`	Um backup na nuvem, como um salvo na Conta do Google do usuário em um dispositivo com criptografia do lado do cliente.
`CLOUD_UNENCRYPTED`	Um backup na nuvem de um dispositivo que não tem criptografia do lado do cliente.
`DEVICE_TO_DEVICE`	Uma transferência de dispositivo para dispositivo, por exemplo, por cabo ou Wi-Fi.

O LOCAL funciona em qualquer dispositivo compatível. Os modos de nuvem e de dispositivo para dispositivo criam os mesmos backups que a ação Backup App Data no Android Studio: o backup é salvo na máquina de desenvolvimento em vez de ser enviado por upload ou para outro dispositivo. Os modos de nuvem e de dispositivo para dispositivo exigem o Google Play Services no dispositivo e um build depurável do app. Se as regras de backup dependerem da criptografia do lado do cliente, teste os dois modos de nuvem.

Requisitos

Para usar o teste automatizado de backup e restauração, verifique se o ambiente atende aos seguintes requisitos:

Gradle versão 9.6.0 ou mais recente.
JDK versão 17 ou mais recente.
Um dispositivo ou emulador com o Android 12 (nível 31 da API) ou mais recente conectado pelo adb:
- Dispositivos ou emuladores no nível 36.1 ou mais recente da API exigem o Google Play Services versão 26.33.30 ou mais recente.
- Para testar as transferências entre dois dispositivos, conecte-os.

Compatibilidade

A tabela a seguir lista as versões mínimas e recomendadas para testes automatizados de backup e restauração:

Componente	Versão mínima	Versão recomendada
Android Studio	Rabbit 2 Canary 1	Rabbit 2 Canary 4 ou mais recente
Plug-in do Android para Gradle (AGP)	9.5.0-alpha06	9.5.0-alpha09 ou mais recente
`androidx.test.backup` bibliotecas	1.0.0-alpha01	1.0.0-alpha03 ou mais recente

Cada versão de pré-lançamento do AGP requer a versão de pré-lançamento correspondente do Android Studio. Para mais informações, consulte Pré-lançamentos do AGP.

Criar o projeto

Para adicionar um pacote de testes de backup e restauração ao módulo do app, siga estas etapas:

Ativar flags experimentais

No arquivo gradle.properties do projeto, ative os pacotes de testes e os testes de backup:

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

Declarar o pacote de testes

No arquivo build.gradle.kts do módulo do app, declare um pacote de testes de backup no bloco testOptions:

android {
    testOptions {
        backupTests {
            create("backupTest") {
                backupTestLibraryVersion = "1.0.0-alpha03"
            }
        }
    }
}

O nome do pacote, backupTest neste exemplo, determina os diretórios do conjunto de origem e os nomes das tarefas do Gradle. É possível personalizar o pacote com as seguintes propriedades opcionais:

Use backupTestLibraryVersion para definir a versão das bibliotecas androidx.test.backup que o AGP adiciona ao pacote, como "1.0.0-alpha03". Esta propriedade é opcional. Se você omitir, o AGP vai usar uma versão de biblioteca padrão com base na versão do AGP. Os exemplos nesta página exigem a versão 1.0.0-alpha03 ou mais recente.
Use targetVariants para especificar as variantes de build que o pacote testa, como targetVariants.add("demoDebug"). Esta propriedade é opcional. Se você omitir, o pacote vai testar as variantes do testBuildType do módulo, que é debug por padrão. Recomendamos testar uma variante depurável, porque os modos de transporte em nuvem e de dispositivo para dispositivo exigem um app depurável.

O AGP adiciona a biblioteca de host, androidx.test.backup:backup-host, e o JUnit 5 aos testes de host. Ele adiciona a biblioteca de dispositivos, androidx.test.backup:backup, ao APK de teste e define o executor de instrumentação do APK de teste.

Para adicionar outras dependências, use os blocos hostJar e testApk do pacote. Por exemplo, para usar o Truth nos testes de host, adicione-o ao bloco hostJar:

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

Criar os conjuntos de origem

Crie diretórios de conjuntos de origem que correspondam ao nome do pacote:

Coloque os testes de host em src/{suiteName}/test/kotlin/.
Coloque as ações do dispositivo em src/{suiteName}/androidTest/kotlin/.

Por exemplo, um pacote chamado backupTest usa a seguinte estrutura de diretórios:

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

Verificar a configuração de backup

Os testes fazem backup e restauram os dados incluídos na configuração de backup do app. Verifique se o backup está ativado para o app e se as regras de backup incluem os dados que você testa.

Criar testes de backup e restauração

Escreva testes de host no conjunto de origem test do pacote. Adicione a anotação @ExtendWith(BackupRestoreExtension::class) a cada classe de teste, que fornece dispositivos conectados aos testes. Os testes são executados na variante do app que o pacote segmenta. Portanto, não é necessário definir o ID do aplicativo.

Cada método de teste declara um parâmetro BackupRestoreController para cada dispositivo que ele usa.

Testar tipos de armazenamento integrados

Para testar os tipos de armazenamento integrados, chame runBackupRestoreFlow com os dados a serem propagados, um diretório para o arquivo de backup e um modo de transporte. O método executa as seguintes etapas no dispositivo:

Propaga cada domínio de armazenamento.
Interrompe o app.
Faz backup do app.
Limpa os dados do app.
Restaura o backup.
Verifica se cada domínio de armazenamento tem o valor de semente.

Se uma etapa falhar, o método vai gerar uma exceção, o que vai causar uma falha no teste. O exemplo a seguir testa uma chave SharedPreferences, uma linha do SQLite e um arquivo interno usando o transporte de backup local:

package com.example.myapp

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)
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,
        )
    }
}

Lembre-se do seguinte ao definir domínios de armazenamento:

Preference usa o nome do arquivo SharedPreferences sem a extensão .xml.
TextFile e BinaryFile resolvem caminhos relativos em relação ao filesDir do app.
Database grava a linha com SQL e cria a tabela com colunas TEXT se ela não existir. Se o app usa o Room, recomendamos testar o conteúdo do banco de dados com ações do dispositivo que usam seus DAOs para que o banco de dados tenha o esquema esperado pelo Room.

Ações de gravação do dispositivo

Para propagar ou verificar dados que os tipos de armazenamento integrados não cobrem, escreva ações do dispositivo no conjunto de origem androidTest do pacote. Uma ação de dispositivo implementa BackupDeviceAction e substitui dois membros:

Defina phase como BackupDeviceAction.PHASE_POPULATE para uma ação que gera dados ou BackupDeviceAction.PHASE_VERIFY para uma ação que verifica dados.
Implemente execute para executar a ação com o Context do app e os argumentos do teste de host. Retorne um resultado criado com o método de fábrica BackupDeviceActionResult.success ou BackupDeviceActionResult.failure e transmita uma mensagem de erro para failure.

O método execute é executado no processo do app em uma linha de execução em segundo plano, então ele pode bloquear até que as leituras e gravações sejam concluídas.

O exemplo a seguir define e verifica uma configuração de tema que o app armazena com o Preferences DataStore. O app define o DataStore no conjunto de origem principal:

// 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")

As ações do dispositivo usam as mesmas definições:

// 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")
        }
    }
}

Para retornar dados ao teste de host, transmita um mapa para o método success. O teste de host lê o mapa de BackupActionResult.Success.data.

Executar cada etapa do fluxo

Para usar ações do dispositivo ou personalizar o fluxo, chame cada etapa por conta própria. O teste de host a seguir executa as ações do dispositivo da seção anterior em um backup e restauração na nuvem:

package com.example.myapp

import androidx.test.backup.host.BackupActionResult
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)
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)
}

Quando uma ação do dispositivo falha, runOnDevice retorna um BackupActionResult.Failure em vez de gerar uma exceção. Portanto, verifique o resultado. As outras etapas vão gerar uma exceção se falharem.

Testar transferências entre dispositivos

Para testar uma transferência entre dois dispositivos, declare um parâmetro BackupRestoreController para cada dispositivo. Faça backup do app no dispositivo de origem e restaure o arquivo de backup no dispositivo de destino. O exemplo a seguir reutiliza as constantes e o auxiliar assertSuccess do exemplo anterior:

package com.example.myapp

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)
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()
    }
}

Os valores role de @Device permitem que você escolha um dispositivo para cada parâmetro ao executar os testes. Se apenas um dispositivo estiver conectado, os dois parâmetros vão usar esse dispositivo, e o teste vai simular a transferência em um único dispositivo. A limpeza dos dados do destino garante que os dados restaurados venham do backup.

Escolher dispositivos

Por padrão, o framework de teste classifica os dispositivos on-line por número de série e os atribui aos parâmetros BackupRestoreController de cada teste em ordem. Se um teste tiver mais parâmetros de dispositivo do que dispositivos, os parâmetros extras vão compartilhar o primeiro dispositivo. A variável de ambiente ANDROID_SERIAL não afeta a atribuição de dispositivos.

Para escolher dispositivos sem colocar números de série nos testes, atribua uma função a cada parâmetro de dispositivo com @Device(role = "..."). Em seguida, ao executar os testes, vincule cada função a um dispositivo com a propriedade do sistema androidx.test.backup.device.serial.{role}. Por exemplo, o comando a seguir executa o pacote com emulator-5554 como o dispositivo de origem e emulator-5556 como o dispositivo de destino:

./gradlew :app:testDebugBackupTestDefaultTestSuite -Dandroidx.test.backup.device.serial.source=emulator-5554 -Dandroidx.test.backup.device.serial.target=emulator-5556

Uma vinculação se aplica apenas a parâmetros com esse papel. Outros parâmetros recebem os dispositivos restantes.

Também é possível escolher dispositivos com os valores serial e api de @Device ou com as seguintes propriedades do sistema, que têm precedência sobre os valores @Device:

Propriedade do sistema	Descrição
`androidx.test.backup.device.serial.{role}`	O número de série do dispositivo para parâmetros anotados com `@Device(role = "{role}")`. Ela tem precedência sobre `serials` e `serial`.
`androidx.test.backup.device.serials`	Uma lista separada por vírgulas de números de série, atribuídos aos parâmetros do dispositivo em ordem.
`androidx.test.backup.device.serial`	O número de série do dispositivo para os parâmetros que o `serials` não cobre.
`androidx.test.backup.device.apis`	Uma lista separada por vírgulas de níveis da API, atribuídos aos parâmetros do dispositivo em ordem.
`androidx.test.backup.device.api`	O nível da API do dispositivo para os parâmetros que não são cobertos por `apis`.

Transmita essas propriedades com -D da mesma forma. As propriedades serial, serials, api e apis se aplicam a todos os testes executados. Portanto, use a opção --tests para executar apenas os testes que precisam delas.

Testar credenciais de restauração

Se o app usa o recurso Restaurar credenciais, teste se a chave de restauração sobrevive a um backup e restauração. Os modos de nuvem e de dispositivo para dispositivo fazem backup da chave com os dados do app, mas o LOCAL não.

Escreva ações do dispositivo que criem a chave e a recebam com o Credential Manager. A ação de criação retorna o ID da credencial da chave para que a ação de verificação possa confirmar que a restauração traz de volta a mesma chave. Neste exemplo, createRequestJson e getRequestJson são as strings JSON de solicitação que o app transmite ao Credential Manager:

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

import android.content.Context
import androidx.credentials.CreateRestoreCredentialRequest
import androidx.credentials.CreateRestoreCredentialResponse
import androidx.credentials.CredentialManager
import androidx.credentials.GetCredentialRequest
import androidx.credentials.GetRestoreCredentialOption
import androidx.credentials.RestoreCredential
import androidx.test.backup.BackupDeviceAction
import androidx.test.backup.BackupDeviceActionArgs
import androidx.test.backup.BackupDeviceActionResult
import kotlinx.coroutines.runBlocking
import org.json.JSONObject

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

    override fun execute(
        context: Context,
        args: BackupDeviceActionArgs,
    ): BackupDeviceActionResult {
        val request = CreateRestoreCredentialRequest(createRequestJson)
        val response = runBlocking {
            CredentialManager.create(context).createCredential(context, request)
        } as CreateRestoreCredentialResponse
        val credentialId = JSONObject(response.responseJson).getString("id")
        return BackupDeviceActionResult.success(mapOf("credential_id" to credentialId))
    }
}

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

    override fun execute(
        context: Context,
        args: BackupDeviceActionArgs,
    ): BackupDeviceActionResult {
        val option = GetRestoreCredentialOption(getRequestJson)
        val response = runBlocking {
            CredentialManager.create(context)
                .getCredential(context, GetCredentialRequest(listOf(option)))
        }
        val credential = response.credential as RestoreCredential
        val credentialId = JSONObject(credential.authenticationResponseJson).getString("id")
        val expected = args["credential_id"]
        return if (credentialId == expected) {
            BackupDeviceActionResult.success()
        } else {
            BackupDeviceActionResult.failure("Expected key $expected, found $credentialId")
        }
    }
}

O teste de host a seguir cria a chave no dispositivo de origem, a restaura no dispositivo de destino e a verifica. Ele usa o auxiliar assertSuccess de Executar cada etapa do fluxo:

package com.example.myapp

import androidx.test.backup.host.BackupActionResult
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

const val CREATE_RESTORE_KEY = "com.example.myapp.CreateRestoreKeyAction"
const val VERIFY_RESTORE_KEY = "com.example.myapp.VerifyRestoreKeyAction"

@ExtendWith(BackupRestoreExtension::class)
class RestoreKeyTest {

    @Test
    fun restoreKeyTransfersToNewDevice(
        @Device(role = "source") source: BackupRestoreController,
        @Device(role = "target") target: BackupRestoreController,
        @TempDir outputDir: Path,
    ): Unit = runBlocking {
        val created = source.runOnDevice(CREATE_RESTORE_KEY)
        created.assertSuccess()
        val credentialId =
            (created as BackupActionResult.Success).data.getValue("credential_id")
        source.stopApp()
        val backupFile = source.performBackup(
            BackupTransportMode.DEVICE_TO_DEVICE,
            outputDir,
        )

        // Also deletes any restore key on the target.
        target.clearAppData()
        target.performRestore(backupFile)
        target.runOnDevice(VERIFY_RESTORE_KEY, mapOf("credential_id" to credentialId))
            .assertSuccess()
    }
}

Para criar uma chave com isCloudBackupEnabled definido como true, o padrão, o dispositivo de origem precisa de uma Conta do Google com o backup ativado e um bloqueio de tela. Caso contrário, o Credential Manager vai gerar E2eeUnavailableException.

Ao contrário de uma restauração na nuvem em um novo dispositivo, os modos de nuvem não exigem a mesma Conta do Google ou o bloqueio de tela do dispositivo de origem e restauram as chaves criadas com isCloudBackupEnabled definido como false.

Manter os dados do app entre os testes

Antes de cada teste, o framework limpa os dados do app em cada dispositivo usado. Para desativar esse recurso em uma classe ou método de teste, adicione a anotação @Isolation(IsolationPolicy.MANUAL).

Criar testes em Java

Os métodos BackupRestoreController são funções de suspensão do Kotlin. Se você escrever testes de host em Java, use a variante Async de cada método, como runBackupRestoreFlowAsync, que retorna um ListenableFuture.

Executar testes de backup e restauração

O AGP cria uma tarefa do Gradle para cada variante testada pelo pacote, chamada test{Variant}{SuiteName}DefaultTestSuite. Para executar o pacote backupTest na variante debug, conecte seus dispositivos e execute a tarefa:

./gradlew :app:testDebugBackupTestDefaultTestSuite

As tarefas check, test e connectedCheck não executam pacotes de teste de backup e restauração. Portanto, execute a tarefa do pacote explicitamente.

Para executar uma única classe ou método de teste, use a opção --tests:

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

Inspecionar relatórios de teste

Depois que uma execução de teste é concluída, o AGP gera um relatório de teste em HTML em {module}/build/reports/tests/{taskName}/index.html, como app/build/reports/tests/testDebugBackupTestDefaultTestSuite/index.html.

Resolver problemas de restaurações com falha

Uma restauração na nuvem ou de dispositivo para dispositivo falha com uma mensagem de erro nos seguintes casos:

O Google Play Services ignora seu app, por exemplo, porque o ID do aplicativo começa com com.google. ou com.android., o backup está vazio ou define android:allowBackup="false". Para testar um app com esse ID, use o modo LOCAL.
A versão do Google Play Services é anterior à 26.33.30 em um dispositivo ou emulador que executa o nível 36.1 ou mais recente da API. Atualize o Google Play Services pela Play Store no dispositivo ou use uma imagem do sistema que venha com a versão 26.33.30 ou mais recente.

Limitações e problemas conhecidos

O teste automatizado de backup e restauração tem os seguintes problemas e limitações conhecidos:

O suporte do Android Studio para pacotes de testes ainda não está disponível. O editor de código pode mostrar erros de referência não resolvidos em arquivos de origem do pacote de testes, mesmo quando o projeto está configurado corretamente. Crie e execute testes de backup e restauração na linha de comando usando o Gradle.
Os testes são executados apenas em dispositivos e emuladores conectados à sua máquina de desenvolvimento pelo adb. O Firebase Test Lab não é compatível.
Os testes limpam os dados do app e mudam as configurações de backup nos dispositivos usados. Recomendamos o uso de dispositivos de teste dedicados.

Para ver as mudanças em cada versão, consulte as notas da versão de teste de backup e restauração.