Multidex appears to be increasing the final build size.
My apps grow by around 3.5 MB when using the latest builds. In one example, from 18.5 MB to 22MB - see attachment.
3.5 MB may seem like a small amount, but I’ve worked hard to minimize my APK sizes in order to serve users in countries with slow / expensive data traffic. My rule of thumb is to stay below 20 MB.
Is there a way to disable Multidex? I don’t use many plugins, so it adds no value for me.
Cheers,
Per
Hi perflubron,
We currently don’t provide an option to disable Multidex. For now, you can revert to a Corona SDK build older than 2853.
You do present a good argument for having this option and providing it is certainly something we’re interested in.
As the size of core grows, these sorts of options become all the more important. It seems to go up and down in a bit of a cycle, fe: natural growth due to new features, then gets too big so parts are pulled out as plugins, shrinks again, but then necessitates multidex, so grows again, etc.
Cuz it’s not just about downsizing the literal “core”, just by shifting parts into plugins, if those plugins are so commonly used would just be added back anyway, but downsizing the whole bundle with plugins included.
Right now (2940) a “do nothing” Android build is sitting at about 6.7M, which seems about par for the cycle, but appears to increase nonlinearly from the way it used to as plugins are added, presumably due to multi-dex overhead? If so, then yes, a single-dex option for apps that don’t much use plugins would be great.
Another such option that I’d like, is to eliminate the widget theme images when not used:
[edit/PS. should the file android-support-multidex.version.txt be present in the apk? it’s of trivial size, but if it’s just gunk left over from the build…]
Thanks Ajay and Dave for response and discussion.
Just a note on the implications of reverting: It will make me need to type in all the info in the build screen, for each of my 30 apps: app name, package name, version name and code, keystore etc. Of course not a showstopper, but a nuisance.
Looking forward to progress on this or any other options for reducing files size.
Requested the ability to disable Multidex support, as it increases file sizes by over 3 MB. Read more here:
Voted! I’m in the same position as perflubron.
Voted as well
Hi perflubron,
We currently don’t provide an option to disable Multidex. For now, you can revert to a Corona SDK build older than 2853.
You do present a good argument for having this option and providing it is certainly something we’re interested in.
As the size of core grows, these sorts of options become all the more important. It seems to go up and down in a bit of a cycle, fe: natural growth due to new features, then gets too big so parts are pulled out as plugins, shrinks again, but then necessitates multidex, so grows again, etc.
Cuz it’s not just about downsizing the literal “core”, just by shifting parts into plugins, if those plugins are so commonly used would just be added back anyway, but downsizing the whole bundle with plugins included.
Right now (2940) a “do nothing” Android build is sitting at about 6.7M, which seems about par for the cycle, but appears to increase nonlinearly from the way it used to as plugins are added, presumably due to multi-dex overhead? If so, then yes, a single-dex option for apps that don’t much use plugins would be great.
Another such option that I’d like, is to eliminate the widget theme images when not used:
[edit/PS. should the file android-support-multidex.version.txt be present in the apk? it’s of trivial size, but if it’s just gunk left over from the build…]
Thanks Ajay and Dave for response and discussion.
Just a note on the implications of reverting: It will make me need to type in all the info in the build screen, for each of my 30 apps: app name, package name, version name and code, keystore etc. Of course not a showstopper, but a nuisance.
Looking forward to progress on this or any other options for reducing files size.
I wanted to bump this topic again.
Now that we’ve got the new admob plugin, gpgs and android dependency system, (and whatever else similarly related), and all of them fighting for multidex support, a formerly “simple little game” now spans 3 dex files, totalling 4.1M (in compressed .dex form, ~38M as extracted classes).
Given the more-or-less static binary lib size (which has been sitting at or around ~4.5M for a while now), and the app’s own more-or-less static assets (which also just happen to be right around 4.5M), I used to be able to build a ~12M apk (4.5M lib + 4.5M assets + 1.5M dex + 1.2M res + trivial misc). Present-day builds are about 14.7M.
The bulk of this appears to be gms (google mobile services) which is apparently sooo big in and of itself that it’s gotta be spread across two of those dex’s. (presumably hits the 64k limit) The android support library is another big contributor at ~7.1M extracted.
I realize that by including admob, com.google.android.gms.ads will be coming along for the ride too. And I realize that the never-ending clamour of your developer community for new features must lead to some bloat over time too.
But is all of this _ really _ necessary?
Requested the ability to disable Multidex support, as it increases file sizes by over 3 MB. Read more here:
Voted! I’m in the same position as perflubron.
just for reference, using build 3025,
a “do nothing” (no code, no assets) resulting apk ~= 6.8M
add ONLY the plugin.admob to build.settings, resulting apk ~= 10.3M
difference ~= 3.5M
This really isn’t a practical option for us. Many plugins are going to push the app over 65K symbols. As Dave pointed out, AdMob alone needs two DEX files.
For simulator builds it’s going to be very hard to make it optional. However Enterprise builds would have much greater control over that process.
Rob
Sorry, I’m not following you here … is all what really necessary? It’s true to say that if you add several third party libraries to your project the resulting APK grows bigger over time as said third party libraries grow. What’s the expected behavior?
Multi-dex is necessary to support the number of symbols in Google’s libraries which increases over time (as does the raw size of the libraries). It’s a complication we’d love to not be needed but that’s how APKs are built today.
For the record, a trivial app (no plugins, 476KB of assets) built with CoronaSDK 2830 (non-multi-dex) is 7.7MB while the same app built with CoronaSDK 3030 (multi-dex) is 7.5MB (the size difference is due to changes unrelated to multi-dex).
Hi Perry, thanks for replying.
My own testing found that an empty/do-nothing project produced a 6.8M apk.
By adding only a single plugin, admob, that same project produced a 10.3M apk.
A difference of roughly 3.5M
The majority of that 3.5M increase is attributable to all the various parts of gms, including large portions of it that don’t seem to have any obvious relevance to ad support. (it’s easy enough to unpack the dex’s and see what’s inside, and diff them between the two builds)
So the question really is: Is it truly necessary to include all of that 3.5M of gms just to get admob support?
IOW, is there a chance that more-than-is-necessary is being linked in?
The prior version of AdMob certainly did not add anywhere near this much overhead to a build.
Voted as well
re-checked again with build 3033, in case maybe I just had a ‘flawed’ daily. complete source:
main.lua:
--
config.lua:
application = {}
build.settings:
settings = { plugins = { ["plugin.admob"] = { publisherId = "com.coronalabs" } }, android = { usesPermissions = { "android.permission.INTERNET", "android.permission.ACCESS\_NETWORK\_STATE" } } }
nothing else.
resuling apk: 10,739,489 bytes, which seems excessive.
Is that just the way it’s gonna be, or is there perhaps something amiss? thx
This thread is now talking about two different things: 1. The increase in size for multi-dex and 2. The increase in size for the AdMob plugin. These probably should be separate threads, but it’s not, so I’m going to have two answers 
Multi-Dex.
I took Dave’s code above and built it with the legacy plugin and without the plugin using 2992, the latest public build and with 2851, the last daily build before we added Multi-dex support as well as a recent daily build (and the new AdMob plugin). Here are the results:
Build w/o AdMob w/ AdMob
2851 7.2mb 9.1mb
2992 7.1mb 8.7mb
3032 7.1mb 10.8mb
It’s clear that multi-dex did not add any overhead, if any we trimmed a touch.
Now for AdMob
It has grown 2.1mb from the legacy plugin and even less (1.7mb) pre-multi-dex. Google has added a lot of features to AdMob. It supports SDK-less mediation and video ads as well as a host of other new features. And they probably have added quite a few features to their support libraries as well. I don’t feel that a 2mb increase going from v4 of Google Play Services to v9 is that much given all of the additions/updates.
I don’t know if Google is providing us source (I doubt it) or compiled binary libraries (most likely). If we are using their binary libraries, our hands are tied. But even if we had source, if we started hacking out parts we didn’t think was needed, we would likely break things for a future update and who knows how much space we would really get back. It might be a minimal gain.
Rob