Handling resources usage accros modules
I had a lot of false positives when I tried disableAndroidResources feature. This happens especially when resources are used across modules.
Imagine a module has a String resource that is used by android module. ModuleCheck will suggest to put buildFeatures.androidResources = false in android {} block. This will actually compile fine.
But then during application's assemble task and during resource linking process, build will fail because of AAPT.
Here is an example error that happens in upstream module when resources disabled in downstream:
Execution failed for task ':app:processDebugResources'.
> A failure occurred while executing com.android.build.gradle.internal.res.LinkApplicationAndroidResourcesTask$TaskAction
> Android resource linking failed
ERROR:/Users/redacted/app/src/main/res/xml/xml_file.xml:79: AAPT: error: resource string/some_string_resource not found.
Thanks for the report! I was able to reproduce this.
Auto-disabling androidResources seems to work correctly, unless the module is referencing its own R (or some other module is -- but that's a strange thing to do in this case).
In order to disable androidResources:
- the module can't have any
resfiles of its own - there can be no references to the R file (since it wouldn't be generated)
- no
AndroidManifest.xmlcan reference any resources at all?? a. I would have to experiment with how this works withnonTransitiveRClass - no
resValuesdefined in its Gradle config - the module can't be an application module
This is a very good summary for sure. When nonTransitiveRClass is not enabled, there could be another edge case:
In parent modules, developers can accidentally use the wrong R import. It can both be the merged R class with the package name of the parent module. Or it can also be the R class from any of the dependant modules.
Yeah, the most common cause I've seen for using the "wrong" R is when copy/pasting. It happened all the time when creating Espresso robots.
I hope to be able to fix this within the next couple of days.
Thanks again for the report!