> It is my understanding that Android N will no longer allow apps to use the > system-installed SQLite library (unless they go through the Android Java > API, android.database.sqlite). > > This is unfortunate, as many existing Android apps do access libsqlite3 > directly and will crash on Android N. > > Apps which ONLY use the Java API will be unaffected. > > Apps that do NOT use the Java API will need to bundle their own SQLite > library, if they are not doing so already. > > And then, there is a particularly unfortunate group: Apps which do some of > their SQLite operations through the Java API, but also do some things > through direct access to libsqlite. > > Because of the POSIX locking issues, these apps cannot just bundle a SQLite > and let the two sections of their code each use their own instance of the > library. The result will be a corrupt SQLite file. So the only obvious > fix for apps in this situation is to change their code to "ONLY use the > Java API" or "NOT use the Java API". > > Of course, another option would be for Google to reconsider and make > libsqlite part of the NDK public APIs. :-)
This would be problematic for me too. Is there a citation? Having used the Android API and the C API in the same app, I have to conclude that the Android API corrupts databases at a prolific rate. The Android API is also rather stupid, forcing the use of stupid "convenience" APIs like update(java.lang.String table, android.content.ContentValues values, java.lang.String whereClause, java.lang.String[] whereArgs). (I was never able to use an UPDATE statement and not have things break.) I hope Google comes to their senses, or provides a proper interface. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
