The problem with Android is that permissions can be disabled on a whim, no matter how you set them up, and JUCE doesn’t allow any flexible way of checking and prompting for the required permissions. This is especially problematic if we rely on file CRUD operations, and the user decides to disable file permissions (nothing we can control on the field, but we can definitely manage this in the app).
No solution is straightforward to extend JUCE: Android contains too many permissions to count (Manifest.permission | Android Developers) so I don’t think a reasonable request would be to “just add all of them” to the list of juce::RuntimePermissions::PermissionID.
Instead, a flexible option could be allowing users to check string versions of these IDs. (eg: QtAndroid::checkPermission)
We really need this extremely bare necessity of an Android feature, and I’d prefer not hand-rolling my own solution or forking JUCE to get ahead. It’s unnerving that a cross-platform SDK with Android support doesn’t have the basic ability to check any permissions at any given point.
The PR is more or less ready to go and just needs some eye balls. Any feedback on the PR will be addressed immediately.
I’ve come to the conclusion that the FR category is pointless - no one pays any attention to anything here. Even if they did, the chances of getting anything done on Android/iOS is practically 0 as has been shown for the last 2-3 years.
Polls are meaningless in this case though - not as many people are using the iOS/Android features so those results are most likely going to be lower - that however, doesn’t mean that they’re not wanted by the people using them.
For example, if only 100 people are using those features but 80% of them vote for updates that’s going to be low compated to 1000 people using a feature and 50% of those wanting updates.
This is the same broken logic behind the FR system on the platform.
One of the main reasons I chose Juce was for iOS/Android and I pay my license fee every year just like everyone else so there should be updates to that part of the system. Once they offered a solution providing those platforms and accepted money for it they made an implicit agreement to keep supporting them, in my opinion anyway, or they should explicitly say they are not supporting it any more so that we can look for other solutions and stop paying for a system which is not going to continue to meet our needs.
