Android Studio Apply Changes: Faster Iteration Without Full Rebuilds

The Problem: Slow Rebuild Cycles

Every Android developer knows the friction: change one line of code, wait for Gradle to assemble the entire APK, reinstall, and navigate back to the screen you were testing. On medium-sized projects that cycle can take 30–90 seconds. Multiply that by dozens of edits per hour and the lost time adds up.

Android Studio’s Apply Changes feature (enabled by default since Arctic Fox with Android Gradle Plugin 7.0+) lets you push code or resource updates to a running debuggable app without a full rebuild. The IDE compiles only the modified classes or resources, swaps them into the live process, and the change takes effect immediately—often in under two seconds.

How It Works: A Worked Example

Assume you’re debugging a MainActivity.kt that shows a toast when a button is clicked:

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
        findViewById(R.id.btnToast).setOnClickListener {
            showToast("Original message")
        }
    }
    private fun showToast(msg: String) = Toast.makeText(this, msg, Toast.LENGTH_SHORT).show()
}

You want to tweak the toast text. With the app running in a debug session (click Debug ▶ app), edit the string literal:

showToast("Updated via Apply Changes")

Instead of rerunning, click the Apply Code Changes button (lightning-bolt icon with a yellow restart arrow) in the toolbar. Android Studio:

1. Compiles only MainActivity.kt (and any dependent classes).
2. Sends the new bytecode to the running VM via the JDWP connection.
3. Redefines the class in-place using the JVM’s RedefineClasses capability.

The next button tap shows the new message instantly—no activity restart, no process restart.

Resource Changes Work Similarly

Add a string in res/values/strings.xml:

<string name="new_greeting">Hello from Apply Resource Changes</string>

Reference it in a TextView, then click Apply Resource Changes (lightning-bolt icon with a green circle). The resource table is updated in the running app; the TextView picks up the new value without a rebuild.

What Apply Changes Cannot Do

The feature relies on hot-swap semantics that the Android runtime supports only for certain modifications. The following always require a full rebuild and reinstall:

• Adding, removing, or renaming classes, methods, or fields (signature changes).
• Modifying AndroidManifest.xml (permissions, components, application attributes).
• Changing annotation processors or generated code (e.g., Room, Hilt, Data Binding).
• Altering the app’s binary structure: new DEX files, native libraries, or asset packs.
• Layout XML edits that add or remove View elements (changing attributes of existing views usually works).

When you attempt an unsupported change, Android Studio shows a dialog: “This change requires a full restart.” Clicking Run triggers a normal build.

Common Pitfalls and How to Avoid Them

1. Stale Static State

If a class uses a static (Kotlin companion object) initializer that runs once at class load, redefining the class does not re-run that initializer. Example:

object Config {
    val API_KEY = System.getenv("API_KEY") ?: "default"
}

Changing the environment variable and applying code changes leaves API_KEY at its old value. Workaround: move mutable config to a non-static holder or restart the app.

2. Resource Cache Inconsistency

Adding a new drawable (res/drawable/new_icon.xml) and applying resource changes may not make the drawable immediately available to ImageView.setImageResource(R.drawable.new_icon). The resource ID exists, but the underlying asset table can be stale. A full run resolves it.

3. Disabled in CI / Remote Environments

Some remote development setups (e.g., GitHub Codespaces, JetBrains Gateway) disable Apply Changes by default because they lack a local ADB connection to the device. In Settings ▶ Build, Execution, Deployment ▶ Debugger ▶ Hot Swap, ensure Enable Apply Changes is checked and the ADB path is correct.

4. Forgetting to Clear App Cache

Repeated hot-swaps can leave the process in a state that no longer matches the source (e.g., removed fields still referenced by old instances). If behavior looks wrong, use File ▶ Invalidate Caches / Restart or simply rerun the app once.

Verification Checklist

After enabling Apply Changes, confirm it works in your project:

1. Start a debug session on a device/emulator running API 26+.
2. Change a method body in a Kotlin/Java file; click Apply Code Changes. The Build Output window should list only the changed module/class, not :app:assembleDebug.
3. Add a string resource; click Apply Resource Changes. The new string appears in the UI without restart.
4. Edit AndroidManifest.xml; Studio should prompt that a full rebuild is required.

If any step behaves differently, check Gradle plugin version (com.android.application:7.0.0 or newer) and that buildTypes.debug.isDebuggable = true (default).

When to Stick with Full Rebuilds

Apply Changes shines for logic tweaks, string updates, color changes, and minor layout attribute adjustments. For structural edits—new Activities, manifest changes, dependency upgrades, or annotation-processor-affected code—accept the full rebuild. The time you save on the 80% of edits that are small more than compensates.