# Find & fix a crash

Source: https://olef.dev/docs/guides/fix-a-crash

**Outcome:** the previously failing interaction succeeds, with evidence from the same app and device.

## Prerequisites

Connect a device or Cloud workspace, open your app's source project, and configure the app package. For source-level debugging, use a debuggable build. See [installation](https://olef.dev/docs/start/install) and [configuration](https://olef.dev/docs/concepts/configuration).

## Ask your agent

```text
The app crashes when I open Settings. Reproduce it with Olef, inspect the
crash and relevant source, make the smallest fix, then apply the build
and repeat the same interaction. Report the before-and-after evidence.
```

## 1. Reproduce with a known starting state

Read the screen before acting:

```bash
olef ui dump
```

Find the actual selector for the failing action. For example, if your app exposes `settings_button` and the destination should contain “Settings”:

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

An unsuccessful postcondition is a useful observation; do not treat a delivered tap as proof that the destination opened.

## 2. Read the diagnosis

```bash
olef why
olef log --last 5m --level e
```

`why` combines available crash/ANR, log, screen, and network evidence. Look at the verdict, exception, app frames, and hints. `no_obvious_cause` means no cause was established by those signals; it is not proof that the app is healthy.

For a bug that needs live state rather than a crash trace, use the [debugger](https://olef.dev/docs/concepts/debugging). For an offline handoff, `olef collect` gathers a diagnostic bundle; review sensitive data before sharing it.

## 3. Fix and apply

Change the relevant source, then run from the configured Android project:

```bash
olef app apply
```

Read the returned result to see whether Olef applied code in place, restarted the activity, or reinstalled. A successful apply does not establish that the bug is fixed.

## 4. Verify the original behavior

Repeat the same starting state and interaction. Assert the expected screen, inspect recent errors, and confirm the behavior that originally failed. Use a recording to [save the flow as a regression test](https://olef.dev/docs/guides/record-a-test).

## Limits

A failure may depend on app data, permissions, device version, or backend state. Preserve those conditions when reproducing it. Avoid clearing app data unless resetting that state is part of the test you intend to run.