How to Optimize Your Agentic-Developed Android Developer Workflow

Agentic Android development works best when agents can build, install, run, test, and validate features against real devices or emulators without relying on Android Studio as the manual control center.

In this article, “skills” means reusable agent instructions for a specific task, and “workflows” means separate working copies or environments where an agent can safely build, test, and iterate without blocking your main local setup.

ADB Setup

Many who have been heavily relying on Android Studio may not have used ADB as much unless for really specific specialized tasks. However, this tool becomes a clear powerhouse with AI-assisted development because now we can instruct agents to run their code on different emulator setups with ADB.

The basic commands I want an agent to know are things like:

adb devices
adb -s emulator-5554 install -r app/build/outputs/apk/debug/app-debug.apk
adb -s emulator-5554 shell am start -n com.yourcompany.app/.MainActivity
adb -s emulator-5554 logcat
adb -s emulator-5554 exec-out screencap -p > screenshot.png

Depending on your app setup, the agent may also need to build the APK first:

./gradlew :app:assembleDebug

Or, if your app uses flavors:

./gradlew :app:assembleDevDebug

I typically use a physical device setup when it’s plugged in, but I also have commands to run the app on an emulator when running multiple workflows. For example:

adb -s DEVICE_ID install -r path/to/app-debug.apk
adb -s emulator-5554 install -r path/to/app-debug.apk

Instead of manually opening Android Studio and clicking through a flow, the agent can build the app, install it with ADB, launch the target activity, and collect logs or screenshots from the emulator.

Test Emulator Skill

In combination with the ADB setup, you can create a test emulator skill that creates tests based on the feature in development. I have two useful skills that help me with this:

• Create Tests for Emulator
• Test Emulator Skill

Writing useful tests is a two-step process. First, the agent reads the AC and description from a Jira ticket. It uses this to surmise useful tests based on the AC that would verify whether the feature is complete.

For example, I might ask the agent:

create-tests-for-emulator JIRA-123

This requires writing good AC, but that isn’t such a bad thing. It forces you to really think about the scope of the ticket and whether you’ve completed it. After writing these tests, the agent writes comments on the ticket that describe the testing criteria needed to complete the AC. This is human-readable but specifically created for an agent to read and use.

A generated testing comment might look like:

For JIRA-123, verify:
1. Launch the app on a clean emulator.
2. Log in with a test account.
3. Navigate to the statement detail screen.
4. Confirm the correct balance is shown.
5. Confirm the loading state appears before data loads.
6. Simulate an API failure and confirm the error state appears.
7. Capture a screenshot of the successful state and error state.

The test emulator skill in our app is specifically instructed to open an emulator within the app and run the test instructions written out in the Jira ticket. Once the skill exists, you don’t need to keep restating the testing process. The ticket number is enough because the skill already knows to read the Jira testing comment, build the app, install it on the configured emulator, run the flow, capture evidence, and report what passed or failed.

For example:

test-emulator JIRA-123

Under the hood, the agent can run commands like:

./gradlew :app:assembleDevDebug
adb -s emulator-5554 install -r app/build/outputs/apk/dev/debug/app-dev-debug.apk
adb -s emulator-5554 shell am start -n com.yourcompany.app/.MainActivity
adb -s emulator-5554 logcat -d

So while you are feature developing, you can call test-emulator JIRA-123, and the agentic AI knows how to test against further development changes that you make within your app.

Taking Advantage of Workflows

Claude Code, Cursor, Codex, and most other agentic coding tools have the ability to set up workflows. However, you may have shied away from using workflows because it’s not super easy to set up or test different workflows, especially with Android Studio.

With workflows, you don’t have to transfer your changes locally to make them work and run on your app. There are a few ways you can do this. The way workflows work is that each agentic coding tool stores workflows in its respective folders.

I created an alias that opens Android Studio directly in the workflow folder. Under the hood, this can work well with git worktrees: each agent gets its own copy of the codebase in a separate folder, so you can inspect, run, or open that version without constantly switching branches in your main checkout.

For example:

git worktree add ../my-app-JIRA-123 -b JIRA-123-agent-work
cd ../my-app-JIRA-123

Then you can open that copy in Android Studio:

open -a "Android Studio" ../my-app-JIRA-123

Or, if you have the Android Studio command line launcher set up:

studio ../my-app-JIRA-123

You can also wrap that in an alias or shell function. For example:

fstudio() {
  open -a "Android Studio" "$1"
}

Then run:

fstudio ../my-app-JIRA-123

So you can create an alias such as fstudio --claude JIRA-123 that passes a certain flag and directory name, allowing you to open the workflow easily in Android Studio, look at the code, and run your app.

But with ADB, you don’t even have to use Android Studio. You can use your preferred text editor or the built-in agentic code diff viewer to review and modify your changes.

Creating Skills to Do Pre-Commit Operations

There are pre-commit operations that you can do to apply the typical updates you make before opening a PR. Examples include running a formatter, running Sonar, and running other static analysis tools.

For example, a pre-commit skill might know to run:

./gradlew ktlintFormat
./gradlew lint
./gradlew testDebugUnitTest
./gradlew :app:assembleDebug

In a project with flavors, that may look more like:

./gradlew :app:ktlintFormat
./gradlew :app:lintDevDebug
./gradlew :app:testDevDebugUnitTest
./gradlew :app:assembleDevDebug

You can also make the skill project-specific:

Before opening a PR:
1. Run the Kotlin formatter.
2. Run unit tests for the touched module.
3. Run Android lint for the dev debug variant.
4. Build the debug APK.
5. Summarize failures and do not open the PR if checks fail.

Then you can ask the agent:

pre-commit-checks

Or, if you want it tied to a ticket or branch:

pre-commit-checks JIRA-123

These things don’t have to be manual anymore. We can create skills that know to run these commands before we commit or before we ask the agent to open a PR in GitHub.

The biggest shift is that the agent stops being only a code generator. Once it can build, install, run, test, format, and prepare PRs in repeatable ways, it becomes much closer to a development partner. Android development has a lot of moving pieces, but that is exactly why agent-friendly workflows around ADB, emulators, worktrees, and pre-commit checks are so useful.