In Android app modules, check manifest or final APK to ensure correct advice for dependencies that are implemented as ContentProviders about dependency-analysis-gradle-plugin HOT 1 CLOSED

There are at least two issues with LeakCanary that I discovered last night while investigating this.

1. Because of how LeakCanary is implemented, it may never show up in the compiled class files of an android-app project (but it must be present in the final APK and in the final manifest, because it registers activities, services, content providers)
2. If you use product flavors, then the reporting is even weirder, saying the configuration is "null". This probably relates to #86.

For (1), it looks like leak canary is basically a runtime dependency. I can probably analyze either the dex files or the manifest and figure out that leak canary is "used" in the sense it's in the final artifact, but it's fundamentally impossible to generalize this (I think). Libraries might contribute activities/etc that are unused, but if the plugin looks at the manifest and finds those contributed elements, it would not be able to suggest removing such unused dependencies.

I'm going to do some exploration to see what I can learn from looking at manifests, but solving this problem in a general way will require some thought and design work.

from dependency-analysis-gradle-plugin.