If you have native code that wants to access a database, not round trip though Java, and not incur the size hit of shipping a separate copy OR (and this is key) want your Java code to be able to read the same database without writing your own Java->JNI SQLite wrapper.

Unless you are hammering on a jni in an inner loop, you won't notice.

Another problem is explained in the feature request that another commenter linked to: https://code.google.com/p/android/issues/detail?id=202658

You have no idea what version of sqlite the OS might be using, so you can't rely on consistent behavior. In many cases the vendor will have tinkered with it and messed it up. Comprehensively testing on all Android devices is basically impossible because there are so many models out there.

That sounds like an argument against direct access to sqlite.so.

Hmm, yeah, but only partly--

The reason they can tinker with it is that it's not public; if it were public it would (hopefully) be better-defined, locked down and stable, part of the Android compatibility test suite.

That feature request would let people supply their own sqlite.so, and also redirect the Java API to use it. Seems like a very promising approach.