Android NDK — принудительная перестройка библиотеки при изменении конфигурации

Сборка NDK всегда обновляет библиотеки .so в lib/armeabi. С другой стороны, каталог obj содержит отдельные деревья для отладочных и выпускных сборок для каждого модуля.

К сожалению, эту настройку довольно легко испортить, если ваш Android.mk делает что-то, что не поддерживается tge framework.

Например, в вашем случае длинные восходящие пути к файлам cpp (../../../..) могут быть плохой идеей. Я бы посоветовал установить LOCAL_PATH для каждого модуля и избегать ../ в LOCAL_SRC_FILES.

Вот мое предлагаемое изменение для Android.mk:

ANDROID_MK_PATH := $(call my-dir)
LOCAL_PATH := $(ANDROID_MK_PATH)/../../../engine/code/main

include $(CLEAR_VARS)

LOCAL_MODULE := game$(MY_BUILD_CONFIG_EXTENSION)
LOCAL_SRC_FILES :=  mainandroid.cpp
LOCAL_STATIC_LIBRARIES := libDebug$(MY_BUILD_CONFIG_EXTENSION) libCore$(MY_BUILD_CONFIG_EXTENSION)

include $(BUILD_SHARED_LIBRARY)

##################################################################
## In addition to the core game library, we also build another
## *.so file here: "libBootInfo". This very small library is used
## by Java to find out which version of game to load based on
## the current build configuration.
##

include $(CLEAR_VARS)

LOCAL_MODULE := libBootInfo
LOCAL_SRC_FILES := bootinfo.cpp

include $(BUILD_SHARED_LIBRARY)

$(call import-module,libBdCore)
$(call import-module,libDebug)

ОБНОВЛЕНИЕ: На самом деле, использование суффикса имени модуля для разделения конфигураций сборки, на мой взгляд, является лучшим решением. Такой подход позволяет создавать и развертывать несколько конфигураций одновременно. Например, я использую его, когда мне нужно оптимизировать библиотеку либо под Tegra (без Neon), либо под Snapdragon (с Neon): до недавнего времени разместить в Play Store два отдельных APK было непросто, поэтому я упаковывал оба libv-neon.so и libv-tegra.so в lib/armeabi-v7a.

Я не знаю, какую логику включает ваша библиотека BootInfo, но если вы развертываете только одну библиотеку, вы можете избежать всех хлопот с помощью следующего кода в своем статическом конструкторе класса Java:

static {
    boolean loaded = false;
    while (!loaded) {
        try {
            System.loadLibrary("game" + nextExtensionAttempt);
            loaded = true;
        } 
        catch (Exception ex) {
        }
    }
}

Альтернативным подходом может быть переопределение выходного каталога ./obj. Для этого вы можете добавить в файл Application.mk следующую строку:

NDK_APP_OUT := obj$(MY_BUILD_EXTENSION)

Таким образом, все файлы .obj, .a и .so (до их установки в libs/armeabi) будут помещены в отдельный каталог для каждой конфигурации. Еще проще, вы можете указать параметр NDK_OUT в командной строке ndk-build, например.

ndk-build V=1 NDK_OUT=obj${MY_BUILD_EXTENSION}

Это очень просто, если вы используете Eclipse для обслуживания и выбора конфигураций. Это упрощает для Java загрузку модуля, поскольку он всегда будет иметь одно и то же имя. Но вы можете развертывать только одну конфигурацию за раз.

Я никогда не мог заставить это работать совершенно правильно. В конце концов я просто создал пакетный файл, который записал пустой исходный файл. Этот пакетный файл выполняется как часть этапа сборки в Eclipse. Затем я включил этот исходный файл как часть моей библиотеки. Поскольку отметка времени меняется каждый раз, когда я строю, это заставляет ndk каждый раз пересобирать эту библиотеку. Я слежу за тем, чтобы библиотека была небольшой, а большая часть кода находилась в других библиотеках, что делало время сборки довольно коротким.