
The Perils of Loading Native Libraries on Android - philippb
https://medium.com/keepsafe-engineering/the-perils-of-loading-native-libraries-on-android-befa49dce2db
======
rsp1984
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)

~~~
gizmo686
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...](http://developer.android.com/google/play/publishing/multiple-
apks.html)

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

------
ianlevesque
There are two Androids: the quirky but generally usable Android described in
Google's documentation and occasionally found on Nexus devices, and then the
Android actually found in the wild after manufacturers, carriers, 3rd party
app stores, users and general neglect have their way with it.

~~~
davtbaum
But it wasn't the fragmented Android that caused this bug...

The article acknowledges that the root cause was an existing bug in Package
Manager.

~~~
JohnTHaller
Security vulnerabilities and bugs happen regularly in every major operating
system. Windows, Mac OS X, Linux, iOS, Windows Mobile, Android, etc. Most of
the time these bugs are patched in a timely fashion due to the fact that the
publisher can release a bug fix directly to the end user's device. This
applies to everything except most Android devices.

When a major bug is discovered in Android, first, Google fixes it and
published the code. This is usually done quickly. Second, the phone
manufacturers take that fix and incorporate it into their own Android build
process with all their extra layers (HTC Sense, Samsung TouchWiz, etc). This
second step takes anywhere from a few weeks to infinity (aka it never
happens). Third, the carrier takes the manufacturers build and adds their own
cruft to it, maybe tests it, and then pushes it out to their customers as an
over the air (OTA) update. This third step takes anywhere from a month to
infinity (aka it never happens).

Due to the interference of manufacturers and carriers, I would not recommend
using Android on anything other than a Nexus device purchased directly from
Google or a retail/online store. Even a Nexus, when purchased from a carrier,
won't get updates as quickly as it should (speaking from experience with my
Nexus 6 and T-Mobile).

~~~
pjmlp
And even with Nexus, if the manufacturer steps out (TI) Google won't assume
its responsibility and provide the respective fixes.

As if they don't have the resources to do so.

~~~
JohnTHaller
When Texas Instruments exited, it's likely neither Google nor anyone else had
the proper legal agreements in place to force the release or licensing of the
appropriate code/patents to ensure continued updates. After this rather large
debacle which affected numerous manufacturers in the mobile industry, I'd
wager that's now part of all of them.

Don't forget that even without an exit, sometimes OEMs don't update drivers,
leaving manufacturers to drop support far earlier than they should in the
lifespan of a product. Case in point, the 2008 Apple Macbook. It only had
32-bit graphics drivers. So, that meant it couldn't run the 64-bit-only OS X
Mountain Lion released just 4 years later in 2012. I found this all out
firsthand supporting my girlfriend's problematic 2008 Macbook (which also had
notoriously bad connections to the LCD panel).

------
js2
We've seem the same problem at Yahoo:

[https://github.com/yahoo/ygloo-
ymagine/blob/master/src/com/y...](https://github.com/yahoo/ygloo-
ymagine/blob/master/src/com/yahoo/mobile/client/android/ymagine/LibraryLoader.java)

Here's another fun Android / PackageManager behavior - Android doesn't kill an
app before upgrading it (unlike on iOS). You may think this is a feature,
except that after the upgrade the PackageManager is now out-of-sync with the
running code. So for example, say v1 of the code is still running after an
upgrade to v2, and the code calls getPackageInfo() in order to find out say,
its versionCode. The running code will erroneously think it's v2.

~~~
Natanael_L
Should you try to detect an initiated install and close?

------
breatheoften
Is the problem discussed in this article something that has to be worried
about still? This is hideous ... By my understanding the only way the solution
discussed in the article can work is by including the native libraries for
every architecture inside the apk which seems like it will make the app larger
than it needs to be ...

I think I'd rather just detect the issue and throw up an error telling the
user that they've managed to install an apk built for the wrong architecture
and need to install a different apk ...

~~~
gizmo686
If you are distributing through Google Play (or, I assume, most 3rd party app
stores), then you can provide a different apk depending on the target
architecture. The problem they were running into (after they worked around the
installation bug) was that some users would sideload their APK, but sideload
the wrong version.

As far as I can tell, their ReLinker solution is only a workaround to the
installation problem.

~~~
whoopdedo
If you're clever enough to sideload are you not clever enough to recognize and
remedy the problem? Developers should not be enabling people who aren't able
to handle that responsibility.

Actually, now that I think of it, I can see a business requiring employee
devices to be flashed with a set of apps but not wanting to put the effort to
actually check that it'll work. In that case the developer should determine if
the user is an individual or a company and in the later case sell them a
contract for support.

~~~
fulafel
Many people choose to not link their device to a Google account, so cannot
access Google Play. Others use devices that haven't licensed Google Play.
Widely used apps are frequently available officially as apk downloads (eg
WhatsApp), or other more inclusive app stores (eg f-droid), others you have to
get from unofficial sources.

~~~
mkesper
F-droid hides versions with wrong architecture.

------
ignoramous
Fire OS fixed this bug in the Package Manager. Amazon treats both, the buyers
and the developers, as its customers. Has a nice process in place to test top
10k+ apps on each upgrade and identify and try and fix issues arising due to
AOSP.

Google needs to start doing the same thing or something similar. I have seen a
fair share of broken stuff. Something even as basic as a ListView was
horrendously let loose in a middle of a refactor between JB and L.

------
jheriko
surely the perils of users using shoddy app stores and installers rather than
developers using native libraries.

kudos to the devs for making the effort to workaround the issues though, its
quite a heroic effort imo.

~~~
ianlevesque
For another heroic effort read: [https://www.facebook.com/notes/facebook-
engineering/under-th...](https://www.facebook.com/notes/facebook-
engineering/under-the-hood-dalvik-patch-for-facebook-for-
android/10151345597798920)

------
voltagex_
I wonder if there's an Android bug report for the first part. And I wonder if
Google cares.

------
modeless
> users may have installed our app from other sources than the Play Store

Is this a euphemism for piracy? Where are these users getting the app?

~~~
ikeboy
The app
[https://play.google.com/store/apps/details?id=com.kii.safe](https://play.google.com/store/apps/details?id=com.kii.safe)
is free, so no. Some users might not want google to know they're using a
particular app (this one a is a security one, so probably a higher proportion
of users would care). There are over 10 million users from the play store, so
100,000 is not that high for sideloaders.

Plus, google might block downloads in some countries.

There are a number of sites that offer apk downloads for free apps: see
[http://apkpure.com/](http://apkpure.com/), [https://apps.evozi.com/apk-
downloader/](https://apps.evozi.com/apk-downloader/), or [http://apk-
dl.com/](http://apk-dl.com/). See also [http://www.makeuseof.com/tag/download-
apk-google-play-bypass...](http://www.makeuseof.com/tag/download-apk-google-
play-bypass-restrictions/) for more reasons people might not want to use
Google Play.

