Risoluzione dei problemi e domande frequenti sulla piattaforma di dispositivi per sviluppatori

Anteprima

Questo prodotto o funzionalità sono soggetti ai "Termini dell'offerta pre-GA" nella sezione dei Termini di servizio generali dei Termini specifici dei servizi. I prodotti e le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per ulteriori informazioni, consulta le descrizioni della fase di lancio.

Questa pagina fornisce assistenza per la risoluzione dei problemi e risposte alle domande frequenti sull'esecuzione di test con la piattaforma per dispositivi per sviluppatori. Se non riesci a trovare quello che stai cercando o hai bisogno di ulteriore assistenza, contattaci.

Risoluzione dei problemi

Perché il mio test richiede così tanto tempo per essere eseguito?

Quando selezioni un dispositivo con un livello di capacità elevato nel catalogo della piattaforma per dispositivi per sviluppatori, i test potrebbero iniziare più velocemente. Quando un dispositivo ha una capacità ridotta, l'esecuzione dei test potrebbe richiedere più tempo. Se il numero di test richiamati è molto maggiore della capacità dei dispositivi selezionati, il completamento dei test può richiedere più tempo.

I test eseguiti su qualsiasi livello di capacità del dispositivo potrebbero richiedere più tempo a causa dei seguenti fattori:

• Traffico, che influisce sulla disponibilità del dispositivo e sulla velocità del test.
• Guasti del dispositivo o dell'infrastruttura, che possono verificarsi in qualsiasi momento. Per verificare se è stata segnalata un'infrastruttura per la piattaforma per dispositivi per sviluppatori, consulta la dashboard Google Cloud Personalized Service Health.

Per saperne di più sulla capacità del dispositivo nella piattaforma per sviluppatori di dispositivi, consulta il catalogo dei dispositivi.

Perché ricevo risultati del test inconcludenti?

I risultati inconcludenti dei test si verificano comunemente a causa di esecuzioni di test annullate o errori dell'infrastruttura. Oltre a PASSED e FAILED, la piattaforma per dispositivi per sviluppatori potrebbe restituire ERROR, TIMED_OUT e CANCELLED.

Gli errori di infrastruttura sono causati da problemi interni della piattaforma per dispositivi per sviluppatori, ad esempio errori di rete o comportamenti imprevisti del dispositivo. La piattaforma per dispositivi per sviluppatori esegue internamente più tentativi di esecuzione dei test che producono errori di infrastruttura prima di segnalare un risultato non conclusivo.

Per determinare la causa dell'errore, segui questi passaggi:

1. Controlla la presenza di interruzioni note nella dashboard Google Cloud Service Health.

2. Riprova il test nella piattaforma per dispositivi per sviluppatori per verificare che sia riproducibile.

   Nota: Developer Device Platform non addebita costi per gli errori dell'infrastruttura.

3. Se applicabile, prova a eseguire il test su un altro dispositivo o tipo di dispositivo. Per ulteriori informazioni, consulta il catalogo dei dispositivi.

Perché lo sharding ha allungato la durata dei miei test?

Lo sharding può causare l'esecuzione più lunga dei test quando il numero di shard specificato supera il numero di dispositivi disponibili per l'utilizzo nella piattaforma per dispositivi per sviluppatori. Per evitare questa situazione, limita il numero di dispositivi al numero di shard. Per ulteriori informazioni sulla scelta di un altro dispositivo, consulta il catalogo dei dispositivi.

Perché il mio test richiede così tanto tempo per iniziare?

Quando invii una richiesta di test, la tua app viene prima convalidata, firmata nuovamente e così via in preparazione all'esecuzione dei test su un dispositivo. Normalmente, questa procedura viene completata in meno di pochi secondi, ma può essere influenzata da fattori come le dimensioni dell'app.

Una volta preparata l'app, le esecuzioni dei test vengono pianificate e rimangono in una coda finché un dispositivo non è pronto per eseguirle.

Nota: il tempo di attesa del test per un dispositivo disponibile non viene conteggiato nel tempo di fatturazione.

Perché il mio test richiede così tanto tempo per essere completato?

Al termine dell'esecuzione del test, gli artefatti di test vengono scaricati dal dispositivo, elaborati e caricati in Cloud Storage. La durata di questo passaggio può essere influenzata dalla quantità e dalle dimensioni degli artefatti.

Risoluzione dei problemi specifici per Android

L'app non restituisce dati e non è possibile individuare gli screenshot

Gli artefatti di esecuzione del test (come screenshot e file di log) vengono archiviati in Cloud Storage e visualizzati direttamente nella console Google Cloud . Verifica di aver assegnato i ruoli a livello di progetto.

Tieni presente inoltre che Developer Device Platform ha un agente di servizio dedicato che utilizza le proprie credenziali anziché le tue per:

• Lettura e scrittura in bucket e oggetti Cloud Storage
• Scarica i file di input di Cloud Storage nel sistema interno
• Carica i file dal sistema interno al bucket di output Cloud Storage

È possibile che tu abbia accesso a un bucket Cloud Storage e a un file, ma che il bucket sia di proprietà di un progetto Google Cloud diverso da quello utilizzato in DDP. Pertanto, il account di servizio della piattaforma per dispositivi per sviluppatori non ha accesso.

Potresti anche avere controlli dell'accesso aggiuntivi sui singoli bucket. Consulta Device Run per scoprire come includere i file nei test.

Perché ricevo risultati parziali o mancanti degli scenari di test di instrumentazione?

Quando esegui test di strumentazione, potresti notare che i casi di test totali sono inferiori a quanto previsto. Questo problema è spesso causato dall'incapacità della piattaforma di dispositivi per sviluppatori di analizzare il logcat per i marcatori di inizio o fine dello scenario di test che vengono solitamente generati da AndroidJUnitRunner.

Di seguito sono riportate alcune cause comuni di questo problema:

Descrizione del problema	Possibile risoluzione
Lo scenario di test non è stato eseguito a causa di un timeout. Se la durata totale dei test è superiore a un timeout specificato o a un timeout massimo, la piattaforma per dispositivi per sviluppatori annulla il resto degli scenari di test.	Aumenta il timeout di instrumentazione per il test utilizzando `--instrumentation-timeout` per assicurarti che tutti i test possano essere completati. Dividi i test in shard se non l'hai già fatto, in modo che ogni shard esegua un sottoinsieme dei test e venga completato in un periodo di tempo più breve. Se hai già abilitato lo sharding, aumenta il numero di shard.
Il caso di test non è stato completato perché è uscito prematuramente o si è bloccato. Il caso di test potrebbe terminare prematuramente a causa di un'eccezione non rilevata o di un errore di asserzione. I casi di test possono bloccarsi in un ciclo infinito o non essere in grado di procedere, ad esempio se l'app non mostra la visualizzazione corretta e il caso di test non può eseguire l'azione sull'interfaccia utente.	Controlla il video e il logcat per capire dove si è interrotto il test.
Un esecutore del test personalizzato (inclusa l'estensione di AndroidJUnitRunner) ha subito un arresto anomalo in modo imprevisto o ha scritto marcatori di inizio o fine dello scenario di test imprevisti in logcat.	Controlla il codice del test runner.
Sono stati scritti log eccessivi in logcat, che hanno sovraccaricato il buffer o causato l'arresto anomalo del processo logcat.	Riduci le scritture a logcat.
L'app in fase di test ha subito un arresto anomalo.	Esegui il debug dell'app.

---

Domande frequenti

Dove posso trovare informazioni sui prezzi della piattaforma per dispositivi per sviluppatori?

Per maggiori dettagli, consulta la sezione Domande su prezzi e fatturazione.

Dove posso trovare i dettagli del dispositivo, come la risoluzione e così via?

Informazioni dettagliate sul dispositivo sono disponibili tramite l'API e sono accessibili dall'interfaccia a riga di comando della piattaforma per sviluppatori di dispositivi con il comando device-run devices describe <device-id>:

gcloud beta device-run devices describe DEVICE_ID

Come faccio a sapere se il traffico che raggiunge il mio backend proviene dalla piattaforma per dispositivi per sviluppatori?

Dal backend, puoi determinare se il traffico proviene da dispositivi di test ospitati dalla piattaforma per dispositivi per sviluppatori controllando l'indirizzo IP di origine rispetto ai nostri intervalli IP.

Developer Device Platform funziona con VPC-SC?

Developer Device Platform non funziona con VPC-SC, che blocca la copia di app e altri artefatti di test tra lo spazio di archiviazione interno di Developer Device Platform e i bucket dei risultati degli utenti.

Come faccio a ridurre i test instabili nella piattaforma per dispositivi per sviluppatori?

Per rilevare un comportamento instabile nei test, ti consigliamo di utilizzare l'opzione --flaky-test-attempts. Le ripetizioni di test per eliminare i test instabili vengono fatturate o conteggiate ai fini della quota giornaliera come le normali esecuzioni dei test.

Tieni presente che:

• Per impostazione predefinita, DDP esegue i nuovi tentativi in sequenza per risparmiare sui costi. Gli utenti devono impostare --flaky-test-parallel-retry in modo che venga eseguito in parallelo.
• Il flag --flaky-test-retry-level definisce se riprovare a livello di shard o di singolo test e il valore predefinito è shard. Imposta il valore su test per ridurre le dimensioni e la durata del test di ripetizione.

Nota: gli errori di infrastruttura sono indipendenti dalla funzionalità di eliminazione dei test instabili e non attivano nuove esecuzioni.

Domande frequenti specifiche per iOS

La piattaforma per dispositivi per sviluppatori supporta Appium, Flutter/FlutterDriver, ReactNative/Jest o Cucumber?

Sebbene alcuni di questi elementi siano nella nostra roadmap, non possiamo impegnarci a supportare queste piattaforme di test e sviluppo di app.

Perché nel test iOS mancano video nei risultati?

Il supporto per i video nei risultati è previsto per iOS 18 o versioni successive.

Domande frequenti specifiche per Android

La piattaforma per dispositivi per sviluppatori supporta i dispositivi indossabili?

Sì. La piattaforma per dispositivi per sviluppatori supporta Google Pixel Watch. Ora puoi eseguire test sulla tua app per Wear OS autonoma su Google Pixel Watch. Per saperne di più sui dispositivi della piattaforma per sviluppatori, consulta il catalogo dei dispositivi.

La piattaforma per dispositivi per sviluppatori supporta i dispositivi Google più recenti?

Sì. La piattaforma per dispositivi per sviluppatori supporta Google Pixel Tablet e Google Pixel Fold. Puoi eseguire i test sui tuoi dispositivi fisici autonomi. Per scoprire di più sui dispositivi disponibili nella piattaforma per sviluppatori, consulta il catalogo dei dispositivi.

La piattaforma per dispositivi per sviluppatori supporta Appium, Flutter/FlutterDriver, ReactNative/Jest o Cucumber?

Sebbene alcuni di questi elementi siano nella nostra roadmap, non possiamo impegnarci a supportare queste piattaforme di test e sviluppo di app. Tuttavia, se hai creato la tua app con un framework che supporta Espresso (ad esempio, Flutter), puoi scrivere un test di strumentazione utilizzando Espresso e poi eseguirlo nella piattaforma per dispositivi per sviluppatori.

La piattaforma per dispositivi per sviluppatori supporta il test di app offuscate, ad esempio con ProGuard o R8?

Developer Device Platform non supporta esplicitamente l'offuscamento o l'annullamento dell'offuscamento. Anche se l'app verrà probabilmente eseguita, tutti i dati dell'app offuscati, come le analisi dello stack, appariranno offuscati nei log.

Posso utilizzare il mio dispositivo pieghevole in diverse posizioni e stati di piegatura durante i test sulla piattaforma Developer Device?

Sì. Puoi testare il tuo dispositivo pieghevole in stati e posture pieghevoli.

I dispositivi pieghevoli possono essere in vari stati di piegatura, ad esempio FLAT (completamente aperto) o HALF_OPENED (tra completamente aperto e completamente chiuso).

Le posture, invece, consistono in un orientamento specifico del dispositivo e in uno stato di piegatura. Ad esempio, la postura da tavolo, che è uno stato HALF_OPENED in orientamento orizzontale, o la postura a libro, che è uno stato HALF_OPENED in orientamento verticale.

Se esegui test di strumentazione, puoi utilizzare la libreria Jetpack WindowManager e seguire la documentazione relativa ai test dell'app sui dispositivi pieghevoli per testare diversi stati e posture.

In alternativa, gli stati disponibili sono specifici per il dispositivo e possono essere usati tramite adb shell command cmd device_state.

• Per elencare lo stato attuale, esegui adb shell cmd device_state state.
• Per impostare o sostituire lo stato attuale, esegui adb shell cmd device_state state <IDENTIFIER>.
• Per reimpostare lo stato, esegui adb shell cmd device_state state reset.
• Per controllare gli stati disponibili, esegui il comando adb shell cmd device_state print-states sul dispositivo pieghevole.

Google Pixel Fold (ID modello felix)

$ adb shell cmd device_state print-states
Supported states: [
      DeviceState{identifier=0, name='CLOSED', app_accessible=true},
      DeviceState{identifier=1, name='HALF_OPENED', app_accessible=true},
      DeviceState{identifier=2, name='OPENED', app_accessible=true},
      DeviceState{identifier=3, name='REAR_DISPLAY_STATE', app_accessible=true},
]

Samsung Galaxy Z Fold4 (ID modello q4q)

$ adb shell cmd device_state print-states
Supported states: [
      DeviceState{identifier=0, name='CLOSE', app_accessible=true},
      DeviceState{identifier=1, name='TENT', app_accessible=true},
      DeviceState{identifier=2, name='HALF_FOLDED', app_accessible=true},
      DeviceState{identifier=3, name='OPEN', app_accessible=true},
]

Posso provare la piattaforma per dispositivi per sviluppatori se non ho un'app?

A differenza di altri prodotti Developer Device Platform, non è necessario aggiungere un SDK Developer Device Platform per utilizzare Developer Device Platform. Se non hai ancora un'app, puoi scaricare un APK online o creare un'app e un APK di test da uno degli esempi nel repository GitHub di AndroidX. Tieni presente che un test di strumentazione richiede sia un'app sia un APK di test creati dal codice sorgente. Per saperne di più, leggi l'articolo sui test strumentati.

Per scoprire di più sulle funzionalità della piattaforma per dispositivi per sviluppatori, consulta la panoramica del prodotto DDP.

Quali dispositivi sono più adatti per i test di confronto degli screenshot?

Il test di confronto degli screenshot si basa sul confronto delle asserzioni di test con le immagini dello schermo ottenute durante l'esecuzione di un test con le immagini di riferimento che rappresentano il comportamento previsto. Questi test potrebbero essere più fragili su alcuni tipi di dispositivi rispetto ad altri. Per questi tipi di test, ti consigliamo di scegliere come target dispositivi emulatore Arm (*.arm). I dispositivi emulatore ARM utilizzano immagini molto simili o identiche agli emulatori generici di Android Studio.

Ti consigliamo inoltre di esaminare le librerie di test che possono contribuire a rendere i test degli screenshot più solidi in presenza di modifiche previste.

La piattaforma per dispositivi per sviluppatori aggiorna i dispositivi virtuali?

Sì. I dispositivi virtuali vengono aggiornati quando vengono apportate le seguenti modifiche:

1. Aggiornamenti alle immagini esistenti
2. Ritiro dei livelli API precedenti
3. Vengono aggiunti nuovi livelli API Android

Come faccio ad attivare i report sulla copertura?

Per attivare i report sulla copertura, aggiungi coverage=true al campo additional-test-options. Se utilizzi Android Test Orchestrator, devi fornire un percorso di directory in cui memorizzare i risultati della copertura:

--additional-test-options coverage=true,coverageFilePath=/sdcard/Download/

Se non utilizzi Orchestrator, puoi specificare un percorso del file:

--additional-test-options coverage=true,coverageFile=/sdcard/Download/coverage.ec

Come faccio ad accedere a un'app Wear senza smartphone?

Se normalmente la tua app richiede un telefono per l'accesso, puoi creare una variante di compilazione che salta l'accesso e utilizza un token incorporato nella build di test oppure leggere i file sul disco in genere inviati utilizzando il flag --other-files-to-push.

---