Open mentalisttraceur opened 3 years ago
adb backups would be useless for devices with Android 6 or higher, as I explained in https://github.com/johanw666/Signal-Android/issues/11 . I am considering a method to restore custom encrypted backups before registration to prevent the safety number warnings.
Use-case debuggability independent of backups: manually getting into the Signal sqlite database to modify settings which cannot be modified through the app itself.
Personally, I had to do that a couple years ago when I accidentally modified a contact color and I wanted to set it back to the default unset darker gray (rather than the manually settable lighter gray) and at the time I could only do this my modifying the database.
From what I hear, the default Signal backups are like this too - the actual scheduled time for the next backup is not exposed in the settings.
Point being: there's almost always the possibility of a user justifiably wanting to change a setting currently not exposed by the app's interface.
Please add
android:debuggable="true"
to the manifest, in the `<application ...> element.This would allow users to use the
run-as
command inadb shell
. This opens up a lot of flexibility, so much that I can't exhaustively list everything that a technical user might be able to do with it.But among other things, it would give technical users another option for backup and restore of the app data (without the Google Cloud backups downside of allowing direct native Android backups like in issue #11 ), including private keys (avoiding the "your safety number has changed" thing), in a way that someone familiar with command line tools would find more convenient or easier to automate.
The only downside I can think of is that on a non-rooted device, a malicious party with physical access to your phone (including ability to unlock it) could access your Signal data with
adb
.But I think with the features of this fork, anyone with that level of access could get the data in other ways too, so this is just adding the convenience of another way of doing it without any obvious additional security risk.