Fixed
Status Update
Comments
al...@gmail.com <al...@gmail.com> #2
Or even material_red_500, it's used in the same file!
al...@gmail.com <al...@gmail.com> #3
Run ./gradlew app:android-base:lint
uc...@google.com <uc...@google.com>
tn...@google.com <tn...@google.com> #4
I looked into this.
material_red_500 is used in the same file, but that doesn't mean it's *really* used: Lint builds up a full graph of resource dependencies, and a resource is unused only if it is referenced from code or the manifest. Otherwise you would have to run unused resources over and over again to remove one leaf node at a time.
In particular, material_red_500 is used exactly once, by @color/delete_background. And this color is also listed as unused.
In grepping through the source code I find only a single reference to it:
feature/templates/src/main/java/com/supercilex/robotscouter/feature/templates/TemplateItemTouchCallback.kt
48: color = ContextCompat.getColor(rootView.context, RC.color.delete_background)
I ran this through a debugger, and lint never comes across that code reference. And sure enough, when I'm looking at the project dependencies, it looks to me like the app module app:android-base does not depend on :feature:templates. Is that correct? I ran ./gradlew app:android-base:dependencies and checked the compile dependencies, and it looks to me like we're not including this code in the app module, which would really make those two resources, but there's quite a bit of stuff going on in your build.gradle files so maybe there's some way that code is getting pulled in that I didn't notice.
material_red_500 is used in the same file, but that doesn't mean it's *really* used: Lint builds up a full graph of resource dependencies, and a resource is unused only if it is referenced from code or the manifest. Otherwise you would have to run unused resources over and over again to remove one leaf node at a time.
In particular, material_red_500 is used exactly once, by @color/delete_background. And this color is also listed as unused.
In grepping through the source code I find only a single reference to it:
feature/templates/src/main/java/com/supercilex/robotscouter/feature/templates/TemplateItemTouchCallback.kt
48: color = ContextCompat.getColor(rootView.context, RC.color.delete_background)
I ran this through a debugger, and lint never comes across that code reference. And sure enough, when I'm looking at the project dependencies, it looks to me like the app module app:android-base does not depend on :feature:templates. Is that correct? I ran ./gradlew app:android-base:dependencies and checked the compile dependencies, and it looks to me like we're not including this code in the app module, which would really make those two resources, but there's quite a bit of stuff going on in your build.gradle files so maybe there's some way that code is getting pulled in that I didn't notice.
al...@gmail.com <al...@gmail.com> #5
No no, you're right about that, but then I'm confused: shouldn't checkDependencies be able to handle it? If you look here, I'm telling the AGP about my dependencies: https://github.com/SUPERCILEX/Robot-Scouter/blob/0f2b9c8f562b2e8aa79f5a738fb0f321c067e60f/app/android-base/build.gradle.kts#L13-L15 .
So maybe this should be a feature request instead? "Support checking dynamic feature modules" A somewhat ugly alternative would be to add a new lint module that pulls in all the dynamic feature modules so lint can get a complete picture of the project.
So maybe this should be a feature request instead? "Support checking dynamic feature modules" A somewhat ugly alternative would be to add a new lint module that pulls in all the dynamic feature modules so lint can get a complete picture of the project.
tn...@google.com <tn...@google.com> #7
Thanks for the details. I've updated the synopsis to reflect that this is related to feature modules. The next step is to make sure that these dependencies are showing up in the dependency graph lint is handed from Gradle.
wb...@gmail.com <wb...@gmail.com> #8
Now that dynamic features are out of beta, do you plan on fixing this issues?
tn...@google.com <tn...@google.com> #9
This is now fixed in Studio 4.1, along with a backport for 4.0, by Change-Id: Ia8aa443832f4c7b7d5cf32d07205bd20271e5a7d. It will be released in 4. I think the first build to contain the fix will be 4.0 beta 2 and 4.1 canary 2. Thanks for the report, and the patience :-)
(Quick detail on how it works: When an app module declared dynamic feature modules, running lint on that app module (./gradlew :app:lintDebug) will include the feature module sources in the analysis as well (no need to turn on checkDependencies or anything like that.)
(Quick detail on how it works: When an app module declared dynamic feature modules, running lint on that app module (./gradlew :app:lintDebug) will include the feature module sources in the analysis as well (no need to turn on checkDependencies or anything like that.)
al...@gmail.com <al...@gmail.com> #10
Thank you! 🙌
ti...@gmail.com <ti...@gmail.com> #11
Hey. This now no longer works with "checkGeneratedSources" for dynamic feature modules. So if I have view binding implemented it shows me "UnusedIds" all over the place because :app:lint ignores generates sources of that dynamic feature module. Please fix or give me a hint how to make it included!
ma...@gmail.com <ma...@gmail.com> #12
Thank you so much for the fix!
(Quick detail on how it works: When an app module declared dynamic feature modules, running lint on that app module (./gradlew :app:lintDebug) will include the feature module sources in the analysis as well (no need to turn on checkDependencies or anything like that.)
So does it mean we should not turn on checkDependencies for project with dynamic feature modules otherwise lint does not run?
[Deleted User] <[Deleted User]> #13
This is still not working when using "typealias" or "import as" inside dynamic feature modules on R from (let's say) common module
for example "import com.example.common.R as Rcommon" will result in every single resource as "UnusedResource"
And it doesn't work if the resource is only used via xml from another module, for example "@dimen/someSpacing"
'gradleBuildTools' : '7.0.0-beta05',
'lint' : '30.0.0-beta05'
for example "import com.example.common.R as Rcommon" will result in every single resource as "UnusedResource"
And it doesn't work if the resource is only used via xml from another module, for example "@dimen/someSpacing"
'gradleBuildTools' : '7.0.0-beta05',
'lint' : '30.0.0-beta05'
Description
Setup: ./gradlew setup
Example: activatable_button_text is used in XML, but still reported.