Hacker News new | ask | show | jobs
by unsoundInput 3428 days ago
Kind of related: There is an outstanding request [0] on the Android issue tracker to offer an official support/compat library for Android's sqlite bindings, that would bridge Android's API (in a different java package) to a sqlite binary that you provide.

There are already implementations [1][2] of this, but because it is not provided by the Android team it is hardly supported by ORMs, libraries, etc.

[0] https://code.google.com/p/android/issues/detail?id=202658

[1] https://www.sqlite.org/android/doc/trunk/www/index.wiki

[2] https://github.com/requery/sqlite-android

1 comments

Does this not just hit the "The Multiple SQLite Problem" described in the article?
I don't think so but I might also interpret the article wrong.

The problem - from what I understand - is that you used to be able to use the systems sqlite.so to access databases owned by your app from the native environment. With Android N you are no longer able to do this, you need to ship your own sqlite binary.

This can lead to problems when you want to access the same sqlite files from both the Android platform APIs and native (e.g. use it from native for business logic, debug it with a tool like Stetho [0] that uses android.database.sqlite) because of a version mismatch.

Would Google offer (a copy of) the Android API with the ability to plug in a different sqlite-compatible binaries, it would very likely find broad adoption. Then the problem stated by the article could be solved by shipping the app with a sqlite build that is used by both the native code and plugged into the compat library.

[0] https://facebook.github.io/stetho/