In case anyone happens upon the same issue when trying to compile for Android, I’m putting this here Thanks to Daniel and MatKat for pointing me in the right direction.
iOS requests permissions ahead of time, so the permission request can be handled using the Projucer setting/manifest. Android as of API level 23 and up requires to the permission request to be handled in the running code itself.
I believe that setting just does the right things in the manifest. I’ve run into the same issue with recording and using the file chooser, ie. needing to add code to invoke the RuntimePermissions code. I’ve even requested that the JUCE team add the permissions request to the FileChooser dialog, so we don’t have to do it every place we user that class… (Any plans for making RuntimePermissions part of FileChooser?)
I’m not an Android user, but it seems a little odd/frustrating to have your user experience repeatedly interrupted by “Allow X to do Y” all the time. Why not just ask all the permissions you’re likely to need at the start and be done with it? I’m probably missing some use-case concept.
For now I’m experimenting with a struct that gets instantiated at the start which in turn triggers permissions to be asked for all the stuff I’m going to need later. It seems to make for a more usable app experience so far. I realise this contravenes Android Best Practice #3 but I’m only playing and learning at the moment so whatever.
Anyway thanks MatKat and cpr for your thoughts and input
@splintersilk, it doesn’t ask all the time. It asks once and remembers. A call to RuntimePermissions::request will only query the user if the permission hasn’t been granted already. Of course, you can choose to ask at startup if you like, but per the link I posted, ‘Android best practices’ recommends that you don’t ask until the user needs the permission. The link explains the rational as well. Having said that, for an audio app that wants to record, I would request the permission at startup, since that is kind of a given based on the app type.