I’m working on a xamarin form project with target just android. I’ve tried to update the couchbase.lite pack to the latested one 3.1.1.
Everything works fine. But the apk size was increased. I’ve looked inside the apk files and I’ve seen that the Couchbase.Lite.Support.Android dll became about 50 MByte. The previous one 3.0.12 was about 6 MByte.
The client claims that the size of the apk is now too big to be drop to the app store. So, I’ve returned back the 3.0.12.
I’ve understood that starting from 3.1.0 a lot of dependencies were changed.
Is it correct to have the package size so high? Is there any trick that I need to adopt to get a smaller size?
Thanks for the kind collaboration,
Yes the package size has increased dramatically, but from what I have been assured this is not supposed to translate into an increased APK size. The reason for the increased size is the inclusion of native debug symbols inside of the package. These are supposed to be stripped out by the toolchain prior to creating the APK. The reason this happens is to facilitate better stack traces from crashes by having the debug symbols present, but not inside of the APK. Unfortunately I am not familiar enough with Android to know exactly when and how this happens but here is the feedback we received from an Android developer:
Regarding Android, IMHO shipping unstripped libraries should not be a problem, since the Android build process strips all native libraries, unless explicitly told not to.
Perhaps @gabriel could shed some light here?
I got an answer from Microsoft that says it looks like this stripping behavior is only on when AOT is enabled, so turning on AOT could possibly strip down the library size for you (although the caveat was “not necessarily for all libs”). Try adding
<AotAssemblies>True</AotAssemblies> to your project.
thanks for the replay. Last week acivating the linking the apk size was reduced. It was tricky due to other library dependencies, but finally it worked. Anyway, I’ll test your suggestion about the aot and also the proguard tool suggested by the ms post you have submitted today Does Android strip native debugging symbols? - Microsoft Q&A
I had no idea that the proguard tool knew anything at all about native libraries. If that works please let me know. In the meantime unfortunately I got word from Microsoft that the workaround I suggested will have no effect. They recommended a hack in the meantime to inject a post build target into msbuild that used the Xamarin Android bundled llvm-strip to strip the libraries prior to packaging but that comes with some weird side effects. If you want to give the technique a try though, it might work.
We have filed CBL-4868 (.NET) and CBL-4873 (Native Android) to track this problem. It is a regression in the 3.1 version. We intend to release v3.1 updates, shortly, in which the core library is stripped.