All committers have signed the CLA.

I rebase it, as "feat: Storage.Pickers.PickerLocationId (#4242)" was merged into master. Added some changes. As the only way known for me after rebase is sqash commits and force push, I did just that - as side effect, loosing what was changed by Martin and what was changed by me.

oh 😅 , I hope I have a local copy of the branch somewhere

All your changes are preserved.
Lost is only "metainfo", who changes what.

Build errors outside scope of this PR. Could you restart build?

Can build be restarted? "Publishing build artifacts failed with an error: Not found PathtoPublish:", not related to this PR.

@pkar70 Some of the build errors do look like they come from this PR:

src\Uno.UWP\Storage\Pickers\FileOpenPicker.Android.cs(33,8): Error CS0234: The type or namespace name 'PermissionHelper' does not exist in the namespace 'Windows.Extensions' (are you missing an assembly reference?)
src\Uno.UWP\Storage\Pickers\FileOpenPicker.Android.cs(33,8): Error CS0234: The type or namespace name 'PermissionHelper' does not exist in the namespace 'Windows.Extensions' (are you missing an assembly reference?)

What is this PermissionHelper? It doesn't exist in UWP or Uno according to my searches. It appears to be an Android-specific helper you may have added yourself?

I checked only first screen with errors, all not related to this PR... And didn't look further.
Yes, this is typo - should be "Permissions", plural form :)
From current Uno, although my additions to PermissionsHelper (#4186) are still waiting for some feedback...

Build error "Removed type Windows.Storage.StorageItem not found in ignore set" seems to be unrelated to this PR. Can you restart build?

Today I recompiled Uno with this PR, for Android, and something was changed. With "base Uno" 2.2.0-dev.386, it works. With "base Uno" 3.1.6, it doesn't work - it shows picker, allows to select file, it even return selected file to app, but it shows splash screen (or empty screen, if no splash screen is defined).
My app works, importing (slowly) SMS messages from text file, but with no screen updates..

Hello guys,
regarding FIleOpenPicker.. I tried to launch fileOpenPicker on Android from opened contentdialog. As efect.. fileopendialog was opened but after file selection (picker disappear).. my contentdialog disappear as well. The funny is, that contentdialog disappear, but control to main view was not returned (seems, that content dialog still present somewhere).

It works with target Android 9.0 and Uno 2.2.0-dev.386; but Uno 3.1.6 and target Android 10.0 - effect as you described. I don't know if it is some change in base Uno, or in Android.

I verified with version 3.1.6 and 3.6.0-dev.103 on Andorid 10 and andorid 8. In both, effect is the same. FIlePicker close content dialog. Seems, that if it works in 2.2.0, issue is in UNO

You run it "on Andorid 10 and andorid 8". But what was target SDK? In both cases, Android 10?
It is important, as Android changes behaviour accordingly to target SDK.
Issue can be somewhere in Android, Uno, Mono, Xamarin, etc. ;)

I debugged your branch and what i found:

1. Opening FilePicker trigger OnPauseMethod() in class ApplicationActivity (in our case ApplicationActivity.Android.cs )

    protected override void OnPause()
    {
    	base.OnPause();
    	VisualTreeHelper.CloseAllPopups();
    	DismissKeyboard();
    }
   

As you see in this method all Popups are closed (content dialogs included)
If I comment out it, content dialog never disappear. Now I wonder about use cases. Should we close any popups once application is paused (swiched to another app by user). I observed, that many applications stay in popup state once is switched but also I've seen apps which close popups.
Question is how we want to handle it?

2. Second topic (maybe related) directly to your FileOpenPicker. I observed that if I select file (any.. picture, document, etc...) your picker always return null.
   I verified my permissions and internally in class FileOpenPicker(.Andorid.cs) handler FilePickerHandler return file, but your converter PathFromUri parse it invalid .. or I'm wrong.

(2) It works OK in my app (besides blank screen after selecting file) - app opens file, and starts importing SMS messages. But my file is local (/Download), my tablet (the only device with Android) has Android 8.1, and I'm using Uno clone from 3.1.6 (because I have several Uno apps, and have too many non-merged PR to rebuild and retest everything after each Uno change).

FileOpenPicker added as part of #5436, partially based on this PR, partially custom for content: URI operations