java.lang.UnsatisfiedLinkError workaround

If you ever worked with native shared libraries in Android you’ve probably already faced the “java.lang.UnsatisfiedLinkError” java exception which randomly seems to happen on certain devices ( actually it’s happening on xperia phones mostly, based on my reports ).
There are a bunch of bug reports in the android project like this: https://code.google.com/p/android/issues/detail?id=35962 or this https://code.google.com/p/android/issues/detail?id=64111.
The problem is that Google basically marked all of them as “resolved”, even if developers are still complaining about it.

The fun thing is that it seems that they are aware of the problem and in fact they’re trying to use a workaround internally in the chromium source code.
For instance, this is the first workaround I found:
https://codereview.chromium.org/180273005/patch/80001/90003

which is basically looking into the “/data/app-lib/{packagename}-1/” folder for the missing libraries.
And in fact, inside the comments of that file you can read this:

Native library directory in an updated package is a symbolic link
to a directory in /data/app-lib/, for example:
/data/data/com.android.chrome/lib -> /data/app-lib/com.android.chrome[-1].
When updating the application, the PackageManager create a new directory,
e.g., /data/app-lib/com.android.chrome-2, and remove the old symlink and
recreate one to the new directory. However, on some devices (e.g. Sony Xperia),
the old directory was deleted, but deleting the old symlink failed,
and that makes system loading library from the /system/lib directory.

Then I noticed another approach which is probably better: http://goo.gl/cbCAmC

which is basically doing what the PackageManager was supposed to do, unzip the shared libraries from the apk file to the “lib” dir of the application itself.

Btw, I’m gonna try both of them and verify if they actually work so I can finally stop seeing that annoying bug in the Google Play Console!

Share with...