Insight sulla generazione di codice degli agenti da Android Bench

Tomáš Mlynarič

Buongiorno a tutti.

Iniziamo.

A marzo abbiamo lanciato Android Bench, il nostro set di dati e la nostra classifica per la misurazione degli LLM sulle attività di sviluppo Android.

Da allora, l'abbiamo eseguito su molti nuovi modelli.

Proprio il mese scorso abbiamo rilasciato Android Bench 2.0.

Anche se sono passati solo un paio di mesi, nel mondo dell'AI sembra un'eternità.

Mi chiamo Tomáš e voglio condividere il nostro percorso con Android Bench e come siamo arrivati dove siamo ora.

Iniziamo con 1.0.

In 1.0, abbiamo preso problemi reali da repository open source.

Abbiamo filtrato i progetti GitHub con problemi GitHub, richieste di pull che risolvono questi problemi e test che verificano le soluzioni.

Suddividiamo le richieste di pull in bucket di attività per i modelli di AI.

Il problema di GitHub è diventato l'istruzione o il prompt per il modello e l'abbiamo inserito nello stato precedente alla PR.

Una volta che il modello ha creato un lavoro, abbiamo preso i test e li abbiamo applicati all'output, ottenendo un risultato positivo o negativo.

Questo singolo tentativo dell'AI di risolvere il problema è chiamato prova.

Inoltre, possiamo confrontarlo con la soluzione creata dall'uomo da quella PR, o quella che chiamiamo la soluzione d'oro.

Questa metodologia è simile al noto benchmark SWE-bench.

Abbiamo iniziato con oltre 10.000 potenziali attività, ma non tutte erano adatte.

Alcuni avevano istruzioni incomplete o troppo specifiche.

I test potrebbero essere stati accoppiati alla soluzione ottimale o lo stato prima della PR era danneggiato.

Per questo motivo, abbiamo dovuto esaminare e rivedere i dati per ottenere 100 attività eque.

Durante queste revisioni, abbiamo utilizzato i modelli allo stato dell'arte per ottenere alcuni risultati.

Siamo partiti con circa il 30% di attività risolte, che chiamiamo percentuale di superamento.

Poi, quando abbiamo bloccato il set di dati per la release ufficiale, i modelli migliori erano già intorno al 70%.

Ma questo avviene circa un mese dopo.

Abbiamo quindi pianificato di valutare nuovi modelli ogni mese e abbiamo osservato come miglioravano.

Nella release di agosto, la percentuale di superamento del 92% era per il modello migliore.

Sapevamo che la nostra soglia era troppo bassa e che questo set di dati era saturo.

Tomáš Mlynarič

Ma l'avevamo previsto e stiamo già lavorando sodo alla versione 2.0, che abbiamo rilasciato il mese scorso.

L'obiettivo è, ed è stato, alzare l'asticella con attività Android complesse e reali e fornire indicazioni e trasparenza sulle prestazioni degli LLM per voi, sviluppatori, ma anche spingere i produttori di modelli a dare priorità ad Android fornendo loro un buon benchmark con cui confrontarsi.

Inoltre, fornisce analisi e risultati utili sia a te che ai creatori di modelli.

Ma dobbiamo anche tenere conto di astuzia, tenacia e imbrogli.

Inoltre, dobbiamo prevenire il rischio di contaminazione.

Un problema della metodologia SWE-bench è l'effettiva apertura del codice sorgente.

OpenAI ha pubblicato un articolo.

Hanno scoperto che i modelli erano in grado di completare le parole successive delle istruzioni o di risolvere un'attività con un errore oscuro che non faceva parte delle istruzioni.

E si sono resi conto che i creatori di modelli si addestrano sul codice open source e che SWE-bench è contaminato.

Per questo motivo, per la versione 2.0, manteniamo il codice chiuso per impedire l'addestramento.

Abbiamo suddiviso il lavoro in quattro flussi di lavoro.

Il primo riguarda le conversioni di app, in cui abbiamo preso app open source, Flutter e React Native e abbiamo chiesto agli agenti di convertirle in soluzioni Android native.

Questo riflette la tendenza alla migrazione da multipiattaforma a nativa che vediamo oggi.

Il secondo flusso di lavoro riguardava le nuove funzionalità e le integrazioni della piattaforma.

Sono stati integrati in codebase di produzione consolidate.

Ad esempio, in Now in Android, abbiamo aggiunto la funzionalità video, Picture in picture e così via.

Il terzo flusso di lavoro riguardava le migrazioni.

Stiamo eseguendo l'upgrade delle app open source di produzione che abbiamo mantenuto chiuse, con librerie e architetture moderne.

Ad esempio, da Nav 2 a Nav 3, da visualizzazioni XML a Compose o da un singolo riquadro a un layout adattivo.

L'ultima era un'app greenfield interna creata da zero utilizzando modelli di progettazione visiva.

In questo caso, gli esempi erano il flusso di autenticazione OTP SMS completo, il monitoraggio degli ordini con Google Maps e altro ancora.

Tomáš Mlynarič

Con un paio di ingegneri, abbiamo creato un'app delle stesse dimensioni di Now in Android.

Ma le nuove attività hanno portato con sé nuove sfide.

Il primo: valutare correttamente gli agenti.

I test di benchmark sono molto più difficili dei test per la tua app perché devono superare qualsiasi soluzione valida, non solo una, e più grande è l'attività, più soluzioni valide ci sono.

Nella versione 1.0, il benchmark si basava principalmente sui test delle unità, che sono piuttosto inadatti a essere agnostici.

import com.foodvibes.MyViewModel

@Test
fun testRetry() {
    val vm = MyViewModel()
    vm.retry()

    assertTrue(vm.retried)
}

Richiedono nomi esatti di classi o funzioni.

Come in questo caso, non esiste un test sofisticato, ma, in pratica, l'agente potrebbe assegnare nomi diversi a questi elementi o, anche se non lo fa, se li inserisce in un pacchetto diverso, i test non verrebbero compilati e, di conseguenza, sarebbero inutilizzabili per il nostro caso.

import com.foodvibes.feature.my.RetriableViewModel

@Test
fun testRetry() {
    val vm = RetriableViewModel()
    vm.tryAgain()

    assertTrue(vm.tried)
}

Quindi, tecnicamente potremmo specificare le API nei prompt, ma questo rivelerebbe troppi dettagli o sovraccaricherebbe il prompt con troppi requisiti di test.

La soluzione è eseguire test indipendenti dall'implementazione.

Questi sono di altissimo livello e testano i risultati e i comportamenti, non gli elementi interni.

Utilizziamo il test dell'interfaccia utente deterministico, ovvero i test che interagiscono con le informazioni pubbliche sullo schermo, in modo simile a come farebbe un utente.

Per questi, utilizziamo i test UI Automator o Compose UI, ma abbiamo anche script specializzati che controllano alcuni limiti del sistema esterno, ad esempio se una chiamata di rete aveva i dati corretti o se i dati corretti vengono salvati in un database senza conoscere gli helper interni o i DAO.

Inoltre, eseguiamo anche controlli statici, ad esempio per verificare le autorizzazioni nel file manifest o se la libreria era presente nei file di build e cose del genere.

Inoltre, abbiamo anche test ibridi che sono una combinazione di questi script e dei test della UI.

Questo è un esempio di uno dei test ibridi.

Guidano al di fuori dell'emulatore.

Questo è il test per il flusso di autenticazione OTP via SMS, in cui lo script deve prima calcolare l'hash dell'app per poter inviare correttamente l'SMS all'emulatore, quindi avvia il test, i test di UI Automator, passa un OTP generato in modo casuale richiesto e invia l'SMS a un emulatore con un comando ADB.

Il test verifica semplicemente se l'input aveva il numero corretto.

Questo è tutto.

Non c'è alcun accoppiamento di implementazione, solo controlli, controlla solo se il flusso funziona.

Il secondo problema di valutazione era che le nostre attività richiedono la multimodalità.

Gli agenti devono produrre l'UI o noi forniamo loro i mockup di progettazione.

Per questo, il modo più semplice è utilizzare i test degli screenshot.

Sapevamo fin dall'inizio che le soglie degli screenshot dovevano essere più alte, ma non sono state comunque raggiunte.

Abbiamo provato alcuni algoritmi di differenziazione dei pixel, ma non hanno funzionato con elementi come il rumore a livello di sistema, dove la barra di stato dell'emulatore era diversa, o l'icona della batteria, o anche l'anti-aliasing hardware dei caratteri era diverso.

Ma non hanno superato nemmeno implementazioni in qualche modo valide, in cui, ad esempio, i padding erano minimi, leggermente diversi, o c'erano lievi differenze di tonalità, come l'interfaccia utente che poteva essere completamente corretta, ma lo sfondo aveva una tonalità leggermente diversa e gli algoritmi di pixel-diffing non funzionavano.

Per questo, abbiamo utilizzato e creato un giudice LLM multimodale che confronta le coppie di screenshot come nei test degli screenshot e ci fornisce un punteggio, ma anche un ragionamento strutturale sul punteggio.

Inoltre, lo alimentiamo con alcuni dump della gerarchia di accessibilità che controllano se la struttura è corretta e se la parità strutturale è corretta.

Abbiamo provato empiricamente su moltissime prove e abbiamo visto che ha un'elevata coerenza e ignora i problemi che abbiamo riscontrato.

Quindi, ora avevamo un buon modo per verificare immagini e comportamenti in modo agnostico e abbiamo visto che gli agenti hanno cercato di falsificare tutto.

Provateci.

Tomáš Mlynarič

Inizia semplicemente.

Oggi, gli agenti dicono: "Ok.

Ho un'attività.

Diamo un'occhiata a GitHub.

Troviamo le soluzioni."

Quindi, questa è la prima cosa che fanno.

Cercano su GitHub o su internet la soluzione valida, motivo per cui dobbiamo mantenere il codice sorgente chiuso e non può essere pubblico.

Ma è stato facile.

In alcune prove, abbiamo detto che tutto era stato superato al 100% e l'agente ha risposto: "Trionfo magnifico!"

Quindi…

Interessante, cosa hanno scoperto?

Ma abbiamo esaminato più da vicino la traiettoria e ci siamo detti: "Non posso farlo.

Provo a cambiare la soglia all'80% del test dello screenshot."

// AuthFlowScreenshotTests.kt

@get:Rule
val dropshots = Dropshots(
    resultValidator =
        ThresholdValidator(
-           0.05f
+           0.80f
        )
)

E pensi: "Sì, trionfo, tutto sta passando".

Sì, ma i test degli screenshot sono inutili.

Ma non era il più sofisticato.

In alcuni casi, in realtà nell'app di conversione Flutter, l'agente ha provato e riprovato a creare l'app Android e ha detto: "Non so cosa fare".

Quindi, hanno preso lo screenshot che abbiamo fornito e l'hanno inserito come elemento drawable in background.

Ora è come superare il test dello screenshot.

Benissimo!

Ma poi, i test della UI continuano a non riuscire, quindi dicono: "Metterò un livello di overlay invisibile sopra con i pulsanti, i testi e i tag di test, tutto ciò di cui abbiamo bisogno.

Ora è tutto verde.

Incredibile.

Ottimo lavoro."

Non è che ce ne sia uno, tipo, davvero buono.

Quindi, abbiamo un'attività di migrazione da Java a Kotlin in cui l'agente deve, in pratica, eseguire la migrazione da Java a Kotlin, giusto?

Non sono riusciti a creare la build.

C'è ancora qualcosa che non va, quindi l'agente ha pensato: "Ok, prenderò le classi compilate da Java, le inserirò in un JAR e poi le aggiungerò ai file di build come una normale libreria.

Quindi ora tutti i test vengono superati, ma abbiamo i controlli statici che controllano i file Java, quindi sì, li eliminerò."

Elimino i file Java, tutto è verde, tranne Kotlin che continua a non funzionare, quindi dicono: "Ok, rimuoverò il set di risorse Kotlin e ora tutto funziona.

Ottimo."

Non so nemmeno se si possa considerare un imbroglio.

Voglio dire, è davvero creativo.

Per evitare tutto questo, abbiamo creato un rilevatore di imbrogli che ha tre difese.

Esaminiamo l'albero della UI, applichiamo diverse dimensioni dello schermo in modo che lo sfondo venga distorto e lo vediamo.

Tuttavia, reimpostiamo anche i test e verifichiamo che non siano stati manomessi, in modo che non possano modificare le soglie.

Inoltre, abbiamo anche LLM-as-a-Judge, che controlla le traiettorie e l'output effettivo dell'agente per individuare eventuali anomalie.

Se succede qualcosa, diciamo semplicemente: "Ok, è un errore".

Tomáš Mlynarič

Quindi, ora non ci sono più scorciatoie, non si cercano soluzioni, non ci sono test delle unità fragili o UI fittizie.

Quindi, quando costringiamo gli agenti a progettare effettivamente un'app per Android, quali sono i numeri?

Quindi, a partire da lunedì, forse hai visto il blog post, i numeri sono questi.

Anche l'agente migliore supera solo circa il 40% delle nostre attività e la maggior parte degli agenti di frontiera si attesta tra il 20% e il 40%.

Questo è un bene per noi, in quanto autori del benchmark, perché si raggiunge un giusto equilibrio: le attività che abbiamo fornito hanno un valore reale, ma c'è anche un ampio margine di crescita.

Diamo quindi un'occhiata ai risultati.

Ora possiamo esaminare i risultati da più punti di vista.

Possiamo dare un'occhiata ad alcuni degli insight che abbiamo già trovato.

La prima domanda che potrebbe sorgere guardando il grafico è: quanto costa eseguire l'agente?

Inoltre, le società di AI in genere indicano il costo per token, per alcuni per token di input, output, forse di cache.

E forse questo è un argomento decisionale nel tuo caso.

Ma possiamo esaminarlo da un'altra prospettiva.

Possiamo tracciare lo stesso grafico su uno spazio 2D con il costo medio per attività, non per token, quindi il costo per attività rispetto alla percentuale di superamento.

E qui, possiamo improvvisamente vedere che alcuni modelli sono molto più loquaci.

Dedicano molto più tempo o token per attività, mentre altri superano più attività con un costo inferiore.

Ma se aggiungiamo anche il prezzo per token allo stesso grafico, possiamo vedere che ciò che le aziende di AI pubblicizzano non corrisponde a ciò che si paga effettivamente per l'attività.

Quindi, puoi vedere che l'agente con la percentuale di superamento migliore è in realtà uno dei più economici per token, ma il più costoso per l'attività.

Oppure altri agenti con lo stesso prezzo per token superano circa il 30% delle attività, ma sono 15 volte più economici.

Quindi, il prezzo del token non è la metrica.

Alcuni modelli esplorano di più il codice, lo ricostruiscono, lo eseguono di nuovo e ogni passaggio consuma più token.

Quindi, il punto è non guardare solo il prezzo, per, costo per token.

Scegli un modello, guarda i dati reali, ad esempio usalo nel tuo caso, oppure guarda Android Bench per vedere quali modelli utilizzano effettivamente più token per le attività.

Alcuni, come sapete, richiedono più passaggi, anche se sono più economici per token.

Tuttavia, c'è un altro aspetto della stessa domanda.

Questo è lo stesso grafico, ma possiamo anche dare un'occhiata e mostrare quanto tempo impiegano gli agenti per completare l'operazione.

E possiamo vedere che gli agenti con la percentuale di superamento più alta potrebbero essere anche i più lenti.

Ad esempio, possiamo vedere che alcuni impiegano quasi due ore per l'attività.

Continuano a ricostruire e a testare finché non funziona.

Sì, hanno il tasso di superamento migliore, ma richiedono anche più tempo.

Alcuni agenti più economici impiegano comunque circa un'ora e mezza per l'attività, ma senza risultati migliori.

Altri agenti, invece, lo completano in meno di 20 minuti e risolvono comunque più di un quarto delle attività.

I modelli piccoli e leggeri sono di solito più veloci ed economici, ma falliscono più spesso nelle attività difficili.

In conclusione, non esiste un unico modello migliore.

Dipende da ciò per cui esegui l'ottimizzazione.

È la percentuale di superamento?

È il costo?

È il tempo di attesa?

In questo caso, a seconda del tipo di lavoro che stai svolgendo, se non stai lavorando su attività così difficili, potresti prendere in considerazione l'utilizzo di modelli più veloci che svolgono il lavoro in modo più economico e rapido.

Tuttavia, il costo e la velocità indicano solo il modo in cui vengono eseguiti gli agenti, ma non il motivo per cui non superano la maggior parte delle prove.

Abbiamo quindi esaminato le esecuzioni non riuscite e abbiamo notato che gli agenti spesso si arrendevano in anticipo.

Sono convinti di aver finito.

Attività completata.

Ok, vado a casa.

Tuttavia, come accennato, nel pacchetto di attività gli agenti ricevono solo le istruzioni e lo stato precedente.

Non possono vedere i test.

Vedono che non possono visualizzare la suite di verifica.

Quindi ci siamo chiesti: cosa succede se lasciamo che vedano i test?

Quindi, abbiamo sperimentato e abbiamo avuto una variante di test aperto della stessa attività, in cui l'agente ha ricevuto in anticipo la suite di test di verifica non riuscita.

Quindi, ora, i test venivano eseguiti in modo iterativo.

Possono esaminare gli errori e perfezionare i codici in un ciclo di feedback.

Abbiamo scoperto che quando gli agenti vedono i test, si impegnano di più e lavorano più a lungo.

Nelle esecuzioni aperte, hanno registrato il 25% di turni in più e il 40% di Agent Runtime.

Quasi 30 minuti per attività, dedicati all'esecuzione e alla correzione dei test non riusciti, perché non eseguivano il debug alla cieca.

In questo modo, vedono esattamente cosa non va e, purtroppo, anche il tasso di superamento aumenta di quasi 50 punti percentuali.

Questo impegno aggiuntivo migliora la percentuale media di superamento, come ho già detto.

Tuttavia, alla fine sono arrivati nuovi modelli pionieristici che hanno rapidamente saturato questa variante aperta.

Beh, quasi il 90% di tasso di superamento.

Pertanto, abbiamo mantenuto la variante di test chiuso con ricerca chiusa come metrica di benchmark principale.

Tuttavia, è comunque molto interessante vedere come i modelli siano effettivamente migliori quando sanno in base a cosa vengono valutati.

Tomáš Mlynarič

Tuttavia, ci ha permesso di ottenere più insight sugli agenti.

Ad esempio, possiamo verificare come i modelli testano effettivamente il loro lavoro.

Quindi, dal grafico possiamo vedere che i modelli pionieristici scrivono sempre più test migliori e hanno tassi di superamento più elevati.

Altri modelli sono troppo sicuri di sé, dicono "Posso farlo, non servono test".

Beh, a volte sono ancora buoni.

Quindi, se utilizzi modelli che non sono molto bravi con i test, puoi aiutarli con migliori competenze di test o istruzioni specifiche su come scrivere i test.

Ma la correlazione non implica la causalità, CS, giusto?

Dobbiamo condurre un esperimento controllato su questo aspetto.

Dobbiamo ancora fare delle ricerche per capire se il prompting per test migliori aumenta effettivamente il punteggio.

Tuttavia, abbiamo eseguito un esperimento sull'altra metà dei test Android, ovvero far utilizzare l'emulatore agli agenti.

All'inizio, nel nostro benchmark, non abbiamo detto nulla sull'emulatore.

Abbiamo pensato che gli agenti dovessero capirlo, giusto?

Abbiamo visto che quasi nessuno di questi emulatori si avviava.

Come ho già detto, i nostri test dell'interfaccia utente sono fondamentali per i nostri benchmark e, senza emulatori, non è possibile utilizzarli.

Quindi, tutti fallivano su una cosa molto semplice.

Quindi, ora ci troviamo di fronte a un dilemma.

Dobbiamo dire agli agenti di usare l'emulatore, rischiando di ottenere punteggi più alti, o non dobbiamo dire nulla, sperando che, sai, lo capiscano?

Ma, dopotutto, il nostro obiettivo era quello di essere un benchmark equo per misurare la programmazione e la risoluzione dei problemi di Android.

Non vogliamo misurare alcune peculiarità ambientali.

Abbiamo quindi scelto una via di mezzo.

Abbiamo spiegato loro come avviare un emulatore, ma non abbiamo detto nulla sull'opportunità di utilizzarlo o meno.

Dopotutto, l'avvio dell'emulatore non è ciò che dobbiamo o vogliamo testare.

Abbiamo misurato l'effetto di questa istruzione dell'emulatore.

E ora, abbiamo visto che quando abbiamo dato loro le istruzioni, gli agenti hanno effettivamente avviato l'emulatore molto di più e hanno effettivamente eseguito i test della UI, e questo ha avuto un grande impatto sulla percentuale di superamento, purtroppo per noi.

Inoltre, ci ha permesso di esaminare i loro veri errori e problemi di programmazione, non solo, ad esempio, l'errore di avvio dell'emulatore.

In conclusione, la specificità dei prompt è ancora molto importante e, se stai progettando i tuoi benchmark o le tue valutazioni, devi testare ciò che conta davvero nel tuo caso.

Ad esempio, se stai valutando l'efficienza dei token o di una competenza o di uno strumento, devi prima iniziare con il superamento della valutazione, apportare la modifica per l'efficienza e poi verificare che la valutazione venga ancora superata con meno token.

Se non lo fai, avrai troppe variabili che cambiano contemporaneamente e non saprai se è stata effettivamente la tua modifica a migliorare la situazione.

Tomáš Mlynarič

Torna alla classifica.

Come ho accennato, i modelli migliori superano circa il 40% delle attività e la percentuale di superamento richiede che tutti i controlli vengano superati.

In caso contrario, l'attività non andrà a buon fine.

Quindi, la domanda è: gli agenti non hanno prodotto nulla di utile per il restante 60%?

No, ci stanno arrivando.

Per mostrare quanto l'agente si è avvicinato alle soluzioni funzionanti, un po' come una distanza, calcoliamo anche la percentuale di completamento o una sorta di punteggio parziale.

Si tratta di un punteggio ponderato in quattro categorie: coerenza visiva, funzionalità, funzionamento corretto, alcuni requisiti specifici per l'attività e alcuni controlli di regressione.

Come puoi vedere, i modelli con un ranking inferiore sono in grado di completare circa la metà del lavoro, mentre i modelli pionieristici sono in grado di completare e raggiungere in media quasi l'80%, più dell'80% delle attività, ma superano solo il 40%.

Abbiamo quindi eseguito un esperimento sulla conversione da Flutter ad Android per verificare cosa stava succedendo.

Quindi abbiamo ricalcolato la percentuale di completamento ogni pochi passaggi dell'agente e abbiamo visto gli stessi schemi in tutti i modelli pionieristici.

Intorno ai 140 passaggi, stavano lavorando per raggiungere un punteggio medio di quasi il 90%, poi hanno impiegato altri 90 passaggi, ovvero quasi il 40% dell'esecuzione, per cercare di colmare il divario con il 100%, ma sono riusciti a ottenere solo l'1 o il 2% in più.

E pensiamo che questo rispecchi effettivamente lo sviluppo basato su agenti di oggi, in cui sviluppatori o utenti inesperti vedono l'app come completa.

Tutto viene visualizzato.

L'input ha funzionato, più o meno.

Potrebbero non esserci incidenti.

Ma quando un senior engineer esamina il codice, vede molti difetti: problemi di architettura, difetti del ciclo di vita e cose del genere.

Tomáš Mlynarič

Per concludere, mettiamo in prospettiva Android Bench, il nostro lavoro 2.0.

Rispetto alla versione 1.0, ora abbiamo solo 30 attività, e questo è intenzionale.

Anziché correzioni di bug isolate e piccole patch, abbiamo schermate complete, migrazioni multimodulo e conversioni di intere app.

Le patch ora sono di un ordine di grandezza più grandi su decine di file.

Inoltre, abbiamo i controlli dell'interfaccia utente multimodale.

Gli agenti devono essere eseguiti più a lungo e lavorare molto di più.

Se facciamo un confronto con altri benchmark di frontiera, possiamo comunque notare che il nostro benchmark richiede modifiche al codice molto più ampie.

È privo di contaminazione perché la maggior parte delle attività è scritta da zero e c'è ancora molto spazio per crescere.

Come ho detto all'inizio, nel mondo dell'AI pochi mesi sembrano un'eternità e, alla fine, ogni benchmark viene massimizzato e saturato.

E quando questo accadrà, spero che ci spingeremo verso attività ancora più difficili e complesse che saranno ancora una volta in sintonia con quell'era e con quello stato dell'AI.

Ora utilizza Android Bench come bussola per confrontare modelli e harness e magari ottenere alcuni insight.

E quando vuoi approfondire, applica gli stessi principi di benchmarking e valutazione alle tue codebase e ai tuoi workflow, perché non c'è niente di meglio che misurare l'AI sul codice con cui lavori effettivamente.

In questo modo, non dovrai più sperare che l'AI abbia fatto bene, ma avrai la certezza che sia così.

A nome di tutto il team di Android Bench, grazie per l'attenzione.