3 ms·

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

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...
- ianlevesque 11y ago
  Much of what you describe is technically possible but poorly supported by the platform.
- cuu508 11y ago
  > 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.
toast0 11y ago
Localized strings are not compressed in a standard apk; if you have a decent number of strings and support many languages, that takes up a lot of space. Doing the work to split packages up into different architectures helps a lot (if you use a bunch of native code), but then you have to deal with the fallout of people downloading from google play for their device, and then posting the slim binary on the web that other people with different devices are going to download and install to incompatible phones.
- iainmerrick 11y ago
  Ha! If anything that sounds like a good way to irritate the pirates. Though I'm sure it adds a lot of support headaches, yeah.
  - toast0 11y ago
    My company's app is a free install, and we have a fat binary to download on our website... but people still post and use the slim binaries elsewhere. Would be amusing if it were pirates though :)

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

ianlevesque 11y ago
Much of what you describe is technically possible but poorly supported by the platform.
cuu508 11y ago
> 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.

toast0 11y ago

Localized strings are not compressed in a standard apk; if you have a decent number of strings and support many languages, that takes up a lot of space. Doing the work to split packages up into different architectures helps a lot (if you use a bunch of native code), but then you have to deal with the fallout of people downloading from google play for their device, and then posting the slim binary on the web that other people with different devices are going to download and install to incompatible phones.

iainmerrick 11y ago
Ha! If anything that sounds like a good way to irritate the pirates. Though I'm sure it adds a lot of support headaches, yeah.
- toast0 11y ago
  My company's app is a free install, and we have a fat binary to download on our website... but people still post and use the slim binaries elsewhere. Would be amusing if it were pirates though :)