Android Studio Apply Changes: Push Code Updates Without Rebuilding Your App

The short answer

Apply Changes lets you push modified code and resources to a running app without a full rebuild and reinstall. For changes that stay inside method bodies, the app keeps running, your activity state survives, and the new behavior shows up in seconds instead of the minute-plus a cold build can take on a large project. It replaced the older Instant Run mechanism and has been the standard iteration path since Android Studio 4.0.

The catch: it only handles certain kinds of edits. Knowing which changes qualify — and which silently require a restart — is what makes the feature useful instead of confusing.

How it actually works

When you click Apply Changes, Android Studio does not recompile and reinstall the APK. Instead it:

1. Compiles only the classes you modified.
2. Builds a small delta containing those classes and any changed resources.
3. Sends the delta to the device over ADB.
4. Uses the runtime's hot-swap support (the JVMTI RedefineClasses capability on Android's runtime, ART) to swap the new class definitions into the live process.

Because the process never dies, your activity stack, fragment state, and in-memory data all survive. This is the key difference from Run, which kills the process, installs a fresh APK, and cold-starts the launcher activity.

The two buttons and what each one does

Android Studio exposes two related actions in the Run menu and toolbar:

• Apply Code Changes (Ctrl+Alt+F10 on Windows/Linux, Cmd+Ctrl+Alt+R on macOS) — pushes only code changes. Fastest option, but cannot touch resources.
• Apply Changes and Restart Activity (Ctrl+F10 / Cmd+Ctrl+R) — pushes code and resource changes, then restarts the current activity so new resources (layouts, strings, drawables) are picked up. The process and application object survive; only the activity is recreated.

If you edited XML and press Apply Code Changes, nothing visible happens — this is the most common beginner confusion with the feature.

A worked example

Suppose you have a running debug build with this method in MainActivity.kt:

private fun greet(name: String): String {
    return "Hello, $name"
}

With the app in the foreground, change the body:

private fun greet(name: String): String {
    Log.d("MainActivity", "greet() called with $name")
    return "Hi there, $name!"
}

Click Apply Code Changes. Within a couple of seconds the IDE reports the changes were applied. Trigger the code path again (tap the button that calls greet) and the new log line appears in Logcat — the activity was never recreated, so any text the user typed into a field is still there.

Now edit res/layout/activity_main.xml — say, change a button label. Press Apply Changes and Restart Activity. The activity is recreated and the new label appears, again without a reinstall.

What Apply Changes cannot do

The hot-swap mechanism can replace method bodies but cannot change the shape of classes. These edits force a full build and reinstall:

• Adding or removing methods or fields, or changing a method signature.
• Changing class inheritance or implemented interfaces.
• Adding a new class in some cases (support has improved across versions, but don't rely on it — check the IDE's response).
• Editing AndroidManifest.xml.
• Changing native C/C++ code.
• Changing resource references in ways that alter resource IDs (for example, adding a new resource that shifts generated R values in older AGP versions).

When you make an unsupported change, Android Studio detects it and prompts you to rerun the app instead. It does not silently apply a broken state — if you see the prompt, believe it and do the full run.

Requirements and failure modes

• Debug builds only. Apply Changes is not available for release builds or builds with code shrinking/obfuscation enabled.
• API level. Apply Code Changes requires a device or emulator running Android 8.0 (API 26) or higher for reliable structural hot-swapping; on lower API levels the feature is restricted or unavailable. If the button is greyed out, check your deployment target first.
• App must be running in the foreground. If the process is paused or has been killed, Apply Changes has nothing to attach to.
• State can mislead you. Because the process survives, singletons and static fields keep their old values. If your change alters initialization logic, the running process will not re-execute it — do a full run to validate startup-path changes.

Common mistakes

Editing XML and pressing Apply Code Changes. Resource edits need Apply Changes and Restart Activity. If nothing changed on screen, this is usually why.

Assuming applied code means correct startup. Hot-swapped code bypasses Application.onCreate and activity launch logic. Always do at least one clean run before committing a change that touched initialization.

Using it to verify fixes for process-death bugs. Since the process never dies, Apply Changes is the wrong tool for testing process restoration, saved-instance-state handling, or cold-start behavior.

How to verify it worked

After pressing Apply Changes, check three things: the IDE status bar confirms the push succeeded, Logcat shows your new output when the code path runs, and the activity state (scroll position, entered text) is unchanged. If the IDE instead shows a dialog saying the change can't be applied, treat that as authoritative — run a full install rather than trying to work around it.