Informa i tester sulle nuove build

Gli SDK iOS e Android opzionali Firebase App Distribution ti consentono di visualizzare avvisi in-app ai tuoi tester quando sono disponibili per l'installazione nuove build della tua app. Questa guida spiega come utilizzare gli SDK per iOS e Android di distribuzione app per creare e personalizzare nuovi avvisi di build per i tuoi tester.

Prima di iniziare

Se non l'hai già fatto, aggiungi Firebase al tuo progetto Android .

Passaggio 1 : abilita l'API del tester di distribuzione delle app

  1. Seleziona il tuo progetto in Google Cloud Console .

  2. In API Firebase App Testers, fai clic su Abilita .

Passaggio 2 : aggiungi la distribuzione dell'app alla tua app

L'SDK per Android di distribuzione app è costituito da due librerie:

  • firebase-appdistribution-api - La libreria solo API, che puoi includere in tutte le varianti di build .
  • firebase-appdistribution : l'implementazione completa dell'SDK (facoltativa).

La libreria solo API consente al tuo codice di effettuare chiamate all'SDK. Le chiamate non avranno alcun effetto se non è presente l'implementazione completa dell'SDK.

Dichiara la dipendenza per l'SDK Android di distribuzione app nel file Gradle del tuo modulo (a livello di app (di solito app/build.gradle ). Per evitare di includere la funzionalità di aggiornamento automatico dell'implementazione completa dell'SDK nelle build di Play, aggiungi la dipendenza dalla libreria solo API a tutte le varianti di build. Aggiungi l'implementazione completa dell'SDK solo alle varianti destinate esclusivamente ai test pre-rilascio:

Java

dependencies {
    // ADD the API-only library to all variants
    implementation 'com.google.firebase:firebase-appdistribution-api:16.0.0-beta03'

    // ADD the full SDK implementation to the "beta" variant only (example)
    betaImplementation 'com.google.firebase:firebase-appdistribution:16.0.0-beta03'
}

Kotlin+KTX

dependencies {
    // ADD the API-only library to all variants
    implementation 'com.google.firebase:firebase-appdistribution-api-ktx:16.0.0-beta03'

    // ADD the full SDK implementation to the "beta" variant only (example)
    betaImplementation 'com.google.firebase:firebase-appdistribution:16.0.0-beta03'
}

Passaggio 3 : configura gli avvisi in-app

L'SDK per Android di distribuzione app fornisce i seguenti modi per impostare avvisi di build in-app per i tuoi tester:

  • Una configurazione di avviso di base fornita con l'aggiornamento dell'app predefinito e finestre di dialogo di accesso da mostrare ai tester.
  • Una configurazione avanzata degli avvisi che consente di personalizzare la propria interfaccia utente.

Se utilizzi per la prima volta l'SDK Android di distribuzione app, ti consigliamo di utilizzare la configurazione di base .

Configurazione di base

Usa updateIfNewReleaseAvailable per visualizzare una finestra di dialogo di abilitazione degli avvisi predefinita per i tester che non hanno ancora abilitato gli avvisi, quindi controlla se è disponibile una nuova build. Quando viene chiamato, il metodo esegue la seguente sequenza:

  1. Verifica se un tester ha abilitato gli avvisi. Se il tester non ha ancora abilitato gli avvisi, il metodo richiede al tester di accedere a App Distribution con il proprio account Google.

  2. Verifica la presenza di nuove build disponibili per l'installazione del tester.

  3. Visualizza un avviso predefinito che richiede al tester di aggiornare.

  4. Se la nuova build è un Android App Bundle (AAB), reindirizza il tester a Google Play per completare il processo di aggiornamento.

    Se la nuova build è un'applicazione Android PacKage (APK), l'SDK scarica la nuova build in background e richiede al tester di installarla al termine del download. L'SDK invia notifiche sull'avanzamento del download all'utente utilizzando NotificationManager . Puoi anche aggiungere il tuo indicatore di avanzamento allegando un gestore onProgressUpdate all'attività updateIfNewReleaseAvailable .

Puoi chiamare updateIfNewReleaseAvailable in qualsiasi momento nella tua app. Ad esempio, puoi chiamare updateIfNewReleaseAvailable durante il metodo onResume dell'attività principale dell'app.

L'esempio seguente verifica se il tester ha abilitato gli avvisi e ha accesso a una nuova build. Se queste condizioni sono soddisfatte, viene visualizzata una finestra di dialogo quando la build è disponibile per l'installazione:

Java

// Copy and paste this into any part of your app - for example, in your main
// activity's onResume method.
FirebaseAppDistribution firebaseAppDistribution = FirebaseAppDistribution.getInstance();
firebaseAppDistribution.updateIfNewReleaseAvailable()
    .addOnProgressListener(updateProgress -> {
      // (Optional) Implement custom progress updates in addition to
      // automatic NotificationManager updates.
    })
    .addOnFailureListener(e -> {
      // (Optional) Handle errors.
      if (e instanceof FirebaseAppDistributionException) {
        switch (((FirebaseAppDistributionException)e).getErrorCode()) {
          case NOT_IMPLEMENTED:
            // SDK did nothing. This is expected when building for Play.
            break;
          default:
            // Handle other errors.
            break;
        }
      }
    });

Kotlin+KTX

// Copy and paste this into any part of your app - for example, in your main
// activity's onResume method.
val firebaseAppDistribution = FirebaseAppDistribution.getInstance()
firebaseAppDistribution.updateIfNewReleaseAvailable()
    .addOnProgressListener { updateProgress ->
      // (Optional) Implement custom progress updates in addition to
      // automatic NotificationManager updates.
    }
    .addOnFailureListener { e ->
      // (Optional) Handle errors.
      if (e is FirebaseAppDistributionException) {
        when (e.errorCode) {
          Status.NOT_IMPLEMENTED -> {
            // SDK did nothing. This is expected when building for Play.
          }
          else -> {
            // Handle other errors.
          }
        }
      }
    }

Configurazione avanzata

Configurazione di accesso avanzata

I metodi signInTester e isTesterSignedIn ti offrono una maggiore flessibilità per personalizzare l'esperienza di accesso del tester, in modo che l'esperienza del tester possa corrispondere meglio all'aspetto dell'app.

L'esempio seguente verifica se il tester ha già effettuato l'accesso al proprio account tester di distribuzione app. Ciò ti consente di scegliere di visualizzare l'interfaccia utente (UI) di accesso solo ai tester che non hanno ancora effettuato l'accesso. Dopo che il tester ha eseguito l'accesso, puoi chiamare updateIfNewReleaseAvailable per verificare se il tester ha accesso a una nuova build.

Java

// Only show sign-in UI if this is the "beta" variant (example).
if (BuildConfig.BUILD_TYPE == "beta" && !firebaseAppDistribution.isTesterSignedIn()) {
    // Start your sign-in UI here.
}

// Only check for updates if the tester is already signed in (do not prompt).
if (firebaseAppDistribution.isTesterSignedIn()) {
    firebaseAppDistribution.updateIfNewReleaseAvailable().addOnFailureListener( e -> {
        // Handle failed update.
    });
}

Kotlin+KTX

// Only show sign-in UI if this is the "beta" variant (example).
if (BuildConfig.BUILD_TYPE == "beta" && !firebaseAppDistribution.isTesterSignedIn) {
    // Start your sign-in UI here.
}

// Only check for updates if the tester is already signed in (do not prompt).
if (firebaseAppDistribution.isTesterSignedIn) {
    firebaseAppDistribution.updateIfNewReleaseAvailable().addOnFailureListener {
        // Handle failed update.
    }
}

Dall'interfaccia utente di accesso, quando il tester sceglie di procedere, chiama signInTester() :

Java

firebaseAppDistribution.signInTester().addOnSuccessListener( unused -> {
  // Handle successful sign-in.
}).addOnFailureListener(e -> {
  // Handle failed sign-in.
});

Kotlin+KTX

firebaseAppDistribution.signInTester().addOnSuccessListener {
  // Handle successful sign-in.
}.addOnFailureListener {
  // Handle failed sign-in.
});

Configurazione aggiornamento avanzato

I metodi checkForNewRelease e updateApp offrono maggiore flessibilità per la personalizzazione quando viene richiesto di aggiornare il tester. Puoi anche personalizzare la finestra di dialogo di aggiornamento predefinita e l'indicatore di avanzamento del download in modo che si adattino meglio all'aspetto della tua app.

Tieni presente che updateApp non fornisce indicazioni sull'avanzamento del download. Ciò significa che devi implementare la tua indicazione di avanzamento utilizzando NotificationManager , una sorta di visualizzazione dello stato in-app o qualche altro approccio.

L'esempio seguente verifica se è disponibile una nuova versione e quindi visualizza un'interfaccia utente personalizzata. Prima di chiamare checkForNewRelease e updateApp , assicurati che il tester abbia eseguito l'accesso usando la configurazione di accesso avanzata .

Java

firebaseAppDistribution.checkForNewRelease().addOnSuccessListener(release -> {
    if (release != null) {
        // New release available. Start your update UI here.
    }
}).addOnFailureListener(e -> {
    // Handle failed check for new release. Fails with Status#NOT_IMPLEMENTED
    // if built for Play.
});

Kotlin+KTX

firebaseAppDistribution.checkForNewRelease().addOnSuccessListener { release ->
    if (release != null) {
        // New release available. Start your update UI here.
    }
}.addOnFailureListener {
    // Handle failed check for new release. Fails with Status#NOT_IMPLEMENTED
    // if built for Play.
}

Quando il tester sceglie di procedere con l'aggiornamento dall'interfaccia utente di aggiornamento, chiama updateApp() :

Java

firebaseAppDistribution.updateApp()
    .addOnProgressListener(updateState -> {
      // Use updateState to show update progress.
    });

Kotlin+KTX

firebaseAppDistribution.updateApp()
    .addOnProgressListener { updateState ->
      // Use updateState to show update progress.
    }

Passaggio 4 : crea e testa la tua implementazione

Crea la tua app e testa la tua implementazione distribuendo la build ai tester utilizzando la console Firebase.

Visita la guida alla risoluzione dei problemi di distribuzione delle app per assistenza con problemi comuni, ad esempio:

  • Il tester non riceve avvisi in-app
  • Al tester viene richiesto di accedere a Google più di una volta