(Put another way: if yourheader file requires "#ifdef _cplusplus", you may have to do some extra work if anything inthat header refers to JNIEnv.)Īll VM threads are Linux threads, scheduled by the kernel. For this reason it's a bad idea toinclude JNIEnv arguments in header files included by both languages. "jni.h" provides different typedefsdepending on whether it's included into ".c" or ".cpp".
The C declarations of JNIEnv and JavaVM are different from the C++declarations.
ANDROID NDK GETBYTEARRAYREGION EXAMPLE CODE
For this reason, you cannot share a JNIEnv between threads.If a piece of code has no other way to get its JNIEnv, you should sharethe JavaVM, and use JavaVM->GetEnv to discover the thread's JNIEnv. On some VMs, the JNIEnv is used for thread-local storage.
Your native functions all receive a JNIEnv asthe first argument. The JNIEnv provides most of the JNI functions. In theory you can have multiple VMs per process,but Android's VM only allows one. (In the C++ version, it's a class whose sole memberis a pointer to a function table.) The JavaVM provides the "invocation interface" functions,which allow you to create and destroy the VM. Both of these are essentiallypointers to pointers to function tables. JNI defines two key data structures, "JavaVM" and "JNIEnv". Someaspects of the interface aren't immediately obvious onfirst reading, so you may find the next few sections handy.The more detailed JNI Programmer's Guide and Specification can be found here. You really should read through the JNI spec for J2SE 1.6to get a sense for how JNI works and what features are available. It's VM-neutral, has support for loading code fromdynamic shared libraries, and while cumbersome at times is reasonably efficient. It defines a way for code written in theJava programming language to interact with nativecode, e.g.
0 kommentar(er)
