IssueTracker

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.

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"

But at what point does it determine if it should use app_process64 instead?

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

Yes, ndk-gdb and ndk-gdb.py in all previously released NDK aren't ready for 64-bit ABIs.  This is fixed (*1) also enclosed.  Please try.

(*1)
https://android-review.googlesource.com/#/c/123221/
https://android-review.googlesource.com/#/c/123841/
https://android-review.googlesource.com/#/c/124361/

Mark it fixed for now.  Welcome to reopen if scripts in #7 don't work for you.

Looks good!  Thanks for the quick turnaround.

From ndk-gdb at https://android-review.googlesource.com/#/c/124361/

    # Old 32-bit devices do not have app_process32. Pull
    # app_process in this case
    run adb_cmd shell test -e /system/bin/$APP_PROCESS_NAME
    if [ $? != 0 ] ; then
        APP_PROCESS_NAME=app_process
    fi

This does not work in setting the name to app_process. The script is still trying to use app_process32 on my Nexus 4 running 4.2.2

Subsequent fix https://android-review.googlesource.com/#/c/132172 address the issue.  See new ndk-gdb enclosed.  The reason is that "adb shell" always return 0.
Sorry about that

Greetings.

Env info:
- OSX Yosemite
- NDK r10e (from May 2015)
- Toolchain 4.9
- ARM v7 .so
- Device: LG G3 - stock AOS, not rooted


Issue Description:

ndk-gdb fails when attempting to debug the .so on Lollipop device (LG G3)

Error reported:
[code]
ERROR: Non-debuggable application installed on the target device.
       Please re-install the debuggable version!
[code]

However, the above error does not appear to be correct.
1. NDK_DEBUG=1 was used during .so compile
1. Above happens whether or not 'debuggable=true' in manifest (by default I omit this but added it long enough to verify)
1. Able to successfully debug the same .APK/.so on Nexus 7 (stock KitKat)
1. Able to successfully debug the same .APK/.so on Nexus 4 (stock/rooted KitKat)

~~

ndk-gdb -v logging indicates the following ABI information:

[code]
ABIs targetted by application: armeabi-v7a
Device API Level: 21
Device CPU ABIs:  armeabi-v7a armeabi
Compatible device ABI: armeabi-v7a
[code]

The above ABI info looks fine. (Consistent with my expectations.)

~~

Examining the ndk-gdb (sh version not py)

Approx line 690 always fails
[code]
if [ "$COMPAT_ABI" = "$ANDROID_ARCH" ]; then
[code]

Reason:
[code]
  Arch Test: COMPAT_ABI= 'armeabi-v7a'  ANDROID_ARCH= 'arm'
  Arch Test: COMPAT_ABI= 'armeabi-v7a'  ANDROID_ARCH= 'arm64'
  Arch Test: COMPAT_ABI= 'armeabi-v7a'  ANDROID_ARCH= 'mips'
  Arch Test: COMPAT_ABI= 'armeabi-v7a'  ANDROID_ARCH= 'mips64'
  Arch Test: COMPAT_ABI= 'armeabi-v7a'  ANDROID_ARCH= 'x86'
  Arch Test: COMPAT_ABI= 'armeabi-v7a'  ANDROID_ARCH= 'x86_64'
[code]

~~

I reverted back to NDK r10d.
But it had the same result - KitKat device debugs fine whereas Lollipop fails.

~~

I also tried the ndk-gdb version attached to response #11.
It yields same result (and is slightly older than the ndk-gdb used in r10e)

~~

I also tried debugging with NDK from the AOSP/platform/ndk master codeline.
(I figured Android devs must be debugging their apps successfully.)
However, it yields same result - debugs KitKat but fails Lollipop.

Or, at least, it fails on my LG G3 (stock image).
So I suppose the LG G3 might have something special about its AOSP image.

If I had more Lollipop devices I would try them too to rule out this being "LG G3 specific"

~~
 
So what step is missing?

Is the "stock LG G3" simply incompatible with AOSP NDK debugging?
Perhaps there is a necessary configuration setting missing from Application.mk (or Android.mk)?
Or maybe unzip of the NDK 10e release failed to unpack "./prebuilt/android-armeabi-v7a/gdbserver/gdbserver"?

Additional information although not sure if this helps.

My LG G34 is not rooted so added some debug logging to list contents of the "/data/data/com.my.app/lib" directory on the device. This apparently is the data directory in which the ndk-gdb script is seeking for presence of the gdbserver.

The file "/data/data/com.MyApp/lib/gdbserver" does exist properly.
However, ndk-gdb is choking when trying to find it.

~~

Since it appears there were other bugs in the return value checks from adb, I fiddled with the data directory and gdbserver lookups.
1. The data directory ('run-as') succeeded but the gdbserver lookup (straight 'ls') failed.
1. Side note: So, as far is it goes, it looks like the success/fail logic of 'adb_var_shell2' is working correctly.

~~

Meanwhile, it seems the ndk-gdb script is attempting to do something all of us wish we could do without needing to root the device. Namely, access the private storage directory of the app package without rooting or other shenanigans.

[code]
    # Approx line 684
    DEVICE_GDBSERVER=$DATA_DIR/lib/gdbserver
    adb_var_shell2 GDBSERVER_RESULT ls $DEVICE_GDBSERVER
[code]

Generated the following on my LG G3 (these are log statements I added)
[code]
    "## GDBSERVER existence checking for: '/data/data/com.my.app/lib/gdbserver'"
    "## Yielded reult: '/data/data/com.my.app/lib/gdbserver: Permission denied'"
[code]
The above fails and kicks the script into the architecture compare test mentioned in my previous post (#12).

Oddly enough, the above succeeds on my Nexus 7. Although seems like maybe it should have also failed too? _shrug_
[code]
    "## GDBSERVER existence checking for: '/data/data/com.my.app/lib/gdbserver'"
    "## Yielded reult: '/data/data/com.my.app/lib/gdbserver'"
[code]

Regardless, the "quick fix" for me is to simply ignore this whole block and assume the gdbserver is present (since I know it is).
And, behold, the application .so is treated as debuggable by ndk-dbg on my Lollipop device.
Yay!

~~

So here are the changes I made to the ndk-gdb script. It's a hack, sure, but at least I can debug on my Lolipop LGG3.
[code]
    # Approx line 684 of ndk=gdb
    DEVICE_GDBSERVER=$DATA_DIR/lib/gdbserver
    # This will fail on some devices permission denied (ie, All Lollipop? Just LG G3?) but I know my .so is debubggable
    adb_var_shell2 GDBSERVER_RESULT ls $DEVICE_GDBSERVER
    rcGdbSvr=$?
    log "Real result of gdbserver query: '${rcGdbSvr}' (CHACK: forcing truth)"
    rcGdbSvr=0
    #if [ $? != 0 ]; then
    if [ ${rcGdbSvr} != 0 ]; then
        # ... block now skipped
    fi
[code]