Fixed
Status Update
Comments
je...@google.com <je...@google.com>
al...@google.com <al...@google.com>
xa...@google.com <xa...@google.com> #2
This time actually attaching the project :)
al...@google.com <al...@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
al...@google.com <al...@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.
al...@google.com <al...@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.
al...@google.com <al...@google.com>
an...@google.com <an...@google.com> #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.
da...@gmail.com <da...@gmail.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
This repro's with AGP
8.1.*
and8.3 alpha06
at least.Applying a transform on the
ASSETS
artifact withwill give the following locations:
The Input being inside the output is broken.
We should also double check all other potential artifacts.