Develop Reference

Using the Clang address sanitizer in an NDK library on Android

The NDK has the ability to enable the address sanitizer on anything you build with it by adding the -fsanitize=address flag to both LOCAL_CFLAGS and LOCAL_LDFLAGS, which is nice. Well, it would be nice if it actually worked. If you add that flag and try building your library, you get a bunch of "undefined symbol" errors. You can ignore these errors by passing -Wl,--unresolved-symbols=ignore to the linker and the build completes successfully, but of course the adventure doesn't end here.
The Google's guide then says that you need a rooted device on which you run a script that modifies the runtime executable on the system partition so it loads the ASan library, and then the aforementioned missing symbols link at runtime. I tried this, and the main problem with this approach is that it also profiles something in the JVM itself thus slowing it down so much that the app doesn't start at all or crashes somewhere inside the JVM.
I've also tried the new malloc debug on an emulator but it also debugs the entire JVM thus making it unusable. All these tools seem to be absolutely not intended for the app developers but for those who work on Android itself.
I desperately need a way to fix a memory corruption crash in my app without profiling the whole virtual machine in the process. Will ASan work if I just put its library into my apk and load it before my JNI library? Are there any other ways to debug this? How do people fix this kind of bugs on Android at all?
Making a "minimal wrapper executable" and running it on some other operating system that has proper debugging tools isn't really an option here because the way the JNI library is used depends substantially on the Java part, and even if I make one, I can't be entirely sure that this bug will reproduce.
Update: I tried the asan_device_setup script on an Oreo emulator because it didn't work at all this time on a Nexus 9 with Nougat. The log flooded with linker errors of 32-bit processes trying to load 64-bit libraries and then it froze and the only way to make it usable again was flashing the factory image. Just to be sure I didn't mess anything up, I tried it several times reflashing the factory image, then TWRP, than SuperSU, and then using the "adbd insecure" app to restart the adb daemon as root. So, I started the emulator with -writable-system and ran the script on it, it completed successfully. I then built my app with ASAN and installed it, but it crashes with java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol "__asan_init_v3" referenced by "/data/...full path to the shared library on launch. I tried it both with and without setprop wrap.com.app.package "asanwrapper", the result is the same.

You should probably file bugs (http://b.android.com) if you're seeing performance issues this serious. We run devices that are fully ASAN instrumented every day and those work better than you'd expect. ASAN is a roughly 2x slowdown, but running your app with ASAN should work fine.
Same goes for debug malloc (I don't remember the performance implications of debug malloc, but I thought they were less severe than ASAN).

Android privileges to execute native applications?

I downloaded the c4droid app for Android and am running commands through system();. I'm learning that somethings work while others don't. Most of the cool stuff don't work and this appears to be due to my user profile not being given the rights to execute such commands at the Linux OS level.
So tried another experiment. I got a special Gnu compiler for the arm processor and compiled a simple hello world app. Then I put on my phone and tried to execute it through the c4droid app like system("./myapp.bin"); . I got a permission denied message.
So I'm just trying to understand what I can do and what I can't do on my phone that paid good money for? Can I execute such a hello world app or not? Do I really need root access to execute an application I made? Is there a way to get my code to run by wrapping it in android/java code? Do I have to go through the Dalvikvm to get this to run?
I'm really looking for a way to do this without rooting it or downloading something like busybox and using su.

Many many different issues.
permission denied is one of the few error messages the primitive shell knows, and it's used for many other types of failures including not finding the requested command.
The toolbox suite is missing many typical unix commands. People sometimes install busybox as a more comprehensive supplement
Some of the things you may want to do will actually require permissions that the shell (or even more so, application user id) accounts do not have. Only on an emulator or engineering device does the adb shell run as root by default, though on a 'rooted' device you may be able to get to a root shell.
You do not need root access to run compiled code, however the code must have a suitable ABI, must have all it's library dependencies satisfied, and must be installed in a file with the executable flag, on a partition which is not mounted with non-executable flag. Some of the issues you face there are glibc (or other) vs Android's bionic libc. Executable scratch directories vary by android version, though the private storage area of an app is an option if the app sets the file to world readable and executable.
The usual (and only "recommended") means of running native code is to build it as a shared library linked against android's Bionic libc, and call into it from a dalvik/java app using JNI.

What are possible causes of "failed to map segment from shared object: operation not permitted", and how to debug?

I have two executables, both cross compiled to run in Android. I have put both on the device in the same directory. I have put all the shared libraries that they are dependent on in the same directory, including ld-linux.so.3. I run the executables by using:
ld-linux.so.3 --library-path /path/to/libraries executable_name
both work on older versions of Android when running as any user. The both work on the latest version of Android if running as root. Only one works on the latest version of android when running as any user. Instead it gives:
failed to map segment from shared object: executable_name operation not permitted
How can I find out what is different with the executable that won't run?
I read a lot online and most people that get this error, either:
A) don't have execute permissions for one of the libraries they are dependent on or the executable itself.
or
B) are trying to run from a directory that is mounted as NOEXEC.
both of these don't appear to be the case. It can find all libraries and I can load any library by itself and see what other things it is dependent on being resolved. Also, I can run basic scripts from the directories of interest.
The newer version of Android, Jelly Bean, is a different linux kernel version and I wonder if that is related.
What give? How do I debug?

Permission issue. Need to remount /tmp. The following command works for me (Centos 7):
sudo mount /tmp -o remount,exec

I had this error in a different context. For some reason it causes an error when trying to use the /tmp folder.
To solve this I simply:
mkdir tmp
export TMPDIR=`pwd`/tmp
The TMPDIR is a constant that tells where the temporary folder of the system is.
This solutions resolves by creating a directory where we are allowed to and settings this directory into the system. Therefore we can now write to the new system default temporary folder.

The issue was with how the executables were compiled. They needed to be compiled with a cross compiler that properly supported newer arm devices. The compiler I used generated executables that would only work on a subset of arm devices. The issue was not with the different versions of android.

SELinux is enabled by default on Android 4.3, however it is supposed to be "permissive" [0]. Maybe your phone vendor added more restrictive rules.
[0] https://source.android.com/devices/tech/security/se-linux.html

Generate core dump in android

I'm developping a android's aplication using some shared
libraries written by me and compiled with ndk-r5b. The application works,
y and the calls to the libraries works too, but I detected some errors,
segmentations faults, and I need to debug it, but, I don't know how debug
native code from android and I don't know if I can generate core dumps,
as in linux, for debug my libraries.
Any idea?

The ndk comes with ndk-gdb, which supposedly allows you to debug native applications. Also, if you download the whole andriod open source project, they also have some version of gdb used for debugging. Look in the docs/ folder of the ndk to learn about using it. This tutorial might also prove helpful: http://vilimpoc.org/blog/2010/09/23/hello-gdbserver-a-debuggable-jni-example-for-android/
However, as shown in a recent question I asked: Running ndk-gdb with package not found error on motorola phone I still can't get it to work.
Edit: You said in the comments you were using a Samsung Device: Samsung decide to wreck havoc on some of the crucial internals required for native debugging, but it's easily fixable if you have root access to the device. If you use the --verbose flag, you'll probably find that the error is different than that, a package unknown error. That's because it's looking in /data/system/packages.list, but samsung renamed that file to /dbdata/system/packages.list. So if you make a symlink to that file in /data/system/packages.list, (requires root access) it should work. Or at least so claims the ndk mailing list: http://osdir.com/ml/android-ndk/2011-03/msg00036.html

Android NDK running native processes

I want to run tcpdump on the NDK using Process.start() and want to capture this output to a buffer.Can anybody show me how i can do this?Also is the process created in the same Dalvik Vm as the JNI call or is it in a different VM?

Running native processes is not really a supported use of the ndk, but you wouldn't be the first person to do it.
Also note that tcpdump may need to be run as root or setuid root to be useful. And you do have a version of tcpdump compiled and linked appropriately for android?
I think that you actually want android.os.Exec.createSubprocess which is um, not public, rather than Process.start. There's a right way to do it using reflection, and a wrong way to do it by copying the Exec.java (which has declarations of the native methods) into your project. You can use a pipe to recover the results, or you can launch it through the shell and redirect the output to a file which you read from java.
See the source of an android terminal emulator with a local shell option for an example of how to do it.
(Actually, I should restate this - the right way to do it is to duplicate the native functionality of the non-public Exec methods in your own jni lib, so that you are immune to changes in that non-public part of the platform).