Status Update
No update yet.
Comments
ne...@gmail.com
It looks like we have more directories
›../../out/androidx/appsearch/appsearch-local-storage/build/../nativeBuildStaging/cmake/debug/arm64-v8a/build.ninja📋
›../../out/androidx/appsearch/appsearch-local-storage/build/../nativeBuildStaging/cmake/debug/arm64-v8a/build.ninja.txt📋
›../../out/androidx/appsearch/appsearch-local-storage/build/../nativeBuildStaging/cmake/debug/armeabi-v7a/build.ninja📋
›../../out/androidx/appsearch/appsearch-local-storage/build/../nativeBuildStaging/cmake/debug/armeabi-v7a/build.ninja.txt📋
›../../out/androidx/appsearch/appsearch-local-storage/build/../nativeBuildStaging/cmake/debug/x86/build.ninja📋
›../../out/androidx/appsearch/appsearch-local-storage/build/../nativeBuildStaging/cmake/debug/x86/build.ninja.txt📋
›../../out/androidx/appsearch/appsearch-local-storage/build/../nativeBuildStaging/cmake/debug/x86_64/build.ninja📋
›../../out/androidx/appsearch/appsearch-local-storage/build/../nativeBuildStaging/cmake/debug/x86_64/build.ninja.txt📋
›../../out/androidx/appsearch/appsearch-local-storage/build/../nativeBuildStaging/cmake/release/arm64-v8a/build.ninja📋
›../../out/androidx/appsearch/appsearch-local-storage/build/../nativeBuildStaging/cmake/release/arm64-v8a/build.ninja.txt📋
›../../out/androidx/appsearch/appsearch-local-storage/build/../nativeBuildStaging/cmake/release/armeabi-v7a/build.ninja📋
›../../out/androidx/appsearch/appsearch-local-storage/build/../nativeBuildStaging/cmake/release/armeabi-v7a/build.ninja.txt📋
›../../out/androidx/appsearch/appsearch-local-storage/build/../nativeBuildStaging/cmake/release/x86/build.ninja📋
›../../out/androidx/appsearch/appsearch-local-storage/build/../nativeBuildStaging/cmake/release/x86/build.ninja.txt📋
›../../out/androidx/appsearch/appsearch-local-storage/build/../nativeBuildStaging/cmake/release/x86_64/build.ninja📋
›../../out/androidx/appsearch/appsearch-local-storage/build/../nativeBuildStaging/cmake/release/x86_64/build.ninja.txt📋
it also considers all of these input to configuration cache
ra...@google.com
su...@google.com
ap...@google.com
Prefab feature also seems to cause the following to be added as configuration ache inputs
›../../out/androidx/external/libyuv/build/intermediates/prefab_package_header_only/prefab_publication.json/debug📋
›../../out/androidx/external/libyuv/build/intermediates/prefab_package_header_only/prefab_publication.json/release📋
›../../out/androidx/test/ext/junit-gtest/build/intermediates/prefab_package_header_only/prefab_publication.json/debug📋
›../../out/androidx/test/ext/junit-gtest/build/intermediates/prefab_package_header_only/prefab_publication.json/release📋
lo...@gmail.com
./gradlew zipTestConfigsWithApks
su...@google.com
./gradlew zipTestConfigsWithApks in the androidx project
Do you mean to run from androidx-main/frameworks/support? If so, I did a run but it took too long and failed in the end with some 9 errors. Even if it finished successfully, it is too long for debug. Do we have to run that specific task or it can be reproduced with some lightweight task? If would be more helpful if we can even reproduce it in a sample project instead of using the androidx project.
Jomo, do you know where those cxx related files are being created? any pointers?
ta...@gmail.com
The easiest is to probably just look at
in there see file system entry. all of these files are treated as input to the configuration cache. There should be no entries to ../../out/ once all the plugins are fixed.
ta...@gmail.com
Sadly, the report doesnt give you traces (I asked rodrigo from gradle to add it in the future version of gradle), so we only see it is coming from plugin 'com.android.internal.library'
ah...@gmail.com
As far as I know, the most effective way to get the traces is to debug a build running with gradle by adding a break point here
ar...@gmail.com
The folder path '../../out/androidx/appsearch/appsearch-local-storage/build/intermediates/cxx' originates from ProjectInfo::getIntermediatesDir() which is deprecated with a message that says "Use the version that returns a provider".
The files mentioned in
The files in
A question maybe for Ivan, I thought the tests under com.android.build.gradle.integration.ndk.* would fail if they violated configuration caching (I recall the original push for configuration caching required some of these tests to be temporarily exempted). Is there a new constraint arriving with Gradle 8.1? In other words, are these regressions or have they always existed? It might help narrow down the cause/fix.
pr...@gmail.com
Re #8:
if you upgrade androidx to 8.1 and run the following:
./gradlew appsearch:appsearch-local-storage:assembleDebug
you'll get that code path triggered.
There is also the whole gerrit topic you can apply if you want the 8.2-alpha** agp.
Re #9:
Gradle now instruments all file calls (exists(), isDirectory(), etc) and makes them part of configuration cache input if it happens during the configuration. This is a new requirement starting 8.1
Description
Version used: 1.0.0-alpha07
Devices/Android versions reproduced on: Pixel 2, Android 9 Pie
The work request below is executed once but not periodically on version alpha07, this works correctly and periodically on version alpha06
val constraints = androidx.work.Constraints.Builder()
.setRequiredNetworkType(NetworkType.CONNECTED)
.build() // Run only when network is available
val workRequest =
PeriodicWorkRequestBuilder<ReportUploader>(REPORTING_REPEAT_INTERVAL_IN_MINUTES, TimeUnit.MINUTES)
.addTag(REPORTER_TAG)
.setConstraints(constraints)
.setBackoffCriteria(BackoffPolicy.EXPONENTIAL, 10, TimeUnit.SECONDS)
.build() // Run every 15 mins
workManager
.enqueueUniquePeriodicWork(REPORTER_TAG, ExistingPeriodicWorkPolicy.KEEP, workRequest)