feat: settings migration (compose)

[BenjaminHalko]

Allows compose to import flutter settings.

On the first run it will detect if the flutter manager is present on the system, and then will query content://app.revanced.manager.flutter.provider/settings.

Edit: It not longer uses content://app.revanced.manager.flutter.provider/settings instead it launches an Activity from Flutter.

[BenjaminHalko]

[PalmDevs]

UI looks good to me.

[BenjaminHalko]

Now instead of showing the "Would you like to import legacy settings" dialog on Compose, it will start an export settings activity on Flutter.

[Ushie]

What about a popup offering to uninstall ReVanced Manager flutter after importing?

[oSumAtrIX]

Ideally, the update happens seamlessly without any interruption. This means that once an update is offered in ReVanced Manager and the user updates, ReVanced Manager Compose imports the settings and uninstalls Flutter if it detects it. After the migration is done, it will disable this functionality in case you ever want to go back. This will feel and look like a usual update without any user interaction.

[Ushie]

Is that possible without any user intervention?

[oSumAtrIX]

@BenjaminHalko Exposing a content:// URL allows any app on the device to hijack the keystore password or other sensitive data. Is it possible to check the signature of the app that tries to read the settings?

@Ushie Uninstalling will probably trigger the Android uninstall popup. To not confuse the user after the update. Once the new app is launched, it can show a popup clarifying that ReVanced Manager has been updated and the old one should be installed. Once the user presses next/ok, uninstallation can be triggered. Other than that everything else should be possible to automate.

[BenjaminHalko]

@oSumAtrIX It not longer uses content://app.revanced.manager.flutter.provider/settings instead it launches an Activity from Flutter.

see #1308

[PalmDevs]

@BenjaminHalko Exposing a content:// URL allows any app on the device to hijack the keystore password or other sensitive data. Is it possible to check the signature of the app that tries to read the settings?

This is no longer the case anymore. Now there's an activity on Flutter's side which prompts the user. However, if you want a 0-interaction importing, we can possibly have it if both sides can provide an activity to verify each other.

🤮 = Flutter (import activity)
😄 = Any app
🔥 = Compose (verify import activity)

😄 calls 🤮 with randomly generated token
🤮 calls 🔥 with the token 😄 gave

If 🔥 doesn't exist OR responds with a no (token unmatched):
- 🤮 responds back, but doesn't give any settings data
else:
- 🤮 responds back to 😄 with settings data

[oSumAtrIX]

Flutter needs a whitelist of the signature of Compose manager. It checks the callers signature and verifies if it's legitimate. This is similar to GMS verifying signatures

[BenjaminHalko]

However, if you want a 0-interaction importing, we can possibly have it if both sides can provide an activity to verify each other.

Well we want some interaction, what if the user does not want to import their settings

[oSumAtrIX]

No interaction should be present. This update should look to the user like a regular update with no intervention. This means the user presses update, is prompted to install the app, compose initiates the migration phase with the least amount of Intervention necessary. One Intervention will be necessary as a restriction on Android to uninstall the old package. A popup will explain why and the user is given the option to keep the old version.

[Axelen123]

Should the LegacySettings data type file be stored somewhere other than in network/dto? It doesn't really have anything to do with networking.

Yeah it doesnt really belong there. Maybe just put it in the viewmodel or activity file and make it private

[BenjaminHalko]

@Axelen123 All done

[Axelen123]

Still need to switch to rememberLauncherForActivityResult

[BenjaminHalko]

@Axelen123 done

[BenjaminHalko]

@Axelen123 done

[BenjaminHalko]

@Axelen123 done... again.