6 ms·

There is absolutely a ton of stuff broken with Android, no doubt about it, and I don't want to sound schoolmasterly but in this case it looks like a RTFM. From

by rsp1984 11y ago

There is absolutely a ton of stuff broken with Android, no doubt about it, and I don't want to sound schoolmasterly but in this case it looks like a RTFM. From the Android NDK docs [1]: You must specify an ABI for each CPU architecture you want your app to work with ... To build machine code for two or more distinct ABIs, using spaces as delimiters. For example: APP_ABI := armeabi armeabi-v7a This setting tells the NDK to build two versions of your machine code: one for each ABI listed on this line. Whereas the post says: To reduce our APK size and ensure that our App would run on all possible devices, we have flavors of our App for the x86, Armv7 and Arm architectures. Each flavor only contains the native libraries corresponding to its respective architecture There we have it. [1] http://developer.android.com/ndk/guides/abis.html http://developer.android.com/ndk/guides/abis.html

Aqueous 11y ago
Does anyone have data that shows the APK size actually hurts the downloads / purchases of an application? Regardless I think this was a mistake on the developers' part and could have been anticipated. First of all, it is important to have a smaller APK for users in developing economies and/or low incomes, but today's newer devices come with so much space that going to great lengths to reduce the APK size early on is a premature optimization, especially when we're talking about removing libraries that are required for proper running of the APK on every conceivable handset configuration. You should only ever reduce the APK by removing things that absolutely are not critical to run the same application package everywhere. So: First, ensure that your app runs for everyone. Then find ways to reduce the APK size without compromising that. And yes, I'm aware that Android / Google Play has added APK splitting, allowing platform-specific APKs to be distributed from the Play store. I actually would argue on balance this was probably a bad idea which presumes an iTunes-like single distribution channel.
- izacus 11y ago
  Yes, APK size is still critical. We still see a huge amount of people owning and running cheaper devices which have problems installing large apps. Your friends with 700EUR phones aren't really all of the market and there's still enough devices out there that will not successfully install a 30+MB APK. And that's not even talking about how wasting users storage for things he doesn't need (just because you're a bit lazy) is just... wrong.
  - deleted 11y ago
    [deleted]
  - Aqueous 11y ago
    Yes, I agree it is important and it is still also one of the last things you should think about. Certainly breaking the one-package-runs-everywhere by delivering different packages for different architectures in order to save disk space is one of the last things that should be considered. There are plenty of optimizations before this that you can make by compiling your native libraries differently, removing redundant information in resources, etc, before you should consider delivering architecture-specific APKs. And this is precisely because there are many back-channels for distributing APKs (back-channels which are also probably more commonly used in developing economies where those newer phones are unaffordable) in addition to the Play store.
gizmo686 11y ago
That documentation describes how to create a fat binary, it does not say that you are required to. In fact, it exlicitly states: When you build multiple machine-code versions, the build system copies the libraries to your application project path, and ultimately packages them into your APK, so creating a fat binary. A fat binary is larger than one containing only the machine code for a single system; the tradeoff is gaining wider compatibility, but at the expense of a larger APK. Furthermore, Google play explicitly allows you to offer multiple APKs, each targeting a specific device configuration [0], although there they do "encourage you to develop and publish a single APK that supports as many device configurations as possible". Having said all of this, none of it is relevent to the main problem discussed, which is that the installer failed to unpack the libraries. [0]http://developer.android.com/google/play/publishing/multiple-apks.html http://developer.android.com/google/play/publishing/multiple...
- rsp1984 11y ago
  I've been developing for Android since 2007 and doing NDK development since that was available and I've seen my fair share of library trouble. I've learned that when Google "encourages" you to do something it's code speak for "you better stick to this or we'll guarantee for nothing". As to why the installer failed to unpack the libraries, it's a bit suspicious that the article doesn't mention an investigation of the root cause nor called it a bug on Google's end. My hunch is that the root cause is somewhere in between making some un-documented moves in Android.mk and how the package generator picks up the libraries.
  - xiphirx 11y ago
    Hi, author here. If you take a look at the end of the article under the "Acknowledgements" there is a comment from the Chromium source code that describes what the issue was. We did file an issue on AOSP's issue tracker, but nothing was accomplished there...
- tadfisher 11y ago
  The PackageManager bug was worked around by Google Play, and was fixed in API 18 (JB MR2). As of today, this is only a problem if you distribute or support the unofficial distribution of ABI-specific packages outside of Google Play and you target API 17 or below. It's also worth noting that Chromium removed their workaround and are shipping a new native library loader purely to optimize for the fact that they are now the system WebView implementation, thus they need to reduce RAM usage when they are loaded by many running processes. https://chromium.googlesource.com/chromium/src/base/+/master/android/java/src/org/chromium/base/library_loader/Linker.java https://chromium.googlesource.com/chromium/src/base/+/master...
xiphirx 11y ago
Hi, author here. I forgot to mention in the article that we distributed an APK that contained all libraries for each architecture for a long time. The problem existed even though the APK had all libraries for all architectures. It was not until much later that we introduced flavors for each architecture. The reason we introduced flavors was to make our app work on the Asus ZenFone. It is an x86 device, however it tries to load ARMv7 libraries (even though x86 libraries are right there in the same installation) and attempts to utilize libhoudini to work, but it just ends up crashing on app start. Trust me, we've read the documentation surrounding this multiple times.

by rsp1984 11y ago

Aqueous 11y ago

Does anyone have data that shows the APK size actually hurts the downloads / purchases of an application? Regardless I think this was a mistake on the developers' part and could have been anticipated. First of all, it is important to have a smaller APK for users in developing economies and/or low incomes, but today's newer devices come with so much space that going to great lengths to reduce the APK size early on is a premature optimization, especially when we're talking about removing libraries that are required for proper running of the APK on every conceivable handset configuration. You should only ever reduce the APK by removing things that absolutely are not critical to run the same application package everywhere. So: First, ensure that your app runs for everyone. Then find ways to reduce the APK size without compromising that. And yes, I'm aware that Android / Google Play has added APK splitting, allowing platform-specific APKs to be distributed from the Play store. I actually would argue on balance this was probably a bad idea which presumes an iTunes-like single distribution channel.

izacus 11y ago
Yes, APK size is still critical. We still see a huge amount of people owning and running cheaper devices which have problems installing large apps. Your friends with 700EUR phones aren't really all of the market and there's still enough devices out there that will not successfully install a 30+MB APK. And that's not even talking about how wasting users storage for things he doesn't need (just because you're a bit lazy) is just... wrong.
- deleted 11y ago
  [deleted]
- Aqueous 11y ago
  Yes, I agree it is important and it is still also one of the last things you should think about. Certainly breaking the one-package-runs-everywhere by delivering different packages for different architectures in order to save disk space is one of the last things that should be considered. There are plenty of optimizations before this that you can make by compiling your native libraries differently, removing redundant information in resources, etc, before you should consider delivering architecture-specific APKs. And this is precisely because there are many back-channels for distributing APKs (back-channels which are also probably more commonly used in developing economies where those newer phones are unaffordable) in addition to the Play store.

gizmo686 11y ago

That documentation describes how to create a fat binary, it does not say that you are required to. In fact, it exlicitly states: When you build multiple machine-code versions, the build system copies the libraries to your application project path, and ultimately packages them into your APK, so creating a fat binary. A fat binary is larger than one containing only the machine code for a single system; the tradeoff is gaining wider compatibility, but at the expense of a larger APK. Furthermore, Google play explicitly allows you to offer multiple APKs, each targeting a specific device configuration [0], although there they do "encourage you to develop and publish a single APK that supports as many device configurations as possible". Having said all of this, none of it is relevent to the main problem discussed, which is that the installer failed to unpack the libraries. [0]http://developer.android.com/google/play/publishing/multiple-apks.html http://developer.android.com/google/play/publishing/multiple...

rsp1984 11y ago
I've been developing for Android since 2007 and doing NDK development since that was available and I've seen my fair share of library trouble. I've learned that when Google "encourages" you to do something it's code speak for "you better stick to this or we'll guarantee for nothing". As to why the installer failed to unpack the libraries, it's a bit suspicious that the article doesn't mention an investigation of the root cause nor called it a bug on Google's end. My hunch is that the root cause is somewhere in between making some un-documented moves in Android.mk and how the package generator picks up the libraries.
- xiphirx 11y ago
  Hi, author here. If you take a look at the end of the article under the "Acknowledgements" there is a comment from the Chromium source code that describes what the issue was. We did file an issue on AOSP's issue tracker, but nothing was accomplished there...
tadfisher 11y ago
The PackageManager bug was worked around by Google Play, and was fixed in API 18 (JB MR2). As of today, this is only a problem if you distribute or support the unofficial distribution of ABI-specific packages outside of Google Play and you target API 17 or below. It's also worth noting that Chromium removed their workaround and are shipping a new native library loader purely to optimize for the fact that they are now the system WebView implementation, thus they need to reduce RAM usage when they are loaded by many running processes. https://chromium.googlesource.com/chromium/src/base/+/master/android/java/src/org/chromium/base/library_loader/Linker.java https://chromium.googlesource.com/chromium/src/base/+/master...

xiphirx 11y ago

Hi, author here. I forgot to mention in the article that we distributed an APK that contained all libraries for each architecture for a long time. The problem existed even though the APK had all libraries for all architectures. It was not until much later that we introduced flavors for each architecture. The reason we introduced flavors was to make our app work on the Asus ZenFone. It is an x86 device, however it tries to load ARMv7 libraries (even though x86 libraries are right there in the same installation) and attempts to utilize libhoudini to work, but it just ends up crashing on app start. Trust me, we've read the documentation surrounding this multiple times.