# Olef in your Android workflow

Source: https://olef.dev/docs/engineers/overview

Olef gives you and your coding agent a structured interface to a running Android app. Keep Android Studio, your editor, Gradle, and code review workflow. Use Olef for the feedback loop between source changes and actual device behavior.

## Choose a problem

| You want to… | Start here |
| --- | --- |
| Find the cause of a crash | [Reproduce, diagnose, fix, verify](https://olef.dev/docs/guides/fix-a-crash) |
| Inspect Compose structure and state | [Inspect a Compose screen](https://olef.dev/docs/guides/inspect-compose) |
| Understand a failed request | [Debug a network request](https://olef.dev/docs/guides/debug-network) |
| Preserve a working user flow | [Record a regression test](https://olef.dev/docs/guides/record-a-test) |
| Run repeatable checks without a model | [Run tests in CI](https://olef.dev/docs/guides/ci) |
| Set breakpoints and inspect locals | [Debugger guide](https://olef.dev/docs/concepts/debugging) |

## The development loop

1. Read the current screen with `ui dump`.
2. Act using a stable selector, and assert the destination with an `--expect-*` option.
3. Inspect logs, network traffic, layouts, or debugger state when the result is wrong.
4. Change the source and apply the build with `app apply`.
5. Repeat the failing behavior and verify the result.

```bash
olef ui dump
olef ui tap --rid settings_button --expect-text "Settings"
olef why
```

The selector and expected text above are illustrative: choose them from your own app's current screen. Configure your app and project using [configuration](https://olef.dev/docs/concepts/configuration).

## A debugger your agent can use

Java/Kotlin debugging uses JDWP directly. Native and mixed debugging use NDK LLDB. Olef exposes breakpoints, call stacks, locals, stepping, and snapshots as structured output, so an agent can diagnose behavior without an interactive IDE debugger.

JDWP permits one debugger per app process. Detach Android Studio's debugger before attaching Olef to that process, and vice versa. Native debugging has additional NDK and ABI requirements; see [capabilities](https://olef.dev/docs/reference/capabilities).

## Local and managed environments

Use your own emulator or connected device, or use [Olef Cloud](https://olef.dev/docs/cloud/overview) for managed workspaces and emulators. Your agent can remain in its usual environment. For multiple projects or concurrent agents, use named targets and [sessions](https://olef.dev/docs/concepts/sessions) to make device ownership explicit.

## Keep your existing tests

Olef holds Android's single `UiAutomation` slot while connected. If your Espresso or UI Automator suite needs that slot, run it through:

```bash
olef test -- ./gradlew connectedDebugAndroidTest
```

This disconnects Olef, runs the command, and reconnects afterward. Olef's own recorded tests use `olef test run` instead. See [CI](https://olef.dev/docs/guides/ci).