Apk size increased again

In App size increased by 6.5 MByte after upgrade to CBL 1.2.0, I complained about a massive increase of apk size when upgrading to CBL 1.2.0. I got promised that the size will be reduced.

So now I tried replacing 1.2.0 to 1.3.0, just to find out that the size again increased massively. For an app that previously had 5.8 MB, we are now at 8.9 MB.

This is not a theoretical issue. From my own experience with Android smartphones, I know that app size is a pain for many users. Those phones come with lots of non-removable Google bloatware, and after installing a few apps of the user’s choice, storage gets short. So a library that increases app size is a major obstacle for a developer to get his app accepted by users.

Before 1.2.0, we were below 2 MB. How should I explain my users an increase by a factor of 5, for the same functionality?

Really? It’s 2016! …

Here’s my idea for a future release: Split CBL into core, feature-x, functonality-z

compile 'com.couchbase.lite:couchbase-lite-android-core:1.3.0'
compile 'com.couchbase.lite:couchbase-lite-android-feature-x:1.3.0'

My personal choice is to have a faster CBL even if the size increases. I’d also prefer more features, like auto-compact even if the size increases

Not everyone uses the latest devices, and I don’t want to force people to do so.

I’m not opposed to speed improvement (who would be :wink: ) – but does this justify a size increase by a factor of 5?

As I’m probably affected by the “disk image is malformed” bug https://github.com/couchbase/couchbase-lite-android/issues/846 (if I understand it right, no one can be sure not to be affected), I’ll have to upgrade to 1.3.0, right?

I don’t know why the size increased so much and I get your point. If I may sum up:
Your point: smaller CBLite > performance, new features
My point: performance, new features > smaller CBLite

My solution to make both groups happy is to split CBLite into smaller libs (see above). But I don’t know if this is possible. It’d be great if the CBLite team weighs in!

Hi @tam5 and @benjamin_glatzeder,

Sorry for late reply.

Library size of CBL Android v1.3.0 increased because of containing SQLite library to support Android N. CBL used to use Android provided SQLite native library. However, from Android N, Android does not allow application to access most of native libraries.

As CBL Android contains all native libraries for all architectures, APK size could be large. However, Android installs only native libraries for targeted architecture.

Major reason of large library size is by containing ICU4C library which is used by the custom collator to support international languages. CBL Android used to call Java class from native library instead of using ICU4C, but it made indexing really slow. To reduce the library size, we are considering to release non-international version and international version. Non-international version does not contain ICU4C and it uses binary comparison for string.

Thanks!
Hideki

@tam5 You might consider complaining to Google that it’s unreasonable to prevent Android apps from using native system libraries like SQLite and ICU.

1 Like