Stop building the data binding runtime Instead, use the latest prebuilt version, 9.4.1: //tools/data-binding:data_binding_runtime now packages the prebuilt runtime libraries from maven.google.com instead of building them from HEAD with Gradle. This removes the Bazel targets that built the runtime libraries with Gradle (runtimeLibrariesAndroidX and runtimeLibrariesSupport), and with them their Gradle 10 deprecations. runtime_version.properties.template now takes the extensions version from a new EXTENSIONS_BUILD_VERSION substitution, which is DATA_BINDING_RUNTIME_VERSION (9.4.1) in all configurations. So AGP adds the 9.4.1 runtime libraries to projects that use data binding or view binding, instead of runtime libraries of its own version. The compiler versions don't change. DATA_BINDING_RUNTIME_VERSION is in the new runtime_version.bzl, which BUILD.bazel loads and propLoader.gradle reads as a Java properties file. compilerCommon/build.gradle, which only the standalone tools/data-binding Gradle build uses, now takes the extensions version from a provider of that value instead of the AGP version. With the tools/base change in this topic, gmaven.zip no longer contains the runtime libraries, so AGP releases don't publish new versions of them. To update them, update the prebuilts, DATA_BINDING_RUNTIME_VERSION and its copy in the integration test framework (TestVersions.kt). The Gradle build in tools/ stops building the runtime libraries too: tools/data-binding/build.gradle no longer registers buildDataBindingRuntimeArtifacts and buildDataBindingRuntimeArtifactsForSupport, or the Gradle tasks that built them (buildExtensionsTask and prepareExtensionPrebuilds), so publishLocal is now the same as publishAndroidGradleLocal. The Gradle build doesn't build compilerCommon itself but by default uses the one from the Bazel build, so AGP from the Gradle build also adds the 9.4.1 runtime libraries. Nothing builds the runtime libraries from source anymore. Their sources (extensions/ and extensions-support/) stay for reference. Also remove the references to the runtime library builds from init.sh, .gitignore and README.md. README.md now explains where the runtime libraries come from, how to update them, and that their sources are only kept for reference. Delete update_googe3.sh, which copied the runtime libraries and adapter sources to google3 and no longer works. Also stop reading tools/buildSrc/base/dependencies.properties in integration-tests/ideCommonBuildScript.gradle. It only set rootProject.ext.kotlinVersion, which nothing uses. With this, only extensions/build.gradle, which nothing runs anymore, reads dependencies.properties, which the version catalog change in tools/buildSrc deletes. ORIGINAL_AUTHOR=akerim TAG=agy CONV=6df5130c-170d-4694-987a-6c051ac7a255 Bug: 534299542 Test: //tools/data-binding:tools.compilerCommon_tests //tools/base/build-system/integration-test/databinding:tests Flag: EXEMPT BUGFIX Change-Id: I9bd5d494d7e96def376d435361f6013eb46aa93e
run the init.sh script in {src}/tools/data-binding. This will make the integration tests runnable directly.
cd {src}/tools/data-binding && ./init.sh
To match the sdk used by android gradle plugin, this script sets the local properties to use the checked in sdk. This might conflict with your local sdk or Android Studio setup. Unfortunately, Android Studio does not support multiple SDKs so you need to live with that. (and your local sdk might just work fine if tools did not upgrade to an unreleased version. YMMV)
They are compiled as part of the Android Gradle Plugin when they are shipped. Under {src}/tools, you can run tasks for
./gradlew :dB:<TASK_NAME>
It also works independently, so you can just run
cd {src}/data-binding && ./gradlew :dB:comp:test
It also compiles with BAZEL :). It will take ages when you run it for the first time, go for a coffee. Then it will be faster and more reliable than gradle.
bazel build //tools/data-binding/...
The runtime libraries (e.g. androidx.databinding:databinding-runtime) are not built from source. AGP adds the version in DATA_BINDING_RUNTIME_VERSION (in runtime_version.bzl), the latest stable version on maven.google.com, to projects that use data binding or view binding. Bazel takes them from the prebuilts in {src}/prebuilts/tools/common/m2/repository, and
bazel build //tools/data-binding:runtimeLibraries
packages them as a Maven repository for tests.
To update them, add the new version to the prebuilts, then update DATA_BINDING_RUNTIME_VERSION in runtime_version.bzl and its copy in the integration test framework (TestVersions.kt in {src}/tools/base/build-system/integration-test/framework).
Their sources are kept in extensions/ (androidx.databinding) and extensions-support/ (the old com.android.databinding namespace) for reference only. Nothing builds them anymore.
The main project still has proper gradle configuration so you can open it in Intellij
Some of data binding tests are only in AGP. To run them:
./gradlew :base:build-system:integration-test:databinding:te or filter them like: ./gradlew :base:build-system:integration-test:databinding:te --tests DataBindingWithDaggerTest
You can run data binding unit tests via: bazel test //tools/data-binding/...
These are run by gradle build.
./gradlew :base:build-system:integration-test:application:cIT -D:base:build-system:integration-test:application:connectedIntegrationTest.single=DataBinding\* We also compile them in bazel builds:
bazel test //tools/base/build-system/integration-test/databinding:tests --test_output=errors --action_env="GTEST_COLOR=1"
You can pass --test_filter=<test class name>\* to filter certain tests
If you did run ./init.sh, you can open integration tests in Android Studio.
Due to the AndroidX change, we still keep old integration tests that use the android.databinding package. They live in integration-tests-support folder and are an exact copy of what we had at the time of the migration.
The entire compilationTests module can be developed and run from intellij (tools/adt/idea).
To run the tests in bazel:
bazel test --config=remote -- //tools/data-binding/compilationTests:studio.compilationTests_tests
There are multiple ways data binding is compiled so build file changes are a bit tricky.
If you add a new dependency, you should update: {src}/tools/data-binding/BUILD.bazel compiler/db-compiler.iml and compilerCommon/db-compilerCommon.iml
Manually editing them and then running bazel to test is the most reliable approach. If you break it, presubmit will catch. Bazel uses these iml files while compiling. You may need to modify the .idea folder inside {src}/tools if your dependency does not already exist for some other project.
After changing the iml files, you should run bazel run //tools/base/bazel:iml_to_build to re-generate the related bazel files. (if you forget, presubmit will probably catch it)
If you add a new integration test app, update {src}/tools/base/build-system/integration-test/src/test/java/com/android/build/gradle/integration/databinding/DataBindingIntegrationTestAppsTest.java to include it.
If you are working on compiler but testing via integration tests, run: ./gradlew :publishAndroidGradleLocal //(in tools/base) then run your integration test.
The easiest way to debug the compiler is to run it from the command line and attach remotely.
First, in IntelliJ, prepare a Remote configuration if you don't already have one. You can use the default options.
Next, kill some Daemons to make sure that new ones we start up will definitely be using our new settings.
jps | egrep "(Gradle|KotlinCompile)Daemon"| awk '{print $1}'| xargs kill -9
Next, build and run your app via the command-line. Note we add an invoked.from.ide property even though we aren't using an IDE. This prevents the build scripts from trying to load some files that may not exist without additional configuration.
If you are running an app that only has Java in it, the following should work, e.g. in tools/data-binding/integration-tests/AppWithDataBindingInTests:
./gradlew clean assembleDebug -Pandroid.injected.invoked.from.ide=true \ --no-daemon -Dorg.gradle.debug=true
If the app you're compiling has Kotlin in it, you may need to use the following arguments instead, e.g. in tools/data-binding/integration-tests/KotlinTestApp:
./gradlew clean assembleDebug -Pandroid.injected.invoked.from.ide=true \ -Dkotlin.daemon.jvm.options="-Xdebug,-Xrunjdwp:transport=dt_socket\,address=5005\,server=y\,suspend=y"
Finally, at some point, while the app is building, it will look like Gradle got stuck. Unfortunately, there's no text to tell you when the debugger is waiting, but this is when you should hit the debug button for your Remote configuration. If it connects, then everything worked! At this point, you should start hitting breakpoints in databinding code.
./gradlew :base:build-system:integration-test:databinding:test :base:build-system:integration-test:application:cIT -D:base:build-system:integration-test:application:connectedIntegrationTest.single=DataBinding\*