Il video in cui un agente apre app, tocca pulsanti e completa un flusso sul telefono è efficace. Ma per chi sviluppa o testa software Android la domanda utile è meno spettacolare: ARTEMIS riesce a riprodurre un problema, verificare il risultato e lasciare prove utilizzabili?
La risposta breve è: il progetto è tecnicamente sostanzioso, ma non c’è ancora un test end-to-end su device in questa analisi. Nel repository sono stati verificati CLI, console Web, SDK Python, server MCP, due modalità di orchestrazione, driver Android, trace e Accessibility Helper. Una suite mirata ha chiuso 152 test su 152. Mancavano però sia un telefono collegato sia le credenziali di un provider LLM reale. Quindi il codice esiste e alcuni componenti sono stati testati; l’affidabilità del flusso completo resta da misurare.
Cos’è Google ARTEMIS, senza marketing
ARTEMIS è un framework open source con licenza Apache-2.0 per controllare e analizzare interfacce Android da un computer. Lavora con un dispositivo reale o un emulatore, usa ADB e può leggere lo stato dell’interfaccia tramite Accessibility o UIAutomator2. Il task arriva da CLI, console Web, SDK Python oppure da un client collegato al server MCP.
Il progetto propone due profili operativi. Flash usa un ciclo diretto: osserva, decide ed esegue. Pro distribuisce il lavoro tra pianificazione, esecuzione, controllo e recupero dagli incidenti. Nel codice sono presenti i moduli descritti dal README; le prestazioni indicate dal progetto, invece, non sono state replicate qui.
Cosa è verificato, cosa è dichiarato, cosa è roadmap
Codice e componenti presenti
CLI, Web UI, SDK Python, server MCP, profili Flash e Pro, gestione ADB, registrazione e replay, diagnostica e Accessibility Helper risultano nel repository esaminato.
Verifica locale: 152/152 test mirati superati su provider Google, helper e MCP.
Prestazioni non replicate
Il README dichiara oltre il 99% di completamento su AndroidWorld, 3-5 secondi per step con Flash e workflow lunghi con Pro.
Limite: in questa verifica non sono emersi runner, traiettorie grezze o una tabella completa sufficiente a riprodurre quel 99%.
Funzioni non ancora disponibili
Plugin Android Studio, supporto iOS, modelli vision leggeri on-device e voce duplex in tempo reale sono indicati come sviluppi futuri.
Conseguenza: non vanno descritti come capacità attuali.
Ti sta piacendo?
Ricevi una guida pratica ogni settimana. AI, tool e automazioni.
Come funziona la catena operativa
In pratica, il modello non “vive” necessariamente sul telefono. Un host esegue ARTEMIS, collega il device tramite ADB, acquisisce schermate e struttura della UI, invia al modello il contesto necessario e traduce la risposta in azioni. Il risultato può essere registrato in trace, screenshot e replay. L’MCP espone cinque strumenti principali per avviare e gestire task, leggere lo stato del device, ispezionare trace e fare diagnosi.
Questo confine è importante. ARTEMIS non è uno strumento per creare un prototipo Android con Google AI Studio: interviene dopo, quando serve esplorare o testare ciò che gira sul device. Non equivale neppure all’automazione del browser con Browser Harness, perché qui l’interfaccia è quella di Android e il canale di controllo passa da ADB e dai servizi del sistema.
Privacy e sicurezza: il telefono non è un ambiente neutro
L’Accessibility Helper ascolta sull’indirizzo locale 127.0.0.1:18888 del telefono; il computer lo raggiunge con un inoltro ADB. Gli endpoint operativi richiedono un token casuale e il token sul computer viene salvato con permessi restrittivi. Sono misure concrete, ma non eliminano il rischio operativo.
L’helper può leggere gerarchia e screenshot, toccare, scorrere, inserire testo, usare gli appunti ed eseguire azioni globali. Resta installato e abilitato finché non viene rimosso. Su un telefono personale questo significa esporre notifiche, sessioni e dati reali a uno strumento con poteri estesi.
Anche ciò che appare sullo schermo va trattato come input non fidato: testo o interfacce costruite per condizionare l’agente possono provocare istruzioni inattese, mentre il fallback a coordinate aumenta il rischio di tocchi errati. Il protocollo prudente prevede un dispositivo dedicato, account sintetici, task reversibili e la rimozione finale dell’helper con artemis helper uninstall.
Attenzione anche alla frase “non invia nulla altrove”: nel README riguarda il piccolo helper sul device, non tutta la pipeline. Con un modello cloud, screenshot, gerarchie, prompt, estratti video e log necessari all’inferenza possono raggiungere il provider configurato. Per capire la differenza con l’inferenza realmente sul dispositivo, conviene partire dalla guida su come eseguire davvero un LLM offline su Android. Nel router Gemini e Vertex, inoltre, quattro categorie di safety filtering risultano impostate su BLOCK_NONE: è un dato di configurazione da valutare, non la prova che ogni protezione operativa sia assente.
Il “99%+ su AndroidWorld” non basta per adottarlo
Il repository e la comunicazione del progetto dichiarano oltre il 99% di completamento su più di 100 task e 20 app AndroidWorld. È corretto riportarlo solo come claim del progetto. L’immagine della leaderboard mostra un risultato, ma non sostituisce dati grezzi, configurazione completa, numero di retry, costi, failure policy e traiettorie necessarie a una replica indipendente.
Anche un benchmark riproducibile avrebbe un perimetro preciso. Un telefono reale aggiunge login, OTP, CAPTCHA, notifiche, localizzazione, WebView, tastiere, permessi, UI personalizzate dal produttore e stato residuo tra una prova e l’altra. “Automatizzare qualsiasi task” generalizza oltre ciò che l’evidenza disponibile permette di sostenere.
La prova utile: riprodurre un crash e consegnare le evidenze
Il test più utile non è ordinare una pizza. È usare un APK controllato con un crash deterministico e una firma Logcat nota. Il task dovrebbe aprire l’app, raggiungere la schermata corretta, attivare il bug, acquisire la schermata finale e restituire trace e firma esatta dell’errore.
- cinque esecuzioni indipendenti, ripristinando lo stato iniziale;
- successo definito prima del test, non dopo;
- tempo, passi, retry, tocchi errati e interventi manuali registrati;
- trace ID, screenshot e firma Logcat presenti nel report;
- costo e chiamate al modello separati per Flash e Pro;
- stop esplicito prima di azioni irreversibili.
Una soglia editoriale ragionevole potrebbe essere almeno quattro successi su cinque, ma sarebbe una soglia proposta per il canary, non un benchmark ufficiale. Un solo video riuscito non misura la ripetibilità. Lo stesso principio vale per qualsiasi automazione con agenti: servono gate, audit e possibilità di arresto, come discusso nei controlli che servono prima della produzione.
Requisiti e costi che la demo nasconde
Il percorso documentato parte da Python 3.12 o successivo e dallo script start.sh su macOS/Linux oppure start.bat su Windows. Lo script può installare uv, ADB, FFmpeg, scrcpy e Node, sincronizzare le dipendenze, compilare la UI Angular e proporre configurazioni globali per MCP e regole. Può quindi scaricare toolchain, modificare configurazioni e richiedere privilegi: prima di eseguirlo va letto.
Servono poi USB debugging autorizzato oppure un emulatore, un provider configurato e un modello compatibile. Il preset chiamato local-ollama non prova che Ollama venga avviato automaticamente: usa un endpoint OpenAI-compatible che deve essere configurato. Anche l’integrazione MCP va intesa correttamente; per il contesto generale rimando a come funziona MCP e in cosa differisce da una skill.
ARTEMIS o strumenti deterministici?
Esplorazione e diagnosi Android
Adatto da valutare quando il percorso non è ancora noto e interessa raccogliere evidenze da un device di test. Il comportamento del modello introduce variabilità e costi.
Regressione ripetibile e CI
Restano più naturali quando passi, selettori e risultato atteso sono definiti e la priorità è la determinazione. ARTEMIS non li sostituisce automaticamente.
Browser e applicazioni Web
È il confine corretto quando l’interfaccia da controllare è Chrome o una Web app, non il sistema Android nel suo complesso.
Inferenza locale o prototipazione
Rispondono ad altri bisogni: provare modelli sul telefono o costruire un’app. Non sono alternative dirette al mobile testing agentico.
Verdetto: candidato interessante, affidabilità ancora da misurare
ARTEMIS è più interessante come strumento agentico di mobile testing e diagnosi che come “assistente universale” per Android. La catena prompt → piano → azioni → verifica → trace è concreta e il repository contiene molto più di una demo. Questo giustifica una prova controllata da parte di sviluppatori e QA.
Non giustifica ancora l’uso come unica garanzia per una CI critica o per operazioni su account personali. Prima servono un device dedicato, account sintetici, task reversibili, criteri scritti, monitoraggio del traffico e rimozione dell’helper a fine test. Per verificare il software generato con l’AI va inoltre separato il test funzionale dal test di sicurezza di un’app: completare un flusso non equivale a dimostrare che l’app sia sicura.
CTA: Se vuoi una prova seria, parti da un task reversibile e conserva trace, screenshot e log: è lì che una demo diventa verificabile.
Domande frequenti
ARTEMIS funziona senza cloud?
Può usare endpoint OpenAI-compatible locali, ma questo richiede un modello, un server e una configurazione realmente locali. Il preset non basta a dimostrare che il flusso sia offline; il default esaminato usa modelli Gemini.
Serve un telefono Pixel?
No. La documentazione prevede un dispositivo Android con USB debugging autorizzato oppure un emulatore. Compatibilità e stabilità su diversi produttori vanno però misurate: in questa analisi non è stato eseguito un test E2E su device.
Può controllare qualsiasi app Android?
Non è dimostrato. Accessibility, UIAutomator2, screenshot e azioni ADB coprono molti casi, ma CAPTCHA, biometria, OTP, UI custom, popup e stato dell’account possono interrompere il flusso.
È un’alternativa ad Appium o Maestro?
Solo per alcuni lavori esplorativi. Per regressioni note e CI, gli strumenti deterministici restano più prevedibili. ARTEMIS può affiancarli per esplorazione, riproduzione di problemi e raccolta di evidenze.
Che cosa installa sul telefono?
Può installare com.artemis.helper, un servizio Accessibility che espone funzioni di lettura e controllo tramite un canale locale protetto da token. Resta presente finché non viene disinstallato.
Il 99% su AndroidWorld è stato verificato indipendentemente?
Non in questa analisi. È un dato dichiarato dal progetto e mostrato in una leaderboard. Non sono stati individuati artefatti sufficienti per riprodurre integralmente il risultato.
Fonti e riferimenti
Le funzioni presenti sono state controllate sullo snapshot del repository 371aa6d. I dati prestazionali restano attribuiti al progetto.
README di Google ARTEMIS
Architettura, installazione, modalità Flash/Pro, benchmark dichiarati e roadmap.
Apri fonte ↗Server MCP di ARTEMIS
Tool esposti, gestione dei task, dispositivi e modalità di trasporto.
Apri fonte ↗Gestione dell’Accessibility Helper
Provisioning, token, inoltro ADB, installazione e fallback del componente sul device.
Apri fonte ↗Aggiungi francescogruner.it come fonte preferita
Se leggi spesso i miei articoli su AI, automazione e tecnologia, ora puoi dire a Google che vuoi vedere più spesso i contenuti di francescogruner.it tra le notizie.
