CODEWITHSUNDEEP
androiddependenciesandroid-gradle-pluginlibrariesbuild.gradle
AADProgramming
AADProgramming

Reputation: 6345

Check if Library is used in Android app

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.

Now, I wanted to clean up unused Libraries/dependencies, by removing them from build.gradle

I searched on Google and came across this project for resource shrinking. But it seems to be used for removal of resources that are unused, at build time, in the packaged app and this also removes resources from libraries you are depending on if they are not actually needed by your application.

Also, I use ProGuard, for obfuscation and shrinking in conjunction with shrinkResources true in build.gradle

My intention is to remove unused Libraries/dependencies from build.gradle itself, without breaking app functionality.

Is there a way or tool which shows which library is safe to remove without breaking the app functionality?

Upvotes: 32

Views: 21201

Answers (4)

AhuraMazda
AhuraMazda

Reputation: 470

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.

Upvotes: 3

Tearo Dactyl
Tearo Dactyl

Reputation: 74

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.

Upvotes: 2

Wojciech Sadurski
Wojciech Sadurski

Reputation: 479

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.

Upvotes: 4

Andrey Vetlugin
Andrey Vetlugin

Reputation: 1074

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.

Upvotes: 6

Related Questions