How to Refactor Legacy Android Applications

"Let's rewrite it properly" is the most expensive sentence in software. While the rewrite is built, the old app still needs features and fixes, the rewrite chases a moving target, and years of hidden edge-case handling get lost. Incremental refactoring keeps delivering value and reduces risk with every step.

Principles of safe refactoring

• Refactoring changes structure, not behaviour. Keep these in separate commits from feature changes.
• Get a safety net first: tests, or at least reproducible manual checks and crash monitoring.
• Small steps that can be released independently.
• Prioritise by pain: refactor what you change often or what crashes most.

A step-by-step playbook

1. Map the app. List screens, entry points, background work and third-party SDKs. Find the top crashes and the most-edited files in Git history.
2. Update the build. Recent AGP, Gradle and Kotlin, a version catalog, R8 enabled. Many later steps depend on modern tooling.
3. Add characterization tests around code you'll touch. They capture current behaviour, even if it's odd.
4. Extract logic out of Activities into ViewModels and plain classes, without changing behaviour.
5. Introduce repositories around scattered network and database code.
6. Replace deprecated async (AsyncTask, raw threads, deep callback chains) with coroutines, one feature at a time.
7. Write new code in Kotlin, and convert old files when you touch them.
8. Build new screens in Compose, and migrate old screens when they're redesigned.

Characterization tests

class LegacyPriceCalculatorTest {
    // We don't know if these results are "right"; we record what the app does today.
    @Test fun `legacy rounding for discounted items`() {
        val calc = LegacyPriceCalculator()
        assertEquals(84.0, calc.finalPrice(99.0, discountPercent = 15), 0.0001)   // floors to rupees: keep it
        assertEquals(0.0, calc.finalPrice(10.0, discountPercent = 120), 0.0001)   // clamps: keep it
    }
}

Extracting a ViewModel from a god Activity

class OrdersActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_orders)
        object : AsyncTask<Void, Void, List<Order>>() {          // deprecated; leaks on rotation
            override fun doInBackground(vararg p: Void?) = Api.getOrders()
            override fun onPostExecute(result: List<Order>) { adapter.submitList(result) }
        }.execute()
    }
}

class OrdersViewModel(private val repository: OrdersRepository) : ViewModel() {
    private val _orders = MutableStateFlow<List<Order>>(emptyList())
    val orders: StateFlow<List<Order>> = _orders.asStateFlow()
    init { viewModelScope.launch { _orders.value = repository.getOrders() } }
}

class OrdersActivity : AppCompatActivity() {
    private val viewModel: OrdersViewModel by viewModels { OrdersViewModelFactory(appContainer) }
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_orders)              // UI unchanged
        lifecycleScope.launch {
            repeatOnLifecycle(Lifecycle.State.STARTED) { viewModel.orders.collect(adapter::submitList) }
        }
    }
}

The XML and adapter stay the same, so the UI is untouched. Later, the screen can move to Compose with the same ViewModel.

Creating seams

Legacy code often calls static singletons (Api.getOrders()). Wrap them behind interfaces so new code can be tested:

interface OrdersRepository { suspend fun getOrders(): List<Order> }

class LegacyOrdersRepository : OrdersRepository {
    override suspend fun getOrders() = withContext(Dispatchers.IO) { Api.getOrders() }   // existing call
}

Prioritisation examples

Common mistakes

• Big-bang rewrites, or long-lived refactoring branches.
• Mixing behaviour changes with refactoring in one PR.
• "Fixing" odd legacy behaviour that users or other systems depend on, without confirming first.
• Introducing every modern library at once (Hilt, Compose, Navigation, KMP) and overwhelming the team.

Frequently asked questions

Conclusion

Refactor legacy Android apps incrementally: build a safety net, extract ViewModels and repositories, replace deprecated async with coroutines, and adopt Kotlin and Compose as you touch code, all while shipping every release.

Next step: scale these practices across teams in Scaling an Android Codebase Across Multiple Teams.