Based on the email discussion about database corruption after being copied on Android platform.
Here is another corrupted DB. This guy claims that he can repro the problem, pretty much at will. He has a Samsung device (S10) with unusually large storage. I asked him about it and he is quite clear that it is not a removable card.
Also in her are the logcat logs from around the time the problem occurred, and a copy of the db before it was corrupted.
Here is my understanding of the sequence of events:
1) Application syncs a complete local instance of the db.
2) Using Database.copy, it copies that instance to Android external storage
3) Delete the application and all of its storage. This should not affect the external copy.
4) Install a new copy of the application.
5) At startup the application looks for a db on external storage. If it finds one, it uses Database.copy to copy it into the app sandbox.
6) It opens the sandbox copy of the db and finds it corrupted.
I mentioned to the customer that I thought that using OS copy might be a better way to do this. Database.copy is going to give the copy a new UUID and thus make replication sub-optimal