# AI use cases for Debroid (PatilShreyas/debroid)

Repo: [PatilShreyas/debroid](https://github.com/PatilShreyas/debroid) | Use cases: 3 | Page: https://dedupedai.com/use-cases/patilshreyas-debroid/

Debroid is a headless Android debugger CLI that lets AI agents set breakpoints, catch exceptions, inspect and change variables, and step through a live Android app over JDWP.

This file holds every use case of this repo. Each one starts with a "## " heading and ends with its URL.

- Catch an app crash and read live state at the throw: https://dedupedai.com/use-cases/patilshreyas-debroid/trap-crash-with-live-state/
- Pause at a suspect line and inspect its variables: https://dedupedai.com/use-cases/patilshreyas-debroid/pause-at-line-and-inspect-variables/
- Find which code writes a field that goes wrong: https://dedupedai.com/use-cases/patilshreyas-debroid/watch-field-changes-to-find-writer/

## How to catch an app crash and read live state at the throw with Debroid

Repo: [PatilShreyas/debroid](https://github.com/PatilShreyas/debroid) | Difficulty: Intermediate | Time: 45 minutes | Basis: From the README

Set exception traps, reproduce the crash, and read locals and frames without a GUI.

**Who it is for:** An Android developer or AI agent handed a crash report with no clear cause, who needs the exact runtime values when the exception fires.

**The problem:** Stack traces show where an exception landed but not the variable values that caused it, and reproducing the crash by hand in Android Studio is slow for an agent.

**The outcome:** The agent gets a JSON record of the caught or uncaught exception, the frames, and the local values at that moment, and can propose a fix based on them.

### Steps

1. Install the CLI with `curl -fsSL https://raw.githubusercontent.com/PatilShreyas/debroid/main/install.sh | bash`
2. Start the app suspended with `debroid launch`, or attach to a running app with `debroid attach`
3. Set an exception trap with `debroid catch-exception` (uncaught only by default; add `--caught` if needed)
4. Trigger the bug in the app, then read events with `debroid poll --with-stacktrace` (inferred, check the README)
5. Read the paused state with `debroid pause-state --pretty` and then `debroid resume` (inferred, check the README)

### Prompt to paste into your agent

```text
Use the Debroid CLI on the Android app <package-name>. Set an uncaught exception trap, trigger the crash path <steps-to-reproduce>, and run `debroid poll --with-stacktrace` followed by `debroid pause-state`. Return the exception class, the frame where it was thrown, and the local values at that point as JSON. Verify that the exception class matches the crash in the bug report before proposing a fix.
```

### Caveat

Debroid needs JDK 11+ and adb set up before the first command, and the daemon listens on localhost without authentication, so run it only on a machine where every local user is trusted.

Risk, reverse engineering: Live JVM inspection can read memory of any app attached to the debugger, so only attach to apps you are authorized to debug.

Dual-use notice: only use this on software, sites and systems you own or are authorized to test.

Disclaimer: Third-party repos we don't own or vouch for. AI-generated use cases can be wrong: review everything and run at your own risk. Full text: https://dedupedai.com/disclaimer/

URL: https://dedupedai.com/use-cases/patilshreyas-debroid/trap-crash-with-live-state/

## How to pause at a suspect line and inspect its variables with Debroid

Repo: [PatilShreyas/debroid](https://github.com/PatilShreyas/debroid) | Difficulty: Intermediate | Time: 30 minutes | Basis: From the README

Set a line breakpoint, hit it, and read the object state the agent needs to test a hypothesis.

**Who it is for:** An AI agent working on a logic bug in a specific Android class, where a developer wants the runtime values at one line.

**The problem:** Reading code alone can suggest several causes, and adding log statements means rebuilding and reinstalling the app for each guess.

**The outcome:** The agent pauses the app at the chosen line, reads the locals and instance fields as JSON, and narrows the cause without rebuilding.

### Steps

1. Install the CLI with `curl -fsSL https://raw.githubusercontent.com/PatilShreyas/debroid/main/install.sh | bash`
2. Set a line breakpoint in the target class with `debroid break`; it defers automatically if the class is not loaded yet
3. Start the flow that reaches that line, then wait for the pause with `debroid poll`
4. Read the values with `debroid locals` and `debroid inspect --max-depth=2` (inferred, check the README)
5. Step or resume with `debroid step` or `debroid resume`, and clear the point with `debroid remove-break`

### Prompt to paste into your agent

```text
Use the Debroid CLI to set a breakpoint in <class-name> at line <line-number> of the app <package-name>. Trigger <user-action>, then run `debroid pause-state --pretty` and `debroid inspect --max-depth=2`. Return the local variables and relevant object fields as JSON, and verify that the paused line matches the breakpoint you set.
```

### Caveat

Inspect output filters out static and synthetic fields by default, so pass `--include-static` or `--include-internal` only when you need them.

Dual-use notice: only use this on software, sites and systems you own or are authorized to test.

Disclaimer: Third-party repos we don't own or vouch for. AI-generated use cases can be wrong: review everything and run at your own risk. Full text: https://dedupedai.com/disclaimer/

URL: https://dedupedai.com/use-cases/patilshreyas-debroid/pause-at-line-and-inspect-variables/

## How to find which code writes a field that goes wrong with Debroid

Repo: [PatilShreyas/debroid](https://github.com/PatilShreyas/debroid) | Difficulty: Advanced | Time: 60 minutes | Basis: From the README

Watch a field for access and modification, then read the stack at each change.

**Who it is for:** A developer or agent tracking a field whose value changes unexpectedly during a user flow.

**The problem:** Searching the codebase for every write to a field is slow, and the actual writer often depends on runtime order.

**The outcome:** The agent gets a list of the code locations that touched the field during the flow, with stack traces, and can name the writer.

### Steps

1. Install the CLI with `curl -fsSL https://raw.githubusercontent.com/PatilShreyas/debroid/main/install.sh | bash`
2. Set a field watchpoint with `debroid watch` (access and modify are both on by default)
3. Run the user flow in the app, then collect events with `debroid poll --with-stacktrace` (inferred, check the README)
4. Check the active points with `debroid points`
5. Remove the watchpoint with `debroid remove-watch` when finished

### Prompt to paste into your agent

```text
Use the Debroid CLI to watch the field <field-name> in <class-name> of the app <package-name>. Run <user-flow> and then run `debroid poll --with-stacktrace`. Return each access or modification with its stack trace as JSON, and verify that the watched field name matches the one you set with `debroid points`.
```

### Caveat

The README does not say how the watch command identifies a field beyond its signature, so confirm the field is picked up with `debroid points` before relying on the results.

Dual-use notice: only use this on software, sites and systems you own or are authorized to test.

Disclaimer: Third-party repos we don't own or vouch for. AI-generated use cases can be wrong: review everything and run at your own risk. Full text: https://dedupedai.com/disclaimer/

URL: https://dedupedai.com/use-cases/patilshreyas-debroid/watch-field-changes-to-find-writer/
