ARTEMIS di Google rende open source l'automazione Android: cosa copre davvero la rivendicazione del 99% su AndroidWorld

Il commit più recente su google/artemis non è una funzionalità. È una riga di attribuzione — "fix: completa il README e le intestazioni dei file pertinenti in base ai requisiti Apache 2.0", inserito il 12 settembre 2026, tre giorni dopo che Minitap ha pubblicato un post intitolato Mi aspettavo di meglio da Google. ARTEMIS di Google è l'agente di automazione Android appena reso open source dall'azienda: trasforma un'istruzione in inglese semplice in tocchi, swipe, digitazione e verifica reali su un dispositivo Android fisico o un emulatore, cattura i log e gli screenshot lungo il percorso, e riporta un tasso di completamento delle attività superiore al 99% sul benchmark AndroidWorld di Google Research. È stato pubblicato questo agosto dal team Pixel Test Engineering Fusion di Google con licenza Apache 2.0, e vale davvero il tuo pomeriggio. È anche, a metà settembre, al centro di una disputa sull'attribuzione open source che dice più su come vengono costruiti gli agenti mobili di quanto non faccia il numero del benchmark. Entrambe le storie sono reali. Solo una di esse è il motivo per cui l'ultimo commit del repository è stato una correzione di licenza.

Cosa è stato effettivamente spedito

ARTEMIS non è un modello e non è un wrapper di chatbot. È un sistema di controllo — un sistema Python 3.12+ che vive tra un modello visione-linguaggio e un dispositivo reale. Gli dai un compito in inglese; osserva lo schermo, decide un'azione, la esegue tramite ADB, controlla cosa è successo e continua. Cinque cose erano incluse nella confezione:

• Una CLI e un SDK Python. code>./start.sh/code> prepara ADB, scrcpy, FFmpeg e l'ambiente uv; code>uv run artemis run "…" --profile flash/code> esegue un task in modalità headless; l'code>artemis-client/code> SDK racchiude la stessa chiamata per pytest e CI, restituendo code>succeeded/code>, code>status/code>, code>device_serial/code> e un code>trace_id/code> che puoi inseguire in seguito.

• Una console web. code>uv run artemis ui/code> fornisce una console di test visuale su code>localhost:8000/code> dove osservi il ciclo passo dopo passo.

• Un server MCP nativo. Questa è la parte che lo ha reso così diffuso. code>uv run artemis mcp --install all/code> espone code>mobile_run_task/code>, code>mobile_manage_task/code>, code>mobile_get_device_state/code>, code>mobile_inspect_trace/code> e code>mobile_diagnose/code> a qualsiasi assistente compatibile con MCP, con percorsi di installazione di prima classe per Antigravity, Claude Code e Codex, oltre alla generazione della configurazione per Cursor, Windsurf, VS Code e Cline/Roo. Per un assistente che ha il server connesso, "compila l'APK, installalo, apri le impostazioni, attiva/disattiva la modalità aereo, fai uno screenshot del risultato" smette di essere uno script e diventa una frase.

• Un supporto per l'accessibilità. La prima attività installa l'Artemis Accessibility Helper, che legge il layout dello schermo senza mantenere attiva la connessione UiAutomation — deliberatamente, così che gli altri strumenti basati su UiAutomator presenti sullo stesso dispositivo non vengano soppressi. Viene eseguito sul telefono e non invia nulla all'esterno, e se non riesce ad agganciarsi ripiega su UIAutomator2, con il fallback mostrato nella timeline dell'attività.

• Acquisizione di log e tracce.Gli stack dei crash, gli screenshot dei keyframe e un report diagnostico vengono raccolti automaticamente anziché essere aggiunti a posteriori dal chiamante — il motivo per cui è utilizzabile come suite di regressione e non solo come demo.

Flash e Pro sono due prodotti diversi che condividono un nome

La cosa più importante da capire prima di confrontare ARTEMIS con qualunque altra cosa è che code>--profile flash/code> e code>--profile pro/code> non sono un'impostazione di velocità di un singolo agente. Sono due agenti.

• Flash — un ciclo reattivo di osservazione e azione a circa 3–5 secondi per passo, nessun piano, nessun appunto, nessun controllo di sicurezza prima dell'esecuzione, nessuna verifica dei checkpoint, nessun report finale e nessuna shell ADB. Il ciclo è illimitato per impostazione predefinita perché la cronologia viene compressa anziché accumulata.

• Pro — un grafo multi-agente a circa 15–40 secondi per passo, costruito da un Planner che mantiene un piano Markdown vivo con code>verify/code> e code>assert/code> come elementi espliciti, un Operator con il set completo di strumenti e un Checker di sola lettura che convalida i checkpoint ed esegue una revisione di uscita. code>--verification-level/code> accetta code>off/code>, code>final/code> (il valore predefinito), code>checkpoints/code> o code>strict/code>.

Si tratta di una differenza di latenza da cinque a dieci volte per la stessa descrizione del compito, ed è la differenza tra uno smoke test e un'esecuzione esplorativa di oltre 100 passaggi. La stessa impostazione di Google prevede che Pro sia per il lavoro a lungo termine e il continuo code>[Loop:continuous]/code> monitoraggio; Flash è per le attività UI di routine e deterministiche. Se leggi una recensione che riporta i tempi dei passaggi senza dirti quale profilo li ha prodotti, non ti sta dicendo nulla.

La strategia di localizzazione è la vera ingegneria

La maggior parte dei framework di automazione mobile muore sui selettori. ARTEMIS è costruito con un approccio dynamic-first: quando esiste un indice degli elementi di accessibilità, lo usa; quando non esiste — un Canvas, una superficie Compose, una vista Flutter, un gioco — ricorre a coordinate e visione. Non c'è alcun livello XPath da mantenere e nessun ID che diventi obsoleto, il che è importante perché le applicazioni che vuoi testare di più sono quelle che rilasciano nuove build ogni settimana.

Il profilo Pro aggiunge una Rete di Sicurezza: ogni azione supera un controllo pre-esecuzione, prima XML con fallback sui pixel, che intercetta il popup di sistema sul punto di mangiarsi il tuo tap. I fallimenti aprono un "incident di esecuzione" che resta nel contesto finché un successo successivo non lo risolve, invece di generare un agente di riparazione separato. Le sessioni lunghe vengono compresse — le vecchie schermate diventano riassunti visivi, i passaggi completati vengono raggruppati in ere richiamabili che code>search_history/code> e code>replay_steps/code> possono recuperare — ed è questo che impedisce a un contesto di 100 passaggi di diventare insostenibile.

99,1% in classifica, e la precisazione che i post di lancio omettono

Il claim principale di ARTEMIS è un tasso di completamento superiore al 99% su AndroidWorld, il benchmark di Google Research di 116 attività realistiche distribuite su una ventina di app, valutato come Pass@1. All'11 settembre 2026, la classifica di AndroidWorld riportava ARTEMIS al 99,1%, contro il mobile-use di Minitap al 91,4%, con le prestazioni umane all'80%. Sul tavolo, questo è lo stato dell'arte tra i risultati resi pubblici.

Due cose vanno affiancate a quel numero. In primo luogo, la classifica di AndroidWorld non verifica esplicitamente in modo indipendente le candidature: ogni cifra che vi compare, comprese quelle di ARTEMIS, è autodichiarata dal team che l'ha prodotta, e un'analisi di robustezza ha dimostrato che le sole variazioni dei compiti possono spostare sostanzialmente il punteggio di un agente. Considera il 99,1% come una solida dichiarazione del fornitore su un benchmark pubblico e controllabile, che è una cosa reale e utile, e non come una misurazione sottoposta ad audit, cosa che non è. In secondo luogo, la forma del confronto conta: il benchmark è un insieme fisso di compiti, e il grafico di confronto pubblicato da ARTEMIS avrebbe omesso mobile-use pur includendo altre voci. Un benchmark in cui il risultato precedente più forte manca dal grafico è un'affermazione più debole di quanto suggerisca la percentuale grezza.

La disputa, che è la vera notizia di questo mese

Sul suo blog e in una issue pubblica sul repository, Minitap — una startup di test mobili il cui progetto open source mobile-use svolge lo stesso compito per Android e iOS — ha sostenuto che 228 dei 229 file di ARTEMIS erano identici ai propri. I dettagli che ha pubblicato sono insolitamente concreti: codice di connessione dei dispositivi Android corrispondente alla sua implementazione, il riutilizzo parola per parola di istruzioni appartenenti a un agente chiamato "Hopper", e un esempio WhatsApp che invia messaggi di Capodanno ad Alice, Bob e Charlie, riprodotto con gli stessi commenti, gli stessi passaggi di pulizia e lo stesso bug. Inoltre, sostiene che un file che riportava i nomi di tre autori di Minitap — Pierre-Louis Favreau, Jean-Pierre Lo e Nicolas Dehandschoewercker — sia stato sostituito tramite force-push in agosto, con i nomi rimossi e un autore diverso al loro posto.

La questione della licenza non è affatto torbida. mobile-use è distribuito con licenza Apache 2.0, e Apache 2.0 consente esattamente questo tipo di riutilizzo — commerciale, derivato, chiuso — a condizione che si preservino gli avvisi di copyright e si dichiari cosa è stato modificato. Ciò che non consente è distribuire il codice con gli avvisi rimossi. Da quando sono emerse le accuse, il repository riporta la riga "This project includes source code developed by Minitap, Inc." e i link a minitap-ai/mobile-use, e il commit del 12 settembre che completa tale attribuzione è, al momento in cui scriviamo, la modifica più recente su code>main/code>. Minitap non ha pubblicato alcuna prova che colleghi la rimozione dell'attribuzione alle proprie iscrizioni in classifica rimaste senza risposta, e Google non ha diffuso una risposta pubblica dettagliata. La lettura onesta è questa: il codice condiviso è legittimo ed è sempre stato consentito; la parte burocratica, per un certo periodo, no, e ora è stata corretta.

La parte che nessuno calcola: la bolletta del modello

ARTEMIS viene fornito con un badge che riporta "Multi-Model — Gemini | Claude | GPT-4o | Qwen-VL", e il suo file di configurazione si trova in code>config/artemis.jsonc/code> è dove lo indirizzi verso qualsiasi modello di visione per cui possiedi le credenziali. Nulla in quel file è rivolto all'utente finché non esegui Pro su un flusso di lavoro reale e osservi quanto costa effettivamente un agente di lunga durata.

Fai i conti sui profili. Un'esecuzione Pro da 100 passi a 15–40 secondi per passo sta da qualche parte tra 25 minuti e poco più di un'ora di tempo reale, e ognuno di quei passi è almeno una chiamata a un modello di visione che porta con sé uno screenshot. Flash costa meno per passo ma entra in loop più facilmente, e poiché il suo contesto è compresso anziché troncato, supererà senza problemi il limite di turni che pensavi fosse un tetto. Qualunque profilo tu scelga, il modello è la voce che scala con la tua suite di test, non la licenza o l'hardware.

È qui che un livello di routing smette di essere un'astrazione. Un modello di visione che guida una lunga sessione Android è un carico di lavoro con due proprietà scomode: è di lunga durata ed è intollerante a un intoppo del provider nel bel mezzo del passo 74, perché il contesto dell'esecuzione si trova sull'endpoint di quel provider. Puntare ARTEMIS su un unico URL di base compatibile con OpenAI e lasciare che il nostro failover sposti l'esecuzione su un altro provider dello stesso modello è la differenza tra un test instabile e un pomeriggio perso. Qwen3.8-Flash è il candidato interessante da provare per primo — un MoE multimodale con 6B di parametri attivi e un contesto da 1M di token, presente nel nostro catalogo a 0,15 $ per milione di token in input e 0,47 $ per milione in output, con letture dalla cache a 0,018 $ e scritture in cache a 0,230 $. Il prezzo rilevante qui è proprio quello delle letture dalla cache, perché un'esecuzione Pro rilegge un contesto che cresce a ogni passo.

Sii però preciso su cosa significhi: Qwen3.8-Flash non è nell'elenco dei backend testati di ARTEMIS, che elenca Gemini, Claude, GPT-4o e Qwen-VL. È un modello che potrebbe plausibilmente adattarsi all'harness, e l'harness è esplicitamente costruito per accettarne uno. Nessuno ha pubblicato un benchmark di quell'abbinamento, e dovresti considerare chiunque affermi che ne esista uno come se l'avesse inventato.

La roadmap, e quanto di essa è portante

Quattro elementi sono sulla roadmap pubblicata: un'integrazione con Android Studio con debug nell'editor, registrazione dei test e controllo dei dispositivi; il supporto per iOS; modelli vision-language leggeri on-device per un lavoro a bassa latenza che mette la privacy al primo posto; e l'interazione vocale duplex in tempo reale.

Il primo è quello di cui fidarsi, perché è il naturale prossimo artefatto di un team di test engineering di Pixel e non comporta alcun rischio di ricerca — l'agente guida già un dispositivo, gli serve solo un pannello nell'IDE. iOS è un'affermazione molto più impegnativa di quanto sembri dall'esterno: l'intera strategia di localizzazione si basa sul servizio di accessibilità di Android, e iOS non ha una superficie equivalente con lo stesso modello di permessi, quindi aspettatevi una riscrittura del livello di percezione più che un port. La voce relativa al VLM on-device è quella da tenere d'occhio, perché è l'unica voce della lista che eliminerebbe il costo API per ogni passo che attualmente domina una grande suite di test — e implica un modello piccolo, veloce e capace di visione in grado di tenere insieme un compito di UI, un obiettivo molto più ristretto di «un modello piccolo bravo nell'uso degli strumenti».

Cosa farne questa settimana

Clonalo, esegui code>./start.sh/code> su un emulatore e assegna a Flash un compito che la tua suite Espresso esistente copre. Questo ti dirà entro un'ora se il locator dynamic-first sopravvive alle superfici Compose della tua app, che è la domanda che decide se qualcosa del resto conti. Poi esegui lo stesso compito su Pro e confronta le due tracce — il divario tra 3–5 e 15–40 secondi per passo è dove vive il tuo budget, e non puoi ragionare sul costo di ARTEMIS senza di esso.

Mentre leggi il codice, leggi anche gli header. Il commit del 12 settembre che ha aggiunto l'attribuzione di Minitap è il più recente nel repository, il che significa che gli header dei file che stai leggendo risalgono a quattro giorni fa e che il progetto è in fase di riparazione attiva in pubblico. Non è una ragione per evitarlo. È una ragione per controllare quale versione della storia hai tra le mani prima di citare un tasso di successo in una slide.

Puntare ARTEMIS su un unico URL di base compatibile con OpenAI e lasciare che il nostro failover sposti l'esecuzione su un altro provider dello stesso modello è la differenza tra un test instabile e un pomeriggio perso.