Googles ARTEMIS gör Android-automatisering öppen källkod: vad 99 %-anspråket om AndroidWorld egentligen täcker

Den senaste commiten i google/artemis är inte en funktion. Det är en krediteringsrad – "fix: komplettera README och relevanta filhuvuden enligt Apache 2.0-kraven," pushad den 12 september 2026, tre dagar efter att Minitap publicerade ett inlägg med titeln Jag förväntade mig bättre från Google. Googles ARTEMIS är företagets Android-automatiseringsagent som nyligen släppts med öppen källkod: den omvandlar en instruktion på vanlig engelska till riktiga tryck, svep, skrivning och verifiering på en fysisk Android-enhet eller emulator, fångar loggarna och skärmbilderna under tiden och rapporterar en slutförandegrad för uppgifter på över 99 % i Google Researchs AndroidWorld-benchmark. Det publicerades i augusti av Googles Pixel Test Engineering Fusion-team under Apache 2.0-licensen, och det är verkligen värt din eftermiddag. Det är också, i mitten av september, centrum för en strid om tillskrivning inom öppen källkod som säger mer om hur mobilagenter byggs än vad benchmarksiffran gör. Båda berättelserna är sanna. Bara en av dem är anledningen till att förvarets senaste commit var en licensrättning.

Vad som faktiskt levererades

ARTEMIS är inte en modell och inte en chattbotswrapper. Det är ett styrharnesk – ett Python 3.12+-system som lever mellan en vision-språkmodell och en riktig mobiltelefon. Du ger det en uppgift på engelska; det observerar skärmen, beslutar en åtgärd, utför den via ADB, kontrollerar vad som hände och fortsätter. Fem saker kom i lådan:

• Ett CLI och ett Python-SDK. code>./start.sh/code> bootstrappar ADB, scrcpy, FFmpeg och uv-miljön; code>uv run artemis run "…" --profile flash/code> kör en uppgift headless; SDK:t code>artemis-client/code> omsluter samma anrop för pytest och CI och returnerar code>succeeded/code>, code>status/code>, code>device_serial/code> och ett code>trace_id/code> som du kan följa upp senare.

• En webbkonsol. code>uv run artemis ui/code> tillhandahåller en visuell testkonsol på code>localhost:8000/code> där du kan följa loopen steg för steg.

• En nativ MCP-server. Det här är delen som gjorde att det spreds. code>uv run artemis mcp --install all/code> exponerar code>mobile_run_task/code>, code>mobile_manage_task/code>, code>mobile_get_device_state/code>, code>mobile_inspect_trace/code> och code>mobile_diagnose/code> till alla assistenter som stöder MCP, med förstklassiga installationsvägar för Antigravity, Claude Code och Codex, plus konfigurationsgenerering för Cursor, Windsurf, VS Code och Cline/Roo. Från en assistent som har servern ansluten slutar "bygg APK:n, installera den, öppna inställningarna, aktivera flygplansläge, ta en skärmbild av resultatet" att vara ett skript och blir en mening.

• Ett hjälpmedel för tillgänglighet. Den första uppgiften installerar Artemis Accessibility Helper, som läser av skärmlayouten utan att hålla UiAutomation-anslutningen — medvetet, så att andra UiAutomator-baserade verktyg på samma enhet inte undertrycks. Den körs på telefonen och skickar inget därifrån, och faller tillbaka till UIAutomator2 när den inte kan ansluta, med reservlösningen synlig i uppgiftens tidslinje.

• Logg- och spårinsamling.Kraschstackar, keyframe-skärmbilder och en diagnostikrapport samlas in automatiskt i stället för att läggas till i efterhand av anroparen — anledningen till att det kan användas som en regressionssvit och inte bara en demo.

Flash och Pro är två olika produkter som delar ett namn

Det enskilt viktigaste att förstå innan du benchmarkar ARTEMIS mot något är att code>--profile flash/code> och code>--profile pro/code> är inte en hastighetsinställning på en agent. De är två agenter.

• Flash — en reaktiv observera-och-agera-loop på ungefär 3–5 sekunder per steg, ingen plan, inga anteckningar, ingen säkerhetskontroll före körning, ingen kontrollpunktsverifiering, ingen slutrapport och ingen ADB-shell. Loopen är obegränsad som standard eftersom historiken komprimeras i stället för att ackumuleras.

• Pro — en multiagent-graf på ungefär 15–40 sekunder per steg, byggd av en Planner som underhåller en levande Markdown-plan med explicita code>verify/code> och code>assert/code>-poster, en Operator med hela verktygsuppsättningen och en skrivskyddad Checker som validerar kontrollpunkter och kör en avslutande granskning. code>--verification-level/code> tar code>off/code>, code>final/code> (standard), code>checkpoints/code> eller code>strict/code>.

Det är en latensskillnad på fem till tio gånger för samma uppgiftsbeskrivning, och det är skillnaden mellan ett smoke-test och en utforskande körning med 100+ steg. Googles egen formulering är att Pro är för långsiktigt arbete och kontinuerlig code>[Loop:continuous]/code> övervakning; Flash är för rutinmässiga, deterministiska UI-sysslor. Om du läser en recension som anger stegtider utan att tala om vilken profil som producerade dem, säger den dig ingenting.

Lokaliseringsstrategin är det verkliga ingenjörsarbetet

De flesta ramverk för mobilautomation faller på selektorer. ARTEMIS är byggt dynamik-först: när ett index för tillgänglighetselement finns använder det det; när det inte gör det – en Canvas, en Compose-yta, en Flutter-vy, ett spel – faller det tillbaka på koordinater och vision. Det finns inget XPath-lager att underhålla och inget ID som kan bli inaktuellt, vilket har betydelse eftersom de applikationer du helst vill testa är de som släpper nya byggversioner varje vecka.

Pro-profilen lägger till ett Safety Net: varje åtgärd genomgår en förkontroll, XML först med en pixel-fallback, som fångar systempopupen som är på väg att äta upp din tryckning. Fel öppnar en "exekveringsincident" som stannar kvar i kontexten tills en senare framgång löser den, i stället för att skapa en separat reparationsagent. Långa sessioner komprimeras – gamla skärmbilder blir visuella sammanfattningar, slutförda steg delas in i återkallbara eror som code>search_history/code> och code>replay_steps/code> kan hämta tillbaka – vilket är det som hindrar en kontext på 100 steg från att bli för dyr.

99,1 % på topplistan, och förbehållet som lanseringsinläggen utelämnar

ARTEMIS främsta påstående är en slutförandegrad på 99 %+ på AndroidWorld, Google Researchs benchmark med 116 realistiska uppgifter i ett tjugotal appar, poängsatt som Pass@1. Per den 11 september 2026 listade AndroidWorlds topplista ARTEMIS på 99,1 % mot Minitaps mobile-use på 91,4 %, med mänsklig prestation på 80 %. I tabellen är det state of the art bland offentligt rapporterade resultat.

Två saker hör ihop med den siffran. För det första genomför AndroidWorlds topplista uttryckligen ingen oberoende verifiering av inlämningar – varje siffra på den, inklusive ARTEMIS, är självrapporterad av teamet som tog fram den, och en robusthetsanalys har visat att enbart variationer i uppgifterna kan förändra en agents poäng avsevärt. Se 99,1 % som ett starkt leverantörspåstående på ett offentligt, kontrollerbart benchmark, vilket är något verkligt och användbart, och inte som en granskad mätning, vilket det inte är. För det andra spelar jämförelsens form roll: benchmarken är en fast uppsättning uppgifter, och ARTEMIS publicerade jämförelsediagram uppges ha utelämnat mobile-use samtidigt som andra poster inkluderades. Ett benchmark där det starkaste tidigare resultatet saknas i diagrammet är ett svagare påstående än vad den råa procentsatsen antyder.

Tvisten, som är den egentliga nyheten den här månaden

På sin blogg och i en offentlig issue i repositoriet hävdade Minitap – en startup inom mobiltestning vars öppna källkodsprojekt mobile-use gör samma sak för Android och iOS – att 228 av ARTEMIS 229 filer var identiska med deras egna. De närmare uppgifter som publicerades är ovanligt konkreta: Android-kod för enhetsanslutning som matchar deras implementation, ordagrann återanvändning av instruktioner som tillhör en agent vid namn "Hopper", och ett WhatsApp-exempel som skickar nyårsmeddelanden till Alice, Bob och Charlie, återgivet med samma kommentarer, samma rensningssteg och samma bugg. Vidare hävdar man att en fil som bar namnen på tre Minitap-författare – Pierre-Louis Favreau, Jean-Pierre Lo och Nicolas Dehandschoewercker – ersattes genom force-push i augusti, varvid namnen togs bort och en annan författare sattes in.

Licensfrågan är inte dunkel. mobile-use är Apache 2.0, och Apache 2.0 tillåter exakt den här typen av återanvändning — kommersiell, härledd, sluten — förutsatt att du bevarar upphovsrättsmeddelandena och anger vad du har ändrat. Vad den inte tillåter är att leverera koden med meddelandena borttagna. Sedan anklagelserna dök upp har repot burit raden "This project includes source code developed by Minitap, Inc." och länkar till minitap-ai/mobile-use, och den commit från 12 september som slutför den tillskrivningen är, vid skrivandets stund, den senaste ändringen på code>main/code>. Minitap har inte publicerat några bevis som kopplar borttagandet av tillskrivningen till sina egna obesvarade inlämningar till resultattavlan, och Google har inte utfärdat något detaljerat offentligt svar. Den ärliga tolkningen: koden som delas är legitim och var alltid tillåten; pappersarbetet var det, under en period, inte, och det har nu rättats till.

Delen som ingen kostnadsberäknar: modellnotan

ARTEMIS levereras med ett märke med texten "Multi-Model — Gemini | Claude | GPT-4o | Qwen-VL", och i dess konfigurationsfil på code>config/artemis.jsonc/code> är det du anger vilken synmodell du än har autentiseringsuppgifter för. Inget i den filen är användarvänt förrän du kör Pro på ett verkligt arbetsflöde och ser vad en lång agent faktiskt kostar.

Räkna på profilerna. En 100-stegs Pro-körning med 15–40 sekunder per steg ligger någonstans mellan 25 minuter och drygt en timme i verklig tid, och vart och ett av dessa steg är åtminstone ett anrop till en visionsmodell som bär med sig en skärmbild. Flash är billigare per steg men loopar hårdare, och eftersom dess kontext komprimeras i stället för att trunkeras kommer den glatt att köra förbi den turgräns du antog var ett tak. Vilken profil du än väljer är modellen den radpost som skalar med din testsvit, inte licensen eller hårdvaran.

Det här är där ett routningslager slutar vara en abstraktion. En visionsmodell som driver en lång Android-session är en arbetsbelastning med två besvärliga egenskaper: den är långlivad, och den tolererar inte ett avbrott hos en leverantör mitt i steg 74, eftersom körningens kontext finns på den leverantörens endpoint. Att peka ARTEMIS mot en enda OpenAI-kompatibel bas-URL och låta vår failover flytta körningen till en annan leverantör av samma modell är skillnaden mellan ett ostadigt test och en förlorad eftermiddag. Qwen3.8-Flash är den intressanta kandidaten att prova först — en multimodell MoE med 6B aktiva parametrar och en kontext på 1M tokens, listad i vår katalog till $0,15 per miljon indatatokens och $0,47 per miljon utdatatokens, med cacheläsningar på $0,018 och cacheskrivningar på $0,230. Det cacheläsningspriset är det relevanta här, eftersom en Pro-körning läser om en växande kontext vid varje steg.

Var dock precis med vad det betyder: Qwen3.8-Flash finns inte med på ARTEMIS lista över testade backends, som anger Gemini, Claude, GPT-4o och Qwen-VL. Det är en modell som rimligen passar i testramverket, och testramverket är uttryckligen byggt för att acceptera en sådan. Ingen har publicerat ett benchmark för den kombinationen, och du bör utgå från att den som hävdar att ett sådant finns har hittat på det.

Färdplanen, och hur mycket av den som är bärande

Fyra punkter finns på den publicerade färdplanen: en Android Studio-integration med felsökning i redigeraren, testinspelning och enhetskontroll; iOS-stöd; lättviktiga vision-språkmodeller på enheten för arbete med låg latens och integritet i första hand; och dubbelriktad röstinteraktion i realtid.

Den första är den att tro på, eftersom det är den naturliga nästa artefakten från ett Pixel-testingenjörsteam och den har ingen forskningsrisk kopplad till sig — agenten styr redan en enhet, den behöver bara en panel i IDE:t. iOS är ett mycket större påstående än det ser ut utifrån: hela lokaliseringsstrategin lutar sig mot Androids tillgänglighetstjänst, och iOS har ingen motsvarande yta med samma behörighetsmodell, så förvänta dig en omskrivning av perceptionslagret snarare än en portning. Punkten om VLM på enheten är den som är värd att titta noga på, eftersom det är den enda punkten på listan som skulle ta bort API-kostnaden per steg som för närvarande dominerar en stor testsvit — och det antyder en liten, snabb modell med synförmåga som kan hålla ihop en UI-uppgift, vilket är ett mycket smalare mål än "en liten modell som är bra på verktygsanvändning."

Vad ska man göra med det den här veckan

Klona det, kör code>./start.sh/code> mot en emulator och ge Flash en uppgift som din befintliga Espresso-svit täcker. Det säger dig inom en timme huruvida den dynamikprioriterade lokaliseraren överlever appens Compose-ytor, vilket är frågan som avgör om något av resten spelar roll. Kör sedan samma uppgift på Pro och jämför de två spåren — gapet mellan 3–5 och 15–40 sekunder per steg är där din budget ligger, och du kan inte resonera om kostnaden för ARTEMIS utan det.

När du läser koden, läs filhuvudena. Commit-en från den 12 september som lade till Minitap-tillskrivningen är den senaste i repositoriet, vilket innebär att filhuvudena du läser är fyra dagar gamla och att projektet aktivt repareras offentligt. Det är inte ett skäl att undvika det. Det är ett skäl att kontrollera vilken version av historien du sitter med innan du citerar en framgångsfrekvens i en slide.

Att peka ARTEMIS mot en enda OpenAI-kompatibel bas-URL och låta vår failover flytta körningen till en annan leverantör av samma modell är skillnaden mellan ett instabilt test och en förlorad eftermiddag.