6 ms·

Support for 100MB APKs on Google Play

58 points by yla92 11y ago

cooper12 11y ago
> 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?
- Tepix 11y ago
  Whatever it is, iOS is also affected. I think the main cause is the addition of various screen resolutions which results in large graphics being needed in multiple variants. Then there's 32bit and 64bit code. But that is an issue that will hopefully be resolved soon.
  - iainmerrick 11y ago
    Apple at least are finally trying to address this, with their new "app slicing" feature. It's just surprising it's taken so long.
- creshal 11y ago
  > Is it all the frameworks and libraries we use? It's one part. The other is graphical assets: You have to provide them in half a dozen DPI versions (vector graphics are still hit or miss), with nowadays ridiculous densities (QHD on 5"? Oh come on). That's a lot of essentially wasted data.
  - salman89 11y ago
    Google Play supports splitting APKs on density. Its a little bit more work but can cut down the binary size if you have significant assets.
    - creshal 11y ago
      > Its a little bit more work That's probably the understatement of the day. The Play developer console is such a pain in the ass to work with that I'd rather not.
      - RyanZAG 11y ago
        Agreed, it's terrible. It's amazing there is no plugin for Gradle that does it all for you, including splitting the app for different dpi and arch. Is there a way and it just isn't publicized? AFAIK Google Play does have an API..
        bane 11y ago
        Well, they should just be doing it for you on the back-end. In fact, all you should have to do is upload an APK with all high-res assets and google should downsample them as appropriate for the downloading device. But they don't so...
        rugbydev 11y ago
        While a technical, low effort solution would be desirable, Google modifying a package after signing is not a desirable solution.
        bane 11y ago
        Well, your signing of the package would just be a signature to Google that it was indeed you who uploaded it. Google would then sign the new packages as themselves and the Play store could only download and install Google signed packages.
- yoklov 11y ago
  For games its mostly binaries (textures, models, sounds, etc). Dunno about anything else, but 100MB is not a lot of asset space these days, and 30MB is approaching game jam sizes.
- iainmerrick 11y ago
  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 11y ago
    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...
- mtgx 11y ago
  Well if your phone comes with a 1440p resolution, you should expect graphics to match that, too, which means much larger file sizes by default.
josephmx 11y ago
Am I missing something? Because I play this >531MB game without any issues: https://play.google.com/store/apps/details?id=com.kabam.swat&hl=en_GB https://play.google.com/store/apps/details?id=com.kabam.swat...
- cromantin 11y ago
  You can't download it over cellular network
- nathankleyn 11y ago
  I suspect it uses the Expansion Files [1] feature. [1]: https://developer.android.com/google/play/expansion-files.html https://developer.android.com/google/play/expansion-files.ht...
- runholm 11y ago
  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.
deleted 11y ago
[deleted]
iainmerrick 11y ago
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.
- parksy 11y ago
  Genuine question, what better solution is there on the market at the moment? I like the idea of binary deltas and expansions if handled well, and I imagine a service that makes it easy for developers to distribute in this way would be a goldmine.
  - iainmerrick 11y ago
    I wish I knew! I've used Google Play, iTunes Connect (i.e. the App Store), the Amazon Appstore, and the Humble Mobile Bundle. iTunes Connect is overall a bit nicer to work with (but often fails with completely incomprehensible errors, usually involving certificates and code signing). The new "app slicing" thing Apple are rolling out sounds very good. On the downside, it's a very closed system. Apple don't want you to script or automate anything, they want you to use their tools, of which some are slick and some are very rough. Amazon's store is similar to Google Play but much worse overall. Their web app is very clunky. Good: no APK size limit, so no expansion files needed! Bad: big APKs need to be uploaded via SFTP(!??). No clever binary deltas or anything as far as I can tell, just massive uploads and downloads for everyone. In the Humble Bundle, a lot of the work is done manually. That sounds bad but they've actually been a real pleasure to work with. It's great when you're doing a Humble release of an existing game; do a few code tweaks if necessary, upload to Dropbox and mail them a link + hash. I don't think they do anything fancy in their back-end, though (and they probably don't have enough engineering capacity to do so). I'd be interested to hear how Steam compares.
choward 11y ago
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.
chocks 11y ago
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 11y ago
  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 11y ago
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.
butz 11y ago
Just in time when Google Chrome app went over 50MB. Coincidence?

58 points by yla92 11y ago

> 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?

Tepix 11y ago
Whatever it is, iOS is also affected. I think the main cause is the addition of various screen resolutions which results in large graphics being needed in multiple variants. Then there's 32bit and 64bit code. But that is an issue that will hopefully be resolved soon.
- iainmerrick 11y ago
  Apple at least are finally trying to address this, with their new "app slicing" feature. It's just surprising it's taken so long.
creshal 11y ago
> Is it all the frameworks and libraries we use? It's one part. The other is graphical assets: You have to provide them in half a dozen DPI versions (vector graphics are still hit or miss), with nowadays ridiculous densities (QHD on 5"? Oh come on). That's a lot of essentially wasted data.
- salman89 11y ago
  Google Play supports splitting APKs on density. Its a little bit more work but can cut down the binary size if you have significant assets.
  - creshal 11y ago
    > Its a little bit more work That's probably the understatement of the day. The Play developer console is such a pain in the ass to work with that I'd rather not.
    - RyanZAG 11y ago
      Agreed, it's terrible. It's amazing there is no plugin for Gradle that does it all for you, including splitting the app for different dpi and arch. Is there a way and it just isn't publicized? AFAIK Google Play does have an API..
      - bane 11y ago
        Well, they should just be doing it for you on the back-end. In fact, all you should have to do is upload an APK with all high-res assets and google should downsample them as appropriate for the downloading device. But they don't so...
        rugbydev 11y ago
        While a technical, low effort solution would be desirable, Google modifying a package after signing is not a desirable solution.
        bane 11y ago
        Well, your signing of the package would just be a signature to Google that it was indeed you who uploaded it. Google would then sign the new packages as themselves and the Play store could only download and install Google signed packages.
yoklov 11y ago
For games its mostly binaries (textures, models, sounds, etc). Dunno about anything else, but 100MB is not a lot of asset space these days, and 30MB is approaching game jam sizes.
iainmerrick 11y ago
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 11y ago
  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...
mtgx 11y ago
Well if your phone comes with a 1440p resolution, you should expect graphics to match that, too, which means much larger file sizes by default.

josephmx 11y ago

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

cromantin 11y ago
You can't download it over cellular network
nathankleyn 11y ago
I suspect it uses the Expansion Files [1] feature. [1]: https://developer.android.com/google/play/expansion-files.html https://developer.android.com/google/play/expansion-files.ht...
runholm 11y ago
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.

deleted 11y ago

[deleted]

iainmerrick 11y ago

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.

parksy 11y ago
Genuine question, what better solution is there on the market at the moment? I like the idea of binary deltas and expansions if handled well, and I imagine a service that makes it easy for developers to distribute in this way would be a goldmine.
- iainmerrick 11y ago
  I wish I knew! I've used Google Play, iTunes Connect (i.e. the App Store), the Amazon Appstore, and the Humble Mobile Bundle. iTunes Connect is overall a bit nicer to work with (but often fails with completely incomprehensible errors, usually involving certificates and code signing). The new "app slicing" thing Apple are rolling out sounds very good. On the downside, it's a very closed system. Apple don't want you to script or automate anything, they want you to use their tools, of which some are slick and some are very rough. Amazon's store is similar to Google Play but much worse overall. Their web app is very clunky. Good: no APK size limit, so no expansion files needed! Bad: big APKs need to be uploaded via SFTP(!??). No clever binary deltas or anything as far as I can tell, just massive uploads and downloads for everyone. In the Humble Bundle, a lot of the work is done manually. That sounds bad but they've actually been a real pleasure to work with. It's great when you're doing a Humble release of an existing game; do a few code tweaks if necessary, upload to Dropbox and mail them a link + hash. I don't think they do anything fancy in their back-end, though (and they probably don't have enough engineering capacity to do so). I'd be interested to hear how Steam compares.

choward 11y ago

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.

chocks 11y ago

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 11y ago
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 11y ago

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.

butz 11y ago

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