This post is old and applies to AIR SDK 23 and lower. If you are using AIR SDK 24+ read here
Since the release of Android 6 Marshmallow, Google has changed how permissions are handled in Android applications. In simple words, they are now working similar to how iOS permissions used to work for years. I think it’s a very good approach though as this will make users feel more secure by knowing that high risk permissions won’t work unless explicitly allowed to. But what does all these mean to an Air developer? In this post, you will clearly understand everything you need to know about handling permissions in Adobe Air apps.
Handling Permissions on iOS:
First, let’s see how permissions are handled in Air apps when built for iOS. As an example, let’s imagine that you are building an Air app that requires access to the camera. Depending on your needs, you are either using the classic Camera library in AS3 or you are using an Air Native Extension. No matter which one you are trying, as soon as you call to open the camera lens, a native iOS window will open and asks you if you are going to allow the application access the camera. This seems all good, right? The missing part is that what if the user is not allowing the access? you cannot easily check if your app has access to the feature or not. besides that, a user can always go to the app’s settings manually and decline the permission from there, when your application is closed! so, although you may be able to prevent your app from hard crashing by different tricks, but there is no easy way to manage this. So, we decided to develop a new ANE for you to be able to not only check if a specific feature like the camera access is allowed or not, but also you can request for the permission. The ANE also lets you open the app’s settings menu right from within your Air app. This ANE will help you big time to manage permissions on iOS apps. You can grab the extension from here.
If you are building an Air app, using this ANE will greatly help you everything you need when dealing with permissions on iOS.
Handling Permissions on Android:
Prior to Android 6, all you had to do to manage permissions was to introduce them in the manifest .xml file. And that was all. But starting with Marshmallow, you have to request for dangerous permissions inside your code before you try to use the APIs required by that permission. This sounds kinda scary to Air developers because they don’t have access to Java code to handle such things. BUT there is a cache here! and you don’t need to worry about the new permission things on Android as right now. Today that I am writing this post, your apps being compiled even with Air SDK 22 beta (UPDATE: AIR 23 is also using an old version of Android SDK), will work just fine like before on Android 6 devices even if you are using dangerous permissions in your app! So, nothing has to change on your side at all. How’s that possible? well, it has a very simple explanation. If you read the the Android documents here, it says “If the device is running Android 6.0 or higher, and your app’s target SDK is 23 or higher: The app has to list the permissions in the manifest, and it must request each dangerous permission it needs while the app is running“. Well, as today, Air SDK 22beta is still using Android SDK lower than 23! So, your apps, being compiled with Air SDK will work just like before with no problem.
We have opened a feature request on Adobe’s bug center where you can follow to know when Adobe team will add the feature. As soon as they do, you can be sure that we will add Android support to our Permission Check ANE also (And yes, updates are free as always!). So you will be safe with the latest changes.
UPDATE: Now permissions are also supported on Android! We have also update the Permissions ANE.
Click here to learn more about the Android support and new permissions support.
Understanding Android and iOS permissions in Adobe Air apps
Since the release of Android 6 Marshmallow, Google has changed how permissions are handled in Android applications. In simple words, they are now working similar to how iOS permissions used to work for years. I think it’s a very good approach though as this will make users feel more secure by knowing that high risk permissions won’t work unless explicitly allowed to. But what does all these mean to an Air developer? In this post, you will clearly understand everything you need to know about handling permissions in Adobe Air apps.
Handling Permissions on iOS:
First, let’s see how permissions are handled in Air apps when built for iOS. As an example, let’s imagine that you are building an Air app that requires access to the camera. Depending on your needs, you are either using the classic Camera library in AS3 or you are using an Air Native Extension. No matter which one you are trying, as soon as you call to open the camera lens, a native iOS window will open and asks you if you are going to allow the application access the camera. This seems all good, right? The missing part is that what if the user is not allowing the access? you cannot easily check if your app has access to the feature or not. besides that, a user can always go to the app’s settings manually and decline the permission from there, when your application is closed! so, although you may be able to prevent your app from hard crashing by different tricks, but there is no easy way to manage this. So, we decided to develop a new ANE for you to be able to not only check if a specific feature like the camera access is allowed or not, but also you can request for the permission. The ANE also lets you open the app’s settings menu right from within your Air app. This ANE will help you big time to manage permissions on iOS apps. You can grab the extension from here.
If you are building an Air app, using this ANE will greatly help you everything you need when dealing with permissions on iOS.
Handling Permissions on Android:
Prior to Android 6, all you had to do to manage permissions was to introduce them in the manifest .xml file. And that was all. But starting with Marshmallow, you have to request for dangerous permissions inside your code before you try to use the APIs required by that permission. This sounds kinda scary to Air developers because they don’t have access to Java code to handle such things. BUT there is a cache here! and you don’t need to worry about the new permission things on Android as right now. Today that I am writing this post, your apps being compiled even with Air SDK 22 beta (UPDATE: AIR 23 is also using an old version of Android SDK), will work just fine like before on Android 6 devices even if you are using dangerous permissions in your app! So, nothing has to change on your side at all. How’s that possible? well, it has a very simple explanation. If you read the the Android documents here, it says “If the device is running Android 6.0 or higher, and your app’s target SDK is 23 or higher: The app has to list the permissions in the manifest, and it must request each dangerous permission it needs while the app is running“. Well, as today, Air SDK 22beta is still using Android SDK lower than 23! So, your apps, being compiled with Air SDK will work just like before with no problem.
We have opened a feature request on Adobe’s bug center where you can follow to know when Adobe team will add the feature. As soon as they do, you can be sure that we will add Android support to our Permission Check ANE also (And yes, updates are free as always!). So you will be safe with the latest changes.
UPDATE: Now permissions are also supported on Android! We have also update the Permissions ANE.
Click here to learn more about the Android support and new permissions support.
Enjoy building Adobe Air apps.
MyFlashLabs Team
Share this:
Related