@th_willenbrink@mastodontech.de @mynacol I agree that not doing anything about it and complaining would be a bad way to handle this. That is not what is happening in #FDroid. The targetSdkVersion sandbox literally breaks access to functionality, by design. That is a central design goal. Those who do not understand that do not understand what a sandbox is. The key question here is who gets to decide which functionality remains functional, and which gets banned by the sandbox.
@mynacol @th_willenbrink@mastodontech.de Off the top of my head, I'm currently struggling to get a decent user experience for offline repo mirrors on USB thumb drives using recent storage APIs. Google has locked out lots of functionality to limit how apps use local folders. If you have invasive apps installed, then that limits the damage. If you have good #FreeSoftware installed, then that limits the possibilities. There are many other real world examples out there.
@eighthave @th_willenbrink I'm not that deep into Android development, but two ideas:
1. Can you use the "allow full storage access" (sth like that) permission?
2. The Storage Access Framework should work just fine. Let the user select a folder on _any_ storage provider (think of cloud storage) and you should be able to create files and folders in the selected folder just fine. Only caveat: This does not support standard POSIX syscalls AFAIK.
@eighthave @th_willenbrink At first, a tightened sandbox removes access and therefore features. But if a more secure/privacy respecting API is created to support those features, it's a net improvement.
I think of the old message bubbles and Picture in Picture modes using the "allow to draw over other apps" special permission. Nowadays, apps can provide this functionality without needing this abusable special permission.
So what functionality in #FDroid is absolutely not possible with new APIs??