Introduction

This warning appears after upgrading Android Gradle Plugin, because the old android.dataBinding.enabled setting was replaced with the buildFeatures block. The fix is simple, but many projects still fail due to mixed plugin versions, wrong Gradle file location, or DSL syntax differences. A clean migration keeps data binding enabled and avoids noisy or failing builds.

Why the Old DSL Was Removed

Older plugin versions exposed data binding through a nested property on the android block. Newer versions group feature toggles under android.buildFeatures, including data binding, view binding, and other generated sources. This change made Gradle configuration more consistent.

If your module still uses the deprecated key, you may see warnings during configuration or hard failures in stricter plugin releases.

Correct Configuration in Groovy DSL

If your module uses build.gradle, switch to the new key in the app or library module that uses layouts with binding expressions.

1plugins {
2    id 'com.android.application'
3    id 'org.jetbrains.kotlin.android'
4}
5
6android {
7    namespace 'com.example.app'
8    compileSdk 34
9
10    defaultConfig {
11        applicationId "com.example.app"
12        minSdk 24
13        targetSdk 34
14        versionCode 1
15        versionName "1.0"
16    }
17
18    buildFeatures {
19        dataBinding true
20    }
21}

Use dataBinding true only where needed. If you only need view binding, enable viewBinding true instead.

Correct Configuration in Kotlin DSL

For build.gradle.kts, syntax differs slightly.

1plugins {
2    id("com.android.application")
3    id("org.jetbrains.kotlin.android")
4}
5
6android {
7    namespace = "com.example.app"
8    compileSdk = 34
9
10    defaultConfig {
11        applicationId = "com.example.app"
12        minSdk = 24
13        targetSdk = 34
14        versionCode = 1
15        versionName = "1.0"
16    }
17
18    buildFeatures {
19        dataBinding = true
20    }
21}

Do not copy Groovy syntax into Kotlin DSL files. That is a common source of confusing parser errors.

Verifying the Migration

After changing DSL, run a clean build and check generated sources.

./gradlew clean :app:assembleDebug

If data binding is active, generated binding classes should appear under build generated sources for the module. Also verify imports in Activity or Fragment code.

1class MainActivity : AppCompatActivity() {
2    override fun onCreate(savedInstanceState: Bundle?) {
3        super.onCreate(savedInstanceState)
4
5        val binding = ActivityMainBinding.inflate(layoutInflater)
6        setContentView(binding.root)
7
8        binding.title.text = "Data binding is enabled"
9    }
10}

If binding classes are missing, first confirm the setting is in the correct module, then confirm plugin and Gradle versions are aligned across the project.

Multi Module Projects

In a multi module setup, each module controls its own features. Enabling data binding in the app module does not enable it for a feature or library module. You must set buildFeatures.dataBinding in every module that contains data binding layouts.

For shared build conventions, many teams place common Android configuration in convention plugins or Gradle scripts. That works well, but ensure module type differences are handled correctly between application and library plugins.

Migration Checklist

Use this sequence for predictable upgrades:

1. Upgrade Android Gradle Plugin and Gradle wrapper to compatible versions.
2. Replace deprecated key with buildFeatures.dataBinding in each relevant module.
3. Sync project and run a clean assemble task.
4. Confirm generated binding classes and runtime behavior.
5. Remove old snippets from copied docs or templates.

This workflow prevents partial migrations where some modules still use obsolete DSL.

Common Pitfalls

• Updating only one module while other modules still contain deprecated android.dataBinding.enabled entries.
• Mixing Groovy and Kotlin DSL syntax in the same file, causing parser or model errors.
• Setting data binding in the root build script instead of the actual Android module where layouts exist.
• Upgrading plugin versions without upgrading Gradle wrapper to a compatible release.
• Assuming view binding and data binding are interchangeable even though they generate different APIs and require different layout conventions.

Summary

• android.dataBinding.enabled is obsolete in modern Android Gradle Plugin versions.
• Use android.buildFeatures.dataBinding in each module that needs it.
• Apply correct syntax for Groovy DSL or Kotlin DSL based on file type.
• Validate by running a clean assemble and checking generated binding classes.
• Keep plugin, Gradle wrapper, and module configuration aligned to avoid migration failures.