Android Studio Build, Run, and Debug Shortcuts
Testing an Android app against an emulator or physical device, and diagnosing what goes wrong when it doesn't behave as expected, is the core iterative loop of Android development, spanning building, launching, breakpoint-based debugging, and reading real-time system logs. Beyond the basic Run/Debug/Logcat trio, everyday device-testing workflow also depends on cleanly stopping a running app, quickly hot-swapping small changes without a full rebuild, and stepping through paused execution line by line once a breakpoint hits.
| Action | Windows | Mac | Description |
|---|---|---|---|
| Run app | Shift+F10 | Ctrl+R | Builds the current run configuration and launches it on the selected emulator or connected physical device, the primary build-and-test loop during active development. |
| Debug app | Shift+F9 | Ctrl+D | Builds the app and launches it on the emulator or device with the JDWP debugger already attached, so any breakpoint you've set fires from the very first line executed instead of requiring a separate attach-to-process step after a plain Run. |
| Toggle line breakpoint | Ctrl+F8 | Cmd+F8 | Sets or removes a breakpoint on the current line. In Kotlin files the debugger sometimes needs to stop on an inline lambda body rather than the line you clicked, since Kotlin's compiled bytecode can spread a single source line across several actual execution points — Android Studio usually resolves this correctly, but if a breakpoint seems to get skipped on a one-line lambda, placing it explicitly inside the lambda body rather than on the enclosing call tends to fix it. |
| Open Logcat panel | Alt+6 | Cmd+6 | Opens the Logcat panel showing real-time system and app log output from the running emulator or device, essential for diagnosing crashes and tracing runtime behavior beyond what the debugger's breakpoints alone reveal. |
| Stop running app | Ctrl+F2 | Cmd+F2 | Forcibly terminates the currently running app process on the target emulator or device, useful for cleanly restarting a test session rather than launching a second instance on top of one that's already running and potentially conflicting. |
| Apply Changes (hot-swap code/resources) | Ctrl+F10 | Cmd+F10 | Pushes certain code and resource changes to the already-running app without a full restart, considerably faster than a complete Run cycle for small, targeted iterations during active UI or logic tweaking. |
| Step Over (debugger) | F8 | F8 | Advances execution past the current line and lands on the next one at the same call depth, skipping over the internals of any method it happens to call. In a Compose UI debug session this is the stepping command you reach for most, since stepping into every recomposition-related internal call the framework makes would otherwise bury you dozens of frames deep in Compose runtime code for a single tap on one button. |
Run (Shift+F10 on Windows/Linux, Ctrl+R on Mac) builds the current run configuration's target and launches it on whatever emulator or connected hardware is active in the device dropdown at the top of the toolbar, the everyday build-and-test action used constantly throughout development. Debug (Shift+F9 / Ctrl+D) does the same but additionally attaches the debugger from the very start of the process, which matters specifically for catching breakpoints or issues that occur early during app initialization, before a debugger attached after the fact via Run could catch them.
Toggling a breakpoint (Ctrl+F8 / Cmd+F8) on a specific line marks it so a running debug session halts right there the moment execution reaches it, opening up variable inspection and step-by-step execution control — the fundamental tool for understanding exactly what a piece of code is actually doing at runtime rather than only observing its final output or crash.
Logcat (Alt+6 / Cmd+6) is where every log line from the currently running device or emulator lands — Android system messages, other apps' output, and anything your own code pushes out through explicit log calls, all interleaved into one live-scrolling stream. Its biggest practical value shows up right after a crash: the runtime writes a full stack trace here automatically, no debugger session required, which makes it worth checking before you've even set a single breakpoint.
A practical distinction worth understanding: breakpoint-based debugging pauses execution entirely to let you inspect state at one specific moment, while Logcat provides a continuous, non-blocking stream of output across the app's entire running lifetime — the two are complementary rather than substitutes, and experienced Android developers typically use both together depending on whether they need to freeze and deeply inspect one specific moment or observe behavior continuously over time.
Stopping a running app (Ctrl+F2 / Cmd+F2) cleanly terminates the process on the target device or emulator, which matters because launching Run again while a previous instance is still active can sometimes create a confusing second running instance rather than cleanly replacing the first — deliberately stopping before relaunching avoids that ambiguity, especially useful when testing app-restart or cold-start-specific behavior that requires the process to have genuinely ended first.
Apply Changes (Ctrl+F10 / Cmd+F10) offers a considerably faster iteration path for certain kinds of edits, pushing updated code or resources directly to the already-running app process without going through a full rebuild-install-relaunch cycle. This only works for a specific subset of changes Android's runtime can hot-swap safely — modifying an existing method's body, for instance, typically qualifies, while adding a brand-new method or class often doesn't and falls back to a full restart — but for the changes it does support, the speed difference during rapid UI iteration is substantial enough that experienced Android developers reach for it constantly rather than defaulting to a full Run every single time.
Step Over (F8) is the single most-used command once a debug session is actually paused at a breakpoint, advancing execution exactly one line at a time while treating any method calls on that line as a black box — executing them fully but not pausing to step through their own internal lines individually. This is the right default choice for most debugging exploration, reserving the related Step Into command (which does descend into called methods) specifically for situations where you suspect the bug actually lives inside that called method rather than the current one.