Check if Library is used in Android app

Question

I received some legacy code of app (not developed by me, but by some other team, with no documentation), which has almost 20+ dependencies, in build.gradle.

Answer 1

If you mean that finding unused library or import, you can easily see with "Ctrl + alt + shift + i" and type "unused import"

You can see now all unused imports.

Answer 2

Finding libraries and resources used in an Android app comes up in several contexts.

For the apps published in Google Play, AppBrain maintains reverse lookups, from the library to the more popular apps that use it. For example, apps using a newish 2D game library Godot.

Apktool will decode the APK directly.

The author instead wants to find (unused) resources, starting from the source code and the build process. Gabriele Mariotti above links to the question, whose accepted answer provides detailed information on use of minifyEnabled and shrinkResources in Gradle configuration.

Review Shrinking Android app and ProGuard vs R8.

Answer 3

By 20+ dependencies you don't need any tooling and can do a manual check.

I would proceed like this:

1. Comment out all dependencies and check what fails (see below)
2. Uncomment the dependency that causes the failure
3. Repeat

This way you might also notice dependencies that are seldom used or can be replaced with standard libraries or other libraries that you use in the project.

Here are the things that will indicate you that a dependency is required (in the order of slowing down the feedback loop):

• compilation errors
• unit test errors
• integration / system / end-to-end / device test errors (whatever you use and call them)
• application functionality at runtime
• application performance at runtime

Runtime dependencies can be especially tricky. For example, your code might not depend on a library, but this library provides a runtime implementation for some other library you depend on. Removing such a dependency will only be visible at runtime as missing functionality or performance issues.

Answer 4

Instead of commenting out all dependencies I would go the other way around - comment out one dependency at a time and see what breaks. This way you would also get a grasp of use-cases of all dependencies because the IDE will point you to the place where code broke. If nothing breaks after commenting out a dependency you'll know that it's not used. Another thing you could potentially do is analyze an unobfuscated release .apk where all unused dependencies will be missing but package structure will be preserved.