I read that apps sometimes access the native libraries for optimization purposes via the Java native interface.
As far as I understand, JNI just provides java wrappers around c/c++ libraries/binaries which are written closer to hardware hence faster and more efficient.
But how does it provide a performance boost, aren't JNI APIs called through Dalvik VM, so they do not run natively, they are still running inside a VM so there shouldn't be any difference.
I think I see the source of your confusion. Dalvik VM isn't a virtual machine the same way as VMware or Virtualbox. In that kind of VM, VMware (or whatever) is pretending to be the whole computer. Every operation has to go through the VM, it has to be prevented from accessing the real hardware, and if it does access the real hardware, VMware has to do some work to pretend to be the real hardware, give the result to the OS, and have the OS give the result to the application. There's a whole copy of the OS running inside the VM, so it's an application, on an OS, on VMware, which is itself an application running on an OS, which is then on the real hardware.
Java and (by extension) Dalvik VM isn't like that. It's more like an abstraction of the real machine. The real hardware isn't being hidden from the application, and there isn't an extra copy of the OS there.
A Java application is just a process on the phone like a non-Java application. When a Java application makes a function call via JNI, Dalvik has to do a small amount of book-keeping to pass the objects used in the function call to the native code, and then the native code just runs in the process, with no VM involved at all. Then there's a little more book-keeping to get the result back to the Java code.
The code within the JNI call is as fast as any native code in a process where there's no Java at all. The only overhead is the book-keeping on entry to and exit from the call.
Q & A