Debug Native C shared library code

[robl2e]

Hello,
I know this topic has been discussed many times before and there are
solutions that exist (not very good ones however), but I could use a
straight answer to this. I created the hello-jni example application
through eclipse. My question is it possible to debug the native c
code (the shared library) with gdb/gdbserver? Since the native code
is a library and not a executable can you debug it while it's
running? The solutions I've found online using gdb/gdbserver to debug
seem to debug native c code that was an executable that had a main().
When I try to use run in gdb it says it' doesn't know how to run.

Sorry for the long post and thanks in advance.

[Nalin Savara]

Hi Rob,
The way the android's GUI shell executes java is by treating it as a content-type-- to be passed as a parameter to a invocation of the java virtual machine-- just the same way it treats a html file as a content-type-- which is passed as a parameter to a invocation of the browser.

Reason gdb says it doesnt know how to run is because unlike the shell-- it doesnt know what program to invoke.

If you debug a invocation of the java-vm-- passing the java-program you want debugged as a parameter to the java-vm-- the debugging should happen-- and when the control flow passes to the native code in library-- possibly with a breakpoint in it-- you should be able to trace code with gdb.

All you need to know is the name of the java virtual machine binary-- and also how to pass a java program's name, path, system environment to a invocation of the java vm similar to the way the shell's GUI does.

I personally have not hacked android much-- and hence cant guide you on the specifics-- but do feel free to dig around-- and when you find a solution, do post to this list too.

Best Regards,

NS

[fadden]

You can attach to the process after it starts running. The binary you
want is called "app_process".

Some info at http://pdk.android.com/online-pdk/guide/debugging_gdb.html

[Nalin Savara]

Thanks Fadden for the useful info and link. It is much appreciated.

Regards,

NS

[robl2e]

@fadden

I believe I've tried what you are saying but maybe I did it
incorrectly.

steps therefore are:
in the emulator i run: gdbserver --attach pid to run it on a currently
running application
in the host machine i then run: gdbclient ? (I could use more
specifics here)

So is gdbclient able to execute/connect to an app's process rather
then supplying the executable name? If this is true that would be
great since i'm not trying to debug a C/C++ standalone application but
rather trying to debug a C/C++ library.

I'm aware that gdbclient is part of Android's OS source code (platform
dev kit), so would I need to obtain that in order to proceed.
I've been using the arm-eabi-gdb.exe from the ndk with no luck in
getting it to work properly.

Thanks again and I appreciate the help from everyone.

On Feb 8, 1:32 pm, Nalin Savara <nsn...@gmail.com> wrote:
> On Tue, Feb 9, 2010 at 2:12 AM, fadden <fad...@android.com> wrote:
> > On Feb 5, 10:52 am, robl2e <robl2...@gmail.com> wrote:
> > > I know this topic has been discussed many times before and there are
> > > solutions that exist (not very good ones however), but I could use a
> > > straight answer to this.  I created the hello-jni example application
> > > through eclipse.  My question is it possible to debug the native c
> > > code (the shared library) with gdb/gdbserver?  Since the native code
> > > is a library and not a executable can you debug it while it's
> > > running?  The solutions I've found online using gdb/gdbserver to debug
> > > seem to debug native c code that was an executable that had a main().
> > > When I try to use run in gdb it says it' doesn't know how to run.
>
> > You can attach to the process after it starts running.  The binary you
> > want is called "app_process".
>

> > Some info athttp://pdk.android.com/online-pdk/guide/debugging_gdb.html

[fadden]

On Feb 8, 1:59 pm, robl2e <robl2...@gmail.com> wrote:
> steps therefore are:
> in the emulator i run: gdbserver --attach pid to run it on a currently
> running application
> in the host machine i then run: gdbclient ? (I could use more
> specifics here)

gdbclient is a shell function defined by build/envsetup.sh.

http://android.git.kernel.org/?p=platform/build.git;a=blob;f=envsetup.sh;h=a32d0b2c22aef5dd504df7b676b620da1c3f8fac;hb=HEAD
(around line 690)

It just runs gdb with a bunch of paths set up.

> So is gdbclient able to execute/connect to an app's process rather
> then supplying the executable name?  If this is true that would be
> great since i'm not trying to debug a C/C++ standalone application but
> rather trying to debug a C/C++ library.

You debug a running process, not a binary on disk. So you need to
attach to a process in which your library is doing something useful.

[Andrei Hanganu]

Hello all,

Reading through
http://pdk.android.com/online-pdk/guide/debugging_native.html I've
come across these lines:

"If debugging output indicates an error in C or C++ code, the
addresses aren't particularly useful, but the debugging symbols aren't
present on the device. Use the "stack" tool to convert these addresses
to files and line numbers, for example:"
Referring to the dump related to SIGSEGV.

I've met the hex dumps the paragraph is referring to, but I can't find
any trace of a "stack" tool, what is it referring to?

[robl2e]

Hello all,

After doing much, much research and headaches, I believe I got
debugging to work FINALLY. I want to thank everyone here for there
responses. For those that want to try this, this is what I did:

note: The way I'm debugging here is on a simple mixed java/native c++
app (app that uses jni) using gdb. Most guides regarding this topic
of debugging native code involved a independent standalone c/c++
executable (runs from android shell), this is not the case here. This
is debugging on a java app that makes calls to code in c/c++.

setup: To do this you need an os that can get and build the android os
source, so linux or mac. For windows you can use a virtual machine of
linux (thats what I did vm linux mint)

the app: SimpleJNI (this sample app is part of android os source
located in development/sample/SimpleJNI), it demonstrates the concept

1. First get the Android OS source following the instructions here
http://source.android.com/download you need to get it and make it.
2. Next follow the instructions here http://source.android.com/using-eclipse
to setup the eclipse and add the SimpleJNI app to the build path (most
important part to note here is adding the app to build path)
3. Now you need edit the app's Android.mk to add debugging symbols for
gdb. Go to SimpleJNI/jni folder in Android.mk and look for this line
"LOCAL_CFLAGS +=" change it to read "LOCAL_CFLAGS += -g"
4. cd /path/to/android/root and do "make SimpleJNI" to make the app.
5. Back in the Using Eclipse link follow these instructions from the
debugging with eclipse:

cd /path/to/android/root
. build/envsetup.sh
lunch 1 # to build the emulator
make # if you didn't already do this
emulator # you should see a GUI picture of a phone

Note: if your terminal can't seem to recognize the commands make sure
you are in the android root, and rerun ". build/ensetup.sh" and "lunch
1" commands

6. Next you need to install the app, from another terminal use this:
adb install -r ./out/target/product/generic/system/app/SimpleJNI.apk

7. You also need to push gdbserver in the emulator too, this will go
in /data/local directory
adb push ./out/target/product/generic/obj/EXECUTABLES/
gdbserver_intermediates/gdbserver /data/local

8. run the app SimpleJNI in the emulator, so it's running.

9. Follow the instructions here http://pdk.android.com/online-pdk/guide/debugging_gdb.html,
use the method of attaching to pid instead of executable

10. To see it work set a breakpoint i.e. b native.cpp:26, now since
there is no main() you can't just use <gdb> run, so what I found that
works is click "back" on the emulator and go back to android
homescreen. Then click open SimpleJNI again and gdb should break at
the breakpoint in this case line 26 in gdb.

11. In the emulator there should be no result displayed except for the
title SimpleJNI if you breaked at line 26

12. In the gdb window type "continue" or "c" and the app should resume
displaying some operation.

Thats it. I hope this was helpful because I felt there wasn't any
clear steps on how to debug w/ gdb/gdbserver on a java/jni app
scenario. I do think this method is very cumbersome and hopefully the
ndk later on will provide a better solution for debuging native code.

[robl2e]

Hey all,
Someone asked if it's possible to do this through the android NDK. To
answer the question I'm not sure. I think it is possible but I do not
know how to do it. The problem is the ndk does not include the
executable "app_process" which is a crucial part to getting the
debugging to work IMHO, but I suppose if someone grabbed the necessary
system libraries from the OS source then it may certainly possible.

Also here some clarifications for step 9
You basically want to follow these commands from the pdk instructions:

(emulator) gdbserver :5039 --attach pid

(host) adb forward tcp:5039 tcp:5039

(host) prebuilt/Linux/toolchain-eabi-4.2.1/bin/arm-eabi-gdb out/
target/product/product-name/symbols/system/bin/app_process

(host) <gdb> set solib-absolute-prefix /absolute-source-path/out/
target/product/product-name/symbols

(host) <gdb> set solib-search-path /absolute-source-path/out/target/
product/product-name/symbols/system/lib

(host) <gdb> target remote :5039

(host) <gdb> shared //Not sure if this is actually needed

[Zalo]

Hi robl2e
First of all thanks for the post. I am still trying to debug my app
and haven't succeded yet.

There are some steps on your list that I don't have clear.
The first thing that I noticed is that you are working with Android OS
source instead of the android-ndk, is there any special reason for
this?
Why is Eclipse required anyway? When you build SimpleJNI it already
generates a pkg that you can install in the emulator
How do you launch the debugger? I am using
gdbclient app_process :5039 com.example.android.simplejni
but then I get lots of warnings in gdb like

warning: .dynamic section for "/home/zalo/tmp/cupcake/out/target/
product/generic/symbols/system/lib/libc.so" is not at the expected
address (wrong library or version mismatch?)
warning: .dynamic section for "/home/zalo/tmp/cupcake/out/target/
product/generic/symbols/system/lib/libstdc++.so" is not at the
expected address (wrong library or version mismatch?)
warning: .dynamic section for "/home/zalo/tmp/cupcake/out/target/
product/generic/symbols/system/lib/libm.so" is not at the expected
address
warning: difference appears to be caused by prelink, adjusting
expectations
warning: .dynamic section for "/home/zalo/tmp/cupcake/out/target/
product/generic/symbols/system/lib/liblog.so" is not at the expected
address

then I can't just simple go back to the android menu without forcing
Android to close the app first. And when I relaunch it the program
never stops in any breakpoint at all

Thanks in advance. I am trying to do this for a week now without any
results :/

[coolblade]

Hi Rob,

For product-name is it just 'generic' because that is all I have in
that folder, this might be why it is breaking for me. I end up getting
a bunch of errors about mapping files and then 0xafe0db64 in ?? (). I
then tried to run 'shared' to see if that helped but instead it just
gave me the mapping errors again and for good practice I tried the
last step of setting a breakpoint and that didn't work due to the
earlier errors.

Did I miss a step where that a simpleJNI folder is created at /
<absolute-source-path>/out/target/product/<simple JNI product>?

This thread has been a major help to me, I really appreciate it.

Logs:
gregmacbook:mydroid gregr$ prebuilt/darwin-x86/toolchain/arm-
eabi-4.2.1/bin/arm-eabi-gdb out/target/product/generic/symbols/system/
bin/app_process
GNU gdb 6.6
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "--host=i386-apple-darwin9.6.0 --target=arm-
elf-linux"...
(gdb) set solib-absolute-prefix /Volumes/android/mydroid/out/target/
product/generic/symbols/
(gdb) set solib-absolute-prefix /Volumes/android/mydroid/out/target/
product/generic/symbols/system/lib/
(gdb) target remote :5039
Remote debugging using :5039
Error while mapping shared library sections:
/system/bin/linker: No such file or directory.
Error while mapping shared library sections:
libc.so: Unknown error: 0.
Error while mapping shared library sections:
libstdc++.so: Unknown error: 0.
Error while mapping shared library sections:
libm.so: Unknown error: 0.
Error while mapping shared library sections:
liblog.so: Unknown error: 0.
Error while mapping shared library sections:
libcutils.so: Unknown error: 0.
Error while mapping shared library sections:
libz.so: Unknown error: 0.
Error while mapping shared library sections:
libutils.so: Unknown error: 0.
Error while mapping shared library sections:
libexpat.so: Unknown error: 0.
Error while mapping shared library sections:
libcrypto.so: Unknown error: 0.
Error while mapping shared library sections:
libssl.so: Unknown error: 0.
Error while mapping shared library sections:
libicudata.so: Unknown error: 0.
Error while mapping shared library sections:
libicuuc.so: Unknown error: 0.
Error while mapping shared library sections:
libicui18n.so: Unknown error: 0.
Error while mapping shared library sections:
libsqlite.so: Unknown error: 0.
Error while mapping shared library sections:
libnativehelper.so: Unknown error: 0.
Error while mapping shared library sections:
libbinder.so: Unknown error: 0.
Error while mapping shared library sections:
libnetutils.so: Unknown error: 0.
Error while mapping shared library sections:
libEGL.so: Unknown error: 0.
Error while mapping shared library sections:
libwpa_client.so: Unknown error: 0.
Error while mapping shared library sections:
libhardware_legacy.so: Unknown error: 0.
Error while mapping shared library sections:
libpixelflinger.so: Unknown error: 0.
Error while mapping shared library sections:
libhardware.so: Unknown error: 0.
Error while mapping shared library sections:
libui.so: Unknown error: 0.
Error while mapping shared library sections:
libemoji.so: Unknown error: 0.
Error while mapping shared library sections:
libskia.so: Unknown error: 0.
Error while mapping shared library sections:
libGLESv1_CM.so: Unknown error: 0.
Error while mapping shared library sections:
libskiagl.so: Unknown error: 0.
Error while mapping shared library sections:
libdvm.so: Unknown error: 0.
Error while mapping shared library sections:
libsonivox.so: Unknown error: 0.
Error while mapping shared library sections:
libmedia.so: Unknown error: 0.
Error while mapping shared library sections:
libandroid_runtime.so: Unknown error: 0.
Error while mapping shared library sections:
libdrm1.so: Unknown error: 0.
Error while mapping shared library sections:
libvorbisidec.so: Unknown error: 0.
Error while mapping shared library sections:
libopencore_common.so: Unknown error: 0.
Error while mapping shared library sections:
libopencore_net_support.so: Unknown error: 0.
Error while mapping shared library sections:
libopencore_player.so: Unknown error: 0.
Error while mapping shared library sections:
libomx_sharedlibrary.so: Unknown error: 0.
Error while mapping shared library sections:
libomx_amrenc_sharedlibrary.so: Unknown error: 0.
Error while mapping shared library sections:
libmedia_jni.so: Unknown error: 0.
Error while mapping shared library sections:
libexif.so: Unknown error: 0.
Error while mapping shared library sections:
libsrec_jni.so: Unknown error: 0.
Error while mapping shared library sections:
libwebcore.so: Unknown error: 0.
Error while mapping shared library sections:
libsimplejni.so: Unknown error: 0.
Error while mapping shared library sections:
gralloc.default.so: Unknown error: 0.
Symbol file not found for /system/bin/linker
Symbol file not found for libc.so
Symbol file not found for libstdc++.so
Symbol file not found for libm.so
Symbol file not found for liblog.so
Symbol file not found for libcutils.so
Symbol file not found for libz.so
Symbol file not found for libutils.so
Symbol file not found for libexpat.so
Symbol file not found for libcrypto.so
Symbol file not found for libssl.so
Symbol file not found for libicudata.so
Symbol file not found for libicuuc.so
Symbol file not found for libicui18n.so
Symbol file not found for libsqlite.so
Symbol file not found for libnativehelper.so
Symbol file not found for libbinder.so
Symbol file not found for libnetutils.so
Symbol file not found for libEGL.so
Symbol file not found for libwpa_client.so
Symbol file not found for libhardware_legacy.so
Symbol file not found for libpixelflinger.so
Symbol file not found for libhardware.so
Symbol file not found for libui.so
Symbol file not found for libemoji.so
Symbol file not found for libskia.so
Symbol file not found for libGLESv1_CM.so
Symbol file not found for libskiagl.so
Symbol file not found for libdvm.so
Symbol file not found for libsonivox.so
Symbol file not found for libmedia.so
Symbol file not found for libandroid_runtime.so
Symbol file not found for libdrm1.so
Symbol file not found for libvorbisidec.so
Symbol file not found for libopencore_common.so
Symbol file not found for libopencore_net_support.so
Symbol file not found for libopencore_player.so
Symbol file not found for libomx_sharedlibrary.so
Symbol file not found for libomx_amrenc_sharedlibrary.so
Symbol file not found for libmedia_jni.so
Symbol file not found for libexif.so
Symbol file not found for libsrec_jni.so
Symbol file not found for libwebcore.so
Symbol file not found for libsimplejni.so
Symbol file not found for gralloc.default.so
warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code.
0xafe0db64 in ?? ()
(gdb) shared
Symbol file not found for /system/bin/linker
Symbol file not found for libc.so
Symbol file not found for libstdc++.so
Symbol file not found for libm.so
Symbol file not found for liblog.so
Symbol file not found for libcutils.so
Symbol file not found for libz.so
Symbol file not found for libutils.so
Symbol file not found for libexpat.so
Symbol file not found for libcrypto.so
Symbol file not found for libssl.so
Symbol file not found for libicudata.so
Symbol file not found for libicuuc.so
Symbol file not found for libicui18n.so
Symbol file not found for libsqlite.so
Symbol file not found for libnativehelper.so
Symbol file not found for libbinder.so
Symbol file not found for libnetutils.so
Symbol file not found for libEGL.so
Symbol file not found for libwpa_client.so
Symbol file not found for libhardware_legacy.so
Symbol file not found for libpixelflinger.so
Symbol file not found for libhardware.so
Symbol file not found for libui.so
Symbol file not found for libemoji.so
Symbol file not found for libskia.so
Symbol file not found for libGLESv1_CM.so
Symbol file not found for libskiagl.so
Symbol file not found for libdvm.so
Symbol file not found for libsonivox.so
Symbol file not found for libmedia.so
Symbol file not found for libandroid_runtime.so
Symbol file not found for libdrm1.so
Symbol file not found for libvorbisidec.so
Symbol file not found for libopencore_common.so
Symbol file not found for libopencore_net_support.so
Symbol file not found for libopencore_player.so
Symbol file not found for libomx_sharedlibrary.so
Symbol file not found for libomx_amrenc_sharedlibrary.so
Symbol file not found for libmedia_jni.so
Symbol file not found for libexif.so
Symbol file not found for libsrec_jni.so
Symbol file not found for libwebcore.so
Symbol file not found for libsimplejni.so
Symbol file not found for gralloc.default.so
(gdb) b native.cpp:26
No source file named native.cpp.
Make breakpoint pending on future shared library load? (y or [n]) n
(gdb)

[robl2e]

@Zalo

Yes I used the Android OS Source. I couldn't get it to work on the
NDK because the NDK does not include "app_process" (I mention this in
the post above yours). The Eclipse step may not be needed. I believe
it's needed because it adds the project SimpleJNI to the Java Build
Path, so that when you do a "make" in the command line the android os
your running is aware of this project.

@coolblade
Sorry for the confusion, yes it should be generic for the path. Here
are the EXACT lines I typed regarding your question and should be fine
as long as you have the android os source and did a MAKE. The folders
should be already there if done correctly.

(host) prebuilt/Linux/toolchain-eabi-4.2.1/bin/arm-eabi-gdb out/
target/product/generic/symbols/system/bin/app_process

(host) <gdb> set solib-absolute-prefix out/target/product/generic/
symbols

(host) <gdb> set solib-search-path out/target/product/generic/symbols/
system/lib

It's very IMPORTANT to follow the directions carefully especially for
getting the android source code and having the correct requirements
(Get the packages they suggest). It's very easy to make mistakes (I
know I have).

[Gregory Ray]

I got the debugging working, Rob your tutorial was amazing.

Rob (or anyone for that matter):

Do you know if Android Market will permit a JNI app built using the OSP instead of the NDK?

Will they (Android Market) permit an app accessing headers that the NDK deems immature, such as audio headers (obviously the burden is bared on the app developer building against shifting headers)?

Does anyone know where the audio headers might be?

Also how closely do the headers of the NDK and the OSP line up, for example, the android team has deemed the open gl headers to be stable enough to include in the 1.6 NDK, do those headers correspond 1-to-1 with the OSP so that you could theoretically switch from OSP to NDK (assuming the JNI portions would be rewritten but your core logic referencing the headers would not) once the NDK matures enough that real development is possible (audio headers and a fix for app_process so we can debug)?

I have a feeling android-5 platform headers (eclair) are right around the corner (March/April) and will give us audio and gdb debugging so I'm struggling with the decision to go OSP with debugging or go NDK and resort back to just logging every other line until NDK 2.* comes out. Google can you please give us some idea of what is to come and when so we can make intelligent decisions? This is seriously the dark ages of native android development.

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.

--
Gregory Ray
COO, Seek Mobile Interactive, Inc.

---

This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain information that is confidential and protected by law from unauthorized disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

[Zalo]

I also was able to do it
Thanks a lot!!

For those of you who want to use NDK instead of OSP I have been able
to use a little trick
Just compile with the NDK as usual (don't forget to add -g in
LOCAL_CFLAGS of your Android.mk)

Then copy the generated library (located in the NDK under <NDK_ROOT>/
out/apps/<app name>/<app_name>.so) to wherever you have Android OS
installed in the folder <AOS_ROOT>/out/target/product/generic/symbols/
system/lib/<app_name>.so
Then do as Rob was saying and you will be able to debug the generated
library generated with the NDK using the OS

This just makes everything even a little bit more complicated, but you
can always write a small script to do it automatically :)

[robl2e]

Hey all,
I'm glad to hear I'm not the only one getting this thing to WORK!
YAY.

@Greg
Hi again, yeah not sure if the market will accept a JNI built using
OSP, your gonna have to ask them I guess.

@Zalo

"you will be able to debug the generated library generated with the

NDK using the OS" Whoa I did not know that thanks for the tip, b/c for
me I had to do this on a virtual machine, so it would be great if I
can just use that for debugging.

The solution currently I feel is definitely a workaround/hack and I
hope they hurry up with a new version of the NDK to make this easier.
I've spent more time trying to figure this out then doing some
developing.

[Gregory Ray]

I would love to ask my question to google but unfortunately this is the only email (group) I know of. Do you know of another email? Maybe I will just repost my question with a subject line more demanding of attention.

Thanks again for the help.

-Greg

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.

[Doug Schaefer]

I don't work for Google, but the answer we get here often is to make sure you are linking against the libraries available in the NDK. They're the only ones guaranteed not to break on real devices.

There should be a way to do this with the NDK only, at least on the emulators where gdbserver is already installed and using --attach. I got it to sort-a work, but had issues with the symbols matching the real addresses. I'll report here if I ever get that working.

Doug.

[fadden]

On Feb 16, 6:42 am, Gregory Ray <gr...@seekmobileinteractive.com>
wrote:

> Do you know if Android Market will permit a JNI app built using the OSP
> instead of the NDK?
>
> Will they (Android Market) permit an app accessing headers that the NDK
> deems immature, such as audio headers (obviously the burden is bared on the
> app developer building against shifting headers)?

The Android market permits just about anything that isn't violating a
trademark or breaking the law.

If you use features that aren't specified by the NDK, there is an
excellent chance that your code will break in the future and you will
have upset customers. It may work on some platforms but not others.
It's generally a bad idea. Don't do it.

[Gregory Ray]

Just so I understand correctly, I understand that with future updates to the OS things will break but why would it break platform to platform? Are the hardware manufacturers changing up the native api per device? I doubt this is the case otherwise adoption of android os updates would become very difficult.

--

You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.

[Doug Schaefer]

The only native API is the one presented in the NDK. So no they don't change that.

[Gregory Ray]

I should not have said API, what I was referring to was the JNI and its relationship to the C++ classes that are wrapped.

Now unless I am mistaken the interface/signatures of the JNI wrappers are pretty well guaranteed to stay static, because for the most part they correspond right up to the API layer.

Now, the JNI methods seem to correlate 1-to-1 with c++ methods and it's hard for me to believe a handset developer is going to go romping through the JNI and changing that 1-to-1 relationship so that the JNI method calls a c++ method with a signature that does not line up.

So therefore it would be my conclusion that if you stick with the NDK headers as much as possible but when you need something like audio you tread lightly and only interface as the JNI (non-ndk) is already defining than your odds of running into device specific issues is greatly reduced. Of course this does not alleviate the head aches that will come from new platform updates but at least you can plan for that a little better.

In my mind any dealing with headers outside of the NDK would just be a band aid until the NDK includes the headers itself.

Please poke holes in my logic.

Thanks,

Greg

[robl2e]

@Zalo

Can you go into more detail about how to debug an app that was built
in the NDK? I copied the generated library from the NDK root to
<AOS_ROOT>/out/target/product/generic/symbols/system/lib/
<app_name>.so. Are there more steps to do? I'm unsure how to
proceed.

On Feb 17, 7:16 am, Gregory Ray <gr...@seekmobileinteractive.com>
wrote:

> >>> android-ndk...@googlegroups.com<android-ndk%2Bunsu...@googlegroups.com>

> >>> .
> >>> For more options, visit this group at
> >>>http://groups.google.com/group/android-ndk?hl=en.
>
> >> --
> >> Gregory Ray
> >> COO, Seek Mobile Interactive, Inc.
>
> >> ---
>
> >> This e-mail message, including any attachments, is for the sole use of the
> >> intended recipient(s) and may contain information that is confidential and
> >> protected by law from unauthorized disclosure. Any unauthorized review, use,
> >> disclosure or distribution is prohibited. If you are not the intended
> >> recipient, please contact the sender by reply e-mail and destroy all copies
> >> of the original message.
>
> >>  --
> >> You received this message because you are subscribed to the Google Groups
> >> "android-ndk" group.
> >> To post to this group, send email to andro...@googlegroups.com.
> >> To unsubscribe from this group, send email to

> >> android-ndk...@googlegroups.com<android-ndk%2Bunsu...@googlegroups.com>

> >> .
> >> For more options, visit this group at
> >>http://groups.google.com/group/android-ndk?hl=en.
>
> >  --
> > You received this message because you are subscribed to the Google Groups
> > "android-ndk" group.
> > To post to this group, send email to andro...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > android-ndk...@googlegroups.com<android-ndk%2Bunsu...@googlegroups.com>

[Zalo]

It is basically that
Then I am doing basically what you said and it is working. But I'll
write here the steps I am following:

cd AOS_ROOT
source build/envsetup.sh
lunch 1
emulator <--- it is important to run this emu instead of the one
included with the SDK

Recompile .so with NDK
cd to NDK_ROOT
make APP=<app_name>
Generate pkg (there are a lot of ways to do this, I am doing it with
eclipse (clean and build))
cp NDK_ROOT/out/apps/<app_name>/<app_name>.so AOS_ROOT/out/target/
product/generic/symbols/system/lib/<app_name>.so

cd to AOS_ROOT
adb install -r NDK_ROOT/apps/<app_name>/bin/<app_name>.apk
execute the installed application in the emulator
adb forward tcp:1234: tcp:1234
adb shell ps
adb shell gdbserver :1234 --attach pid <--- the pid displayed with ps

Open another terminal and cd to AOS_ROOT
prebuilt/linux-x86/toolchain/arm-eabi-4.2.1/bin/arm-eabi-gdb out/
target/product/generic/symbols/system/bin/app_process
----INSIDE GDB ----
set solib-absolute-prefix out/target/product/generic/symbols
set solib-search-path out/target/product/generic/symbols/system/lib/
target remote :1234

Then a list of lines saying the symbols have been loaded appear and
you can insert breakpoints and debug as usual. I have changed the
behaviour of my app so that it stays doing nothing until I press down
in the keyboard, then the lib is loaded and executed, that way I have
time to attach the debugger.

Hope it helps. You have helped me a lot so I'll be happy to help you
if it still doesn't work

Zalo

[robl2e]

Thanks Zalo,

Your directions were very helpful, but I still not able to get
debugging to work. I think its the app I'm trying to run though. It
was built using the ndk, it has two libraries a "<name>.so" and
a ."<name>a", so it may be causing problems. I get a segmentation
fault when loading the libraries. "system/lib/
libssl.so...Segmentation fault" If anyone has any more tips about
debugging native code from an app built using the ndk, I'll appreciate
it. Thanks!

[robl2e]

For some clarification the app I'm trying to debug has two libraries
Static Library (.a) and a Shared Library (.so). Does this mean I need
to add the .a library somehow to the AOS.

[Zalo]

I am not sure about that...
Have you tried to debug the hello-jni sample just to make sure you are
doing things right?
I was using this one to test everything at first because it is very
simple.

[robl2e]

Yup I'm tried the hello-jni, but it is still throwing me a
Segmentation fault error. It happens after i do the set solib-search-
path command. I don't know why it would be throwing a seg fault. I
appreciate all the help thanks.

[Zalo]

Ok, try this...
Instead of manually installing the application via adb install run the
emulator that comes with Android OS, then from Eclipse run the
project(and before that don't forget to clean the project). This
usually installs the app in the emulator and also runs it (it will
detect the emulator running as a valid emu even if it is the one that
comes with AOS and not the one with the SDK)

Let me know if this helped...

[Zalo]

Ok, try this...
Instead of manually installing the application via adb install run the
emulator that comes with Android OS, then from Eclipse run the
project(and before that don't forget to clean the project). This
usually installs the app in the emulator and also runs it (it will
detect the emulator running as a valid emu even if it is the one that
comes with AOS and not the one with the SDK)

Let me know if this helped...

On Feb 20, 8:21 am, robl2e <robl2...@gmail.com> wrote:

[robl2e]

FINALLY, I got it to work Thanks for all your help Zalo! I ended up
not having to do the eclipse thing you mentioned above. I think mine
didn't work at first because a combination of things. First of all
I'm using a virtual machine, so everytime I tried compiling the AOSP I
got compile errors apparently you need to set the virtual memory high
enough number so that it can compile w/o errors. Android recommends
1.5 GB ram allocated to the virtual machine. Second when loading the
libraries I had to use gdb from the version 4.4.0 toolchain. I also
ended using an older version of linux that had sdk java 1.5 in the
repo. I left with some questions however, I hope someone can answer
me:

1. When initializing the repo for the android source what branch did
you take and does it even matter? (i used eclair)
2. When debugging the hello-jni from the ndk I got the message "30
apps/hello-jni/project/jni/hello-jni.c: No such file or directory." if
I moved that file there would I be able to see the code?
3. If there is two libraries .so and an .a, do i need to add the .a
to the symbols/system/lib?

Thanks again