
Support for 100MB APKs on Google Play - yla92
http://android-developers.blogspot.com/2015/09/support-for-100mb-apks-on-google-play.html
======
iainmerrick
Too little, too late.

Google Play makes you jump through a bunch of hoops to ship an oversized APK,
and the tools they provide are totally inadequate. (For example, see this
years-old bug affecting expansion files:
[https://code.google.com/p/android/issues/detail?id=61344](https://code.google.com/p/android/issues/detail?id=61344))

Raising the basic size limit to 100MB doesn't fix any of the underlying
problems. In fact it may make things slightly worse for users, because some
developers who would otherwise have been forced to ship variant APKs or an
expansion file (more work for the developers, but easier to download for
users) will now just ship a single bloated APK instead.

When you get an app update, why do you still have to download the whole thing?
Why not a binary delta? For that matter, why can't the _developer_ upload a
binary delta to the store? The Play Store holds golden copies of each version
of the APK, after all. Instead, we have the clunky expansion file system, and
each developer has to do the work.

When shipping variant APKs to different phone sizes / architectures / etc, why
does the developer have to build and upload each APK separately? Why can't the
Play Store just do the "app slicing" automatically? In most cases it already
has all the information it needs.

I realise that all this stuff is hard work, and my complaints really boil down
to "Google should do all that hard work for me". But they have thousands of
engineers working on Android and Google Play, so I don't think it's too
unreasonable.

~~~
xd1936
Google Play has been doing delta updates since 2012.

[http://www.androidcentral.com/what-are-delta-updates-and-
why...](http://www.androidcentral.com/what-are-delta-updates-and-why-youll-
forget-about-it-tomorrow)

~~~
iainmerrick
Is there an up-to-date official doc or blog post about that? I haven't been
able to find one.

It seems like in practice expansion files never use deltas, and (as far as I
can tell) APKs generally don't either. I could be wrong about the APKs, or
maybe my updates are always big because I'm using native code.

[Edit to add: my paranoid theory is that they pre-announced this, but then
never properly shipped it. But I'd love to be proven wrong!]

[Edit edit: OK, it sounds like APKs already get deltas and it all just works
invisibly. But I don't think expansion files get deltas.]

~~~
fredrik-j
Expansion files do support a so called patch version[0] - which may sound like
a delta but it isn't. The job of creating a patch and merging it with the main
expansion file is placed on the app developer. Additionally there can only be
one patch to each main extension file. There is not a new delta generated for
each new version of the expansion file.

I'm not at all surprised if most developers just ignores the patch option all
together and just re-uploads a new main expansion file every time any content
has changed.

Besides, while seemingly well documented[0], IME expansion files requires
quite a lot of undocumented magic. Including patching Google's own source
code. Code that they recommend that you vendor into the app rather than
include as a library.

Further the user experience is less than stellar. On many devices the
expansion is only downloaded after the app is started the first time. So the
app needs to work even while the file is missing, and at that time manually
request that the system retrieves the file.

BTW, did anyone notice the fine print of this announcement? Only devices with
Android 4.0 or newer supports 100 MB apk:s. If your app supports 2.3 - i.e.
some 70 million Android users - you're stuck at 50 MB and will have to keep
using expansion files to serve those users.

[0] [https://developer.android.com/google/play/expansion-
files.ht...](https://developer.android.com/google/play/expansion-files.html)

------
cooper12
> Even though you can make your app bigger, it doesn’t always mean you should.

I'm glad they included and expanded on this point. I used to be stuck on a
gingerbread device that wouldn't let me install anything larger than a
megabyte due to storage issues. I was always grateful to devs who kept their
APK sizes in the kilobytes. Now I have a Nexus 5 and install 30MB+ APK's
without hesitation because that seems to be the status quo. Does anyone know
why most apps these days are so bloated in size? Is it all the frameworks and
libraries we use?

~~~
iainmerrick
For apps that use native code, you typically ship a "fat binary" with ARMv5,
ARMv7 and x86 binaries. Maybe even ARM64 and x64 for the adventurous. Also the
set of stable native APIs on Android is pretty small, so you typically include
lots of frameworks and libraries directly into your APK, yeah.

It seems like apps written in Java have less of an excuse -- no fat binary
needed and the system APIs are much richer. But maybe people tend to use a lot
of frameworks there too.

Also, graphics can take up a surprising amount of space in normal apps, not
just games, if you ship variants for all the different screen sizes. On iOS,
for example, you include a startup image for each screen size / orientation.
That could be a dozen or so full-screen images! And screens are massive these
days.

Modern "flat" UI images ought to compress much better, though...

Overall, I don't think it's _just_ bloat, there is some justification. But I
bet most apps could fairly easily be made significantly smaller.

~~~
userbinator
_For apps that use native code, you typically ship a "fat binary" with ARMv5,
ARMv7 and x86 binaries. Maybe even ARM64 and x64 for the adventurous._

It's not as if one of the major use-cases is to copy APKs between devices with
different architectures and have them work easily, and I'm pretty sure it
should be possible to implement something that detects which one the device is
_before_ downloading, so how did this situation occur?

 _On iOS, for example, you include a startup image for each screen size /
orientation. That could be a dozen or so full-screen images!_

Unless the images are truly very different (and I don't see why they would
be), isn't it possible to just include the highest resolution images and
resize if necessary?

 _Modern "flat" UI images ought to compress much better, though..._

If anything, "flat" UI means there shouldn't be a need to store much in the
way of imagery - they can be procedurally generated very compactly in the code
itself, or stored in some sort of vector format (even better) - but then
again, I've seen people use huge _solid colour_ bitmap images for UI elements
in other (desktop) apps.

Libraries/frameworks are slightly more tricky but once again, there already is
a solution: identify them as dependencies by something like a hash, and don't
download if they already exist. You may end up with multiple versions of the
same "module", but at least you won't get multiple copies of the exact same
one.

I'm really astounded that such wasteful practices are prevalant in the mobile
device world, where bandwidth and storage are far more constrained than for
desktops. It's almost as if they deliberately chose the most bloated way to do
everything...

~~~
cuu508
> I'm pretty sure it should be possible to implement something that detects
> which one the device is before downloading, so how did this situation occur?

If you only have 2 architectures, and .so files in tens of kilobytes, it's
just more convenient than building and uploading multiple APKs. When you have
3+ architectures, and 7MB javascript runtimes for each, it indeed feels
ridiculous. Looking at you Titanium, NativeScript and now React Native.

> Unless the images are truly very different (and I don't see why they would
> be), isn't it possible to just include the highest resolution images and
> resize if necessary?

Good icons can be quite different in different sizes: in smaller sizes you
remove details, adjust line thickness etc.

Another, now historic reason is that early Android devices were underpowered
and loading correct size graphic vs loading-and-resizing was important for
performance.

------
chocks
Just curious how does large apps like Microsoft Word for Android gets
packaged? The size on Play Store is 105 MB, and in App Info, it shows: Total -
152 MB, Application - 66.92 MB. Is there a way to look at APK sizes on these
apps?

~~~
dogma1138
Most "AAA" wanna be 3D games these days they download a bunch of files. But
word isn't actually big enough on small screen mobile devices to need that.
Office 2016 is 2GB on the PC for it's full installation, if you don't install
the fonts, templates, themes help and quite a bit of other nonsense you can
cut it by almost half. On small screen devices Microsoft is shipping the
office suit in individual APK's so they are probably still fine within the
50/100MB limit per size considering it's a much cut down version of office.

------
andmarios
So, how many apps can now fit on a (rumored) 16GB Google Nexus 5X taking into
account that:

1\. APKs will expand when installed (dalvik-cache directory)

2\. APKs need to store user data and cache data (think Google Play Services,
Chrome)

3\. Google's “ecosystem” takes up more than 1.5GB from user-space (services,
chrome, maps, google app, gmail, docs, slides, sheets, photos, drive,
hangouts, street view, tts-engine, youtube, music, calendar, games, webview,
play store etc)

4\. User will want to store a few photos and videos on his phone and maybe
have some offline music.

------
choward
I find it funny that they are rumored to be releasing the Nexus 5X today with
only 32GB of memory and no SD card slot.

------
josephmx
Am I missing something? Because I play this >531MB game without any issues:
[https://play.google.com/store/apps/details?id=com.kabam.swat...](https://play.google.com/store/apps/details?id=com.kabam.swat&hl=en_GB)

~~~
runholm
Several apps download a large amount of additional data to the phone after
installation, typically large blobs like audio, video and textures. The limit
on APKs only affected the part of the application that was shipped through the
Play store.

------
butz
Just in time when Google Chrome app went over 50MB. Coincidence?

