# AI use cases for DSH Android (ZSeven-W/dsh-android)

Repo: [ZSeven-W/dsh-android](https://github.com/ZSeven-W/dsh-android) | Use cases: 4 | Page: https://dedupedai.com/use-cases/zseven-w-dsh-android/

DSH Android is a DeepSeek Harness plugin that streams a live Android emulator or USB phone into a conversation and lets an agent build, run, and drive it through adb.

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

- Build and run a Gradle app on a live Android device: https://dedupedai.com/use-cases/zseven-w-dsh-android/build-and-run-gradle-app-on-live-device/
- Check a screen flow by element ID or on-screen text: https://dedupedai.com/use-cases/zseven-w-dsh-android/automate-ui-check-by-element-or-text/
- Confirm a like or count changes by exactly one: https://dedupedai.com/use-cases/zseven-w-dsh-android/verify-feed-counter-changes-after-tap/
- Diagnose a crash, ANR, or memory spike on a device: https://dedupedai.com/use-cases/zseven-w-dsh-android/diagnose-crash-or-anr-with-logs-and-meminfo/

## How to build and run a Gradle app on a live Android device with DSH Android

Repo: [ZSeven-W/dsh-android](https://github.com/ZSeven-W/dsh-android) | Difficulty: Intermediate | Time: 90 minutes | Basis: From the README

Stream a device, build the debug APK, install it, and check the first screen from one conversation.

**Who it is for:** An Android developer who wants to test a Gradle project on an emulator or USB phone without switching windows.

**The problem:** Building, installing, and launching an Android app by hand takes several separate commands, and checking the result means picking up the device.

**The outcome:** The app is built, installed, and launched on the chosen device, and the live panel shows the result.

### Steps

1. Run `adb devices -l` through android_devices and note the serial of the online emulator or phone.
2. Call android_boot with that serial so the live stream appears in the panel.
3. Call android_build_run with the Gradle project path, which runs `./gradlew assembleDebug`, then `adb install -r`, then launches the app.
4. Call android_screenshot to confirm the first screen, and use android_interact to tap through it.
5. If the build fails, read the Gradle error tail in the result, then call android_logs in snapshot mode with bundle_id set to the package name.

### Prompt to paste into your agent

```text
Using the dsh-android plugin, call android_devices, pick the online serial, call android_boot with it, then call android_build_run with projectPath set to <path to the Gradle project>. Expected output: a result showing the debug APK installed and the app launched, plus a screenshot path. Verify that the install and launch both succeeded before reporting done.
```

### Caveat

The first full Gradle build takes minutes, and the plugin only works when adb can be resolved on the machine.

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/zseven-w-dsh-android/build-and-run-gradle-app-on-live-device/

## How to check a screen flow by element ID or on-screen text with DSH Android

Repo: [ZSeven-W/dsh-android](https://github.com/ZSeven-W/dsh-android) | Difficulty: Intermediate | Time: 60 minutes | Basis: From the README

Tap buttons by resource-id or text, verify the next screen, and fall back to OCR when the UI tree is empty.

**Who it is for:** A QA tester who needs to walk through a screen flow on a device and confirm each step with a screenshot.

**The problem:** Scripted UI tests break when coordinates shift, and manual checks are slow to repeat across builds.

**The outcome:** Each step is tapped by identity, the expected next text is confirmed, and the result is backed by a screenshot.

### Steps

1. Call android_ui_tree on the streamed device to list the text and resource-id of each node on the foreground screen.
2. Call android_tap_element with resource_id or text, and set expect_text to a string that should appear on the next screen.
3. If the tree is empty or the label is baked into an image, call android_tap_text with the query, or android_wait_for with mode appear.
4. Review the screenshot that comes back with each tap and mark the step as pass or fail.
5. Repeat for the next screen in the flow until the check is complete.

### Prompt to paste into your agent

```text
Using the dsh-android plugin, call android_ui_tree on the streamed device, then call android_tap_element on <element resource-id or text> with expect_text set to <text expected on the next screen>. Expected output: a tap result that reports whether the expected text appeared, plus a screenshot path. Verify the expect_text check passed before moving to the next step.
```

### Caveat

Taps are sent to whatever is on the live device, so use a test device or emulator rather than a phone with personal data.

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/zseven-w-dsh-android/automate-ui-check-by-element-or-text/

## How to confirm a like or count changes by exactly one with DSH Android

Repo: [ZSeven-W/dsh-android](https://github.com/ZSeven-W/dsh-android) | Difficulty: Intermediate | Time: 60 minutes | Basis: From the README

Tap a row action in a list and check that its counter moved by exactly plus or minus one.

**Who it is for:** A product tester checking that a like, follow, or favorite button updates its count correctly in a feed.

**The problem:** Manually confirming that a counter changed by the right amount on each row is tedious and easy to misread.

**The outcome:** The row is tapped at a known position and the counter change is verified automatically.

### Steps

1. Call android_ui_rows on the streamed device to read the list as rows, each with an index and a counter key.
2. Pick the row index and the counter key you want to test from that output.
3. Call android_tap_row with that index and expect_count set to the counter key with delta 1.
4. Read the verification in the result, which checks the counter moved by exactly the expected amount.
5. If the key is unknown, the tap is refused, so copy the key exactly as listed.

### Prompt to paste into your agent

```text
Using the dsh-android plugin, call android_ui_rows on the streamed device, then call android_tap_row with index <row index> and expect_count set to {key: <counter key from the listing>, delta: 1}. Expected output: a result showing the counter's before and after values and whether it moved by exactly 1. Verify the result reports a match before marking the test as passed.
```

### Caveat

The counter parsing depends on the label format the app uses, so an unusual label may not produce a counter key.

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/zseven-w-dsh-android/verify-feed-counter-changes-after-tap/

## How to diagnose a crash, ANR, or memory spike on a device with DSH Android

Repo: [ZSeven-W/dsh-android](https://github.com/ZSeven-W/dsh-android) | Difficulty: Advanced | Time: 90 minutes | Basis: From the README

Pull logs, process stacks, and a memory summary for one app to find the cause of a failure.

**Who it is for:** An Android developer investigating a crash, an application not responding error, or high memory use reported during testing.

**The problem:** Finding the failing process, its stacks, and its memory split usually means running several adb commands and reading raw output.

**The outcome:** The developer gets the app's logs, its memory breakdown, and a stack dump or the crash buffer, all in one conversation.

### Steps

1. Call android_processes with a filter set to the app name to get the pid.
2. Call android_logs with mode follow, a duration_seconds value, and bundle_id set to the package name, to capture live output while the bug happens.
3. Call android_backtrace with the pid or bundle_id to dump stacks and read the ANR trace, or the crash buffer if the trace is refused.
4. Call android_meminfo with bundle_id to read total PSS and the Java, native, and graphics split.
5. Read the reported engine in the backtrace result, which states which source answered and what it cannot see.

### Prompt to paste into your agent

```text
Using the dsh-android plugin, call android_processes with filter <app name>, then android_backtrace with bundle_id <package name>, and android_meminfo with bundle_id <package name>. Expected output: the stack or crash-buffer result with the engine named, plus the memory summary. Verify the backtrace result states which engine answered before drawing a conclusion.
```

### Caveat

Most non-rooted devices refuse the ANR trace directory, so the backtrace tool may fall back to the crash buffer only.

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/zseven-w-dsh-android/diagnose-crash-or-anr-with-logs-and-meminfo/