Android Sqlite Backup/restore Without Overwriting

Question in short form: It seems from the followups that I should perhaps emphasize and simplify the core of my question. The core is this: other backup options for Android DBs see

Solution 1:

I think the problem of restoring old data without changing (or conflicting with) the ‘newer’ data is not very hard to solve in the scenario you describe. It seems that essentially you just want to ‘add’ the old data (records) to the new database with the assumption that the old data has no logical conflict with the newer data (that is, it is semantically OK to create new records for the old data). I believe that taking care of the primary key conflicts during restoration would be the most important issue to consider.

Let’s take two cases:

1: You are using the auto generation of primary key values feature of the database (e.g., using an AUTOINCREMENT column of a SQLite table).

Let’s assume that the ‘newer’ database records might have used primary key (ROWID) values of 1 to 10 before the restoration process is started. If you have ‘older’ database records with any of those primary key values (1 to 10), you have a problem only if you want to preserve those old primary key values. To avoid that problem, don’t retain the ‘old’ primary key value of an‘old’ record – after reading the record from the ‘old’ database, just save the values of other attributes (columns) of the ‘old’ record and let the database generate a new primary key value for this ‘restored’ record. Essentially, the ‘old’ record is saved with a new primary key value. If you are concerned about maintaining a chronological order of the records after this ‘restoration’ process, I suggest you also keep a timestamp column whose value does not get changed in the process.

2: You are using an alternate mechanism (UUID, Sequence Generators, etc.) for generating primary key values:

In this case, read the ‘old’ record and before saving it in the ‘newer’ database, replace the ‘old’ primary key value with a primary key value generated with the alternate mechanism – that would, by design, guarantee the uniqueness of the primary key value of the ‘restored’ record with respect to the pre-existing ‘newer’ records.

To simplify the programming effort for this ‘restoration’ process, especially if you are dealing with multiple tables, you may use an ORM like JDXA. One of the sample apps shipped with the SDK illustrates a similar technique for transferring ‘old’ data while upgrading a database to a newer version. JDXA also offers a convenient sequence generator mechanism to easily and efficiently create unique ids that you can assign to your objects before persisting them.

Solution 2:

After continued research I'm increasingly concluding there isn't a better approach to this problem. For a simple backup you can simply copy the database file as many of the other threads discuss and leave the overwrite on restore issue unaddressed (and also risk compatibility problems evidently: https://stackoverflow.com/a/10842043/3108762). For a truly robust backup you just have to write your entire DB out to XML and read it back in with all the work that entails.

The only better alternative I've found is mentioned in https://stackoverflow.com/a/34477622/3108762 which refers to the new Android feature Configuring Auto Backup for Apps, but only works in Android 6.0 and up. I will be testing that, but if it doesn't work, and for anything below Marshmallow, it seems writing my entire DB out to XML and then reading it back in again is the only truly robust approach. Not entirely a surprise but good to know.