Changes to resource require all upstream targets to rebuild

Given:-

android_binary("app") -> android_library("libA") -> android_library("libB) -> android_library("libc") -> "res/values/strings.xml"

bazel build //:app

Adding a new string resource in "libc" causes a rebuild of all upstream targets ("app", "libA', "libB").

We're using android_strict_resource_deps as well as the namespaced_r_classes https://github.com/bazelbuild/bazel/pull/11385 I have open.

As I expect there is no resource merging or linking for "libA' + "libB", just a single `AndroidResourceCompiler` for "libC" and a single `AndroidAapt2`action to link the changed resource into the android_binary.

What I am surprised about is that all upstream targets have a `KotlinCompile` action associated with them. This is because the new resource has changed the R.class and libC_resource.jar which is an input to all upstream targets.

This is where my knowledge of Bazel is a little hazy, but is it expected that the libC_resource.jar output is given as an input to ALL upstream targets (i.e: "app", "libA", "libB")?

I think, what we want, since we have strict_java_deps is that the change to the resource would only require recompiling the Java/Kotlin for libC + libB (since B is permitted to depend on libC.R.class as its a direct dependency)

I noticed that all transitive resource jars are collected and added to `AndroidLibraryResourceClassJarProvider` here:-

https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/rules/android/AndroidLibrary.java#L233

Commenting out the collection of transitive resource jars and only including the locally produced resource jar has no affect though.

Of is this is correct, do we need to put some kind of ijar in place for upsteam targets that are not direct parents?

@donaldchai - would appreciate your thoughts here. I'm happy submit a PR if you think this is valid change and can give a few pointers.

Thanks, Jonathan