This is why they want the legacy gone, devs were cheating for years. SAF Came in KitKat which was about 2015-2016 or so.
When Android started it was like the new horizon, walled garden debates, all that. Now for some reason Google realized years later (since the start) that full access to a file system would get exploited, imagine that.
That was my point, Android had to appeal to “all others” at that time, iOS was proprietary, so they started straight out with a file access sandbox. Android needed to get established and IMHO is why this mess even exists and was not taken care of at the start (sandboxed file system).
Sometimes it’s just plain depressing talking as an Android dev. So many mistakes along the way, but again it’s what happens when you have to serve “all the rest”, they cut corners. (purely opinion of course)
It seems that of August 2021, Android apps need be built with the target SDK version 30 to allow them to upload to Google Play. That also means the ‘requestLegacyStorage’ trick in the manifest does not work anymore. It thus seems that using the Storage Access Framework is the way to go to allow JUCE apps to read and write to shared folders and to allow export or import of files in your app.
If so, is this something we should request as feature to the JUCE team to prevent everybody to have to write their custom code? If there would be a simple way to use the JUCE URL to be able to read or write a file using SAF would be awesome…
I was preparing to release the app and now ran into this show-stopper…
From earlier tweaking I know it’s dangerous to play around with Projucer/AndroidStudio/Java/NDK/C++.
Suddenly everything blows up or gets overwritten when you save or reload the wrong thing
For now the Android exporter is pretty useless - except you want to deal with apk’s and maybe cash money
We’ve now improved support for working with content:// URLs, such as those returned from native file choosers, through the AndroidDocument API:
Internally, AndroidDocument uses the DocumentsContract API on Android. As a result, it should be possible to read and write to shared locations, as long as the user has granted access to those locations via the native file picker. Unfortunately, DocumentsContract doesn’t support as many operations as File, so changing the implementation of File directly would have resulted in several unsupported or partially-working functions. We decided instead to add a new class which only supports operations that work on all platforms.