Introduction

Android View Binding can generate binding access not only for the main layout, but also for layouts brought in with an include tag. The key is that the included layout must be referenced in a way the code generator can understand, usually by giving the include tag an android:id. Once that is in place, the parent binding exposes a nested binding object instead of forcing you back to findViewById.

How Included Layout Binding Works

When View Binding processes a layout file, it generates a binding class for that file. If the parent layout includes another layout, the generated parent binding can expose a field for the included binding as well.

A common setup looks like this:

1<!-- res/layout/content_header.xml -->
2<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
3    android:layout_width="match_parent"
4    android:layout_height="wrap_content"
5    android:orientation="vertical">
6
7    <TextView
8        android:id="@+id/titleText"
9        android:layout_width="wrap_content"
10        android:layout_height="wrap_content"
11        android:text="Header" />
12</LinearLayout>

1<!-- res/layout/activity_main.xml -->
2<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
3    android:layout_width="match_parent"
4    android:layout_height="match_parent"
5    android:orientation="vertical">
6
7    <include
8        android:id="@+id/header"
9        layout="@layout/content_header" />
10
11</LinearLayout>

With that structure, the generated ActivityMainBinding typically exposes binding.header, and that field is a ContentHeaderBinding.

Accessing the Included Binding in Code

Once the layout is inflated, the included binding is available as a nested property.

1import android.os.Bundle
2import androidx.appcompat.app.AppCompatActivity
3import com.example.app.databinding.ActivityMainBinding
4
5class MainActivity : AppCompatActivity() {
6    private lateinit var binding: ActivityMainBinding
7
8    override fun onCreate(savedInstanceState: Bundle?) {
9        super.onCreate(savedInstanceState)
10        binding = ActivityMainBinding.inflate(layoutInflater)
11        setContentView(binding.root)
12
13        binding.header.titleText.text = "Welcome"
14    }
15}

This is the main benefit: the compiler knows both the included layout and its child views, so you get type-safe access all the way down.

Naming Rules and Generated Property Names

The property name comes from the android:id on the include tag, not from the filename alone. For example, @+id/header becomes binding.header.

That means two practical rules matter:

• Give the include tag an ID if you want a clear nested binding property.
• Use naming that matches the role of the included section, not just the XML filename.

Good IDs improve readability because binding.header.titleText says more than a generic name would.

When Things Look Different

If your included layout uses special root structures or you omit the include ID, the generated access pattern may not match what you expected. In some layouts, especially when refactoring older XML, developers assume a nested binding object will always appear and then wonder why only individual child views are exposed or why code generation is missing a field.

The reliable debugging steps are:

1. Confirm View Binding is enabled in the module.
2. Confirm the parent include has android:id.
3. Rebuild the project so binding classes regenerate.
4. Inspect the generated binding type in autocomplete instead of guessing property names.

Why This Is Better Than Manual View Lookup

Without View Binding, included layouts often lead to extra lookup code and fragile casts. With binding, the included layout remains a reusable UI component but the parent still gets strong typing.

That improves:

• refactor safety
• null safety compared with manual lookup
• readability in activities and fragments
• discoverability in IDE autocomplete

For large screens made of reusable XML sections, this is one of the most practical features of View Binding.

Common Pitfalls

• Forgetting to set an android:id on the include tag and then expecting a nested binding field.
• Guessing generated property names instead of checking the binding class.
• Mixing View Binding assumptions with older findViewById patterns and creating duplicate logic.
• Changing XML IDs without rebuilding and then assuming View Binding is broken.
• Expecting every include scenario to expose the exact same generated shape after complex XML refactors.

Summary

• Included layouts can be accessed through View Binding as nested binding objects.
• The include tag should usually have an android:id.
• The generated parent binding exposes the included binding through that ID-derived property.
• Rebuild the project if generated binding access looks wrong.
• Use View Binding for included layouts to keep reusable XML sections type-safe and easy to navigate.