Introduction

setRetainInstance(true) was the old Fragment API for keeping the same fragment instance across configuration changes such as rotation. It is important to understand mostly because you may still see it in legacy code, but in modern Android it is deprecated and the recommended replacement is to keep retained state in a ViewModel instead.

What setRetainInstance(true) Used To Do

Normally, when an activity is recreated after a configuration change, its fragments are recreated as well. A retained fragment changes that behavior: the fragment instance itself is kept and reattached to the new activity instance.

In older code, you would see:

1class LegacyFragment : Fragment() {
2    override fun onCreate(savedInstanceState: Bundle?) {
3        super.onCreate(savedInstanceState)
4        retainInstance = true
5    }
6}

or in older Java:

1public class LegacyFragment extends Fragment {
2    @Override
3    public void onCreate(Bundle savedInstanceState) {
4        super.onCreate(savedInstanceState);
5        setRetainInstance(true);
6    }
7}

The main effect was that long-running state held by the fragment instance did not need to be rebuilt on every rotation.

What It Did Not Retain

This API was often misunderstood. It retained the fragment instance, not everything associated with it.

Important limits:

• it did not preserve the old activity instance
• it did not preserve the fragment's view hierarchy
• it did not survive process death

That means UI references such as TextView, RecyclerView, or the activity context still had to be recreated safely after configuration changes.

This is exactly where many memory leaks came from. Developers retained a fragment and accidentally also retained references to old views or old activities.

Why It Was Deprecated

Modern Android guidance moved away from retained fragments because ViewModel solves the retained-state problem more cleanly. The retained state can live in a lifecycle-aware object, while the fragment itself remains a normal UI controller.

A modern replacement looks like this:

1class UserViewModel : ViewModel() {
2    val counter = MutableLiveData(0)
3}
4
5class UserFragment : Fragment() {
6    private val viewModel: UserViewModel by viewModels()
7
8    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
9        super.onViewCreated(view, savedInstanceState)
10        viewModel.counter.observe(viewLifecycleOwner) { value ->
11            println(value)
12        }
13    }
14}

Here, the retained state lives in the ViewModel, and the fragment can be recreated safely without leaking stale UI objects.

When You Still Need to Understand It

Even though the API is deprecated, you may still encounter it when:

• maintaining an older app
• migrating legacy fragments to AndroidX
• debugging lifecycle behavior in pre-ViewModel code

In those situations, the key question is usually: "What state was this fragment trying to keep across rotation?" Once you identify that state, the migration path usually becomes clearer.

Common Pitfalls

The biggest mistake was storing activity or view references in a retained fragment. That could keep dead UI objects alive after rotation and cause leaks or crashes.

Another issue was assuming retained fragments survive everything. They only helped across configuration-driven activity recreation, not process death. If the app process was killed, retained fragment state was gone unless it was persisted elsewhere.

A third pitfall was using retained fragments for data that belonged in a more explicit architecture layer. Once ViewModel became standard, retained fragments stopped being the clearest tool for this job.

Finally, if you are working in current AndroidX code, do not add new uses of setRetainInstance. Treat it as legacy behavior to understand and replace, not as a pattern to keep spreading.

Summary

• 'setRetainInstance(true) kept a fragment instance across configuration changes.'
• It did not retain the old activity, the old view hierarchy, or state across process death.
• The API is deprecated in modern Android development.
• 'ViewModel is the recommended replacement for retained state.'
• Learn it for legacy maintenance, but do not use it for new fragment design.