To see how your app looks and behaves on a device, you need to build and run it. Android Studio sets up new projects so that you can deploy your app to a virtual or a physical device with just a few clicks.
This overview focuses on how to use Android Studio to build and run your app for testing and debugging. For information on how to use Android Studio to build your app so that it can be released to users, see Build your app for release to users. For more detailed information about managing and customizing your build with or without Android Studio, see Configure your build.
To build and run your app, follow these steps:
- In the toolbar, select your app from the run configurations menu.
In the target device menu, select the device that you want to run your app on.
If you don't have any devices configured, you need to either create an Android Virtual Device to use the Android Emulator or connect a physical device.
Android Studio warns you if you attempt to launch your project to a device that has an error or a warning associated with it. Iconography and stylistic changes differentiate between errors (device selections that result in a broken configuration) and warnings (device selections that might result in unexpected behavior but are still runnable).
If an error occurs during the build process, Gradle may recommend command-line options to help you resolve the issue, such as or . To use command-line options with your build process:
- Open the Settings or Preferences
dialog:
- On Windows or Linux, select File > Settings from the menu bar.
- On macOS, select Android Studio > Preferences from the menu bar.
- Navigate to Build, Execution, Deployment > Compiler.
- In the text field next to Command-line Options, enter your command-line options.
- Click OK to save and exit.
Gradle applies these command-line options the next time you try building your app.
The default way to build and run your app in Android Studio should be sufficient to test a simple app. However, you can use these build and run features for more advanced use cases:
If you have an app with multiple build variants or versions, you can choose which build variant to deploy by using the Build Variants tool window. For more information about running a specific build variant, see the Change the build variant section.
To fine-tune app installation, launch, and test options, you can change the run/debug configuration. For more information about creating custom run/debug configurations, see the Create run/debug configurations section.
We recommend that you use Android Studio for your development needs, but you can also deploy your app to a virtual or physical device from the command line. For more information, see Build your app from the command line.
In Android Studio 3.5 and higher, Apply Changes lets you push code and resource changes to your running app without restarting your app—and, in some cases, without restarting the current activity. This flexibility helps you control how much of your app is restarted when you want to deploy and test small, incremental changes while preserving your device's current state.
Apply Changes uses that are supported on devices running Android 8.0 (API level 26) or higher. To learn more about how Apply Changes works, see .
Requirements
Apply Changes actions are only available when you meet the following conditions:
- You build the APK of your app using a debug build variant.
- You deploy your app to a target device or emulator that runs Android 8.0 (API level 26) or higher.
Use Apply Changes
Use the following options when you want to deploy your changes to a compatible device:
You can also perform this action by pressing Control+Alt+F10 (Control+Command+Shift+R on macOS).
You can also perform this action by pressing Control+F10 (Control+Command+R on macOS).
Enable run fallback for Apply Changes
If you don't want to be prompted every time this occurs, you can configure Android Studio to automatically rerun your app when changes can't be applied. To enable this behavior, follow these steps:
Open the Settings or Preferences dialog:
- On Windows or Linux, select File > Settings from the menu.
- On macOS, select Android Studio > Preferences from the menu.
Navigate to Build, Execution, Deployment > Deployment.
Select the checkboxes to enable automatic run fallback for either or both of the Apply Changes actions.
Click OK.
Platform-dependent changes
Some features of Apply Changes depend on specific versions of the Android platform. To apply these kinds of changes, your app must be deployed to a device running that version of Android (or higher). For example, adding a method requires Android 11 or higher.
Limitations of Apply Changes
Apply Changes is designed to speed up the app deployment process. However, there are some limitations on when it can be used.
Code changes that require app restart
Some code and resource changes can't be applied until the app is restarted, including the following:
- Adding or removing a field
- Removing a method
- Changing method signatures
- Changing modifiers of methods or classes
- Changing class inheritance
- Changing values in enums
- Adding or removing a resource
- Changing the app manifest
- Changing native libraries (SO files)
Libraries and plugins
Code that directly references content in an installed APK
If you encounter any other issues while using Apply Changes, file a bug.
Live Edit is an experimental feature in the Android Studio that lets you update composables in emulators and physical devices in real time. This functionality minimizes context switches between writing and building your app, letting you focus on writing code longer without interruption.
To change the build variant Android Studio uses, do one of the following:
- Select Build > Select Build Variant in the menu.
- Select View > Tool Windows > Build Variants in the menu.
- Click the Build Variants tab on the tool window bar.
For projects without native/C++ code, the Build Variants panel has two columns: Module and Active Build Variant. The Active Build Variant value for the module determines which build variant the IDE deploys to your connected device and is visible in the editor.
To switch between variants, click the Active Build Variant cell for a module and choose the desired variant from the list.
For projects with native/C++ code, the Build Variants panel has three columns:
- Module
- Active Build Variant
- Active ABI
The Active Build Variant value for the module determines the build variant that the IDE deploys to your device and is visible in the editor. For native modules, the Active ABI value determines the ABI that the editor uses, but doesn't impact what is deployed.
To change the build variant or ABI, click the cell for the Active Build Variant or Active ABI column and choose the desired variant or ABI from the list. After you change the selection, the IDE syncs your project automatically. Changing either column for an app or library module applies the change to all dependent rows.
By default, new projects are set up with two build variants: a debug variant and release variant. You need to build the release variant to prepare your app for public release. To define other variations of your app with different features or device requirements, you can define additional build variants.
Conflicts in Android Studio Build Variants dialog
In the Android Studio Build Variants dialog, you might see error messages indicating conflicts between build variants, such as the following:
This error doesn't indicate a build issue with Gradle. It indicates that the Android Studio IDE can't resolve symbols between the variants of the selected modules.
For example, if you have a module that depends on variant of module , but has variant selected in the IDE, you have unresolved symbols in the IDE. Suppose depends on a class that is only available in ; when is selected, that class is not known by the IDE. Therefore it fails to resolve the class name and shows errors in the module's code.
These error messages appear because the IDE can't load code for multiple variants simultaneously. In terms of your app’s build, however, the variant selected in this dialog has no effect, because Gradle builds your app with the source code specified in your Gradle build recipes, not based on what’s currently loaded in the IDE.
When you run your app for the first time, Android Studio uses a default run configuration. The run configuration specifies whether to deploy your app from an APK or an Android App Bundle as well as the module to run, package to deploy, activity to start, target device, emulator settings, Logcat options, and more.
The default run/debug configuration builds an APK, launches the default project activity, and uses the Select Deployment Target dialog for target device selection. If the default settings don't suit your project or module, you can customize the run/debug configuration or create a new one at the project, default, and module levels.