Fixed
Status Update
Comments
sg...@google.com <sg...@google.com> #2
This time actually attaching the project :)
ch...@google.com <ch...@google.com>
ap...@google.com <ap...@google.com> #3
Yes, we don't merge assets in libraries now for performance reasons. This is a larger change that I don't think will make it in 3.0
ap...@google.com <ap...@google.com> #4
Could test_config.properties & Robolectric then be updated to accept a set of assetDirs (currently points to a single dir) to workaround this problem? I'll try to find some time to craft a Gradle hack (copying assets) in the meantime as this is a blocker for our migration to AGP 3.0.
ap...@google.com <ap...@google.com> #5
Problem is this means that Robolectric tests won't work for libraries using the new build system api.
I wonder how users test library components now, does AGP generate a BuildConfig.class for libraries?
Is it possible to mitigate / defer the performance concerns and just do the merging if includeAndroidResources = true is specified?
If its not going to be supported in 3.0 we'll need to message it on the Robolectric site and provide some kind of alternative.
I wonder how users test library components now, does AGP generate a BuildConfig.class for libraries?
Is it possible to mitigate / defer the performance concerns and just do the merging if includeAndroidResources = true is specified?
If its not going to be supported in 3.0 we'll need to message it on the Robolectric site and provide some kind of alternative.
m....@anfe.ma <m....@anfe.ma> #6
Jerome, can you triage this?
Looking at the code history, I think this never worked, as we never merged assets from dependencies in library subprojects. The AndroidTest variants have their own asset/resource source folders and processing pipeline, so that works fine. If this isn't a regression from 2.3 it's going to be a hard sell for 3.0 at this point.
I think the work involved would be:
- Introduce a second android asset merger task in libraries (maybe in the unit test variant, but doesn't really matter) that includes dependencies
- When includeAndroidResources=true, wire the task dependency and include that in the properties file we pass to roboelectric
Yes, there is a build config class per library, in the same package as the R class, not sure what that has to do with this though.
Hope that helps.
Looking at the code history, I think this never worked, as we never merged assets from dependencies in library subprojects. The AndroidTest variants have their own asset/resource source folders and processing pipeline, so that works fine. If this isn't a regression from 2.3 it's going to be a hard sell for 3.0 at this point.
I think the work involved would be:
- Introduce a second android asset merger task in libraries (maybe in the unit test variant, but doesn't really matter) that includes dependencies
- When includeAndroidResources=true, wire the task dependency and include that in the properties file we pass to roboelectric
Yes, there is a build config class per library, in the same package as the R class, not sure what that has to do with this though.
Hope that helps.
an...@google.com <an...@google.com> #7
Parsing the BuildConfig.class was the way the ad-hoc Robolectric integration used to work, obviously we'd like to move to the new includeAndroidResources API, just thinking about workarounds.
Description
I'm currently developing an Android App using Gradle & Android Studio.
I recently upgraded my project to
When running
./gradlew assembleMyAppRelease --rerun-tasks
i get lots of warnings of the following format:This might be a totally valid warning (can't judge). However, this does occur for
proguard-android-optimize.txt
which is the reason i'm writing this ticket.This warning also occurs for a few major dependencies' proguard files (e.g.
navigation-common-2.8.2/proguard.txt
,retrofit2.pro
) but i guess that's the job of the dependencies' maintainers.Might be related to: https://issuetracker.google.com/issues/225394515
Full warning text attached: