Android NDK: создайте толстый двоичный файл с помощью BUILD_EXECUTABLE и armeabi-v7a-hard

Кратко: Как система Android NDK преобразует "APP_ABI: = armeabi-v7a-hard" в окончательные файлы .so, расположенные в "libs / armeabi-v7a"? Как правильно сделать то же самое в Android.mk? В настоящее время, чтобы создать автономный исполняемый файл и поместить его в папки, соответствующие различным ABI, я использую его, который выглядит некрасиво из-за жестко запрограммированного "ifeq ($ (TARGET_ARCH_ABI), armeabi-v7a-hard)":

LOCAL_PATH:= $(call my-dir)
include $(CLEAR_VARS)
SAVED_NDK_APP_DST_DIR := $(NDK_APP_DST_DIR)

ifeq ($(TARGET_ARCH_ABI),armeabi-v7a-hard)
    NDK_APP_DST_DIR := assets/armeabi-v7a
else
    NDK_APP_DST_DIR := assets/$(TARGET_ARCH_ABI)
endif

LOCAL_MODULE := run_pie
LOCAL_SRC_FILES := run_pie.c    
include $(BUILD_EXECUTABLE)
NDK_APP_DST_DIR := $(SAVED_NDK_APP_DST_DIR)

Длинный: в своем приложении для Android я использую набор автономных двоичных файлов. После сборки они сохраняются в ресурсах APK. При первом запуске приложения я копирую их в личную папку моего приложения, chmod 777, а затем использую их как системные утилиты, такие как «ls» или «cp». Я хочу создать «толстый двоичный файл»: один APK, в котором есть двоичные файлы для всех ABI, и выбрать правильный двоичный файл для текущего устройства после установки. Для библиотек .so Android делает все это автоматически. И "APP_ABI: = armeabi-v7a-hard" является внутренним для системы сборки NDK, это указано в документации, а окончательные файлы .so для "armeabi-v7a-hard" помещаются в папку "armeabi-v7a". Я могу сделать то же самое для своих двоичных файлов, и в настоящее время у меня есть способ, который работает, однако он выглядит некрасиво.

Как правильно размещать выходные двоичные файлы в пользовательских папках с именами ABI и обрабатывать преобразование «armeabi-v7a-hard» в «armeabi-v7a»?


android android-ndk android-build
person Playful Curiosity    schedule 08.01.2016    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Если вы заглянете в $NDK/build/core/setup-toolchain.mk, вы найдете там следующие строки:

# compute NDK_APP_DST_DIR as the destination directory for the generated files
NDK_APP_DST_DIR := $(NDK_APP_LIBS_OUT)/$(TARGET_ARCH_ABI)
# install armeabi-v7a-hard to lib/armeabi-v7a, unless under testing where env. var. _NDK_TESTING_ALL_
# is set to one of yes, all, all32, or all64
ifeq (,$(filter yes all all32 all64,$(_NDK_TESTING_ALL_)))
ifeq ($(TARGET_ARCH_ABI),armeabi-v7a-hard)
NDK_APP_DST_DIR := $(NDK_APP_LIBS_OUT)/armeabi-v7a
endif
endif

Итак, как видите, это тот же подход, что и в вашем Android.mk. Единственная разница в том, что вы не учитываете _NDK_TESTING_ALL_, который является внутренним для системы тестирования NDK. Так что просто продолжайте использовать свой Android.mk как есть и не беспокойтесь.

Другой подход - собрать ваши исполняемые файлы как обычно, но назовите их lib${TOOLNAME}.so. В этом случае они будут помещены в NDK_APP_DST_DIR по умолчанию, а также в настоящие библиотеки, и при установке на устройство диспетчер пакетов Android скопирует их в нужное место. Затем при первом запуске вы можете скопировать их из папки lib (а не из ресурсов, как вы это делаете сейчас) и переименовать соответствующим образом.

person Dmitry Moskalchuk    schedule 08.01.2016
comment
Большое спасибо, это именно то, что я искал. Я попытался найти это место в источниках NDK, но setup-toolchain.mk ускользнул от моего внимания. В настоящее время я также ищу пророческий способ найти ABI во время выполнения. Я знаю о Build.CPU_ABI, Build.CPU_ABI2 и System.getProperty("os.arch"), однако я хочу узнать, как это обрабатывается в исходных кодах установщика пакетов Android, почти найденного на данный момент. Но ваш вариант с lib${TOOLNAME}.so тоже интересен, спасибо еще раз. - person Playful Curiosity; 08.01.2016