How to Inspect Elements on Android Devices

Use Android Studio Layout Inspector to inspect the live hierarchy and properties of an app you are developing. Use UI Automator to find and interact with controls exposed to UI tests. Use Accessibility Scanner, Android Studio accessibility checks, and assistive technology such as TalkBack to review accessibility. These tools answer different questions; none is a universal inspector for every visible pixel or custom-drawn object.

1. Choose the right kind of inspection

Your goal	Start with	What you can inspect	Keep in mind
Debug your own app’s live layout	Android Studio Layout Inspector	Runtime component hierarchy and attributes, including View, Compose, and hybrid layouts	Behavior depends on Android Studio and device versions; attribute inspection may restart an activity. Android Layout Inspector guide
Find controls for an automated test	UI Automator	Elements exposed through the UI or accessibility hierarchy, with APIs to locate and interact with them	It shows exposed semantics, not every pixel or custom drawing. UI Automator guide
Find common accessibility problems	Accessibility Scanner and Android Studio checks	Suggestions for common label, contrast, layout, and interaction issues	Automated checks do not prove that runtime behavior works well for assistive-technology users. Accessibility testing guide
Understand screen-reader behavior	TalkBack or another accessibility service	How labels, focus, and navigation are experienced	Exercise the actual user flows manually as well as running checks. Compose inspect and debug guide

2. Inspect a running app with Layout Inspector

Run your app on an emulator or connect a physical Android device, then launch the app you want to inspect.
In Android Studio, open Running Devices and start Layout Inspector for the running process.
Use the Component Tree to select a view or composable. Review its available properties in the Attributes panel and relate the selected node to the rendered screen.
For overlapping or hard-to-select components, use Deep Inspect to select the component, then turn Deep Inspect off when you want to interact with the app again.
For Compose interfaces, inspect the composable structure. The inspector can also help identify recomposition and skipped recomposition behavior.

Layout Inspector supports snapshots that you can export and import. You can load a bitmap overlay to compare the rendered app with a design mockup. Attribute inspection can trigger an activity restart in some configurations; this is version-sensitive, so consult the current guide for your Android Studio and device combination before relying on a particular workflow. Official Layout Inspector documentation

What to check in the tree

Select the node corresponding to the visible control, then confirm that its bounds and attributes match the issue you are investigating.
For a missing or unexpected Compose item, check whether the displayed structure and recomposition behavior explain what appears on screen.
Compare the inspector view with the actual rendered screen. A hierarchy is useful context, but it is not a replacement for observing the UI.

3. Inspect controls with UI Automator

UI Automator is the better fit when you need to know what a test can locate and operate. Android documents UI Automator Viewer as a GUI for scanning the foreground UI hierarchy and viewing component properties. The current UI Automator testing APIs also provide predicate-based element lookup and interaction, and can wait for the accessibility tree to settle in scenarios where the screen is still changing. Android accessibility testing for Views · Write automated tests with UI Automator

Open the screen and state you need to test. If the screen is still loading or animating, allow it to settle before evaluating what elements are available.
Use the viewer or a UI Automator test to inspect the exposed hierarchy and relevant properties.
Locate a control using the properties your test will rely on, then exercise the interaction and check its outcome.
If a visible object is absent from the tree, investigate how the app exposes it to accessibility and automation. Custom-drawn content may not appear as a separate element.

A UI hierarchy represents the semantics exposed by the app and framework. It should not be treated as a complete map of all visible pixels. For a control that is visually present but missing or poorly named, compare the hierarchy with the screen and test the actual interaction. Android documentation on testing Views accessibility

4. Review Android accessibility labels and behavior

Run Android Studio’s available accessibility checks and use Accessibility Scanner to surface common issues.
Review whether controls have meaningful accessible labels and whether the layout and interactions create problems for users.
Try the relevant flows with TalkBack or another assistive technology. Check focus order, announcements, and whether the control’s purpose is understandable in context.
Recheck the running experience after changes. A static scan cannot establish that every device-time interaction is accessible.

Accessibility Scanner scans the screen and suggests ways to improve accessibility. Its findings are suggestions for common problems, not a complete accessibility verdict. A content label need not be visible on screen; an accessibility service such as TalkBack can use it to communicate an element’s meaning. Accessibility Scanner results

Some screens limit what a scanner can analyze. For example, secure windows using FLAG_SECURE cannot be captured for image or contrast analysis. Android’s guidance also warns that some issues only occur while an app is running on a device. Pair automated checks with manual testing using actual assistive technology. Accessibility Scanner FAQ · Android accessibility testing

5. Diagnose common inspection problems

Symptom	Likely cause	What to do
The app or process is not available in Layout Inspector	The app is not running on the selected emulator or connected device, or the wrong process is selected.	Launch the app on the intended target, confirm it is the active running app, then select its process in Android Studio. Check the current Layout Inspector guide for version-specific behavior.
A node is difficult to select because another component overlaps it	Overlapping content makes ordinary screen selection ambiguous.	Use Layout Inspector’s Deep Inspect to select the component, then disable Deep Inspect before returning to normal app interaction.
A visible control is missing from the UI Automator tree	The object may be custom drawn or not exposed as a distinct accessible element.	Compare the hierarchy with the rendered screen. Check the app’s accessibility exposure and verify the real interaction, rather than assuming every pixel has a corresponding node.
A scanner cannot assess contrast or image content on a screen	The screen may be protected with `FLAG_SECURE`.	Recognize that secure content is not capturable for those analyses. Review the screen through permitted app-level checks and manual testing; do not infer that an unavailable scan means the screen passed.
An attribute inspection seems to restart the activity	Inspector behavior can depend on the Android Studio/device combination and settings.	Save or reproduce the app state, consult the current official guide for that combination, and account for a possible restart in the debugging workflow.
Accessibility checks pass but TalkBack behavior is confusing	Automated checks cover common detectable issues, not every runtime experience.	Test navigation and announcements with TalkBack on the actual flows, then adjust semantics, labels, or interaction behavior and repeat.

6. Performance, reliability, and practical limits

For a fast debugging loop, start with Layout Inspector on the running app and inspect only the component related to the issue. Use snapshots or an overlay when you need a repeatable visual comparison. If inspection itself changes the activity state, reproduce the issue and capture relevant state before starting that inspection step.

For test reliability, wait until the UI and accessibility tree have settled before asserting that a changing screen contains an element. Prefer checks grounded in the exposed properties and interactions your test needs. A hierarchy dump is a snapshot of exposed UI semantics, not a guarantee that every animation frame or custom-rendered detail is represented.

For accessibility reliability, combine automated suggestions with manual use of assistive technology. Scanner coverage can be limited by secure windows, and some defects only appear during device runtime. These tools are available as Android development and accessibility workflows; this task does not require buying a particular phone or accessory. The reviewed documentation does not provide a benchmark or cost comparison for these inspection methods.

Or skip the browser setup

If your Android inspection work also needs screenshots of web pages, ScreenshotNeo is a website screenshot API and MCP server for developers. It is separate from Android Studio’s live app hierarchy inspection: a screenshot captures a web page, while Layout Inspector examines your running Android app.

One GET request returns an image or PDF. See the ScreenshotNeo API documentation for the API options.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await Bun.write('shot.webp', res);

ScreenshotNeo removes cookie banners, newsletter popups, and chat widgets before a shot; each cleanup step can be turned off. Bot checks, blank pages, timeouts, and failed loads are never billed, and cache hits cost nothing. Responses identify the page verdict and billing status in X-Page-Verdict and X-Billed headers. Its MCP server provides take_screenshot, get_page_info, and capture_pdf tools for Claude, Cursor, and other MCP clients. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 shots. Sign up free for 1,000 screenshots a month, no card required.

Frequently asked questions

Can I inspect elements on any Android phone?

For your own app, Layout Inspector can connect to an emulator or physical device running the app. The exact workflow and available attributes may vary by Android Studio and device combination.

Can Layout Inspector show Compose interfaces?

Yes. It supports Compose as well as View and hybrid layouts, and exposes composable structure for inspection.

Does Accessibility Scanner tell me whether my app is fully accessible?

No. It suggests fixes for common issues. Test real flows with TalkBack or another assistive technology as well.

Why does a secure screen not appear in scanner image analysis?

A window protected with FLAG_SECURE cannot be captured for image or contrast analysis by Accessibility Scanner.

Will UI Automator expose every visible shape as an element?

No. It works with elements exposed through the UI and accessibility hierarchy. Custom-drawn content may not be a separate node.