what happened to the app size?

Starting with beta-05, APK size suddenly jumped from less than 8M to more than 36M, going beyond the size limit of my repo. Taking a look, number of libraries didn’t change, number of architectures was even reduced. What is causing the huge size increase – and can that be mitigated?

Looking inside the APK, libflorisboard-native.so for ARMv7 was around 115k with beta-04, becoming 15M+ (!!) with beta-05. If that cannot be reduced, may I ask for an ARMv7-only build to keep FlorisBoard betas available in my repo? Thanks in advance!

[patrickgold]

I experimented with reducing the APK size and #1082 showcases the first outcome: I fiddled around with the data feature filter, checked what Nuspell really needs from the ICU data and was able to cut down the per-arch size for ICU by about 5MB. This means the APK size is at about 26MB instead of 36MB, which is a huge leap forward.

After pushing the draft commits I then tried to extract the data into data archives (so I don’t need per-arch ICU data files), but for now this didn’t work out that well, will experiment more with it tomorrow, Should this also work, I can further cut down the APK size by a few MB while re-adding support for x86 and x86_64 (which I temporarily disabled to keep the current APK’s size smaller). I still have to do some testing if I didn’t remove too much ICU data, but the first tests on my devices are really promising that everything still works perfectly. Will update you tomorrow with further results.

[patrickgold]

I guess the option to ship spell checking separately does not exist (I’m thinking of the tons of language packages available for AnySoftKeyboard)?

AnySoftKeyboard’s language pack are the dictionaries which are added per pack, in FlorisBoard’s case the core functionality itself uses so much space (without any pre-shipped dictionaries at all). Also I try to have every privacy-friendly functionality in the core app to avoid an extension mess just to enable some features. I think the main issue is that hunspell/nuspell isn’t really designed for mobile devices but it is ported and storage isn’t an issue on desktop devices (Nuspell is very small but one of their dependencies - ICU - is a massive package).

Until you find a solution, don’t feel too much pressed with this. As indicated, I’m ready to make exceptions when they cannot be avoided as long as it’s reasonable. So better take the safe road than the fast one, please.

Will do but like I said I don’t like the fact that FlorisBoard exceeds the limit and the APK size issue has to be resolved anyways in the near future - so it is the first thing I am currently experimenting with so I can resolve the size issue.

How do “commercial” keyboards tackle this issue? Are they just enormous or do they simply do their spellchecking on some server? (Wouldn’t make much sense because they also work offline.)

Well GBoard AFAIK is based on the original AOSP keyboard (at least their App ID and their manifest indicate so), but has since then been heavily modified in both adding well implemented and performing features but also a lot of data collection. The dictionary problem is solved by just having full network access and downloading the dictionaries (but like I said this isn’t even the problem with the current APK size issue). Gboard I think uses the word lists in the dictionary files and user dictionary combined with some magic (machine learning maybe?) to make spell checking working (although the spell checker is sometimes a separate system app and thus not included in the Gboard APK size).