Question: How does DAGP resolve dependencies for duplicate resource names across modules?

[zepurplez]

There is an Android project with three modules: a, b, and c. Suppose modules b and c both contain a string resource with the same name - common_ok. Modules b and c are included in module a. In module a, there is an XML file(layout) that uses the string resource common_ok. How will the :a :projectHealth DAGP task advice which dependency to add or remove?

There is a suspicion that this issue occurs due to this particular case.

[autonomousapps]

This plugin requires use of non-transitive resources. So in the case above, if you're not using non-transitive resources, then the analysis won't work very well. If you are using non-transitive resources, then it will accurately connect the string common_ok (with a fully-qualified and unique package) to the correct module.

If you have an issue, please provide a minimal reproducer along with a complete issue report.

[zepurplez]

Unfortunately, I can’t provide a reproducer, but in my case we’re regularly seeing issues on CI when adding/removing the same dependency. The problems seem to be related to resource usage in XML files.

The nonTransitiveRClass option is enabled in our project, and it works great when using resources in Kotlin classes and explicitly importing the required R class. However, I’m not sure whether this option has any effect on resource references in XML files.

Project a and project b:

<resources>
    <string name="common_ok">OK</string>
</resources>

Project c:

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:orientation="vertical"
    android:layout_width="match_parent"
    android:layout_height="match_parent">

    <TextView
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="@string/common_ok" />

</LinearLayout>

So in this case, there is no explicit import of the R class.

[autonomousapps]

I've added a test case at #1750. It (sadly) fails to fail. So you're right in that there's an issue regarding duplicate resources in Android libs. But this is also a fundamental issue with how resource merging works.

If you can describe the scenario by which this plugin can lead to #1029, I will try to recreate it in a test case and see what I can do.

[zepurplez]

The scenario is roughly the same as I described above. There is module A that uses a resource (id, color, attribute, etc.) in an XML file that comes from other modules/artifacts B and C . The resource has the same name in both places. Locally, the plugin’s behaviour may suggest to adding a dependency, while on CI the behaviour differs - it may ask to remove/add a dependency. Unfortunately this is hard to reproduce because it apparently depends on some cache or state change.

I reproduced another case with resources you can check it here. In the modules lib_resource and lib_resources2 there is a file ids.xml:

<resources>
    <item type="id" name="icon" />
</resources>

The lib module includes lib_resources, lib_resources2, androidx.appcompat:appcompat-resources and uses this id in a layout exactly as @id/ rather than @+id/ :

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:id="@id/icon"
    android:orientation="vertical"
    android:layout_width="match_parent"
    android:layout_height="match_parent">
</LinearLayout>

Now, if you run ./gradlew :lib:projectHealth you get the following suggestions:

Unused dependencies which should be removed:
  implementation(libs.androidx.appcompatResources)

These transitive dependencies should be declared directly:
  implementation("androidx.core:core:1.6.0")
  implementation("androidx.vectordrawable:vectordrawable-animated:1.1.0")
  implementation("androidx.vectordrawable:vectordrawable:1.1.0")

It looks like the plugin found all the dependencies in which this id was declared and wants to add them to the dependency graph. I’m not sure whether this will help reproduce the flakiness issue, but it is one of those cases where we see flakiness on CI.