Насколько я знаю, когда System.loadLibrary не может найти библиотеку(а он её найти не может), он кидает исключение UnsatisfiedLinkError. Попробуй исходить из этого. Может достаточно и правда обернуть в трайкетч и всё запустится.

До запуска дело не доходит, приложение не устанавливается. Ошибку на этом этапе выдаёт.

Там на этапе установки APK видимо возникает INSTALL_FAILED_NO_MATCHING_ABIS или нечто подобное.

Можно как-то сделать, чтобы он хотя бы ставился, понятно, что те классы, которые грузили ту библиотеку, работать не будут, мне и не надо, пусть кидают исключения. Версии этой библиотеки для x86 естественно нет.

Попробовать добавить фейковую либу-заглушку и под x86? Или как вариант посмотреть в сторону трансляторов ARM => x86, вроде как были подобные проекты…

Напиши стабы. Ну просто пустой so подкинь.

Выкинет другую ошибку, которую вроде ТОЖЕ можно словить. :)

Как всё сложно-то. Я надеялся на какой-нибудь ignoreMissingLibraries=«true» :) Ладно, попробуем, спасибо.

Версии этой библиотеки для x86 естественно нет.

Сделай. Скорее всего, это даже реально.

Каким образом? Это либы из SDK от китайцев. Там даже исходников нет.

Там даже исходников нет.

plasma^W opera не падает

Ну так стабовую SO можно собрать фактически из /dev/null. :)

Костыли-и-и!

А как её собрать? Честно говоря никогда не собирал ничего нативного под андроид. Если я поставлю в виртуалку x86 дебиан и в нём соберу пустую .so, оно подойдёт, или под андроидом особые .so?

Спасибо, оставим на крайний случай.

Помогло заклинание в app/build.gradle:

android {
    ...
    splits {
        abi {
            enable true
            reset()
            include 'x86', 'armeabi-v7a'
        }
    }
}

После него всё установилось, вызов API кидает UnsatisfiedLinkError который можно ловить и обрабатывать.

Тоже интересный выход. Ты просто собрал джва APK с разными lib. Ну и соответственно ставя x86 версию, Android не ругается при несоответствии либ с ARMv7 версией, так как их тоже не находит. :)

Под андроидом частично особые *.so: по умолчанию ищут другой линкер. Если у тебя Android.mk, то достаточно проверить на архитектуру и подсунуть вместо пребилденной китайской библиотеки, пустой сишный файл. Главное обмануть установщик андроида. :)

Прочёл комменты.

Весело и здорово.

Но не проще ли в эмулятор присунуть образ для armчего-то-там, как правило это «armv7-a», т.к. остальные варианты типа aarch64 (v8a) пока сравнительно редки и не париться?

Да, в принципе скорость эмулятора тут будет ниже чем при использовании архитектуры x86, но по крайней мере хоть отлаживаться можно будет в более-менее нативном EABI, что зачастую немаловажно.

Откройте android-sdk-update-manager или в AndroidStudio->Sdk Manager, посмотрите для Вашего случая какой там у Вас API Lvl предполагается (пусть, например, будет 7.0, Nougat) и поставьте Google APIs ARM EABI v7a System Image в случае, если у Вас ARMv7-a на устройстве предполагается или какой там нужен будет (по своей задаче). В этом имидже есть гуглёвые АПИ, которые потенциально могут понадобиться софтине для работы. Дальше в эмуляторе создаёте соответствующую avd с данным образом и туда свободно и ненапряжно ставите софт для данной архитектуры.

Так очень удобно знакомиться со всякой malware, например...

Когда я последний раз пробовал ARM-овский эмулятор, скорость там была не просто ниже, она вообще была практически неюзабельна. Не думаю, что это удобно для отладки.

Иногда только так, к сожалению.

Насчёт скорости соглашусь целиком и полностью. К сожалению да, оно работает довольно медленно. На «родном» гуглёвом эмуляторе. На genymotion всё слегка побыстрее, но там и эмулятор несколько другой, на основе virtualbox, а не qemu.

Но иногда, если та же малварь живёт только под ARM и больше не под чем, то чтобы посмотреть на её работу, приходится использовать вариант avd на этом эмуле. В особенности, если малварь что-то сама подкачивает. Либо ставить genymotion.