how to retrieve data from a db room of another instance of my app

Question

I made a very personal application a while ago, which only 2 of us use (my wife and I).

In this application, I use a room DB.

This application is on the Google Store. And it is installed on my smartphone from the Google store.

I had implemented a remote backup/restore functionality from the database room, to my Apache/php server. But it's a feature we rarely use. Today I realize that it no longer works, but I can't figure out why. I guess it's a bug related to my data in the database.

But if I install the dev version to have the log in android studio, I necessarily lose access to my database (since the installation does not have the same origin I suppose), and everything works correctly, so impossible to find the bug. Same if I run the app in an emulator.

My question is therefore: how to recover my database and use it with the dev version of Android Studio, knowing that it is precisely my backup function that does not work and that I absolutely do not want to lose my data.

Edit:

In other words, I need to explore this database to see what anomaly it causes. The solution is really not to reset it but to explore it. Do you see a solution?

Answer 1

In other words, I need to explore this database to see what anomaly it causes. The solution is really not to reset it but to explore it. Do you see a solution?

With android an App's data (which includes the database(s)) is protected which is the fundamental issue that you are facing.

1. An option would to be root the smart phone in which case you could then access the App's data/data/<the_package_name>/database folder and copy the database file(s) somewhere.

   1. you may find this helpful https://www.androidcentral.com/root

2. Another option would be to develop and then install a version of the App that allows the database file(s) to be copied to an unprotected destination somewhere.

• somewhere could be on or off the device as long as the location is accessible.
• file(s) will be either just the database file or in the case that a file, the same name as the database file but suffixed with -wal (and less important another file suffixed with -shm) and if the -wal file is not empty , the database file and the -wal file and the -shm file. Noting that if the additional files are copied then they should also be copied.
  • SQLite has two logging modes, Journal and WAL.
    • Journal mode keeps a log of the changes made to the database in a file ( -journal ) this can be used to rollback the changes. Importantly without this file only the ability to rollback is lost.
    • WAL (Write Ahead Logging) mode applies changes to the -wal file not the database file. Importantly the -wal file is considered part of the database, without it data will be lost and hence if the -wal exists and is not empty then it MUST be treated as part of the database.

In either case you could then copy the file(s) into the development App's data/data/<<the_package_name>/database folder (using Device Explorer) and that database would then be available.

Alternately in either case, it may useful to utilise an SQLite tool to ascertain the issue (if the issue is purely an SQLite issue and not the UI).

If taking the 2nd option then this could be a feature of the App which if kept would allow future debugging of the database.

• All the above considers copying the database file. However there are other options such as extracting the data as the SQL required to build the database or perhaps a CSV or JSON representation of the data. Typically the file copy will be the most efficient and also the most flexible means of copying/restoring/using the file (any SQLite tool should be able to handle such a file (unless an SQLite encryption tool is used)).