In a nutshell, the blog author (Eric Sink) and the SQLite folk discourage using two SQLite libraries in a single program.
However, this is difficult to avoid in an Android app. Last I checked, WebView uses SQLite, and it (presumably) uses the system-supplied SQLite. Third-party libraries might use the system-supplied SQLite. So, even if in our own app code we stick with SQLCipher for Android — even the new N repackaging — it would seem as though we are at risk.
Does SQLCipher for Android do something that gets around this issue?
SQLCipher doesn’t do anything specifically to mitigate this, so there is a theoretical risk. However, in practice, it is a lower risk with SQLCipher.
The possibility for data corruption really exists when you have two different SQLite libraries linked into a single application that are concurrently accessing the same database files. That is an important qualifier; the scenario that Erik describes in his post is a big problem for their Zumero library because it performs synchronization for arbitrary application data in SQLite databases. In that case, Zumero is presumably syncing and sharing access to the same database that the application is also managing. When a different library is used by the application than the Zumero sync engine, they risk corruption because they are acting on the same database files. This is the same scenario demonstrated in the sample application that causes a live corruption, i.e. two threads in the same process manipulating the same database using different instances of the library.
This is a much lower risk for applications using SQLCipher. Because the vast majority of SQLCipher deployments feature encrypted databases, it is not even possible to open or read them with a different version of SQLite. As a result, only SQLCipher can really operate on any given database, avoiding the issue completely.
There are a few edge cases where there could be a problem, but these should be rare:
Using the SQLCipher library concurrently with another SQLite library to operate simultaneously on standard (plaintext) databases
Cross-attaching standard databases to an encrypted session with SQLCipher while they are simultaneously being used by another SQLite library
Using android.database.sqlite to open and close SQLCipher databases, even though its not able to read them
In summary, a separately linked SQLite library could be managing other databases, but as long as they don’t overlap the POSIX close bug and resulting corruptions should not occur.
Please let us know if this addresses your question, or if there were any other specific scenarios you’re considering that could cause problems.
Neither the blog posts nor the SQLite documentation emphasize the “accessing the same files” scope restriction, though the docs allude to it a bit. What you say makes sense, and is more or less how I would have expected things to work. Even ignoring those posts and stuff, I would have assumed that hitting the same database with two separate SQLite libraries would have been risky (to be generous).