Add export/import ability

[gdt]

I would at least like to be able to look at the data in the database. For export, the simplest thing seems to be just copying the database file (assuming it is sqlite) to the (real or emulated) SD card.

For import, this could be more work than is justified, but just iterating over a database in the above format and adding info for emitters not already known would help a lot with syncing between multiple personal devices.

[n76]

To export the sqlite database, from a computer attached via a USB cable with ADB enabled:

> adb root
> adb pull /data/data/org.fitchfamily.android.dejavu/databases/rf.db

My fear is that adding settings and controls will make the backend more complex that it needs to be. With the advent of Lineage with microG I see a future with more people consider to use microG who are not as technically minded as currently. Every bell and whistle, even something as simple as getting and setting a API key, incrementally increases the work/fear factor and can decrease the adoption rate.

That, and my experience with the local WiFi and local GSM backends is that some people seem to have to play with controls they don't understand and then I feel obligated to try and help them. :(

So my goal, is to make this, to borrow an old phrase from the Apple ecosystem, "just work".

On the other hand, having a backup/restore option could be a reasonable request. To the best of my knowledge I've done nothing to block a standard backup utility from backing up and/or restoring the database.

[gdt]

Thanks. (I was pretty sure that I could grab the database with root.)

I can certainly see the point about complexity. I guess the big question is if you are opposed to the concept of a settings UI at all, or trying for the more limited properties of not having things that can be misconfigured, or not having things that could be confusing.

[n76]

With a few more steps you can restore that same database. I ended up doing that a few times to test the database migration needed from my first released version of the backend to the current version. Only real trick is to disable the backend so it is not in use, that you set the restored database file ownership and that you delete the old journal file before re-enabling the backend.

I have been hoping for no settings at all. I can see a legitimate argument for a limited settings menu that simply had a backup and restore option.

But am leery of a "slippery slope" where once a settings menu exist people start pressuring for more controls. Each one would have, of course, a very reasonable use case. And eventually you end up where the other two older backends are.

[gdt]

It was not clear from the README if the recording service was active only when the backend was enabled to be used for location. It makes sense that if it isn't, it shouldn't be allowed resources, but it also makes sense to passively scan anyway. It would be nice to explain this in the README, even if logically this is forced by the way unifiednlp works.

[n76]

Good point regarding the README.

[X-Ryl669]

Could you add a BroadcastReceiver for a specific intent's action name, that would reply with the path to the database (or better, trigger a database dump to a defined, accessible, location, since the former requires root to read). This would allow a third party app to backup the database (and, depending on the author's will, maybe to synchronize it online?). Similarly for a import intent ?

This would clearly add no UI requirement, and be transparent to users, yet, it can be used by some other software a user will decide to install. Obviously, for security reasons, you might trigger a notification when such intent are received, so the user will notice any unexpected "backup" of the database.

[n76]

If/when I get around to implementing a backup/restore it is very likely to along the lines you suggest: Create a helper app that sends backup or restore intents to the backend and then have the backend generate a CSV file or read one.

[X-Ryl669]

Using a plain sqlite DB might be easier in the end, since it allows fast lookup (what a CSV does not, at least without implementing it yourself) so it might prove useful for finding duplicate when sync'ing. Generating a CSV from a DB's query/cursor is a 10-lines' job, so might be left for the helper instead, if it need it.

Anyway, it's cool!

[SebiderSushi]

Is storing the database in the Context.getExternalFilesDir() no option at all?

[ProjectMoon]

I was bitten by this. It would be a nice thing to at least store the database in a non-root location for ROMs that don't have root access like Graphene or Calyx OS.