Android Ndk - Force Library Rebuild On Configuration Change

Is there a way to force the Android NDK to rebuild a particular library when changing build configurations in Eclipse? I am building building an Android Project using the Android N

Solution 1:

NDK build always refreshes the .so libraries in lib/armeabi. The obj directory, on the other hand, contains separate trees for debug and release builds, for each module.

Unfortunately, it's rather easy to screw this setup if your Android.mk does something not supported by tge framework.

For example, in your case, the long upgoing paths to cpp files (../../../..) may be a bad idea. I would advise to set LOCAL_PATH for each module, and avoid ../ in LOCAL_SRC_FILES.

Here is my suggested change for 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)

UPDATE: Actually, using a module name suffix to separate the build configurations is, in my eyes, the best solution. This approach allows you to build and deploy more than one configuration at a time. For example, I use it when I have to optimize a library either to Tegra (without Neon) or to Snapdragon (with Neon): until recently, it was not easy to place two separate APKs on the Play Store, therefore I was packaging both libv-neon.so and libv-tegra.so into lib/armeabi-v7a.

I don't know what logic your BootInfo library includes, but if you are only deploying one library, you can avoid all the hassle with the following code in your Java class static constructor:

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

An alternative approach would be to override the output directory ./obj. For this purpose, you can add the following line to your Application.mk file:

NDK_APP_OUT := obj$(MY_BUILD_EXTENSION)

this way all the .obj, .a, and .so files (before they are installed into libs/armeabi) will be placed in a separate directory per configuration. Even easier, you can supply NDK_OUT parameter on the ndk-build command line, e.g.

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

This is very easy if you use Eclipse to maintain and choose your configurations. This makes it easy for Java to load the module, because it will always have the same name. But you can only deploy single configuration at a time.

Solution 2:

I was never able to get this working quite right. In the end I just created a batch file which wrote out an empty source file. That batch file is executed as part of a build step in Eclipse. I then included that source file as part of my library. Since the time stamp changes every time I build, it tricks ndk into rebuilding that library every time. I make sure that library is kept small and most code lives in other libraries, making the build time quite short.