fix(droid): FileOpenPicker public path

[ajpinedam]

GitHub Issue (If applicable): closes #16587

PR Type

What kind of change does this PR introduce?

• Bugfix

What is the current behavior?

What is the new behavior?

PR Checklist

Please check if your PR fulfills the following requirements:

• Docs have been added/updated which fit documentation template (for bug fixes / features)
• Unit Tests and/or UI Tests for the changes have been added (for bug fixes / features) (if applicable)
• Validated PR Screenshots Compare Test Run results.
• Contains NO breaking changes
• Associated with an issue (GitHub or internal) and uses the automatic close keywords.
• Commits must be following the Conventional Commits specification.

Other information

Internal Issue (If applicable):

[unodevops]

🤖 Your Docs stage site is ready! Visit it here: https://unodocsprstaging.z13.web.core.windows.net/pr-16863/index.html

[ajpinedam]

Sample app running with a new Manual Test"

Picking Videos	Picking Photos

[unodevops]

🤖 Your Docs stage site is ready! Visit it here: https://unodocsprstaging.z13.web.core.windows.net/pr-16863/index.html

[jeromelaban]

Where is this hash coming from?

[ajpinedam]

This is just a directory name. We can name it differently and have a different value, like "UnoPlatform"

[MartinZikmund]

I'm not sure if this is reliable, as the user can pick from any arbitrary location and the path will in many cases be not accessible via an actual path, only via that Android SAF framework. There is however a way to cache access to previously opened files (maybe it is just about storing the content URI, I don't remember exactly), so we could use that to implement FutureAccessList API

[MartinZikmund]

Ah, I understand now, so this does copies the picked files into the temporary storage of the app? I'm not sure if that is the ideal, as this means that if a potentially large file is picked, it will take time to copy it as well as it will require additional space on the device. Plus, I think that this change means one cannot do actual read/write changes to picked files, as modifications will actually be done to this private copy instead, so this could even be a breaking change. I guess if that is the only way, it should be responsibility (workaround) of the user to copy the file to temporary storage instead, as the path that is shown there is not the "actual" path to the source file anyway. What do you think @jeromelaban?

[MartinZikmund]

@ajpinedam we discussed with Jerome and actually making a temporary copy would really be potentially breaking. Could you see if there is a way to get the file size from the Android Storage Access Framework URI (https://developer.android.com/guide/topics/providers/document-provider)? Then we could implement the StorageFile.GetBasicPropertiesAsync() API that would include this information, without making a local copy

[MartinZikmund]

Sorry about that close, accidental :-D

[unodevops]

🤖 Your Docs stage site is ready! Visit it here: https://unodocsprstaging.z13.web.core.windows.net/pr-16863/index.html

[ajpinedam]

@jeromelaban @MartinZikmund here's the PR with the documentation changes related to this issue: #17143

[ajpinedam]

Closing as we are not going to go this route as these changes break some other functionality. Refer to the documentation for more information.