By pressing the Back button in the FilePicker, the file picker exists, and shows this error:
Error 4501: No URI returned to FilePicker
I did not find similar problems with the ImagePicker.
The only way to get around this is to ignore the error with an ErrorOccurred event.
I think this is good because we know the file is not selected and we can handle it accordingly.
As for the display on the phone, landscape mode is even worse.
This is an oversight. In an earlier version of the component the function took a string argument rather than the LOBFValues block. I will look into fixing this, but in the meantime you should be able to do some type laundering using a variable:
The changes we've made for SDK 33 should allow most components to make use of a content URI automatically.
Which is good, but it would be nice to have a built-in convertor block to get the file path, for those situations where one may need it. This would be helpful in many other situations as well, e.g. when using the activityStarter to PICK files. Or to at least return the filename....
The challenge is that, as far as I know, Android does not provide a way to convert content URIs to file URIs directly. In fact, there is no requirements for a content provider's content URIs to actually represent files in the file system. It would be better for folks to think of content URIs as opaque things and that component authors update the logic to support them rather than forcing the more abstract content provider model down to the file system level.
Another problem is intention. If we always copy the content URI to a corresponding file URI, then (1) we use more storage than otherwise might be needed, and (2) it would prevent updating existing files if the write permission is requested. The following is an example of how you might do what you want using the built-in capabilities of App Inventor (although there is a bug in current test server where this doesn't work that will be fixed in the next test server update):
This is a simple test app I had made to copy an image picked using the file picker to the app storage and then copy it back when I selected a destination.
I agree.
Hundreds of extensions still don't support content uris and it is going to be a huge problem soon.
Code taken from here:
However GetContentUri block is misleading as it returns file uri 
Short answer: changes were made to support iOS builds in the buildserver, but the iOS specific functionality will come in a future release
Long answer: The buildserver logic previously had been wrapped up in a single, very complex class called Compiler, this includes all of the compilation, but also processing of assets, creating metadata like the AndroidManifest and other XML files, etc. This makes adding new paths for different target outputs very difficult, as we found out when we added AAB support. This new build server breaks all of the steps building apps into smaller discrete chunks so that we can have common processing tasks separate from platform-specific and target-specific tasks. The iOS build infrastructure stacks on top of this refactoring, but we want to release the two pieces separately so that we can more easily resolve any issues that arise.
Thanks for the explanations.
Tried just now in test server and the issue still exists
Yes, because as you can read the first post, there is no mentioned fix for screen orientation.
The test server has been updated with some bug fixes, including fixes to the companion, compiled apps, and the web interface.
Also, please consider moving the Privacy Policy & ToS link to the top, just like Guide and Report an Issue. This sticky bar at the bottom just looks quite disturbing.
