Introduction

RecyclerView is optimized for scrolling large lists, which is why wrap_content can feel unreliable when you expect it to measure all children and grow to the full content height. By design, RecyclerView tries to measure efficiently and render only what it needs, so “measure everything and expand forever” is not its default strength.

If you need wrap_content, the first question is whether the UI actually wants a scrolling list. In many layouts the better fix is to avoid nesting scroll containers and let the RecyclerView own scrolling. When that is not possible, there are a few workable approaches.

Why wrap_content Is Awkward Here

A RecyclerView is not a LinearLayout that eagerly measures every child. It is built around recycling and viewport-based measurement.

That means these layouts are often problematic:

• 'RecyclerView inside ScrollView'
• 'RecyclerView inside NestedScrollView'
• small list embedded in another scrolling container with wrap_content expectation

For long datasets, fully expanding the list defeats much of the reason RecyclerView exists in the first place.

Best Fix: Let RecyclerView Handle Scrolling

If the list is the main content, make the RecyclerView match_parent in the scrolling dimension and remove the outer scroll container.

1<androidx.recyclerview.widget.RecyclerView
2    android:id="@+id/list"
3    android:layout_width="match_parent"
4    android:layout_height="match_parent" />

This is the most performant and least surprising solution.

For Small Embedded Lists, Disable Nested Scrolling

If the RecyclerView really must live inside another scrolling parent, disabling nested scrolling often improves behavior.

val recyclerView = findViewById<RecyclerView>(R.id.list)
recyclerView.isNestedScrollingEnabled = false

In XML, you can also set:

android:nestedScrollingEnabled="false"

This does not magically make RecyclerView ideal for every nested-scroll layout, but it is often enough for short lists inside forms or detail screens.

Use a LinearLayoutManager and Fixed-Size Assumptions Carefully

For short static-ish lists, a vertical LinearLayoutManager is the simplest layout manager.

recyclerView.layoutManager = LinearLayoutManager(this)
recyclerView.isNestedScrollingEnabled = false

Avoid setHasFixedSize(true) if the item heights or item count are expected to change the total measured height significantly. That flag is useful for optimization when layout size does not depend on content size changes.

When a Custom Measuring Approach Is Needed

If you truly need the RecyclerView to measure itself to the combined height of all items, you can use a custom LayoutManager override. But this should be a last resort and is usually appropriate only for small datasets.

The reason is simple: measuring every item removes the performance advantage of lazy rendering.

A simplified example looks like this:

1class WrapContentLinearLayoutManager(context: Context) : LinearLayoutManager(context) {
2    override fun onMeasure(
3        recycler: RecyclerView.Recycler,
4        state: RecyclerView.State,
5        widthSpec: Int,
6        heightSpec: Int
7    ) {
8        super.onMeasure(recycler, state, widthSpec, heightSpec)
9    }
10}

Real custom measuring implementations are more involved than this and can get fragile quickly. Before going down that path, re-check whether the layout design itself should change.

Better Alternatives for Non-Large Lists

If the list is small and not performance-sensitive, sometimes RecyclerView is simply the wrong widget. A vertical LinearLayout or a custom compound view may be easier to reason about if the content count is tiny.

Use RecyclerView when you want:

• recycling
• animations
• adapters and diffing
• scalable list rendering

Use simpler containers when the list is so small that virtualization provides little value.

Common Pitfalls

A common mistake is putting a RecyclerView inside a ScrollView and expecting both to cooperate automatically. Nested scrolling and measurement often become messy in that setup.

Another mistake is forcing wrap_content for long lists. That can lead to expensive measurement and poor performance.

Developers also jump straight to custom layout manager code when disabling nested scrolling or redesigning the layout would solve the real problem more cleanly.

Finally, be careful with fixed-size optimization flags. They are useful, but only when the assumptions behind them are actually true.

Summary

• 'RecyclerView is optimized for scrolling, not for eagerly expanding to the full height of all items.'
• The best fix is usually to let RecyclerView own the scrolling area.
• For short embedded lists, disabling nested scrolling often helps.
• Custom wrap-content measurement is possible but should be a last resort for small datasets only.
• If the content is tiny and static, a simpler layout may be a better fit than RecyclerView.