Status Update
Comments
xa...@android.com <xa...@android.com>
ch...@gmail.com <ch...@gmail.com> #2
See my answer here: http://stackoverflow.com/questions/26530675/ndk-debugging-ndk-gdb-fails-to-pull-app-process-who-and-when-creates-the-app-p/28200279#28200279
I've added recommended changes to the NDK here:http://pastebin.com/YfxNs06U .
The change is as follows:
# Get the app_server binary from the device
APP_PROCESS=$APP_OUT/app_process
if [ "$API_LEVEL" -lt "21" ] ; then
run adb_cmd pull /system/bin/app_process `native_path $APP_PROCESS`
log "Pulled app_process from device/emulator to $APP_PROCESS"
else
run adb_cmd pull /system/bin/app_process32 `native_path $APP_PROCESS`
log "Pulled app_process32 from device/emulator to $APP_PROCESS"
fi
This is perhaps a more elegant solution to the error-checking version from OP.
My reasoning for not keeping the app_process32 name when pulling to the development machine is so that a single debug config can be maintained in Eclipse for debugging api21 and <api21 devices.
I've added recommended changes to the NDK here:
The change is as follows:
# Get the app_server binary from the device
APP_PROCESS=$APP_OUT/app_process
if [ "$API_LEVEL" -lt "21" ] ; then
run adb_cmd pull /system/bin/app_process `native_path $APP_PROCESS`
log "Pulled app_process from device/emulator to $APP_PROCESS"
else
run adb_cmd pull /system/bin/app_process32 `native_path $APP_PROCESS`
log "Pulled app_process32 from device/emulator to $APP_PROCESS"
fi
This is perhaps a more elegant solution to the error-checking version from OP.
My reasoning for not keeping the app_process32 name when pulling to the development machine is so that a single debug config can be maintained in Eclipse for debugging api21 and <api21 devices.
dm...@gmail.com <dm...@gmail.com> #3
Alternatively: set the device binary name in a variable, changing based on API level.
# Get the app_server binary from the device
APP_PROCESS=$APP_OUT/app_process
APP_PROCESS_DEVICE=app_process32
if [ "$API_LEVEL" -lt "21" ] ; then
APP_PROCESS_DEVICE=app_process
fi
run adb_cmd pull /system/bin/$APP_PROCESS_DEVICE `native_path $APP_PROCESS`
log "Pulled $APP_PROCESS_DEVICE from device/emulator to $APP_PROCESS"
# Get the app_server binary from the device
APP_PROCESS=$APP_OUT/app_process
APP_PROCESS_DEVICE=app_process32
if [ "$API_LEVEL" -lt "21" ] ; then
APP_PROCESS_DEVICE=app_process
fi
run adb_cmd pull /system/bin/$APP_PROCESS_DEVICE `native_path $APP_PROCESS`
log "Pulled $APP_PROCESS_DEVICE from device/emulator to $APP_PROCESS"
pa...@gmail.com <pa...@gmail.com> #4
But at what point does it determine if it should use app_process64 instead?
xa...@android.com <xa...@android.com> #5
I guess that's up to the NDK team to determine what the binary will be
named for each api level. Hopefully this issue being raised means we can
expect a fix to encompass all future names of this binary, and that the
ndk-gdb script will work seamlessly for all api levels.
Jacob Kwitkoski
named for each api level. Hopefully this issue being raised means we can
expect a fix to encompass all future names of this binary, and that the
ndk-gdb script will work seamlessly for all api levels.
Jacob Kwitkoski
Description
OS version: Windows 8.1
Java JRE/JDK version: 1.7.0_51 64bits
gradle version: 1.11
android-plugin version: 0.9.0
NDK version: r9d 64bits
When building ndkJniLib sample from the gradle-samples-0.9 on windows I get this error:
make.exe: *** No rule to make target `C:\Users\xhallade\Desktop\ndkJniLib\lib\build\ndk\release\obj/local/armeabi-v7a/objs/hellojni/C_\Users\xhallade\Desktop\ndkJniLib\lib\src\main\jni', needed by `C:\Users\xhallade\Desktop\ndkJniLib\lib\build\ndk\release\obj/local/armeabi-v7a/objs/hellojni/C_\Users\xhallade\Desktop\ndkJniLib\lib\src\main\jni\hello-jni.o'.
Stop.
If I create a new empty .c file aside hello-jni.c and run gradle again, the .so files are getting generated correctly.
In fact instead of calling gradle again, I can edit myself the generated Android.mk and add the second file to fix this.
When I re-run the ndk-build command line issue by gradle everything compiles fine, so the root cause seem to come from the NDK and not from the build system.
The command issued by gradle:
C:\Android\ndk\ndk-build.cmd NDK_PROJECT_PATH=null APP_BUILD_SCRIPT=C:\Users\xhallade\Desktop\ndkJniLib\lib\build\ndk\release\Android.mk APP_PLATFORM=android-19 NDK_OUT=C:\Users\xhallade\Desktop\ndkJniLib\lib\build\ndk\release\obj NDK_LIBS_OUT=C:\Users\xhallade\Desktop\ndkJniLib\lib\build\ndk\release\lib APP_ABI=all
The generated Android.mk:
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := hellojni
LOCAL_SRC_FILES := \
C:\Users\xhallade\Desktop\ndkJniLib\lib\src\main\jni\hello-jni.c \
LOCAL_C_INCLUDES += C:\Users\xhallade\Desktop\ndkJniLib\lib\src\main\jni
LOCAL_C_INCLUDES += C:\Users\xhallade\Desktop\ndkJniLib\lib\src\release\jni
include $(BUILD_SHARED_LIBRARY)
They are the same in both cases - only the reference to the other .c file is added in Android.mk when it's there.
The sample is attached.