I have a problem getting the native debugging support to work for my Eclipse project under Windows for Android.
Google unfortunately didn't help after more than 1 day of research.
I am pretty much a beginner with eclipse, so the solution might be easy because I do also some non-standard things I guess.
My android project is already functioning and running fine on my devices (Acer Iconia A500 Android 3.2.1, HTC Incredible S Android 4.0.4 etc.).
I created the project with the ADT Plugin Wizard and then added native support by using the project context menu entry added by ADT.
I then added the java files I already had (previously I used to compile with CMake and the Android stand-alone toolchain, though I never tried to remote debug this way). I created a new package for that "com.x.y" where I dropped them on to (I don't want to reveal the real package name as the project will be part of a commercial product).
Then I added my Sources by dragging them into the jni folder. The sources are not located inside the jni folder but are linked to a location "../../" below the project (Its part of a cross platform application so I can reuse the source files accross different toolchains).
I also link against 4 static libraries that will be shipped with the product by adjusting the Android.mk the following way:
LOCAL_PATH := $(call my-dir)
MY_PATH := $(LOCAL_PATH)
LOCAL_PATH := $(MY_SDK)/lib/Android/armeabi-v7aD
include $(CLEAR_VARS)
LOCAL_MODULE := A
LOCAL_SRC_FILES := libA.a
include $(PREBUILT_STATIC_LIBRARY)
include $(CLEAR_VARS)
LOCAL_MODULE := B
LOCAL_SRC_FILES := libB.a
include $(PREBUILT_STATIC_LIBRARY)
include $(CLEAR_VARS)
LOCAL_MODULE := C
LOCAL_SRC_FILES := libC.a
include $(PREBUILT_STATIC_LIBRARY)
include $(CLEAR_VARS)
LOCAL_MODULE := D
LOCAL_SRC_FILES := libD.a
include $(PREBUILT_STATIC_LIBRARY)
include $(CLEAR_VARS)
LOCAL_C_INCLUDES += $(my_SDK)/include/
LOCAL_PATH := $(MY_PATH)/../../..
LOCAL_CFLAGS += -Wno-format -DANDROID -fno-rtti -fno-exceptions #And many other flags If they are important I will post them later, too
LOCAL_CPPFLAGS += -fno-rtti -fno-exceptions
LOCAL_MODULE := MY_PROJECT
LOCAL_SRC_FILES := Android/Main.cpp # Some other sources..
LOCAL_LDLIBS := -lstdc++ -lEGL -lGLESv2 -llog -Wl,--allow-multiple-definition -Wl,--no-undefined
LOCAL_STATIC_LIBRARIES := A B C D
include $(BUILD_SHARED_LIBRARY)
I also have a Application.mk:
APP_ABI := armeabi-v7a
APP_PLATFORM := android-9
APP_STL := stlport_static
APP_CFLAGS += -fno-rtti -fno-exceptions
Then I added under Debug Configurations a new "Android Native Application" launching the default Activity and using
Debugger "${NdkGdb}"
Command File "${NdkProject}\libs\${NdkCompatAbi}\gdb.setup"
Shared Libraries (Added automatically) ${NdkProject}/obj/local/$NdkCompatAbi}/
The rest is also added automatically and I think should work this way.
One thing that I think is odd is that I get the console Output
[2013-03-08 10:50:36 - Unable to launch cygpath. Is Cygwin on the path?] java.io.IOException: Cannot run program "cygpath": CreateProcess error=2, The system cannot find the file specified
But I can build the project fine this way and later I don't get any warnings trying to attach gdb (I am using Msys, I also have cygwin installed so I don't know why Eclipse is complaining here).
When I launch the application, it starts up on the device and then I get the following Console output([Android Native Application] gdb):
(no debugging symbols found)
Error while mapping shared library sections:
/system/bin/linker: No such file or directory.
Error while mapping shared library sections:
libstdc++.so: No such file or directory.
... And alot more of that type
(no debugging symbols found)
warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code.
warning: shared library handler failed to enable breakpoint
No line 219 in file "jni/../../../MySourceFile.cpp".
I definitely build with NDK_DEBUG=1, my static .a Libraries are build with -g
AndroidManifest.xml has an entry android:debuggable="true".
When I run "sh /ndk-gdb --verbose" in the eclipse project directory (using Msys) I get the following output:
Android NDK installation path: /c/SDK/android-ndk-r7
Using default adb command: /c/SDK/android-sdks/platform-tools/adb.exe
ADB version found: Android Debug Bridge version 1.0.31
Using final ADB command: '/c/SDK/android-sdks/platform-tools/adb.exe'
Using auto-detected project path: .
Found package name: com.x.y
ABIs targetted by application: armeabi-v7a
Device API Level: 13
Device CPU ABIs: armeabi-v7a armeabi
Compatible device ABI: armeabi-v7a
Found debuggable flag: true
ERROR: Non-debuggable application installed on the target device.
Please re-install the debuggable version!
I really want to have native debugging support for this project. So I really appreciate any help.
Is it true that I have to use cygwin? I don't get any reasonable error message for that while trying to attach the debugger.
Related
I've found some serious difficulties in getting a working .so library to develop an Android app with Android NDK and intel TBB.
Basically I've downoaded version 4.4 Update 4 bundle for Android and followed the steps there (kind of, since the docs are not correct...).
Problem is that I can only get x86 and x86_64 .so libraries when compiling, since there are no armeabi-XXX or mips folders with the necessary .so in there.
Using the suggested command ./ndk-build.cmd tbb target=android arch=arm does not produce anything, in fact it tells me
/workspace/tbb44_20160413oss/lib/android/mips/libtbb.so library not found. Copy mips version of library to /home/filippo/workspace/tbb44_20160413oss/lib/android/mips folder to enable its build.
and the same for the other missing directories.
Threfore using only ./ndk-build.cmd tbb target=android gives me a cuople of dirs: x86 and x86_64 which I can use in Android Studio, and work with the emulator.
The result is taht I can properly test my apps on an emulator but cannot make it work into my personal device.
What am I missing here?
Application.mk
APP_ABI := x86 x86_64 // if I choose all, of course it won't find the .so for the other architectures
APP_GNUSTL_FORCE_CPP_FEATURES := exceptions rtti
APP_STL := gnustl_shared
Android.mk
LOCAL_PATH := $(call my-dir)
#
# TBB
#
include $(CLEAR_VARS)
LOCAL_MODULE := libtbb
LOCAL_SRC_FILES := $(LOCAL_PATH)/$(TARGET_ARCH_ABI)/libtbb.so
include $(PREBUILT_SHARED_LIBRARY)
#
# Main module
#
include $(CLEAR_VARS)
LOCAL_MODULE := myndkapp
LOCAL_SHARED_LIBRARY := libtbb
include $(BUILD_SHARED_LIBRARY)
Thanks.
As you can see in 'jni/Application.mk' you can use targets 'ia32', 'intel64', 'arm' and 'arm64'.
Also it looks like you trying to build on Windows platform, so you should add a tbb_os=windows to your make command like this:
C:\TEMP\tbb44_20160413oss\src>ndk-build.cmd tbb tbbmalloc target=android arch=arm tbb_os=windows
I have a question regarding why I cannot simply drop in new shared libraries in Android without recompiling via NDK-build. Heres what i do:
Using Android Studio and the recent release of the Android NDK, I have been able to compile an app that uses a C code, which refers to a shared library. I compile the shared library with:
GCC := /xxx/AndroidStudioProjects/android-ndk-r10d/toolchains/x86-4.6/prebuilt/windows/bin/i686-linux-android-gcc.exe
GPP :=/xxx/AndroidStudioProjects/android-ndk-r10d/toolchains/x86-4.6/prebuilt/windows/bin/i686-linux-android-g++.exe
AR := /xxx/AndroidStudioProjects/android-ndk-r10d/toolchains/x86-4.6/prebuilt/windows/bin/i686-linux-android-ar.exe
OPTIONS :=\
-ffunction-sections \
-funwind-tables \
-DANDROID
default: all
all: obj
$(AR) r libmathadd.so mathadd.o
obj:
$(GCC) $(OPTIONS) -c mathadd.c
This gives me my .so file. I now run my ndk-build with the Android.mk makefile:
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := mathadd
LOCAL_SRC_FILES :=./libmathadd.so
include $(PREBUILT_SHARED_LIBRARY)
include $(CLEAR_VARS)
LOCAL_LDLIBS := -llog
LOCAL_MODULE := ndk1
LOCAL_SRC_FILES := native.c
LOCAL_SHARED_LIBRARIES := mathadd
include $(BUILD_SHARED_LIBRARY)
Following this, I have my ndk1 .so file and my mathadd .so which i then place in a folder directory:
app -> src -> jniLibs -> x86 -> libmathadd.so
and
app -> src -> jniLibs -> x86 -> libndk1.so
I compile and run on my emulator, and boom everything works!
Now heres my problem.
I slightly modify my shared library source (mathadd.c). I recompile it using the first make file and drop it straight into the app tree (without rebuilding the native c code) . I rebuild the app in Studio, and run on my emulator, and notice that my modifications did not occur.
I am not changing my native source, nor the api between native and my shared library.
If I rebuild the native with the ndk-build script, and drag the new native ndk1 in, everything works again, including the new modifcations. It seems I need to rebuild source via ndk everytime I tweak a shared library...??
Any ideas?
UPDATE:
I opened up my libndk .so library with a RE tool. Turns out the ndk compiler is statically adding the libmathadd code into the libndk, despite it being listed as a local shared library. Im curious if this is because the optimization is by default set for fastest speed, and the libmathadd code is simplistic math.
So libndk1.so has a dependency on libmath.so ? That would then be logical to rebuild it when you touch to libmath source.
I'm trying a webm decorder for Android x86 with libvpx.
I built the library by following command and got "libvpx.a".
../configure --target=x86-android-gcc --disable-vp8-encoder --disable-vp9-encoder --disable-examples --sdk-path=$ANDROID_NDK_ROOT --enable-pic --enable-postproc
When I use this library is by ndk-build on Windows, an error occurred.
C:/android/[project]/jni/../plib/libvpx.a(postproc_mmx.asm.o)(.text+0x1c8): error: undefined reference to 'rand'
C:/android/[project]/jni/../plib/libvpx.a(postproc_sse2.asm.o)(.text+0x65c): error: undefined reference to 'rand'
collect2.exe: error: ld returned 1 exit status
libvpx.a for armeabi didn't occur an error. Doesn't someone know solution?
(jni/Android.mk)
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := sublib
LOCAL_SRC_FILES := sublib.cpp
LOCAL_LDLIBS := -llog
LOCAL_STATIC_LIBRARIES := libvpx_pre
include $(BUILD_SHARED_LIBRARY)
include $(LOCAL_PATH)/../plib/Android_x86.mk
(plib/Android_x86.mk)
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := libvpx_pre
LOCAL_SRC_FILES := libvpx.a
LOCAL_STATIC_LIBRARIES := cpufeatures
include $(PREBUILT_STATIC_LIBRARY)
$(call import-module,android/cpufeatures)
Contrary to the initial impression (from the subject), this isn't (directly) a duplicate of Cannot load library: reloc_library[1285]: cannot locate 'rand'.
It seems that when configuring libvpx with --target=x86-android-gcc, it actually doesn't automatically pick an android compiler or try to use android headers (contrary to what it does for armv7-android-gcc). (In fact, if you compile with --target=x86-android-gcc on OS X, it doesn't even build linux/android binaries, it will end up building a binary for OS X.)
Instead it builds pretty much as usual, using the normal system compiler, with the normal system headers (unless you manually specify them), which contain a normal rand function, which isn't available on Android. (On Android versions prior to 5.0, the rand function in stdlib.h is an inline function that actually maps to the lrand48 function, which is what the binary ends up linking to).
(Also, when building for android on arm, it doesn't seem to allow you to pick which android version you're targeting, so if your NDK contains android-21, it seems that it will try to build with that, which can also give you similar errors, such as in Cannot load library: reloc_library[1285]: cannot locate 'rand'.)
Since the configure script magic doesn't seem to set up the right things for building for x86 android (as it does for arm), you should be able to set it up yourself instead, which requires setting a bit more parameters:
export PATH=<NDK>/toolchains/x86-4.8/prebuilt/*x86*/bin:$PATH
ASFLAGS="-D__ANDROID__" CROSS=i686-linux-android- LDFLAGS="--sysroot=<NDK>/platforms/android-9/arch-x86" ./configure --target=x86-android-gcc --extra-cflags="--sysroot=<NDK>/platforms/android-9/arch-x86" --disable-examples
make
With this, I'm able to build a libvpx.a which should be built against the right headers, which hopefully should work fine for you.
I m trying to compile the muPDF lib in eclipse for android app since 3 days without any success
I downloaded and configured the android-ndk, cygwin
Im getting this still
15:25:36 **** Build of configuration Debug for project ChoosePDFActivity ****
"E:\\android-ndk\\android-ndk-r9d\\ndk-build.cmd" all
Android NDK: WARNING:E:/Workspace_SIL/ChoosePDFActivity//jni/Android.mk:mupdfcore: LOCAL_LDLIBS is always ignored for static libraries
Android NDK: WARNING:E:/Workspace_SIL/ChoosePDFActivity//jni/Android.mk:mupdfcore: LOCAL_LDLIBS is always ignored for static libraries
[armeabi] Compile thumb : mupdf <= mupdf.c
E:/Workspace_SIL/ChoosePDFActivity//jni/mupdf.c:10:18: fatal error: fitz.h: No such file or directory
compilation terminated.
make.exe: *** [E:/Workspace_SIL/ChoosePDFActivity//obj/local/armeabi/objs-debug/mupdf/mupdf.o] Error 1
15:25:36 Build Finished (took 489ms)
jni/mupdf.c:10:18: fatal error: fitz.h: No such file or directory
where I can get this God Damn fitz.h and other header files
see this happens in my eclipse
included the following paths for my header files
setup android Ndk path like this
Update1
Here is my Android.mk file
LOCAL_PATH := $(call my-dir)
TOP_LOCAL_PATH := $(LOCAL_PATH)
MUPDF_ROOT := ..
include $(TOP_LOCAL_PATH)/Core.mk
include $(TOP_LOCAL_PATH)/ThirdParty.mk
include $(CLEAR_VARS)
LOCAL_C_INCLUDES := \
$(MUPDF_ROOT)/draw \
$(MUPDF_ROOT)/fitz \
$(MUPDF_ROOT)/pdf
LOCAL_CFLAGS :=
LOCAL_MODULE := mupdf
LOCAL_SRC_FILES := mupdf.c
LOCAL_STATIC_LIBRARIES := mupdfcore mupdfthirdparty
LOCAL_LDLIBS := -lm -llog -ljnigraphics
include $(BUILD_SHARED_LIBRARY)
Check the jni folder and find the Anroid.mk. Open it and check whether you added the LOCAL_SRC_FILES and LOCAL_C_INCLUDES. The LOCAL_C_INCLUDES should be your .h files' path. The LOCAL_SRC_FILES should be every .c or .cpp file's path.
cygwin no t install properly, follow following links and sure your installations correctly than run some commands according to below links.
For window 7
For window XP
You're also using an old version of the MuPDF source code.
1) Use the latest version (1.5 currently, or better, work from git).
2) Don't build it using eclipse, use the supported ndk/sdk based build as described in platform/android/ReadMe.txt. If you want to use eclipse, do so only after you have managed to build it in the supported way.
3) Do not skip step 10 of the instructions. Seriously, why does everyone try to skip step 10?
4) If you get stuck, come talk to us in the #ghostscript irc channel on freenode. A weblink can be found to this on mupdf.com
Trying to run ndk-gdb and getting this error:
Android NDK installation path: /Library/AndroidSDK/ndk/
Using specific adb command: /Library/AndroidSDK/platform-tools/adb
ADB version found: Android Debug Bridge version 1.0.31
Using ADB flags:
Using auto-detected project path: .
Found package name: com.dev.project
jni/Android.mk:18: * Android NDK: Aborting. . Stop.
ABIs targetted by application: Android NDK:
Device API Level: 17
Device CPU ABIs: armeabi-v7a armeabi
ERROR: The device does not support the application's targetted CPU ABIs!
Device supports: armeabi-v7a armeabi
Package supports: Android NDK:
The 18th line in the jni/Android.mk is an import module call.
What does that mean and how to remedy it?
App is debuggable as per ndk documentation. I'm using Mac.
I can build and run the App, so build script should be fine.
Android.mk
LOCAL_PATH:= $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := libgl2jni
LOCAL_CFLAGS := -Werror -Wall -g
LOCAL_CPPFLAGS := -std=c++11
LOCAL_C_INCLUDES := $(LOCAL_PATH)/../../src $(LOCAL_PATH)/../../include $(LOCAL_PATH)/../../../boost
NDK_MODULE_PATH := $(LOCAL_PATH)/../../lib/ndk
LOCAL_SRC_FILES := $(subst $(LOCAL_PATH)/,,$(wildcard $(LOCAL_PATH)/*.cpp) $(wildcard $(LOCAL_PATH)/../../src/*/*.cpp))
LOCAL_LDLIBS := -llog -lGLESv2
LOCAL_STATIC_LIBRARIES := freetype
include $(BUILD_SHARED_LIBRARY)
$(call import-module,otherlib) #commenting this line launches the ndk-gdb, but ndk-build fails
Application.mk
APP_STL := gnustl_static
#remove for release?
APP_ABI := armeabi armeabi-v7a
APP_OPTIM := debug
I had the same problem. I'm quite sure it is a bug in the core/build-local.mk script. At least the error message is not meaningful.
I fixed doing this:
export NDK_MODULE_PATH=path_to_look_for_modules
Where path_to_look_for_modules should be the parent directory of your module declared in the Android.mk. That is, if you have /myproject/mylibs/otherlib export the path /myproject/mylibs
If you have several paths, as usual:
export NDK_MODULE_PATH=path1:path2:path3
If you are building an Android app and have some ndk code you may be able to solve this problem by adding/modifying your Application.mk (usually in the jni directory) with the following line:
# The ARMv7 is significanly faster due to the use of the hardware FPU
APP_ABI := armeabi armeabi-v7a x86 mips
#APP_ABI := armeabi
APP_PLATFORM := android-10
I mean the APP_ABI line. This is specifying the target processors to compile the ndk code for. I am assuming from the error message that you are testing on a device that has a different cpu type than the ones you built the app for.
Useful information about third party libraries
Possible issue with makefile or environment
export NDK_PROJECT_PATH=[Path]
where [Path] is the parent of "jni" directory, which in turn contains your NDK code.
You "might" face this issue if your NDK code (jni directory) is located separately from your Android java code.
A common solution to this problem is to include this line in your Application.mk.
APP_ABI := armeabi-v7a
Replace armeabi-v7a by the appropriate API as per the Device supports line. This will ensure that your application is built for the correct platform, and that ndk-gdb can find it.