Почему на некоторых телефонах Android наше приложение выдает ошибку java.lang.UnsatisfiedLinkError?

У меня та же проблема, и ошибка UnsatisfiedLinkErrors появляется во всех версиях Android — за последние 6 месяцев для приложения, которое в настоящее время имеет более 90000 активных установок, у меня было:

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%

и пользователи сообщают, что обычно это происходит сразу после обновления приложения. Это для приложения, которое получает от 200 до 500 новых пользователей в день.

Думаю, я придумал более простой обходной путь. Я могу узнать, где находится оригинальный apk моего приложения, с помощью этого простого вызова:

    String apkFileName = context.getApplicationInfo().sourceDir;

это возвращает что-то вроде «/data/app/com.example.pkgname-3.apk», точное имя файла APK-файла моего приложения. Этот файл является обычным ZIP-файлом и доступен для чтения без рута. Поэтому, если я поймаю java.lang.UnsatisfiedLinkError, я могу извлечь и скопировать свою родную библиотеку из папки .apk (zip) lib/armeabi-v7a (или любой другой архитектуры, на которой я работаю) в любой каталог, где Я могу читать/записывать/выполнять и загружать его с помощью System.load(full_path).

Изменить: кажется, работает

Обновление от 1 июля 2014 г. с момента выпуска версии моего продукта с кодом, аналогичным приведенному ниже, 23 июня 2014 г. не было ошибок неудовлетворенных ссылок из моей родной библиотеки.

Вот код, который я использовал:

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();
            }
        }
    }
}

К сожалению, если плохое обновление приложения оставляет старую версию родной библиотеки или каким-то образом поврежденную копию, которую мы загрузили с помощью System.loadLibrary("MyNativeLibName"), выгрузить ее невозможно. Узнав о такой остаточной несуществующей библиотеке, которая находится в стандартной папке родной библиотеки приложения, например. вызвав один из наших нативных методов и обнаружив, что его там нет (снова UnsatisfiedLinkError), мы могли бы сохранить предпочтение, чтобы вообще не вызывать стандартный System.loadLibrary() и полагаться на собственный код извлечения и загрузки при следующих запусках приложения.

Для полноты картины вот класс UnzipUtil, который я скопировал и изменил из этого статья CodeJava UnzipUtility:

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();
    }
}

Грег

РЕДАКТИРОВАТЬ: Поскольку вчера я получил еще один отчет о сбое для одного из моих приложений, я немного углубился в этот вопрос и нашел третье очень вероятное объяснение этой проблемы:

Не удалось обновить частичный APK Google Play

Честно говоря, я не знал об этой функции. Суффикс имени файла APK «-2.apk» вызвал у меня подозрения. Это упоминается в сообщении о сбое этого вопроса здесь, и я также мог найти этот суффикс в отчете о сбое этого моего клиента.

Я считаю, что «-2.apk» намекает на частичное обновление, которое, вероятно, обеспечивает меньшую дельту для устройств Android. Эта дельта, по-видимому, не содержит нативных библиотек, поскольку они не менялись с предыдущей версии.

По какой-то причине функция System.loadLibrary пытается найти собственную библиотеку из частичного обновления (где она не существует). Это недостаток как в Android, так и в Google Play.

Вот очень актуальный отчет об ошибке с интересным обсуждением подобных наблюдений: https://code.google.com/p/android/issues/detail?id=35962

Похоже, что Jelly Bean может иметь недостатки с точки зрения установки и загрузки собственной библиотеки (оба отчета о сбоях, которые пришли, были устройствами Jelly Bean).

Если это действительно так, я подозреваю, что некоторые принудительные изменения в коде библиотеки NDK могут решить проблему, например, изменение некоторых неиспользуемых фиктивных переменных для каждого выпуска. Однако это должно быть сделано таким образом, чтобы компилятор сохранил эту переменную, не оптимизируя ее.

EDIT (19.12.13): Идея изменения кода собственной библиотеки для каждой сборки, к сожалению, не работает. Я попробовал это с одним из своих приложений и получил отчет о сбое «неудовлетворенная ошибка ссылки» от клиента, который все равно обновился.

Неполная установка APK

К сожалению, это просто из моей памяти, и я больше не могу найти ссылку. В прошлом году я прочитал статью в блоге о проблеме с неудовлетворенными ссылками. Автор сказал, что это ошибка в процедуре установки APK.

Когда копирование собственных библиотек в их целевой каталог завершается сбоем по какой-либо причине (на устройстве закончилось место для хранения, возможно, также испорчены права на запись в каталог...), установщик по-прежнему возвращает «успех», как если бы собственные библиотеки были просто «дополнительными расширениями» для приложение.

В этом случае единственным обходным решением будет переустановка APK, убедившись, что для приложения достаточно места.

Тем не менее, я больше не могу найти ни сообщения об ошибках Android, ни исходную статью в блоге, и я искал ее довольно долго. Так что это объяснение может быть из области мифов и легенд.

Каталог "armeabi-v7a" имеет приоритет над каталогом "armeabi"

Это обсуждение заявки на ошибку намекает на "проблему параллелизма" с установленными собственными библиотеками, см. заявку об ошибке Android № 9089.

Если имеется каталог "armeabi-v7a" только с одной собственной библиотекой, весь каталог для этой архитектуры имеет приоритет над каталогом "armeabi".

Если вы попытаетесь загрузить библиотеку, которая только что присутствует в «armeabi», вы получите исключение UnsatisfiedLinkException. Кстати, эта ошибка была помечена как «работает, как задумано».

Возможный обходной путь

В любом случае: я нашел интересный ответ на аналогичный вопрос здесь, на SO. Все сводится к упаковке всех нативных библиотек в виде необработанных ресурсов в ваш APK и копированию при первом запуске приложения правильных библиотек для текущей архитектуры процессора в файловую систему (приватную). Используйте System.load с полными путями к файлам для загрузки этих библиотек.

Однако у этого обходного пути есть недостаток: поскольку собственные библиотеки будут находиться в качестве ресурсов в APK, Google Play больше не сможет их найти и создать фильтры устройств для обязательных архитектур процессоров. Это можно обойти, поместив «фиктивные» нативные библиотеки в папку lib для всех целевых архитектур.

В целом я считаю, что об этой проблеме следует должным образом сообщить в Google. Кажется, что и Jelly Bean, и Google Play имеют недостатки.

Обычно помогает предложить клиенту с этой проблемой переустановить приложение. К сожалению, это не очень хорошее решение, если вас беспокоит потеря данных приложения.

Android начал упаковывать свои библиотеки в /data/app-lib// где-то около Ice Cream Sandwich или Jellybean, я не могу вспомнить.

Вы создаете и распространяете как для «arm», так и для «armv7a»? Насколько я понимаю, вы построили только для одной из архитектур, а тестируете другую.

Если вы выпускаете только наборы приложений, эта проблема может быть связана с https://issuetracker.google.com/issues/127691101

Это происходит на некоторых устройствах LG или старых устройствах Samsung, где пользователь переместил приложение на SD-карту.

Один из способов решить эту проблему — использовать библиотеку Relinker для загрузки собственных библиотек вместо прямого вызова метода System.load. Это сработало для варианта использования моего приложения.

https://github.com/KeepSafe/ReLinker

Другой способ — заблокировать перемещение приложения на SD-карту.

Вы также можете оставить android.bundle.enableUncompressedNativeLibs=false в файле gradle.properties. Но это увеличит размер загружаемого приложения в Play Store, а также размер его диска.

После того, как я сам столкнулся с этой проблемой и провел небольшое исследование (также известное как гугление), я смог решить проблему, нацелившись на более низкий SDK.

У меня для compileSdkVersion было установлено значение 20 (что работало на 4.4)

а также

minSdkVersion 20 targetSdkVersion 20

Как только я изменил их на 18 (я был в состоянии сделать это без каких-либо серьезных последствий), я смог без проблем запустить приложение на Lollipop.

Надеюсь, это поможет - это сводило меня с ума в течение нескольких дней.