Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <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>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    1. COThis does not seem to be the case for me. NDK does not build *.so and *.a files into separate directories. Only the object files (*.o and *.o.d) are put into "obj/local/armeabi/objs-debug/" and ".../armeabi/objs/". The actual compiled libraries are all found in "obj/local/armeabi/" with no regard for build configuration. Not to mention, the objs-debug folder appears to be based on APP_OPTIM flag which only supports "release" and "debug" but our engine has far more configurations than that.
      singulars
    2. COUsing `$(MY_BUILD_CONFIG_EXTENSION)` is actually a very good solution. in my opinion. This is more or less what I prefer in my projects. This gives very good control of what configurations are actually deployed to the device (_hint:_ it may be more than _one!). For an alternative solution, please see the **update** section of the answer.
      singulars
    3. COThe try/catch solution seems great to me, but one thing I am not clear on is how to stop the other versions of the libs from getting deployed to the device during debugging sessions (eg. Hitting F11 in Eclipse). For example, in "...\obj\local\armeabi" I have both "radgamed.so" and "radgamer.so". If I Run in the Debug configuration I want it to only find the libraries ending in "d" but it appears that the libraries ending in "r" also get deployed, so my try/catch will just succeed on the first one it tries. BTW: Thanks for the detailed answers! I really appreciate it!
      singulars
 

Querying!

 
Guidance

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