(I was hoping to comment on the blog directly, but haven't been able to get the WordPress SSO to work - hence contacting you this way.)
In Android 9, it seems that Google have changed the default operation of SQLite to use something called "Compatibility WAL (Write-Ahead-Logging)". Full details are here, and there's more about the WAL concept itself here but, in a nutshell, it means that just copying over the database is no longer sufficient in itself.
To resolve this I initially tried manually deleting the *-shm and *-wal files on the device when copying over the archive DB version, but that ends up with the DB stuck in a locked state. In the end, the simplest option I found was to disable WAL when running in debug mode.
Just sharing these findings case it helps save time for you and anyone else!
hereisderek
commented
5 years ago
@overhq, thanks for your grest blog post at https://riggaroo.co.za/automated-testing-sqlite-database-upgrades-android/. I found it really useful.
(I was hoping to comment on the blog directly, but haven't been able to get the WordPress SSO to work - hence contacting you this way.)
In Android 9, it seems that Google have changed the default operation of SQLite to use something called "Compatibility WAL (Write-Ahead-Logging)". Full details are here, and there's more about the WAL concept itself here but, in a nutshell, it means that just copying over the database is no longer sufficient in itself.
To resolve this I initially tried manually deleting the
*-shmand*-walfiles on the device when copying over the archive DB version, but that ends up with the DB stuck in a locked state. In the end, the simplest option I found was to disable WAL when running in debug mode.Just sharing these findings case it helps save time for you and anyone else!