Status Update
Comments
il...@google.com <il...@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
ch...@gmail.com <ch...@gmail.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📋
ch...@gmail.com <ch...@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?
ap...@google.com <ap...@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.
il...@google.com <il...@google.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'
Description
I have two Activities, MainActivity and SecondActivity. Using Navigation architecture in MainActivity, which has two fragments, such as HomeFragment and DetailFragment, the Navigation diagram is declared as follows:
Generate ViewModels in the DetailFragment onCreate with "by navGraphViewModels".
There is a button in DetailFragment, clicking it will jump to SecondActivity, when "Do not keep background Activity" is enabled, pressing the back button in SecondActivity will trigger the program crash:
If I put the vm creation declaration in the onViewCreated lifecycle or later, there will be no crashes.
Does "by navGraphViewModels" necessarily require the user to use it this way?
In my opinion, as long as the NavBackStackEntry viewModelStore corresponding to "R.id.navigation_home_flow" is in the CREATED state, it's OK, not the DetailFragment.
The Navigation version I use is 2.4.0-alpha06.
Thanks in advance if you can address my issue.