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.
Foreword
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.
Basic Details
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?):
Weight Distribution
[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 /smali
, /assets
& /res
now.
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
support
are non-essential, and can be gotten rid of.
Similarly, inside 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
The 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.
Bottomline
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.