Android Bench è un sistema di valutazione progettato per misurare la capacità dei modelli linguistici e degli agenti di programmazione di affrontare problemi reali nello sviluppo Android. Il benchmark non si limita a sottoporre ai modelli domande teoriche sul linguaggio Kotlin, sulle API della piattaforma o sulle librerie Jetpack, ma li inserisce in un processo operativo simile a quello seguito da uno sviluppatore chiamato a correggere un difetto all’interno di un progetto esistente.
A ogni agente viene fornita la descrizione di un problema insieme al relativo repository software. Il sistema deve esaminare la struttura del progetto, individuare i file coinvolti, comprendere la causa del malfunzionamento e produrre una modifica del codice. La patch generata viene quindi applicata al progetto e sottoposta a una serie di controlli automatici per verificare se compila, se supera i test previsti e se risolve effettivamente il problema assegnato.
Questa impostazione distingue Android Bench dai test che valutano un modello attraverso risposte testuali o brevi frammenti di codice isolati. La capacità di completare correttamente un’attività dipende infatti da una combinazione di competenze: interpretazione della richiesta, esplorazione del repository, comprensione dell’architettura, scelta degli strumenti, modifica di più file e controllo del risultato. Il modello deve quindi comportarsi come il componente decisionale di un agente software, non come un semplice generatore di codice.
Il benchmark comprende cento attività selezionate da un insieme iniziale di 38.989 pull request provenienti da progetti Android open source. Le modifiche utilizzate come riferimento sono legate a problemi realmente segnalati e successivamente risolti dagli sviluppatori. La presenza di una soluzione originale e di test associati consente di trasformare ogni intervento in una prova riproducibile, dotata di criteri di verifica più affidabili rispetto a una valutazione manuale basata sulla sola plausibilità del codice prodotto.
La composizione del dataset cerca di rappresentare sia lo sviluppo Android moderno sia il patrimonio di applicazioni costruite con tecnologie precedenti. La maggior parte delle attività utilizza Kotlin, ormai centrale nell’ecosistema Android, ma rimangono presenti progetti e componenti Java. Anche sul piano delle interfacce convivono prove basate su Jetpack Compose e attività relative al tradizionale sistema View, riflettendo una realtà nella quale molte applicazioni stanno migrando gradualmente senza poter sostituire immediatamente l’intera base di codice.
Le prove coinvolgono tecnologie e problemi specifici della piattaforma, come la costruzione delle interfacce con Jetpack Compose, la programmazione asincrona mediante coroutine e Flow, la persistenza locale con Room e l’iniezione delle dipendenze con Hilt. Sono presenti anche modifiche alle configurazioni Gradle, migrazioni dei sistemi di navigazione, aggiornamenti delle API, gestione dei permessi, adattamento ai dispositivi pieghevoli e interventi sulle funzioni di sistema, sulla fotocamera e sui contenuti multimediali.
Android Bench valuta inoltre attività di dimensioni differenti. Una parte consistente richiede modifiche relativamente contenute, ma il dataset comprende anche interventi superiori a cento righe e casi nei quali l’agente deve coordinare cambiamenti distribuiti tra più componenti. La difficoltà non dipende soltanto dal numero di righe da produrre: una correzione breve può richiedere una comprensione approfondita del ciclo di vita Android, della concorrenza, dello stato dell’interfaccia o delle dipendenze tra moduli.
L’esecuzione del benchmark è suddivisa in due fasi. Nella prima, l’agente riceve il problema e opera sul repository per generare una patch. Può leggere i file, cercare riferimenti nel codice, utilizzare strumenti disponibili nell’ambiente e procedere attraverso più passaggi di analisi e modifica. Nella seconda fase, un verificatore applica la patch e avvia i test predisposti per quella specifica attività.
La separazione tra agente e verificatore è necessaria per evitare che il risultato venga giudicato sulla base della spiegazione fornita dal modello. Un agente può descrivere una soluzione in modo convincente e produrre codice sintatticamente corretto, ma ciò non significa che l’applicazione compili o che il difetto sia stato eliminato. Android Bench assegna il successo solo quando la modifica resiste a una verifica eseguibile.
Le attività vengono svolte in ambienti standardizzati e isolati, costruiti attraverso container. Ogni modello incontra quindi la stessa configurazione software, le stesse dipendenze e gli stessi test. Questa riproducibilità consente di confrontare agenti differenti riducendo l’influenza di variabili esterne, come versioni diverse dell’SDK, librerie mancanti o configurazioni locali non equivalenti.
L’isolamento assume particolare importanza nello sviluppo Android, dove la compilazione può coinvolgere Gradle, plugin, emulatori, strumenti dell’SDK e dipendenze scaricate da repository esterni. Un errore ambientale potrebbe essere facilmente confuso con un limite del modello. La predisposizione di immagini specifiche per ciascuna attività permette invece di ricostruire le condizioni necessarie e di attribuire il risultato principalmente al comportamento dell’agente.
Il framework registra anche la traiettoria seguita durante la prova. Non viene conservata soltanto la patch finale, ma anche la sequenza di operazioni attraverso cui il sistema ha esplorato il progetto e costruito la soluzione. Questi dati permettono di osservare se l’agente ha individuato rapidamente i file corretti, se ha eseguito tentativi inutili, se ha interpretato male il problema oppure se ha prodotto una soluzione quasi completa, fallita soltanto in fase di compilazione o di test.
L’analisi della traiettoria è utile perché due modelli possono ottenere lo stesso punteggio attraverso comportamenti molto diversi. Un agente può risolvere il problema con poche operazioni mirate, mentre un altro può consumare molte più risorse, effettuare numerose modifiche e arrivare casualmente a una patch funzionante. Per questo Android Bench considera anche aspetti legati all’efficienza e al costo, affiancando al tasso di successo informazioni che aiutano a valutare l’impiego concreto dei modelli.
Il costo di esecuzione è un parametro rilevante negli agenti di programmazione. Ogni lettura del repository, richiesta al modello, generazione di codice e iterazione di verifica può aumentare il numero di token elaborati e il tempo necessario. Un modello più accurato ma molto costoso potrebbe risultare poco adatto a interventi frequenti, mentre un sistema meno potente ma rapido ed economico potrebbe essere efficace per attività circoscritte. Il benchmark consente quindi di confrontare non soltanto la qualità finale, ma anche il rapporto tra risultato e risorse utilizzate.
La metodologia è indipendente dal produttore del modello. L’agente di valutazione può essere collegato a differenti LLM attraverso interfacce comuni, consentendo di eseguire le stesse attività con sistemi proprietari o con modelli a pesi aperti. In questo modo il confronto non dipende dalle dimostrazioni preparate dalle singole aziende, ma da una procedura condivisa applicata a problemi identici.
Il passaggio al framework Harbor rafforza questa impostazione standardizzata. Harbor fornisce un’infrastruttura comune per distribuire le attività, eseguire gli agenti e raccogliere risultati confrontabili. L’adozione di un framework esterno e riproducibile permette a ricercatori e sviluppatori di ripetere le prove, valutare configurazioni personalizzate o verificare modelli che non compaiono ancora nella classifica pubblica.
Android Bench utilizza mini-swe-agent come base per l’esecuzione delle attività. Si tratta di un agente generalista per l’ingegneria del software, adattato alle caratteristiche dello sviluppo Android. Il modello non viene interrogato una sola volta per ottenere una soluzione completa, ma può interagire con gli strumenti dell’ambiente, osservare i risultati delle operazioni e decidere i passaggi successivi.
Questa struttura misura una competenza diversa dalla semplice generazione di una funzione. In un progetto reale, il problema può essere descritto in modo incompleto, la causa può trovarsi in un modulo differente da quello apparentemente coinvolto e la prima modifica può provocare nuovi errori. L’agente deve mantenere il contesto, aggiornare la propria ipotesi e utilizzare le informazioni restituite dagli strumenti di compilazione e test.
Il dataset viene sottoposto anche a controlli contro la contaminazione. Poiché i problemi derivano da repository pubblici, esiste la possibilità che il codice originale e le relative soluzioni siano stati inclusi nei dati di addestramento dei modelli. Un agente potrebbe quindi riprodurre una patch già osservata senza aver realmente analizzato il problema. Android Bench introduce marcatori specifici nei file delle attività e limita la selezione a modifiche recenti, pur senza poter eliminare completamente un rischio che riguarda gran parte dei benchmark costruiti con materiale disponibile online.
Anche la scelta dei repository segue criteri precisi. I progetti devono contenere codice Android, avere una diffusione significativa e offrire elementi sufficienti per verificare la correzione. Le pull request devono essere state integrate, devono risolvere un problema identificabile e devono disporre di test unitari o strumentali. Quando la descrizione originale non contiene informazioni adeguate, può essere riformulata per trasformarla in una richiesta comprensibile, senza però fornire direttamente la soluzione.
La classifica prodotta da Android Bench non stabilisce quale modello sia migliore in ogni attività di sviluppo software. Misura una capacità circoscritta: risolvere un insieme definito di problemi Android attraverso uno specifico agente, con determinati strumenti e limiti operativi. Il punteggio può cambiare modificando il prompt di sistema, il budget di elaborazione, il numero di tentativi o la configurazione dell’agente, anche quando il modello sottostante rimane identico.
I risultati devono quindi essere interpretati come una misura dell’intero sistema formato dal modello, dall’agente, dagli strumenti e dall’ambiente di esecuzione. Un LLM con buone capacità di ragionamento può ottenere prestazioni inferiori se non utilizza correttamente i comandi disponibili, mentre un agente ben progettato può migliorare il rendimento dello stesso modello attraverso una gestione più efficace del contesto e delle verifiche.
Android Bench offre agli sviluppatori un riferimento per valutare quanto gli assistenti AI siano realmente in grado di intervenire su una base di codice Android. Il benchmark sposta l’attenzione dalla qualità apparente del codice alla sua validità operativa, misurata mediante compilazione e test. In questo modo rende più evidente la distanza tra un suggerimento tecnicamente plausibile e una modifica pronta per essere integrata in un progetto software.