Re:The Perils of Loading Native Libraries on Android
by tadfisher on Sunday November 08, 2015 @03:18PM
(#10529699)
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...
Re:The Perils of Loading Native Libraries on Android
by rsp1984 on Sunday November 08, 2015 @02:54PM
(#10529599)
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.
Re:The Perils of Loading Native Libraries on Android
by xiphirx on Sunday November 08, 2015 @11:24PM
(#10531384)
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...
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...