How can I find transitive dependency that adds native library to my project?

Let me guess: 16KB page size requirement on Android? 😄

Correct

Some native libs must be recompiled with different settings to make them compatible with the 16KB requirement. It basically means you usually must update your dependencies to newer versions (provided that their authors have already released the 16KB-compatible versions of their libraries, which is not always the case). With the script I sent you earlier you can find out which Java/Kotlin libraries (e.g.

io.sentry:sentry-android-ndk

) contain those native

.so

libraries (in your case:

libopenjpeg.so

) that must be updated. If it's only a transitive dependency, you can still update it by adding an explicit dependency in your project. So, assuming there is a library like

com.example.something:library

that contains said

.so

file • use mvnrepository.com to find that library • find its latest version there • maybe check the release notes of that library to see if they mentioned fixing the compatibility • add an explicit dependency in your project, e.g.

implementation("com.example.something:library:<latest version>")

to see if that helps with 16KB compatibility • EDIT: but long-term, add a dependency constraint instead of the explicit dependency

If it's only a transitive dependency, you can still update it by adding an explicit dependency in your project.

You can but shouldn't. To update a transitive dependency, better use a dependency constraint. That way you update the version if the lib is still used transitively at all. Otherwise some day the dependency that uses it does no longer use it but you still ship it because you depend on it while not actually using it.

Yeah, @Vampire is correct. Adding it explicitly like I suggested can be a quick workaround just to see if that fixes your problem with 16KB compatibility. Long-term you should prefer adding a dependency constraint.

Is it really that quicker than adding a

constraints { ... }

around that line? 😄

Sorry, I'm biased. For people who are not very familiar with Gradle APIs (so, 95% of Android devs I know personally), adding a dependency is much easier than figuring out how to use the constrains for the first time.

Hey hey people

Based on my experience, constraints in Android apps are quite rare, so people usually don't know how to do it.

I'm not talking about how to manage dependencies now

@Eug I've already told you how to find it with the script above https://gist.github.com/azabost/3f8a33dca49a2b951bde0ba7d63499a0

Oke, let me try that non-gradle way of finding dependency. Maybe it is so obvious and I don't have many of these.

I don't know if there is any "Gradle way" of doing it, but I would love to know if there was. @Vampire any other ideas than inspecting the contents of JAR/AAR files in Gradle cache? 😅

Not really. But then, maybe there is some AGP way, Android builds are always "special". 😄 Where a dependency is coming from is trivial. But I'm not aware of a built-in way to find which dependency contains a given file. At least other than coding a task that iterates through the files in the

runtimeClasspath

configuration and looking inside to find which contains the file in question.

i did this via api analyzer in studio (to find culprit .so) then once you have the .so (which it seems like you have) I did

find ~/.gradle/caches -name "*.aar" | xargs grep -l "blah.so"

Yeah,

grep -l

should also work fine, unless you are very unlucky and find an accidental

blah.so

text content (instead of a file) somewhere 😄