Question

I’m currently implementing a custom Logging mechanism that I need to be accessible from both native and Java code. The fundamentals of the logging are implemented in C/C++ with a Java wrapper, and the two together are being built as an android Library Project.

The issue at hand is that while my Java code can access the Library project output, there doesn’t seem to be a way for my native code to access the native .so or headers from the Library project. Is there an additional step I’m missing or is this just a limitation of the current ADT? More specifically, is there a makefile/eclipse configuration that will address the things I’m used to getting out of Library projects in general? (Build .so as needed, import rebuilt .so, import relevant headers for c/c++ compilation, etc.)

Answer 1

Worked out a way to get what I wanted – most of the information is (of course) in the NDK documentation, but what I was trying to do isn’t 100% supported within the ADT. It should also be noted that I’m currently stuck developing in a windows environment, so much of this might be easier or unnecessary in Linux. The first key is the $(call import-module ...) macro. Within your library project, move the source files and the Android.mk folder into a named directory you can locate later. My Library project directory looked like this:

MyProject
  > src
  > res
  v jni
      - Application.mk
      v MyLib
          - source.cpp
          - source.h
          - Android.mk

I also had to edit my Application.mk to point to the project:

APP_PROJECT_PATH := <path-to-my-project>
APP_BUILD_SCRIPT := $(APP_PROJECT_PATH)/jni/MyProject/Android.mk

Annoyingly, this broke my Android.mk in ways unforseen until I added a ./ to my source files. Also you need to export your includes for linking:

LOCAL_SRC_FILES := ./source.cpp
LOCAL_EXPORT_C_INCLUDES := $(LOCAL_PATH)

Ensure that the system path variable NDK_MODULE_PATH is set to include your library’s JNI directory, e.g. <path-to-my-project>/jni (Note: I had to restart eclipse after I did this).

In the receiving application’s Android.mk file (the one you’d like to link natively to your app), import the module:

LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE    := MyNativeProject
LOCAL_SRC_FILES := source.cpp
LOCAL_CFLAGS := -DANDROID_NDK -g -std=c99
LOCAL_SHARED_LIBRARIES := MyLib
include $(BUILD_SHARED_LIBRARY)

$(call import-module,android/native_app_glue)
$(call import-module, IntelLog)

At this point everything built perfectly, but the APK packager didn’t like the generated .so binary being included twice (once from the Library project’s natural import process, and again from the import-module call). To solve this, clean the library and don’t build it again! the import-module call will build the .so and import it into your project. (Obviously, if your project only requires the Java API, you would need that .so file to be built). Congratulations! you have a functional (if not straightforward) build process with a hybrid native/Java Library