Status Update
Comments
vi...@google.com <vi...@google.com> #2
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
ha...@meta.com <ha...@meta.com> #3
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📋
vi...@google.com <vi...@google.com> #4
./gradlew zipTestConfigsWithApks
to...@gmail.com <to...@gmail.com> #5
./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?
ra...@google.com <ra...@google.com> #6
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.
to...@gmail.com <to...@gmail.com> #7
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'
ra...@google.com <ra...@google.com> #8
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
ra...@paynearby.in <ra...@paynearby.in> #9
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.
Description
We can't reproduce these but after integrating with the in app review library we started to see crash reports with these stack traces at the bottom. We don't have info on the Google play services version on the client. But the issues might be device specific. Seems like we are on the latest versions of these libraries.
app library versions :
com.google.android.play:core-common: 2.0.3 com.google.android.play:review: @2.0.1
Crash 1
Mostly occuring on some xioami devices on android 14 Top 3 devices: Xiaomi-23127PN0CG Xiaomi-22071212AG Xiaomi-2303ERA42L
Crash 2
mostly occuring on vivo and huawei devices on differend android versions
top 3 devices vivo-V2027 vivo-V2029 HUAWEI-CAM-L21