Android libsentry.so takes 209KB after compression: Can it be smaller?

[fzyzcjy]

Platform:

• [x] Android -> If yes, which Device API (and compileSdkVersion/targetSdkVersion/Build tools) version?
• [ ] Java -> If yes, which Java (and sourceCompatibility/targetCompatibility) version?
• [x] Kotlin -> If yes, which Kotlin (and jvmTarget) version?
• [x] NDK -> If yes, which NDK/CMake version?
• [ ] React-Native -> If yes, which version?
• [ ] Timber -> If yes, which version?
• [ ] Log4j2 -> If yes, which version?
• [ ] Logback -> If yes, which version?
• [ ] Spring -> If yes, which version?

IDE:

• [ ] Android Studio -> If yes, which version?
• [x] IntelliJ -> If yes, which version?
• [ ] Other -> If yes, which one?

Build system:

• [x] Gradle -> If yes, which version?
• [ ] Buck -> If yes, which version?
• [ ] Bazel -> If yes, which version?
• [ ] Maven -> If yes, which version?
• [ ] Other -> If yes, which one?

Android Gradle Plugin:

• [x] Yes -> If yes, which version?
• [ ] No

Sentry Android Gradle Plugin:

• [ ] Yes -> If yes, which version?
• [x] No

Proguard/R8:

• [x] Enabled
• [ ] Disabled

Platform installed with:

• [ ] JCenter
• [x] Bintray
• [ ] Maven Central
• [ ] Manually

The version of the SDK: latest

---

I have the following issue:

When looking at my output apk, I see libsentry.so takes 209KB after compression. Can it be smaller? Thank you!

Steps to reproduce:

• just compile it

Actual result:

• big

Expected result:

• small

[bruno-garcia]

You have the option of not tracking native crashes by installing sentry-android-core instead of sentry-android. That is because sentry-android brings in sentry-android-ndk which includes native libraries such as libsentry.so.

If that works for you, docs about how to do that are here: https://docs.sentry.io/platforms/android/using-ndk/#using-the-sdk-without-the-ndk

You wouldn't capture crashes from native libraries though.

/cc @getsentry/owners-native

[fzyzcjy]

@bruno-garcia I have some c++ code so I need to capture the native crashes :/ is there any ways to shrink it?

[marandaneto]

@fzyzcjy currently not, but you can pre-compile your own version of https://github.com/getsentry/sentry-native and remove features that are not used by your project.

[fzyzcjy]

@marandaneto Thank you.

[Swatinem]

its possible that some of the codesize comes from us vendoring a libunwindstack fork, which is heavy on c++, which is not known for small code size.

Anyhow, it is currently needed, otherwise you won’t have any stack traces. But we are looking into ways to improve that in the future.

[fzyzcjy]

@Swatinem Thank you as well.

[marandaneto]

@Swatinem can we transfer this issue to sentry-native since the Native bits live there? https://github.com/getsentry/sentry-native/tree/3436a29d839aa7437548be940ab62a85ca699635

[Swatinem]

Sure, though I doubt there is any actionable thing we can do about code size right now. Unless we drop our custom fork of libunwindstack and rely on the system library, which only exists on fairly recent Android versions.

[Swatinem]

Leaving this here as breadcrumbs:

https://android.googlesource.com/platform/system/unwinding/+/refs/heads/master/libunwindstack/AndroidVersions.md

libunwindstack was first introduced in API level 28.

Also, https://android.googlesource.com/platform/bionic/+/master/docs/status.md

New libc functions in T (API level 33): backtrace, backtrace_symbols, backtrace_symbols_fd ().

So once we raise our minimum supported API level to 28, we can drop our custom libunwindstack fork. Which should cut down the code size by quite a bit (though I never measured that; but I suspect it amounts to a large chunk). And probably using the system provided version might also yield better quality stack traces. 🎉

But alas, backwards compatibility prevents us from having nice things.

What we could probably do now is make mpack serialization an opt-out feature. Its only used actively with the crashpad backend, but it is part of the public API for reasons. Making it opt-out would mean we are still API compatible, but give people the opportunity to remove that probably unused chunk of code.

[Swatinem]

Another thing worth mentioning:

New libc functions in L (API level 21):

dl_iterate_phdr.

That would make it possible to get rid of our custom module finder, which has caused pain over and over again; and getting rid of that would also gain us some code-size wins.