Introduction

Restarting an Android activity usually means destroying the current instance and creating a new one with the same intent or updated configuration. That can be useful after a theme change, locale change, or when you want to reset transient UI state. The correct technique depends on whether you want a full recreation, a data refresh, or a navigation-level restart.

Use recreate() for a True Activity Restart

The simplest built-in option is recreate(). It tells Android to destroy the current activity instance and create it again. The lifecycle runs through onPause, onStop, onDestroy, and then a new onCreate.

1class MainActivity : AppCompatActivity() {
2    override fun onCreate(savedInstanceState: Bundle?) {
3        super.onCreate(savedInstanceState)
4        setContentView(R.layout.activity_main)
5
6        findViewById<Button>(R.id.restartButton).setOnClickListener {
7            recreate()
8        }
9    }
10}

This is the right choice when the same activity should come back with the same intent, but with fresh views and resources.

Restart with a New Intent When Inputs Must Change

If you need to restart the activity and pass new extras, launch a new instance and close the current one.

1val intent = Intent(this, MainActivity::class.java).apply {
2    putExtra("mode", "dark")
3}
4finish()
5startActivity(intent)

This approach is useful when the replacement activity should start with different state than the original one. It is also clearer than trying to mutate a lot of fields before calling recreate().

If you do not want a transition flash, you can suppress animations:

1finish()
2overridePendingTransition(0, 0)
3startActivity(intent)
4overridePendingTransition(0, 0)

Do Not Restart When a Simple Refresh Is Enough

A full activity restart is heavier than reloading data into existing views. If the user only needs fresh content, update the screen in place instead of recreating the activity.

1private fun reloadProfile() {
2    lifecycleScope.launch {
3        val profile = repository.fetchProfile()
4        findViewById<TextView>(R.id.nameView).text = profile.name
5    }
6}

This avoids lifecycle churn and usually gives a smoother experience.

Configuration Changes Need Deliberate Handling

Developers often restart an activity after theme or locale changes. That is reasonable, because Android resources such as strings, dimensions, and colors are resolved again when the activity is recreated.

For example, after changing an app setting that affects theme selection:

AppCompatDelegate.setDefaultNightMode(AppCompatDelegate.MODE_NIGHT_YES)
recreate()

In contrast, forcing restarts for every small state change is a design smell. Most UI state should survive configuration changes through ViewModel, saved instance state, or persistent storage.

Preserve State You Actually Care About

Restarting destroys the current view hierarchy. If the screen has typed text, scroll position, or other transient state, save it before recreation and restore it afterward.

1override fun onSaveInstanceState(outState: Bundle) {
2    super.onSaveInstanceState(outState)
3    outState.putString("draft_text", findViewById<EditText>(R.id.editor).text.toString())
4}
5
6override fun onCreate(savedInstanceState: Bundle?) {
7    super.onCreate(savedInstanceState)
8    setContentView(R.layout.activity_main)
9
10    val draft = savedInstanceState?.getString("draft_text")
11    if (draft != null) {
12        findViewById<EditText>(R.id.editor).setText(draft)
13    }
14}

That gives you the benefits of recreation without losing user work.

Common Pitfalls

• Restarting the activity when only a view refresh is needed.
• Using finish() and startActivity() without carrying forward required extras.
• Forgetting to preserve user-entered state before recreation.
• Restarting repeatedly inside lifecycle callbacks and causing loops.
• Disabling normal configuration handling with manifest flags when standard recreation would be simpler.
• Treating process restart and activity restart as the same thing. They are not.

Summary

• Use recreate() when you need the same activity rebuilt cleanly.
• Use finish() plus startActivity() when the new instance needs different intent data.
• Prefer in-place UI refresh when a full restart is unnecessary.
• Save important transient state before recreation.
• Handle theme and configuration changes deliberately rather than restarting by habit.