Just an FYI on backing up the database. I currently do this in my app the same way you are explaining above. Beware when creating backups this way. It works great for the most part, but the problem is that the backup that's created is not guaranteed to be compatible with all devices and Android versions. I thought this sounded odd the first time I heard that, but I'm now finding that it's true. I have been receiving several reports lately of missing data, disappearing data and such. This was all happening when the user was restoring a backup either from a different device or a different Android version or ROM. A few of them contacted me directly, which was great, so I was able to get backup files from the to test them out and examine them. When I tried to restore them, I would get the following logcat error: android.database.sqlite.sqlitedatabasecorruptexception: database disk image is malformed
What I was finding out was that, mainly, certain HTC devices and some custom roms (on any device) were creating these backups that wouldn't restore to other devices or roms. The databases weren't really corrupt, but Android thought they were. I would take them into a SQLite browser and no data would show there either. It turns out that newer versions of SQLite have WAL (Write Ahead Logging) enabled by default and if it is enabled and a backup is made with that database, it cannot be restored to an older version of SQLite or even sometimes the same version (for some odd reason). So, I disabled WAL with "PRAGMA journal_mode = DELETE" and then I was able to view the database in the browser and able to restore it on my test device fine. The other problem is that there doesn't seem to be a way to catch this exception in code and Android automatically deletes the database when it comes across this exception (very bad management on Android's part in my opinion).
Sorry for the long response, but I wanted to explain what I was seeing happening with this sort of backup. I'm in the process of trying to find another way to create a universal backup on the SD card. Creating csv files and sql scripts like @Kingamajick said may be another way to do it. It is more code and more work, but if it works on any device, SQLite version and ROM then it would be worth it. Your customers losing data is never a good thing.
これが最良のアプローチのようです。確実性を高めるために、コピーする前に SQLite ファイルのチェックサムを取得し、宛先ファイルと比較することを検討してください。コピーを取得するときに、データベースへの接続が開いていないことを確認してください。そうしないと、DB が復元されたときに予期しない状態になる可能性があります。
私がそれを行うことができる他の唯一の方法は、DBの実際の内容を読み取り、復元できるSQLを含むファイルを生成することです.これは明らかにより複雑であり、利点はありません.この複雑さを正当化します。
Kingamajick の回答にコメントを 1 つ追加します (フォーラムでは、実際のコメントとして追加することはできません)。単純にファイルをコピーするアプローチでは、ユーザーが DB を復元したときに、たまたまそこに既にデータが存在していた場合、それは上書きされます。たとえば、ユーザーが新しい電話にアップグレードし、それをしばらく使用した後、古い電話からデータベースを復元すると、新しい電話に既にあるデータは失われます。これは、DB を読み取ってファイル (XML や CSV など) に書き出す複雑さに対する利点の 1 つです。
誰かがこの問題を回避するより良い解決策を持っていることを期待して、別の質問 ( Android sqlite バックアップ/上書きなしの復元) を投稿しましたが、今のところ解決策はないようです。それとssuperz28が指摘した懸念との間で、DBをバックアップするより安全な方法は、DBをxmlに書き出してから読み取り、復元時に再度追加することです.
また、https://stackoverflow.com/a/34477622/3108762は、これまでに見た他の提案の中で最高のものであり、マシュマロからこれに取り組むためのより良い方法を約束します.