Thanks for the reply, I was a bit perplexed watching the slides as it looked like committing to have 5.0 api level only. When we do code for our internal devices, we settled for a 7.x and newer baseline as pretty much anything that is running 5.x and 6.x today is likely to be very ram constrained.
Maybe is a missunderstanding here. The Runtime Permissions is the way Android 6.0+ Permissions should be used. Evary time you use targetSdkVersion 26+, This is the default behavior for Android 6.0+
There are no permissions when the app is installed, instead, you request them when the app is running (runtime permissions) either all at once first time you run the app (really bad practice and discouraged by Android) or when you are going to do something that requieres it.
For example, the normal flow in an app that uses the camera is to call a checkSelfPermission() if the app donst have it, then it calls to requestPermissions(), When the users allows or deny it, a event is raised onRequestPermissionsResult, If you have the permission, you proceed using the camera, if not, you use a msgbox to tell the user that he cant use the function until he allows it.
Will xojo follow the Android guidelines and have this “RuntimePermissions” functionality? Or what is the idea?
Maybe you can make it part of the activity, including the Check and the Request Subs, along with constants for the permissions and the “RequestPermissionsResult” event.
Edit. The just Including the permissions in the app manifest, is for backward compatibility with Android 5.
Let people have an option to set the min API level to something above Android 5.0 (API 21) in the Xojo project properties. If you need biometrics… better… if you MUST HAVE biometrics, and it is only available on API23+, let the dev set the minimum API to API 23 (>=21) and the dev will guarantee that the app will be only installed on proper platforms.
Yes, this is the idea.
Thanks for the suggestion. I’ve put it on our list for consideration.