Google ARTEMIS open source: fa usare Android agli agenti AI per controllare app e smartphone

Far usare uno smartphone Android a un agente AI, senza preparare in anticipo una sequenza rigida di tocchi e coordinate, è uno dei problemi più interessanti dell’automazione moderna. ARTEMIS, progetto open source pubblicato nel repository Google su GitHub, affronta proprio questo compito: riceve istruzioni in linguaggio naturale, osserva ciò che accade sullo schermo, individua gli elementi dell’interfaccia e agisce sul dispositivo fino a completare l’obiettivo. Non si limita quindi a generare test: può pilotare realmente uno smartphone o un emulatore, attraversare più applicazioni, acquisire screenshot e log e restituire a un assistente di sviluppo le informazioni raccolte durante l’esecuzione.

Prima dell’arrivo degli agenti multimodali, l’automazione Android ruotava soprattutto attorno a strumenti deterministici: Espresso per i test strettamente integrati con l’app, UIAutomator per interagire con elementi dell’interfaccia a livello di sistema, Appium per l’automazione multipiattaforma e ADB (Android Debug Bridge) per il controllo più vicino al dispositivo.

Nel 2024 Google Research e Google DeepMind presentarono AndroidWorld, un ambiente pensato specificamente per valutare agenti capaci di controllare Android. Per ARTEMIS, Google dichiara oggi un tasso di completamento superiore al 99% su AndroidWorld: è un dato certamente d’impatto anche se bisogna fare qualche distinguo.

ARTEMIS trasforma una richiesta in azioni sul telefono

Utilizzando ARTEMIS, si può impartire un comando come “apri le impostazioni, vai alla batteria e controlla il livello corrente” oppure chiedere una sequenza che attraversi applicazioni differenti. Dietro quella frase, però, il sistema deve risolvere diversi problemi: capire lo stato dello schermo, determinare quale elemento corrisponde all’obiettivo, decidere l’azione successiva, eseguirla e verificare che l’interfaccia sia davvero passata allo stato previsto.

ARTEMIS, tuttavia, si allontana dai classici script basati su coordinate fisse: il progetto combina la gerarchia degli elementi Android, OCR e analisi visuale. Quando esiste un elemento identificabile attraverso la struttura dell’interfaccia, l’agente AI può sfruttarlo direttamente; se incontra componenti personalizzati, Canvas, interfacce Compose o Flutter difficili da rappresentare attraverso l’albero UI, può ricorrere alla posizione sullo schermo e ai modelli visuali.

La filosofia suggerita agli agenti collegati al progetto è descritta con la frase “Dynamic-First, Coordinate-Fallback“: prima si cercano ID, testi, informazioni semantiche e altri riferimenti resistenti ai cambiamenti del layout; soltanto quando tali segnali non bastano si passa alle coordinate.

Un Accessibility Helper legge la struttura della schermata

Alla prima esecuzione su un dispositivo Android, ARTEMIS installa un piccolo Accessibility Helper. Si tratta di un servizio che sfrutta le API di accessibilità di Android per leggere la struttura dell’interfaccia: Android usa le stesse API di base anche per tecnologie assistive come screen reader e strumenti di controllo alternativo; UiAutomation, introdotta fin da API level 18, permette invece ai software di test di ispezionare l’interfaccia e simulare input.

Gli sviluppatori Google precisano che l’helper opera in locale sul telefono e non spedisce autonomamente dati verso servizi esterni. Compare nell’area Accessibilità delle impostazioni e mostra una notifica mentre è attivo.

Se l’helper smette di funzionare durante una sessione, ARTEMIS può passare automaticamente a UIAutomator2; chi preferisse questa seconda modalità può forzarla tramite configurazione e disattivare l’installazione automatica dell’helper.

Il fatto che l’helper resti locale non implica che l’intera elaborazione AI avvenga sul dispositivo. ARTEMIS supporta provider LLM esterni e il file di configurazione d’esempio prevede chiavi per Gemini, Google, OpenAI, Anthropic, OpenRouter e xAI. Screenshot, descrizioni o altri dati necessari al modello possono quindi essere elaborati fuori dal PC a seconda della configurazione scelta.

Flash e Pro: due modi molto diversi di controllare Android

Una delle scelte tecniche più interessanti riguarda i due profili di esecuzione. Flash privilegia velocità e consumo ridotto di token: usa un singolo modello all’interno di un ciclo Observe-Think-Act: osserva lo stato corrente, decide cosa fare e richiama gli strumenti disponibili. Il progetto indica normalmente circa 3-5 secondi per passaggio.

Flash lavora in modo più diretto: osserva la schermata, decide quale azione compiere e la esegue, senza affidarsi a un agente separato che pianifica in anticipo tutti i passaggi. Inoltre non applica tutti i controlli di sicurezza disponibili in modalità Pro prima di ogni interazione e, al termine dell’attività, non utilizza un Checker dedicato per verificare in modo indipendente che l’obiettivo sia stato realmente raggiunto.

In compenso è adatto a operazioni abbastanza prevedibili e può proseguire per molti passaggi: il limite predefinito non è un numero massimo di turni, perché ARTEMIS comprime progressivamente la cronologia anziché conservarla integralmente nella finestra del modello.

La compressione serve a risolvere un problema concreto degli agenti che usano interfacce grafiche. Centinaia di screenshot, azioni e osservazioni saturerebbero rapidamente la finestra disponibile. ARTEMIS sostituisce quindi le schermate meno recenti con riassunti visuali e raggruppa parti concluse della sessione in blocchi recuperabili in seguito. Se serve tornare a un evento precedente, l’agente può interrogare la cronologia o analizzare la registrazione video della sessione.

Cos’ha di diverso il profilo Pro

Il profilo Pro punta invece su pianificazione, controllo e recupero. In questo caso, un Planner suddivide l’obiettivo in tappe e mantiene un piano aggiornabile; un Operator osserva il dispositivo ed esegue le azioni; un Checker può verificare i checkpoint e confrontare il risultato finale con la richiesta iniziale. ARTEMIS prevede vari livelli di verifica, da disattivata fino alla modalità strict.

La differenza si sente anche nei tempi: il repository indica indicativamente 15-40 secondi per ciascun passaggio in Pro. Usare questa modalità per aprire una semplice voce delle impostazioni sarebbe spesso uno spreco. Diventa invece interessante per test lunghi, diagnosi che richiedono ADB e Logcat, verifiche con più rami decisionali o attività che devono osservare l’app per un periodo prolungato.

Safety Net riduce i clic sbagliati, ma non li elimina

In modalità Pro, prima di una normale azione, ARTEMIS esegue un controllo sul bersaglio. Il meccanismo chiamato Safety Net verifica prima la struttura XML dell’interfaccia e, se necessario, passa all’analisi dei pixel. Lo scopo è semplice: evitare che il modello decida di premere un determinato pulsante mentre, nel frattempo, la schermata è cambiata.

Gli agenti hanno una latenza molto superiore a quella di uno script tradizionale: tra screenshot, elaborazione del modello e nuova azione possono trascorrere secondi. Nel frattempo, la configurazione generale dell’interfaccia può cambiare anche in modo radicale.

ARTEMIS gestisce anche sequenze rapide di tocchi, chiamate action bursts, per quei controlli che esistono solo per pochi istanti: meno controllo intermedio, ma più possibilità di intercettare elementi transitori. Se un’azione fallisce, Pro mantiene inoltre un’indicazione di “incidente” nella memoria dell’Operator.

Il telefono diventa uno strumento dell’assistente AI tramite MCP

ARTEMIS acquista un significato particolare quando si usa da un IDE: il progetto include infatti un server nativo basato su Model Context Protocol (MCP), lo standard aperto che consente alle applicazioni AI di esporre strumenti, risorse e funzioni ai modelli.

Il server MCP mette a disposizione operazioni per avviare un test mobile, controllarne lo stato, acquisire lo stato corrente del dispositivo, ispezionare una traccia oppure diagnosticare eventuali problemi dell’ambiente. ARTEMIS dichiara integrazioni con strumenti come Antigravity, Codex, Claude Code, Cursor, Windsurf, Cline, Roo Code e OpenClaw.

Un programmatore può chiedere all’assistente di compilare l’APK, installarlo sul dispositivo collegato, aprire la schermata di login, eseguire una procedura e controllare se compare una finestra inattesa. L’agente che lavora sul codice può delegare l’interazione fisica ad ARTEMIS, recuperare screenshot e log, quindi usare quei dati per individuare il problema o preparare un test riproducibile.

Il server non obbliga inoltre l’assistente a rimanere bloccato per tutta la durata della prova. Le esecuzioni possono partire come processi in background; al termine ARTEMIS supporta notifiche desktop, webhook e registri JSONL. La documentazione contempla anche integrazioni con Slack, Discord e ambienti CI attraverso webhook configurabili.

Installazione su Windows, macOS e Linux

Per usare ARTEMIS serve almeno un dispositivo Android autorizzato tramite ADB oppure un emulatore. Il progetto richiede Python 3.12 o versioni successive e include script di avvio per macOS, Linux e Windows. Il bootstrap controlla e prepara strumenti come ADB, scrcpy, FFmpeg e uv, il gestore utilizzato per l’ambiente Python.

Su Windows PowerShell, ad esempio, dopo aver clonato il repository si può avviare start.bat dalla directory del progetto. ARTEMIS apre quindi un’interfaccia web locale sulla porta 8000 con procedura guidata per la connessione del dispositivo, mirroring dello schermo, area per i prompt e replay delle esecuzioni. Chi preferisse usare il terminale può inviare direttamente un’attività tramite la CLI.

Esiste anche un client Python pensato per integrare ARTEMIS all’interno di suite esistenti, per esempio basate su pytest. Il client comunica con l’host ARTEMIS e restituisce risultati strutturati tramite modelli Pydantic. Il dispositivo può essere selezionato esplicitamente attraverso il seriale ADB oppure scelto automaticamente dal pool disponibile.

ARTEMIS supporta inoltre più dispositivi in parallelo. Ogni telefono dispone però di un lock di esecuzione: sullo stesso dispositivo passa una sola attività alla volta, mentre telefoni o emulatori distinti possono lavorare contemporaneamente.

AndroidWorld al 99% non equivale a un Android risolto al 99%

La vera novità di ARTEMIS risiede nell’insieme delle tecniche adottate: percezione multimodale, fallback tra locator differenti, compressione della memoria, verifica prima dell’azione, pianificazione multilivello e collegamento diretto con gli assistenti di sviluppo. Sono pezzi che avvicinano l’automazione AI a uno strumento utilizzabile davvero durante sviluppo e controllo qualità.

Come anticipato in apertura, gli autori di ARTEMIS dichiarano ora oltre il 99% di completamento delle attività all’interno dell’ambiente AndroidWorld. È una percentuale che va però presa con le pinze: un’app reale può contenere CAPTCHA, richiedere autenticazione biometrica, attivare protezioni contro l’automazione, utilizzare WebView, superfici grafiche personalizzate, animazioni imprevedibili, notifiche del sistema, richieste di permesso, rete instabile e versioni differenti della stessa interfaccia. Anche AndroidWorld, pur generando milioni di varianti possibili attraverso i parametri, mantiene 116 modelli di attività conosciuti e un insieme determinato di applicazioni.

Il progetto guarda già oltre Android

La roadmap pubblica cita integrazione nativa con Android Studio, supporto iOS, modelli visuali leggeri eseguiti localmente e controllo vocale duplex in tempo reale. Sono obiettivi ancora da realizzare, non funzionalità già disponibili, ma mettono bene in evidenza dove vogliano andare gli autori del progetto.

ARTEMIS è distribuito con licenza Apache 2.0 e il repository specifica che parte del codice deriva dal lavoro sviluppato da Minitap. La presenza sotto l’organizzazione Google, insieme al legame con AndroidWorld e all’integrazione MCP, rende il progetto particolarmente interessante per chi segue l’evoluzione degli agenti capaci di usare direttamente software e dispositivi.

Alla fine, ARTEMIS segna il passaggio concreto da un assistente che suggerisce codice a un assistente che può verificare sul dispositivo reale se quel codice produce l’effetto previsto.