5 ms·
I wonder. If an Android app sticks to api level 22, then presumably they can continue demanding those permissions without having them denied, even on Android 6.
by CountSessine 11y ago
I wonder. If an Android app sticks to api level 22, then presumably they can continue demanding those permissions without having them denied, even on Android 6.0, no?
There are already apps that let you re-write a side-loaded app's permissions, but that usually doesn't work very well. I tried re-writing Facebook's permissions and it aborts fairly quickly.
- dethstar 11y agoI guess it depends how they worked it in. Is it in the app permission requesting code? Then yeah, app would need to upgrade their api level. Is it on the OS level, and they'll do something like just give null/useless data when you deny the permisson? Then it wouldn't matter.
- CountSessine 11y agoThat's how cyanogen does it - empty address book, camera that always takes black pictures, etc. But I didn't think that Google would ever do that, and @T-A's link to howtogeek.com seems to confirm this. The app will fail on api calls that previously worked and you'll be stuck restoring the permissions.
- T-A 11y agohttp://www.howtogeek.com/230683/how-to-manage-app-permissions-on-android-6.0/ http://www.howtogeek.com/230683/how-to-manage-app-permission...
- CountSessine 11y agoWhen revoking permissions from older applications, you’ll see a warning message saying, “This app was designed for an older version of Android. Denying permission may cause it to no longer function as intended." Older applications weren’t designed for this feature, and they generally just assume they have access to any permissions they request. Most of the time, applications should just continue working normally if you revoke their permissions. In some rare cases, the application may crash — if it does, you’ll need to give it permission again. So yeah, if Facebook decides to stick to api level 22 for a while, you won't be able to un-privilege it.
- what_ever 11y agoI know you are giving Facebook as just an example but they have updated their app. If any well known app company continues to do this you can assume they are avoiding/delaying the API update to get more of your data and you should stop using them if you can.
- digi_owl 11y agoMy Huawei P6 (yep, a Chinese company providing user selectable privacy options) shipped with some variant of this, and i have yet to see anything break when using it.
- JohnTHaller 11y agoThey can. But you can then enter Options and turn those specific permissions off. Apps like that get fake data, like an empty contact list or that the device doesn't have GPS present/turned on.
- CountSessine 11y agoThat's how cyanogen works, but Google will never do that. The howtogeek.com link that someone else here posted confirms this - apps will just fail and you'll be stuck restoring the permission.
- x1798DE 11y agoWell, you'll restore the permission if you want to use that app, but if you disable microphone permissions and the app breaks for no reason, do you really want to keep using that app?
- CountSessine 11y agoAgreed.
- JoshTriplett 11y agoExactly. An app like Netflix couldn't get away with that; if it started breaking, people would contact Netflix support, and if the answer was "turn on the microphone", people would demand a reason why it needs to have access all the time.
- CountSessine 11y agoI completely agree with you that we shouldn't be using applications that demand more permissions than are obviously needed, but... ...the top 10 flashlight apps in the Play store require network access, camera access, address book access, etc. I can't believe that there would be any great complaint among the majority of android users if Netflix asked for microphone access. And that's exactly why we need the ios-style permissions that google is finally bringing to android.
- mtgx 11y agoFacebook will likely be one of the worst offenders for this. That's why Google may need to enforce the new permission model as soon as Android 7.0.
- izacus 11y agoFacebook already updated their app.