SoylentNews is people
SoylentNews
A pretty nice addition to [the third developer preview of the OS formerly known as Android M] is granular control over the permissions [which] each and every app requires upon installing it, giving Android users "meaningful choice of control". Just like in iOS, apps in Android 6.0 Marshmallow will only [allow] you to grant them a certain permission immediately before the app needs it and not in bulk during the installation, [as was the case] in previous Android installments.
[...] Android 6.0 Marshmallow officially introduces API Level 23, which is one of the requirements to have app permissions that can be granted on demand. All Android apps need to be updated [by their developers] so that they support the brand new API0 Level 23 libraries in order to introduce the individual granular app permissions.
SiliconANGLE notes that 6.0 is also getting native fingerprint support, a new power-saving mode, and Android Pay.
They also note
Hardly anyone with an existing Android phone will ever get to use [6.0].
[...] Android-powered devices rely on the manufacturer to update the operating system and the reality is that it rarely happens.
To put it more crudely, the Android update process is f**ked.
[...] [As Android remains open source and free to use,] Google can't force manufacturers to come to the party in terms of upgrades [any] more than it can force manufacturers to stop skinning their Android installs with their own custom user interfaces and software.
Release of Android 6.0 is expected in 2015Q4.
Original Submission
(Score: 2) by quacking duck on Monday August 31 2015, @08:56PM
Older apps that used all-or-nothing permissions could get away with not handling a no-location exception, but new ones built around granular permissions will have to handle it and a host of other no-data and no-access conditions. At the very least throw up a "you must enable this app's access to X to use feature Y".
(Score: 2) by albert on Monday August 31 2015, @09:45PM
To the maximum extent possible, an app should not know that a permission has been denied.
If I want to deny network access, just make it fail with a common error that provides no hint that I'm denying. The app should think I'm in airplane mode, down in a subway, or out in the middle of the ocean.
If I want to deny my IMEI number, provide a randomly generated one.
Etc.
DO NOT REVEAL THAT PERMISSIONS ARE DENIED.
I don't want some app to be able to refuse to work just because I refuse to let it do what it pleases.
(Score: 2) by Hyperturtle on Monday August 31 2015, @10:00PM
I am under the impression you won't get what you want.
Heck, upgrading to a new wifi nic on a laptop or desktop will cause some license validation schemes to fail. I was once told that only hackers change their mac addresses. Uh, right. That's why they are locally administrated addresses right? Next thing up will be being called a hacker because I used a static IP on the network.
(Score: 2) by quacking duck on Tuesday September 01 2015, @03:08AM
Thinking it's in airplane mode isn't as useful as you think it is. Chances are the app will just throw up a "please disable airplane mode to continue using certain features" every time you run the app.... which can confuse the user if they previously denied the app network access.
Providing spoofed data to an app falls far outside the intended audience for Android, even given its more techie-friendly nature. I think there's utilities you can load from other sources that do this, but probably have to be run as root.
My take on spoofing is completely opposite yours. Apps deserve to get accurate info when they request it, or be told when they're explicitly denied it. Unless you're the developer of the app you're spoofing, any false info may as well be due to malware.
Incidentally, iOS doesn't even allow apps to get the IMEI, the closest they get is the identifierForVendor (different for every developer, so no point sharing with ad trackers) or advertisingIdentifier (can be reset by user anytime).