Android JNI, is there any way C++ code can directly read the app's sqlite database?

I'm working on an Android app with a Java component and a C++ component via JNI. The C++ component is used on other platforms.

It would make my life considerably easier if the C++ component c开发者_如何学Goould query the existing SQLite database (via the SQLite C API), without having to shell calls out to the Java side.

I know it's a long shot, has anyone attempted this?

---

No, the NDK only offers limited apis. The only officially supports areas are:

• libc (C library) headers
• libm (math library) headers
• JNI interface headers
• libz (Zlib compression) headers
• liblog (Android logging) header
• OpenGL ES 1.1 and OpenGL ES 2.0 (3D graphics libraries) headers
• libjnigraphics (Pixel buffer access) header (for Android 2.2 and above).
• A Minimal set of headers for C++ support

From ndk docs.

---

If you don't need to access the database from java, then as far as android is concerned it's just a file in a directory you have rights to. Accessing it via the platform's libsqlite.so and approved java wrappers is one way, but there is absolutely nothing stopping you from using your own sqlite implementation to operate on your own file if you really want to.

Since it's you own implementation (probably based off a copy of the current platform one), you aren't technically abusing a private api, since even if the platform's version evolves in incompatible ways you can control the evolution of your own copy.

If you wanted to optimize package size, you could first "evaluate" the platform's libsqlite.so to decide if you can work with it, and if not download your own version from your server. On my device it's only about 300K. However, this has some dependencies on other non-ndk libs as well, so a version that fully follows the nkd "rules" would probably be a bit larger as it would need to duplicate bits of some other things like libutils, etc.

The question then is if it's better for you to:

• call back up through jni (the "android way")
• use your own implementation (safe but a hassle to create)
• abuse the existing library as long as it works, then make your own if you can't figure out how to adapt to whatever changes broke it

---

Try using this customized NDK with standard C++ library support http://www.crystax.net/android/ndk-r4.php