Why do some Android phones cause our app to throw an java.lang.UnsatisfiedLinkError?
Solution 1:
EDIT: Since I got another crash report yesterday for one of my apps I dug a bit deeper into the matter and found a third very likely explanation for that problem:
Google Play Partial APK Update Goes Wrong
To be honest, I did not know about that feature. The APK file name suffix "-2.apk" made me suspicious. It is mentioned in the crash message of this question here and I could also find that suffix in the crash report of that customer of mine.
I believe the "-2.apk" hints at a partial update that probably delivers a smaller delta to Android devices. That delta apparently does not contain native libraries when they did not change since the previous version.
For whatever reason the System.loadLibrary function tries to look up the native library from the partial update (where it doesn't exist). It's both a flaw in Android and in Google Play.
Here is a very relevant bug report with an interesting discussion about similar observations: https://code.google.com/p/android/issues/detail?id=35962
It looks like Jelly Bean may be flawed in terms of native library installation and loading (both crash reports that came in were Jelly Bean devices).
If this is really the case I suspect that some forced change in the NDK library code may fix the problem, like changing some unused dummy variable for each release. However, that should be done in a way that the compiler preserves that variable without optimizing it away.
EDIT (12/19/13): The idea of changing the native library code for each build unfortunately does not work. I tried it with one of my apps and got an "unsatisfied link error" crash report from a customer who updated anyway.
Incomplete APK installation
That's unfortunately just out of my memory and I cannot find a link anymore. Last year I read a blog article about that unsatisfied link issue. The author said that this is a bug in the APK installation routine.
When copying native libraries to their target directory fails for whatever reason (device ran out of storage space, maybe also messed up directory write permissions...) the installer still returns "success", as if native libraries were just "optional extensions" to an app.
In this case the only workaround would be reinstalling the APK while making sure there's enough storage space for the app.
However, I cannot find any Android bug ticket nor the original blog article anymore and I searched for it for quite a bit. So this explanation may be in the realms of myths and legends.
"armeabi-v7a" directory takes precedence over "armeabi" directory
This bug ticket discussion hints at a "concurrency issue" with installed native libraries, see Android bug ticket #9089.
If there is an "armeabi-v7a" directory present with just a single native library, the whole directory for that architecture takes precedence over the "armeabi" directory.
If you try to load a library that is just present in "armeabi" you'll get an UnsatisfiedLinkException. That bug has been flagged as "works as intended" by the way.
Possible workaround
In either case: I found an interesting answer to a similar question here on SO. It all boils down to packaging all native libraries as raw resources to your APK and copy on first app start the correct ones for the current processor architecture to the (app private) file system. Use System.load with the full file paths to load these libraries.
However this workaround has a flaw: since the native libraries will reside as resources in the APK Google Play won't be able to find them and create device filters for the mandatory processor architectures anymore. It could be worked around by putting "dummy" native libraries into the lib folder for all target architectures.
Overall I do believe this issue should be properly communicated to Google. It seems as if both Jelly Bean and Google Play are flawed.
It usually helps to tell the customer with that problem to reinstall the app. This is unfortunately not a good solution if app data loss is a concern.
Solution 2:
I have the same trouble, and the UnsatisfiedLinkErrors comes on all versions of Android - over the past 6 months, for an app that currently has over 90000 active installs, I had:
Android 4.2 36 57.1%
Android 4.1 11 17.5%
Android 4.3 8 12.7%
Android 2.3.x 6 9.5%
Android 4.4 1 1.6%
Android 4.0.x 1 1.6%
and the users report that it usually happens just after the app update. This is for an app that gets around 200 - 500 new users per day.
I think I came up with a simpler work-around. I can find out where is the original apk of my app with this simple call:
String apkFileName = context.getApplicationInfo().sourceDir;
this returns something like "/data/app/com.example.pkgname-3.apk", the exact file name of my app's APK file. This file is a regular ZIP file and it is readable without root. Therefore, if I catch the java.lang.UnsatisfiedLinkError, I can extract and copy my native library, from the inside of .apk (zip) lib/armeabi-v7a folder (or whatever architecture I'm on), to any directory where I can read/write/execute, and load it with System.load(full_path).
Edit: It seems to work
Update July 1, 2014 since releasing a version of my product with the code similar to the listed below, on June 23, 2014, did not have any Unsatisfied Link Errors from my native library.
Here is the code I used:
public static void initNativeLib(Context context) {
try {
// Try loading our native lib, see if it works...
System.loadLibrary("MyNativeLibName");
} catch (UnsatisfiedLinkError er) {
ApplicationInfo appInfo = context.getApplicationInfo();
String libName = "libMyNativeLibName.so";
String destPath = context.getFilesDir().toString();
try {
String soName = destPath + File.separator + libName;
new File(soName).delete();
UnzipUtil.extractFile(appInfo.sourceDir, "lib/" + Build.CPU_ABI + "/" + libName, destPath);
System.load(soName);
} catch (IOException e) {
// extractFile to app files dir did not work. Not enough space? Try elsewhere...
destPath = context.getExternalCacheDir().toString();
// Note: location on external memory is not secure, everyone can read/write it...
// However we extract from a "secure" place (our apk) and instantly load it,
// on each start of the app, this should make it safer.
String soName = destPath + File.separator + libName;
new File(soName).delete(); // this copy could be old, or altered by an attack
try {
UnzipUtil.extractFile(appInfo.sourceDir, "lib/" + Build.CPU_ABI + "/" + libName, destPath);
System.load(soName);
} catch (IOException e2) {
Log.e(TAG "Exception in InstallInfo.init(): " + e);
e.printStackTrace();
}
}
}
}
Unfortunately, if a bad app update leaves an old version of the native library, or a copy somehow damaged, which we loaded with System.loadLibrary("MyNativeLibName"), there is no way to unload it. Upon finding out about such remnant defunct library lingering in the standard app native lib folder, e.g. by calling one of our native methods and finding out it's not there (UnsatisfiedLinkError again), we could store a preference to avoid calling the standard System.loadLibrary() altogether and relying on our own extraction and loading code upon next app startups.
For completeness, here is UnzipUtil class, that I copied and modified from this CodeJava UnzipUtility article:
import java.io.*;
import java.util.zip.ZipEntry;
import java.util.zip.ZipInputStream;
public class UnzipUtil {
/**
* Size of the buffer to read/write data
*/
private static final int BUFFER_SIZE = 4096;
/**
* Extracts a zip file specified by the zipFilePath to a directory specified by
* destDirectory (will be created if does not exists)
* @param zipFilePath
* @param destDirectory
* @throws java.io.IOException
*/
public static void unzip(String zipFilePath, String destDirectory) throws IOException {
File destDir = new File(destDirectory);
if (!destDir.exists()) {
destDir.mkdir();
}
ZipInputStream zipIn = new ZipInputStream(new FileInputStream(zipFilePath));
ZipEntry entry = zipIn.getNextEntry();
// iterates over entries in the zip file
while (entry != null) {
String filePath = destDirectory + File.separator + entry.getName();
if (!entry.isDirectory()) {
// if the entry is a file, extracts it
extractFile(zipIn, filePath);
} else {
// if the entry is a directory, make the directory
File dir = new File(filePath);
dir.mkdir();
}
zipIn.closeEntry();
entry = zipIn.getNextEntry();
}
zipIn.close();
}
/**
* Extracts a file from a zip to specified destination directory.
* The path of the file inside the zip is discarded, the file is
* copied directly to the destDirectory.
* @param zipFilePath - path and file name of a zip file
* @param inZipFilePath - path and file name inside the zip
* @param destDirectory - directory to which the file from zip should be extracted, the path part is discarded.
* @throws java.io.IOException
*/
public static void extractFile(String zipFilePath, String inZipFilePath, String destDirectory) throws IOException {
ZipInputStream zipIn = new ZipInputStream(new FileInputStream(zipFilePath));
ZipEntry entry = zipIn.getNextEntry();
// iterates over entries in the zip file
while (entry != null) {
if (!entry.isDirectory() && inZipFilePath.equals(entry.getName())) {
String filePath = entry.getName();
int separatorIndex = filePath.lastIndexOf(File.separator);
if (separatorIndex > -1)
filePath = filePath.substring(separatorIndex + 1, filePath.length());
filePath = destDirectory + File.separator + filePath;
extractFile(zipIn, filePath);
break;
}
zipIn.closeEntry();
entry = zipIn.getNextEntry();
}
zipIn.close();
}
/**
* Extracts a zip entry (file entry)
* @param zipIn
* @param filePath
* @throws java.io.IOException
*/
private static void extractFile(ZipInputStream zipIn, String filePath) throws IOException {
BufferedOutputStream bos = new BufferedOutputStream(new FileOutputStream(filePath));
byte[] bytesIn = new byte[BUFFER_SIZE];
int read = 0;
while ((read = zipIn.read(bytesIn)) != -1) {
bos.write(bytesIn, 0, read);
}
bos.close();
}
}
Greg