I have two applications with Couchbase Lite to store data locally.
The first is an “old” one with Couchbase Lite v3.0.5. When building the APK, I only get one .so file in each architecture folders : libLiteCoreJNI.so (about ~5-6 MB). My resulting APK size is about ~38 MB.
The second app is built with Couchbase Lite v3.1.0. When building the APK, I get two .so files in each architecture folders : liteLiteCoreJNI.so (same as v3.0.5) and libLiteCore.so (~47 MB). My resulting APK size grows to ~195 MB.
I tried to downgrade the second app to v3.0.5, and I get only one file in folders (resulting in APK size about the same as the first app).
I am not using .aab files. These apps are deployed from a MDM solution and the publishing doc from the MDM never mentions .aab files so I stick with APK files.
This increase in APK size is not described in the doc of Couchbase Lite Android 3.1.0. Are those additional .so files necessary ? (I’m wondering because v3.0.5 does not include them and the system still works).
I’m not looking for obfuscation/shrinking stuff. I don’t think this would have an impact on the size of .so files anyway because they would still be packaged, even with proguard rules in the app. And the majority of the APK size comes from those .so files.
In my situation, an APK between 25-50 MB seems reasonable, but I would prefer avoiding APKs around ~190 MB if that’s possible.
I was just wondering why this new file (libLiteCore.so) is present in 3.1.0 compared to 3.0.5. If the only way to reduce the size at download using 3.1.0 is to use an .aab file, then I will look into this with my MDM solution.
This is a problem even I just noticed. The app size which was previously around 110MB has shot up to 225MB (excluding User data & cache) after upgrading to 3.1.0. I think there is more that the couchbase lite library is doing in 3.1.0. It would be good if someone in the couchbase lite team can help us understand what’s happening behind the scenes.
Using AAB bundles would certainly optimize the size of the APK. However, even with this optimization, i think that the size would still be relatively larger compared to the 3.0.5 version.
The extra size coming in with 3.1.0 is the debug symbols being shipped compiled into the native libraries. From what I’ve been told, those are supposed to be stripped by the Android NDK when an application is made, unless that stripping is disabled. They are not needed for runtime functionality but very useful to have when a crash happens because there will be a lot of information about the crash. I can’t track down the source of that conversation since it happened almost 2 years ago, but does that sound like something that you can work with? If you are able to strip the library (using the stock NDK strip tool) then it will fall back down to the size you expect. That is supposed to happen automatically when building an Android application from what I understand.
It seems that debug symbols are not stripped automatically in this case. I’ve found an issue related to this matter: Link to Issue. If you have any configurations or suggestions for native library that could be helpful, I would appreciate it if you could share them.
In my opinion, it might be beneficial to explicitly configure the release configuration in the Couchbase Lite library’s build file.
Additionally, we have noticed an increase in the size of the Couchbase Lite database on disk. I’m curious to know if this issue might be related to the debug symbols situation as well.
In our specific case, we have noticed that the size of the Couchbase Lite database on disk is approximately 26% higher (115MB vs 145MB) compared to the 3.0.5 version. We were wondering if this increase in size could be attributed to the implementation of scopes and collections support. It’s worth mentioning that currently, we are not utilizing any features specific to scopes and collections. All our client-side data is stored in the default collection.
The link provided by @PShri about the strip issue works for me too. But for it to work, you need to have the NDK (Side by side) installed in SDK Tools of Android Studio. I did not have it before and I got a warning messages that I just noticed during build :
Unable to strip libraries, packaging them as they are (with .so files listed)
After installing the NDK and providing the associated version in the android config of the module’s gradle file, the resulting APK size drops to 32 MB.
I did not analyze the size of the database file in the app, but I’m using scopes/collections and just wanted to say that this feature is great !
I’'ll be thinking about how to properly apply this to my CI setup, but that’s another story .
@borrrden is correct: the extra size is the unstripped symbols. It is not a consequence of splitting the native library in two, JNI and LiteCore. I have configured the build so that the symbols are no longer stripped as part of the production of the library.
If you want to strip the symbols, you should be able to do so by including an NDK in your build, as described by @PShri .
Those symbols, on the other hand, are the only prayer we, the Couchbase team, have of analyzing an issue when it occurs. If you remove them, especially as an enterprise customer, we may not be able to help you.
.