StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>NDK build always refreshes the <strong>.so</strong> libraries in <code>lib/armeabi</code>. The <code>obj</code> directory, on the other hand, contains separate trees for debug and release builds, for each module.</p> <p>Unfortunately, it's rather easy to screw this setup if your <code>Android.mk</code> does something not supported by tge framework.</p> <p>For example, in your case, the long upgoing paths to cpp files (<code>../../../..</code>) may be a bad idea. I would advise to set <code>LOCAL_PATH</code> for each module, and avoid <code>../</code> in <code>LOCAL_SRC_FILES</code>.</p> <p>Here is my suggested change for Android.mk:</p> <pre><code>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) </code></pre> <p><strong>UPDATE</strong>: 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 <code>libv-neon.so</code> and <code>libv-tegra.so</code> into <code>lib/armeabi-v7a</code>.</p> <p>I don't know what logic your <strong>BootInfo</strong> 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:</p> <pre><code>static { boolean loaded = false; while (!loaded) { try { System.loadLibrary("game" + nextExtensionAttempt); loaded = true; } catch (Exception ex) { } } } </code></pre> <p>An alternative approach would be to override the output directory <code>./obj</code>. For this purpose, you can add the following line to your <code>Application.mk</code> file:</p> <pre><code>NDK_APP_OUT := obj$(MY_BUILD_EXTENSION) </code></pre> <p>this way all the <code>.obj</code>, <code>.a</code>, and <code>.so</code> files (before they are <em>installed</em> into <code>libs/armeabi</code>) will be placed in a separate directory per configuration. Even easier, you can supply <code>NDK_OUT</code> parameter on the <code>ndk-build</code> command line, e.g. </p> <pre><code>ndk-build V=1 NDK_OUT=obj${MY_BUILD_EXTENSION} </code></pre> <p>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.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload