How to Run an App in Android Studio (Shift+F10 / Ctrl+R)

Shift+F10 (Windows/Linux) or Ctrl+R (Mac) builds the current run configuration's target module and launches the resulting app on whatever emulator or physical device is currently picked from the IDE's device selector. **What the build step actually does**: Gradle, Android's build system, compiles Kotlin/Java source, processes resources (layouts, strings, images), and assembles everything into an APK or Android App Bundle, then Android Studio installs that package onto the target device or emulator before launching its main activity. **Emulator versus physical device**: launching on an emulator (a virtual Android device running on your development machine) requires no special device setup and is the default choice for most iterative development, while a physical device requires USB debugging enabled in the device's Developer Options and, for the first connection, accepting a debugging authorization prompt on the device itself. **Why a Run sometimes fails before the app even appears**: Gradle build errors (a compile error in your code, a misconfigured dependency, a Gradle sync issue) stop the process before installation, with errors surfaced in the Build panel and, for code-level issues, highlighted directly in the editor. **Incremental builds and why subsequent runs are usually faster**: Gradle caches build outputs and only recompiles what's actually changed since the last build, meaning repeated Run presses during active iteration are typically much faster than the initial build after opening a project or making a large-scale change like updating a dependency version. **Related shortcuts**: Shift+F9 (Ctrl+D on Mac) for Debug, which launches with the debugger attached from the start rather than running normally, and Ctrl+F8 (Cmd+F8) for toggling a breakpoint before launching in Debug mode. **Choosing between multiple connected devices**: if several emulators or physical devices are available simultaneously, the device dropdown lets you pick exactly which one Run targets, and Android Studio remembers your most recent selection for subsequent Run presses until you change it again — worth double-checking before a run if you've recently connected or disconnected a device, since a stale selection can silently attempt to launch on a device that's no longer available. **Cold boot versus quick boot for emulators**: a freshly started emulator takes noticeably longer to boot than resuming from a saved emulator snapshot (quick boot), which affects how long the very first Run of a session takes compared to subsequent ones — this is an emulator-level setting rather than something Run itself controls directly. **Multi-module projects**: in a project with several modules (an app module plus one or more library modules), the run configuration determines which specific module's app actually launches, and switching between modules for testing purposes is done through the run configuration dropdown next to the Run button rather than through Run's shortcut itself. Building awareness of which device and module a given run is actually targeting avoids one of the most common sources of confusing 'why is nothing happening' moments for developers new to the IDE. This awareness becomes automatic with experience. **Apply Changes as a faster alternative to a full Run**: for many code edits, especially to method bodies, the lightning-bolt Apply Changes actions (available once an app is already running) push updated code to the running app without a full reinstall, which is noticeably faster than repeating Run from scratch for small iterative tweaks, though structural changes like adding a new method or resource still require a complete relaunch.