Sqlite issues with HTC Desire HD

Question

Recently I have been getting a lot of complaints about the HTC Desire series and it failing while invoking sql statements. I have received reports from users with log snapsh

Answer 1

Short answer: try removing SQLiteDatabase.OPEN_READONLY.

Longer answer:

The "WAL" is the write-ahead log, a relatively new feature in SQLite as I understand it. The SQLite docs on WAL say "It is not possible to open read-only WAL databases." Now, that appears to be more in the context of read-only media, but it might hold true for OPEN_READONLY.

I'd be somewhat surprised if this helps, as it presumes that:

• WAL is not used in standard Android
• HTC enabled WAL in those two devices
• Something special about your environment (e.g., the binary database you're schlepping out of assets) is causing this problem where an ordinary read-only database still works fine, as I cannot imagine that those devices would have passed compatibility tests with broken read-only database support

But, I would think it is at least worth a shot.

You might also consider switching from packaging the binary database to packaging the SQL statements to build/populate the database and executing them. While this will be slower (much slower if you don't use transactions), it might be less prone to database file-specific issues.

Answer 2

The fundamental underlying issue here is that you're assuming that sqlite3 database files are portable among Android devices. This is not true. The file format -- indeed, the use of SQLite at all as a database engine -- is not part of the API. HTC could make an Android phone that uses postgres instead of sqlite3, and it could still be officially compatible.

Yes, it's a common trick to pre-populate database content by bundling a sqlite3 .db file in your application's assets, and then using it intact after install. It isn't guaranteed to work, though, not even between devices running the same version of the Android platform. The only thing you can be assured of is that a .db file created on a given device running a given version of Android will continue to be usable on the same physical device, running the same or later Android build from the same system vendor.

(Not even devices of the same model from the same vendor? No: there is no guarantee that two devices branded the same way actually run the same system build under the hood, or indeed are necessarily identical hardware at different points in time during their product lifetime.)

The only way to do this portably is to embed not the raw database file itself, but a genericised parseable representation that can be played into the public API to establish the device-appropriate database file.