feat: Migrate option file selector to SAF

[X1nto]

This gets rid of external file access requirements by moving the patcher options path selector to Storage Access Framework. Because of this change, it has become necessary to 1) separate folder and file selector actions and 2) copy selected folder/file to the app's internal storage. Internal storage refers to Filesystem.tempDir.

androidx.documentfile was added to handle SAF and everything related to external storage permissions have been removed.

screen-20260219-230118.mp4

[oSumAtrIX]

If we exit the app does it remove these files?

[Ushie]

Yes, it's stored in the same place as the temporary files generated for patcher

[Axelen123]

The temporary files will be gone after an app restart and won't be present if manager attempts to use saved patch options. This is partly why I chose not to use SAF when implementing patch options.

[Axelen123]

@X1nto app restarts still need to be handled, since the temporary directory will be cleared on restarts. To fix this, you could:

• Create a new data class for holding the SAF URI (and whether or not it is a folder). The data class probably needs to be java.io.Serializable and/or Parcelable.
• Change StringOptionEditor to : OptionEditor<Any>.
• Set it to a string whenever a string is specified and the custom type otherwise.
• In Options.kt, define and implement a json object representation for the custom type whenever a patch option with the string type is encountered. The SAF URI will be valid even after a restart and can be persisted in the database.
• Move the SAF copying logic and transform the custom types into strings right before passing the options to runtime.execute in PatcherWorker.kt

[X1nto]

@X1nto app restarts still need to be handled, since the temporary directory will be cleared on restarts. To fix this, you could:

• Create a new data class for holding the SAF URI (and whether or not it is a folder). The data class probably needs to be java.io.Serializable and/or Parcelable.
• Change StringOptionEditor to : OptionEditor<Any>.
• Set it to a string whenever a string is specified and the custom type otherwise.
• In Options.kt, define and implement a json object representation for the custom type whenever a patch option with the string type is encountered. The SAF URI will be valid even after a restart and can be persisted in the database.
• Move the SAF copying logic and transform the custom types into strings right before passing the options to runtime.execute in PatcherWorker.kt

TBF this would be much easier if patches themselves could use a different Option type for URIs. The only reason why copying files is even needed is because patches expect a string path instead of URIs. I'll take a look at your suggestion, but sounds like a lot of work.

[oSumAtrIX]

TBF this would be much easier if patches themselves could use a different Option type for URIs. The only reason why copying files is even needed is because patches expect a string path instead of URIs

The reason for this is the direction of dependency. The Manager depends on the Patcher, but not the other way around. Therefore, the Patcher cannot consider the requirements of the Manager and instead, it is the Manager that must take the Patcher into account.

Options are specified with typed intentions for basic types such as string, int, long, boolean, and arrays of these types. These options are compatible with any platform and can be used as base types for arbitrary purposes. You can express any kind of option using them. There are no specific types to avoid unnecessary or unwanted specialization, as the API is designed to be generalized. This is why Options dont have "URI" type. Instead there is the string type, that can be used and serialize as URIs