I was drafting a blog-post, while it hit me… Discourse would be rather better platform for this topic.
Chhota Fennec (Li’l Fennec / छोटा फेनक) is a new experimental Mozilla project, being designed for participation (hence this category seemed most suited for posting this). The core agenda behind the project, is to make Firefox for Android slimmer, leaner and faster on lower end devices, primarily targeting Indian not-yet-web-native users.
There are several aspects of making Fennec more feasible for that target audience. Loweing the APK size, removing unnecessary features (and downloadable components on demand), server side compression (with care for privacy) etc. are the lower to higher hanging fruits to achieve the goal.
N.B: This post explicitly discusses my today’s trial of dismembering the APK & discovering which all parts contribute into the “download size” of Fennec & how.
I’m using apktool to unpack yesterday’s nightly (42.0a1 x86) build, on a *nix host system. There will be just enough information for anyone who wants to give this another try. I’m open to questions which dig deeper, but initially will not go into the technical details, and focus on summarizing my findings in layman’s terms - easy to be understood & communicated with.
Firefox for Android is built for 3 different platforms (binary compatibility). Each weighs around 45MiB in download size, and around 100-110MiB while expanded/installed.
For a regular person on 2G GPRS/EDGE (~300kbps working bandwidth) this is roughly a 20min download - IF Murphy doesn’t strike (but we all know, Murphy does strike - right?). Also, 100MiB free space on entry level Android phones are a considerable amount (even if available/allocable).
It may look like a far-fetched, blown-out-of-proportion argument to make Firefox for Android more popular, or a strawman fallacy from a personal perspective of who already has better/faster devices and internet (2G ought’a be just an edge case at best - because who doesn’t have 4G, right?), but this is a raging problem & primary reason for people to not opt for Firefox on their Android devices. Here’s a proof (notice any common theme?):
[root@debs fennec]# du -h --max-depth=1 62M ./smali # 62 MiB 364K ./original 664K ./lib 24K ./unknown 37M ./assets # 37 MiB 7.9M ./res # 8 MiB 107M . # Total Unpacked Size
These are the sizes of the directories inside the unpacked APK . Clearly we can focus on the
So, looking inside
/smali for things which count in MiB:
[root@debs fennec/smali]# du -h | grep [0-9]M # snipped 11M ./android/support # snipped 23M ./org/mozilla/gecko # snipped 23M ./com/google/android/gms # snipped 62M .
- I’m no pro at GMS (Google Mobile Services), but a hell lot of them (fitness, wearables, plus…), if not all, can be simply gotten rid of.
- Gecko is next in the line bulky stuff that’s included in the package. Discussed up next.
- A lot of content inside
supportare non-essential, and can be gotten rid of.
assets we basically have the XUL libs. It’s the thing that makes Firefox’s (and its addon’s) interface work (and the thing we’re trying to get rid of, for a while):
[root@debs assets]# du -h | sort -hr 9.2M omni.ja # 9 MiB of XUL/XBL/PNG overloads 26M x86/libxul.so # 26 MiB... oh noes! 1.1M x86/libnss3.so # snipped
res directory primarily has all the cool effects, animations, and the interface images, icons, logos of various sizes (for different resolutions) etc. I’m not getting further into this, but I hope it’s agreeable that we don’t need too much eye-candy for a lean browser.
More about Gecko
[root@debs smali/org/mozilla/gecko]# du -h --max-depth=1 | sort -hr 23M . 3.9M ./sync 2.2M ./home 1.5M ./widget 1.4M ./fxa 1.3M ./background 1.2M ./gfx 1.2M ./db 748K ./toolbar 576K ./webapp 552K ./tabs 516K ./preferences 304K ./util 268K ./overlays 256K ./prompts 236K ./menu 236K ./favicons 172K ./health 160K ./animation 136K ./mozglue 124K ./updater 112K ./tabqueue 112K ./distribution 84K ./tokenserver 84K ./browserid 80K ./mdns 76K ./javaaddons 64K ./sqlite 64K ./firstrun 56K ./lwt 28K ./trackingprotection 8.0K ./tiles
The amount of
background services we run (sync, telemetry, healthreport etc), others have made usable browser-clients of that size-factor. Clearly a lot of components can be safely removed without a regular user even noticing anything. All that’s required, is to be able to browse web-pages. Period.
OK, I’m lost now…
No, you’re not. Here’s an approximated summary of what all we do, and projected results:
Component Size (MiB) ~ removable % Saved (MiB) GMS 23 70% 16 Gecko 23 50% 12 Support 11 50% 5 Interface 10 50% 5 XUL Lib 26 100% 26 Eye candy 8 75% 6 Total 70
So with a ballpark estimation, we just saved 65MiB of expanded app size, which is about ~30MiB reduced from APK size as well (that is 65% of the initial 45MiB).
There are further possibilities of removing miscellaneous not-important-to-have components, like WebRTC, shumway and stuff like them. Combined, they’re 10MiB+ as well.
It doesn’t seem to be an unreachable goal to reduce 70% of the size of Firefox for Android to fit the purpose of feature-limited browsing experience. A sub-10MiB browser is likely to increase in popularity manifold in bandwidth deprived mass markets like India (and pretty sure, it’s not ONLY India, where this challenge is faced).
FWIW, there will be many volunteer developers as well, willing to contribute to make this happen. We simply need to design the project making it mutually beneficiary for both Mozilla and the contributors.