Introduction

A fragment appearing on top of another fragment is usually not a rendering bug. It is a transaction problem: the app added a second fragment to the same container without removing or replacing the first one. Once you understand how FragmentManager applies transactions, the fix is usually straightforward.

Why Fragments Overlap

The most common cause is using add() when the screen should show exactly one fragment at a time.

supportFragmentManager.beginTransaction()
    .add(R.id.fragment_container, DetailsFragment())
    .commit()

add() inserts a fragment into the container but keeps any existing fragment view there as well. If both fragments render into the same area, you see one layered over the other. That is correct behavior for overlays, dialogs, or multi-pane layouts, but it is wrong for simple screen-to-screen navigation.

If the intent is “replace the current screen with a new one,” use replace().

1supportFragmentManager.beginTransaction()
2    .replace(R.id.fragment_container, DetailsFragment())
3    .addToBackStack(null)
4    .commit()

replace() removes the current fragment from that container before adding the new one, which prevents stacking two full-screen views in the same space.

Use the Right Container

Modern apps should host fragments in a dedicated FragmentContainerView or another clear container view. A minimal layout looks like this:

1<androidx.fragment.app.FragmentContainerView
2    android:id="@+id/fragment_container"
3    android:layout_width="match_parent"
4    android:layout_height="match_parent" />

Using a single, well-defined container reduces confusion about where fragments are being attached. Problems often appear when a transaction targets the wrong container ID, especially after refactors or when multiple fragment areas exist on tablets.

Back Stack Behavior Matters

Developers sometimes fix overlap by removing fragments manually, but the real issue is navigation design. If you want the back button to return to the previous fragment, add the replacement to the back stack.

1supportFragmentManager.beginTransaction()
2    .replace(R.id.fragment_container, SettingsFragment())
3    .addToBackStack("settings")
4    .commit()

That way, Android restores the previous fragment when the transaction is popped. Without a back stack entry, pressing back may finish the activity instead of returning to the previous content.

Avoid Mixing Manual View Hiding with Fragment Transactions

Another common source of visual glitches is hiding fragment root views manually instead of letting the fragment manager control lifecycle and view state.

val fragment = supportFragmentManager.findFragmentById(R.id.fragment_container)
fragment?.view?.visibility = View.GONE

That may appear to solve the visible overlap, but the fragment still exists and its lifecycle is unchanged. Later transactions become harder to reason about because the UI state and fragment state drift apart. Prefer explicit fragment operations such as replace(), remove(), show(), or hide() on the transaction itself.

Nested Fragments Need childFragmentManager

If the overlap happens inside another fragment, make sure you are using childFragmentManager rather than the activity’s fragment manager.

childFragmentManager.beginTransaction()
    .replace(R.id.inner_container, ChildListFragment())
    .commit()

Using the wrong manager can place a fragment in an unexpected part of the hierarchy or create back stack behavior that feels broken. Nested containers should be managed by the parent fragment that owns them.

Prefer a Clear Navigation Pattern

For apps with screen-style navigation, Jetpack Navigation reduces many of these mistakes because it centralizes destinations and back stack handling. Even without it, adopting a rule such as “one full-screen fragment per container, always switched with replace()” eliminates most overlap bugs.

A small helper can also make transactions consistent:

1fun AppCompatActivity.showScreen(fragment: Fragment, tag: String? = null) {
2    supportFragmentManager.beginTransaction()
3        .replace(R.id.fragment_container, fragment, tag)
4        .addToBackStack(tag)
5        .commit()
6}

Consistency matters more than clever transaction logic.

Common Pitfalls

The biggest mistake is using add() for normal screen navigation. Another is targeting the wrong container ID after a layout change. Developers also run into trouble when they manually change fragment view visibility instead of updating fragment transactions. In nested UIs, using supportFragmentManager where childFragmentManager is required can produce confusing overlap and back stack behavior. Finally, calling multiple transactions in quick succession after state is saved can create hard-to-reproduce UI issues.

Summary

• Use replace() when only one fragment should occupy a container.
• Reserve add() for intentional stacking or multi-pane layouts.
• Keep fragment transactions tied to the correct container ID.
• Use childFragmentManager for fragments hosted inside other fragments.
• Let the fragment manager control visibility and back stack state instead of manually hiding views.