Overview
AGI Android refers to Android GPU Inspector, Google’s graphics profiler for analyzing GPU performance on real devices. If you build Android games or graphics‑intensive apps, this guide shows what AGI does, when to use it, and how to get to your first meaningful trace and frame capture.
You’ll also see how AGI fits with Perfetto, Arm Streamline, and RenderDoc, and we’ll cover the metrics, overheads, and pitfalls that matter in production.
- Key takeaways:
- AGI Android is Android GPU Inspector, a graphics-first profiler for Vulkan and OpenGL ES on real devices.
- Use AGI for GPU counters, frame analysis, and system traces; pair it with Perfetto and Streamline for automation and CI coverage.
- Focus your KPIs on frame time stability, GPU busy/stalls, thermals, and battery impact.
With those themes in mind, let’s define AGI Android and how it compares to other profilers you may already use.
What is AGI Android and how does it differ from other profilers?
AGI Android is Android GPU Inspector (AGI), Google’s graphics profiler for Android that captures GPU counters, frame data, and system traces. It focuses on graphics workloads and complements system profilers and debuggers rather than replacing them.
AGI offers two core workflows: system profiling to view device‑wide activity and GPU timelines, and frame profiling to inspect a single frame’s draw calls and pipeline behavior. You can learn more and download builds from the Android Developers page and the product site at https://developer.android.com/agi and https://gpuinspector.dev/. Compared to debuggers, AGI emphasizes real‑device GPU metrics and cross‑vendor support and is better suited to optimization than to purely functional correctness.
Why does disambiguation matter for AGI on Android in 2026?
It matters because “AGI” is widely used to mean Artificial General Intelligence, but here it means Android GPU Inspector. Knowing this upfront helps you land on the right tool and documentation for GPU profiling.
If you’re targeting performance, you want the profiler (Android GPU Inspector), not AI concepts. Keep this distinction clear in team conversations and documentation to avoid misrouted requests or tool choices.
Which graphics APIs and GPUs does AGI support today?
AGI targets Android graphics stacks built on Vulkan and OpenGL ES. These APIs are standardized by Khronos, with current specifications at https://www.khronos.org/vulkan/ and https://www.khronos.org/opengles/. That covers the dominant path for modern Android games and rendering engines.
On hardware, AGI focuses on major mobile GPUs used in Android devices, including Qualcomm Adreno (see https://developer.qualcomm.com/software/adreno-gpu) and Arm Mali (see https://developer.arm.com/graphics). PowerVR devices are also present in the ecosystem, though exact counter availability can vary by device and vendor integration. Always verify device‑ and driver‑specific counter support before committing to a profiling plan.
Why use AGI for Android performance work now?
Because AGI exposes GPU counter evidence you can act on to remove bottlenecks, stabilize frame time, and reduce power cost. It’s built for real devices and modern APIs, making it practical for production optimization.
AGI has demonstrated real benefits in published guidance; Google documents measurable wins from AGI-guided fixes on Android titles (see https://developer.android.com/agi). For most teams, AGI shortens the loop from “we feel jank” to “we see the stall and fix it,” especially when paired with a controlled test scene per title.
What bottlenecks can AGI uncover that typical debuggers miss?
AGI can reveal GPU pipeline stalls, shader occupancy issues, memory bandwidth pressure, overdraw hot spots, and synchronization bubbles that aren’t obvious from functional debugging. These appear as counter patterns—such as high fragment busy with low tiler efficiency, or spikes in barrier and wait states.
Traditional debuggers excel at correctness and resource inspection but rarely quantify why a frame is slow across the whole GPU timeline. AGI’s counters and timelines help you target shader variants, render pass ordering, or transient attachment usage. Move from reproducing a hitch to isolating the pipeline stage causing it, then test a change and re‑measure.
Example: A racing game sees 30–40 ms frames on a subset of Adreno devices. AGI shows fragment shader occupancy pegged during heavy post‑processing. By moving bloom to a lower‑resolution pass and simplifying a dependent texture read, the team normalizes frame time and frees GPU headroom for thermal stability.
What do you need to run AGI on your Android devices?
You need a supported desktop build of AGI, a USB‑connected Android device with Developer options enabled, functional ADB, and a title that can run at realistic settings. Check the AGI download page for current host OS support and installation notes at https://developer.android.com/agi.
- Prerequisites checklist:
- Install AGI on a supported desktop OS (verify supported platforms on the download page).
- Enable Developer options and USB debugging on your device; confirm ADB connectivity: https://developer.android.com/tools/adb.
- Use a near-release build (symbols/validation off) to avoid skewing performance.
- Ensure the device’s GPU drivers and firmware are up to date (via OEM updates).
- Verify GPU counter availability for your device/GPU; some counters are vendor- or build-specific.
- Prepare a representative scene or replayable test path to capture stable data.
With the basics in place, you can connect, capture, and iterate quickly without fighting setup issues.
Which Android versions and permissions are required?
Modern Android devices with Developer options and USB debugging enabled are sufficient for most AGI workflows. For system tracing, AGI leverages Perfetto, Android’s native tracing stack used across many Android versions (see https://perfetto.dev/). Current devices typically work out of the box.
You may be prompted to allow debugging and capture permissions on the device the first time you connect. Some devices expose additional developer toggles to enable hardware counters. Consult your device’s developer settings or vendor documentation if counters appear unavailable.
What are your tooling options alongside AGI on Android?
Use AGI for GPU‑centric profiling and pair it with adjacent tools for coverage and automation. Perfetto handles broader system tracing. Arm Streamline offers system‑level CPU/GPU analysis on Arm‑based devices. RenderDoc remains the gold standard for functional frame debugging.
In practice, you’ll iterate between tools. Use AGI to find GPU stalls and shader issues. Use Perfetto to correlate with CPU scheduling, I/O, and app lifecycle. Use RenderDoc to step through resources and shader code for correctness. This toolbox approach shows the whole picture, not a single layer.
How does AGI compare to Arm Streamline for system profiling?
AGI is graphics and API‑first. It emphasizes GPU counters and frame‑level insight. Arm Streamline is a holistic system profiler tailored to Arm SoCs across CPU, GPU, and interconnect events.
If you’re deciding between them, pick AGI when the core question is “what is the GPU doing this frame?” Choose Streamline when the question is “how do CPU and GPU interact under load across the system?” See Arm’s overview at https://developer.arm.com/Tools%20and%20Software/Streamline.
When should you use Perfetto or RenderDoc with AGI?
Use Perfetto when you need OS‑level context—thread scheduling, binder/IPC timing, disk or network I/O, and app lifecycle events—alongside your GPU timeline. Perfetto’s project site is https://perfetto.dev/.
Use RenderDoc when you need correctness‑oriented frame debugging, resource inspection, and shader stepping beyond AGI’s performance focus. A common flow is: reproduce stutter, capture a Perfetto system trace to confirm CPU/GPU scheduling and background activity, then use AGI to isolate GPU stalls, and finally validate frame correctness and resource usage in RenderDoc.
How much does AGI cost and what hidden costs should you plan for?
AGI is free to download and use from Google’s portal at https://developer.android.com/agi. The real costs are time, device coverage, and process. You’ll invest in building a representative device matrix, learning counters, and reviewing traces.
Expect some capture overhead and plan for it. Use short, targeted traces and verify results on real gameplay paths. Also budget storage for large trace files and a simple process to annotate, version, and share them so findings persist across the team.
What are the performance overheads during tracing or frame capture?
All profilers add overhead, and AGI is no exception, especially when collecting detailed counters or capturing a full frame. System tracing via Perfetto is designed for minimal overhead suitable for production‑grade diagnostics, but you should still validate impact on your specific devices and workloads (see https://perfetto.dev/).
To minimize bias, measure a baseline, keep capture windows short, avoid debug builds, and repeat tests to confirm trends. If a fix looks promising only under heavy tracing, retest with lighter instrumentation to ensure it holds in normal play.
What steps set up your first AGI system trace and frame capture?
A simple checklist will get you from install to insight in minutes. Follow these steps to capture both a system trace and a representative frame.
- Install AGI and confirm ADB connectivity (adb devices) on your desktop.
- Enable Developer options and USB debugging on the device; accept the host key prompt.
- Launch your app and navigate to a repeatable scene (e.g., a fixed camera path or replay).
- In AGI, start a system trace; reproduce the issue for 10–30 seconds; stop the trace and save it.
- Inspect the GPU and CPU timelines; note frame time spikes and correlate with scene events.
- Switch to frame profiling in AGI; capture a single frame at a hitch point.
- Examine pipeline stages, draw call cost, and counters (fragment/vertex busy, stalls).
- Export trace artifacts and jot down hypotheses for your first fix.
This repeatable loop—trace, inspect, hypothesize, change, retest—builds momentum and keeps your team focused on measurable gains.
How do you read essential counters after your first capture?
Start with GPU “% busy” to gauge overall load. Then compare fragment versus vertex occupancy to see which stage dominates.
If overall busy is moderate but frame time spikes, look for stalls and barriers, cache misses, and tiler inefficiency. These often signal synchronization or memory pressure rather than pure shader cost. Correlate counter spikes with the frame timeline and scene events. Heavy post‑processing implies fragment pressure. High vertex busy suggests geometry or skinning cost. Frequent layout transitions or resolve passes hint at render graph inefficiency. For energy over play sessions, complement AGI data with Android Battery Historian at https://developer.android.com/topic/performance/power/battery-historian.
How should teams operationalize AGI in their workflow?
Treat AGI as a recurring practice. Profile weekly on a device matrix, track KPIs over time, and use Perfetto or Streamline for automation where AGI’s UI isn’t scriptable. This prevents “optimize once, regress later.”
- Operational checklist:
- Define a device matrix across vendors (Adreno, Mali, plus a PowerVR device if applicable) and OS versions.
- Create reproducible scenes/replays and pin graphical settings for apples-to-apples tests.
- Set a cadence (e.g., weekly) to capture system traces and a few frames per title/scene.
- Use Perfetto in CI to collect system traces around performance tests; attach AGI captures during manual deep-dives.
- Document counter interpretations and fixes in short playbooks so new engineers align quickly.
- Re-verify after content drops or engine upgrades; regressions often hide in art or pipeline changes.
AGI’s desktop app is the primary workflow. If you need automation or CLI today, lean on Perfetto’s command‑line capture and Arm Streamline’s scripting for system‑level runs. Then investigate hotspots with AGI interactively.
What governance and data-handling practices keep traces safe?
Store traces in a versioned, access‑controlled location, and avoid capturing or sharing personally identifiable information. Strip logs of user data, annotate with device, OS, and build identifiers, and share minimal context with external partners.
When collaborating with vendors or engine providers, export only what’s necessary for diagnosis and review retention policies for production devices. A tidy governance approach prevents accidental data exposure while keeping performance knowledge accessible to the team.
Example: A studio shares an AGI frame capture with a GPU vendor to investigate a stall. They remove account identifiers from logs, include device, OS, and build info, and add a brief timeline note—“spike at 14.2s entering rain scene.” The vendor can reproduce without extra data.
How do you measure success with AGI on Android projects?
Anchor on user‑perceptible improvements: smoother frame time, fewer spikes, stable thermals, and lower battery drain. Track these over time alongside GPU counter changes so you can prove sustained wins.
- KPI set to track:
- Frame time p95/p99 in target scenes (and FPS bands for your target refresh rates).
- GPU % busy and dominant stage (fragment vs vertex) under steady load.
- Stall indicators (barriers, cache misses, bandwidth saturation) during spikes.
- Thermal behavior (throttling events) across 10–20 minute stress runs.
- Battery discharge trends using Battery Historian: https://developer.android.com/topic/performance/power/battery-historian.
- Content-size or draw-call budgets per scene (to protect wins from regression).
Keep a lightweight dashboard or spreadsheet per title with these KPIs by device. Wins stick when they’re visible and reviewed during planning and content lock.
Which metrics tie profiling to player experience and battery life?
Frame time stability—particularly p95/p99—maps directly to perceived smoothness and jank. Thermals and GPU busy or stall patterns indicate whether your wins will hold under sustained play without throttling. Battery discharge rate shows how expensive your rendering is over a session.
Use system traces to catch background services or CPU scheduling effects that corrode smoothness, and pair them with AGI counters to pinpoint GPU‑side causes. For energy validation, chart discharge and temperature trends with Battery Historian and confirm you’re not trading smoothness for unsustainable power.
What pitfalls and anti-patterns should you avoid with AGI?
Avoid profiling in debug builds, profiling only one device, or trusting a single long capture. These habits hide real‑world issues and can mislead your fixes.
- Pitfalls to skip:
- Profiling debug or validation-heavy builds that distort timing.
- Capturing marathon traces; instead, do short, targeted captures at known hitches.
- Relying on one device; include Adreno, Mali, and at least one different OS version.
- Ignoring warm-up; profile after shaders, pipelines, and caches are primed.
- Reading counters in isolation; always correlate with frame time and scene context.
- Treating AGI as an automation tool; use Perfetto/Streamline for CI, then deep-dive with AGI.
By sidestepping these traps, your traces will tell a consistent story and your fixes will translate to real player gains.
How can you troubleshoot common AGI capture issues?
If the device doesn’t appear, check ADB authorization, USB drivers, and cables. Re‑run adb kill-server and adb start-server, and confirm visibility with adb devices (see https://developer.android.com/tools/adb).
If counters are missing, enable relevant developer toggles and ensure the latest device firmware. Try a different OS version or vendor device to isolate build‑specific gaps. For failed frame captures, confirm your app isn’t using incompatible validation layers, disable overlays, and retry on a simpler scene. As a fallback, take a Perfetto system trace to ensure the issue isn’t CPU‑side or OS interference, then return to AGI for GPU‑specific inspection.
What should you do next after your first wins with AGI?
Expand your device matrix, schedule recurring profiling, and fold counter knowledge into your engine and art workflows. Use a “performance gate” before content lock and release candidates so regressions are caught early.
As your team gains confidence, build lightweight playbooks for common issues—overdraw, post‑processing, heavy skinning—and preflight new content against them. This raises the baseline and reduces firefighting late in the cycle.
Where can you learn more and stay current?
Start with the official AGI page at https://developer.android.com/agi and the product site at https://gpuinspector.dev/. For API specifics, rely on Khronos references for Vulkan and OpenGL ES at https://www.khronos.org/vulkan/ and https://www.khronos.org/opengles/. Keep system tracing skills sharp with Perfetto at https://perfetto.dev/.
For vendor perspectives and device nuances, track Qualcomm’s Adreno developer resources at https://developer.qualcomm.com/software/adreno-gpu and Arm’s graphics hub at https://developer.arm.com/graphics. These sources cover new counters, driver behaviors, and best practices that inform how you interpret your next trace.