I realized I goofed and that accessing the camera wasn't actually a permission itself. It was permission for the camera to access your location. So everything should be working fine for older sdk + M preview. The issue about not returning to the app that calls the camera after accepting this permission is still a bug.
On Fri, Aug 21, 2015 at 1:14 AM, Joe Bowser <[email protected]> wrote: > On Thu, Aug 20, 2015 at 9:28 PM Karen Tran <[email protected]> wrote: > > > Hi all, > > > > I've been doing some testing with Android M Preview 3 and with Android > API > > 23 to investigate the behavior I'm seeing with permissions. > > I tested older sdk levels with M Preview 3, API 23 with Preview 3, and > API > > 23 with Lollipop. > > * If anyone has different results, let me know. > > > > On master, the target sdk level is currently set to 22. > > Running mobilespec at this target level on the 3rd Preview, all the > > automatic plugin tests passes. > > For manual tests, there are also no regressions, however, when testing > the > > camera, I get prompted for permission. > > > > > This seems odd, since we're using intents to do camera, so it may be camera > asking for the camera permission? It's listed in the Android Best Practices > now, which is hilarious, since we get so much hostility for using intents > instead of owning our own camera. > > > > This is a bit odd because older sdk running on the Preview should use the > > old permission model, which is granting permission at install time, not > > runtime as stated in the Android documentation. > > > Unless Camera is using the new permission model, because it's the new app. > That said, the default Android Camera should already have permission. I > think that this will literally be a one time thing. > > > > > > Another odd behavior is if I accept this permission for mobilespec, I never > > have to accept again, even if another app is accessing the camera. > > > That sounds like the intent for camera asking for the permission, not > MobileSpec. > > > > I tested > > this with another cordova app I made that calls the camera plugin. > > The last odd behavior I noticed is when you accept for camera, the camera > > app itself opens, so when you take a picture, you don't return to > > mobilespec. You just stay in the camera app. This only happens right > after > > accepting. When you go back to mobilespec manually and use the camera > > again, the expected behavior of the camera resumes and your picture shows > > up in the yellow box of mobilespec. > > > > > That is interesting, there's probably a bug with using intents this way, > and a native Android Test app should be written to demonstrate this > behaviour. This is very low priority, since most people will use the > camera before using any other application. > > > > The above behaviors also happen with older sdk levels. > > > > > > Now manually setting the target sdk level to 23, all permissions are off > by > > default, I don't get prompted for any permissions either when trying to > run > > manual plugin tests. Of course having no permissions on, certain plugin > > tests will fail. Turning them all on manually, everything passes. > > Documentation of the new permission model says that we'll need to add > some > > code to check for permissions and request them. > > > > > That's currently as expected. We are currently working on code to ask for > permissions, and we should be re-writing the plugins to expect the code to > > > > > > *On your apps that target the M Preview release or higher, make sure to > > check for and request permissions at runtime. To determine if your app > has > > been granted a permission, call the newcheckSelfPermission() method. To > > request a permission, call the new requestPermissions() method. Even if > > your app is not targeting the M Preview release, you should test your app > > under the new permissions model.* > > > > The cordova permissions we'll need to handle are : > > - contacts > > - location > > - microphone > > - phone > > - storage > > > > > Actually, plugin authors need to be able to handle all the permissions and > ask for them. I have no idea what a third party plugin is going to need to > access stuff, but I do know that it's bigger than the list here. Some may > want some access to the phone itself, and to make calls. Those are the > permissions our plugins need to ask for. > > > > > > Lastly testing Lollipop and older with API 23 looks fine. > > > > > > *TL;DR * > > Using M Preview with API 22 and older should be using the old permission > > model. All tests are passing except some strange behavior with the manual > > camera test which prompts for permission at runtime. > > Using M Preview with API 23 should use the new permission model where > apps > > should request permission at runtime. Our cordova plugins will need to be > > updated to handle this. > > Using Lollipop and older with API 23 should use the old permission > model. I > > didn't see any problems here. > > > > > If you turn a permission off manually, there's problems and we should have > code that addresses those problems. Since we target the lowest API, we > will by default always have our permissions on, and so will every other > real world Android application given Android's poor track record of being > up to date, and that this month is the first month that Gingerbread, the > version that everyone wanted to die is finally past our arbitrary 5% > threshhold for support (which we disregarded because the platform go so > insecure and cumbersome to support, even though we put off incrementing the > minApiLevel). We're going to supporting Samsung Galaxy S2 and S3 devices > for years to come, not to mention the other random Samsung Devices people > have that still run Android 4.1 (like my test camera). > > https://developer.android.com/about/dashboards/index.html > > You know if I had an old PhoneGap app that had the kitchen sink of plugins > installed, the first thing I'd do is turn the off one by one, because an > app telling me about the wonders of a park really doesn't need to have > access to my Contacts. We should offer a compelling reason to upgrade, and > working on the latest version of Android when people become skeptical is a > good reason. Unlike when people do that annoying thing where they don't > let apps run in the background, adding support for this should be expected. > > Regards, > > Karen > > >
