[frik]

Permissions

"We are giving users control of app permissions in the M release. Apps can trigger requests for permissions at runtime, in the right context, and users can choose whether to grant the permission. Making permission requests right when they’re needed means users can get up and running in your app faster. Also, users have easy access to manage all their app permissions in settings."

Great, finally Google got it. Hopefully with the old Android 2.3 style fine granular permissions and not the few permission groups of Android 4/5.

[calvin_c]

They've actually set the number of permission groups to 8. But at least you can accept/decline each individually.

EDIT: The permission groups are

Location

Camera

Microphone

Contacts

Phone

SMS

Calendar

Sensor

[rentnorove]

Conspicuously absent:

- Read external storage

- Internet

[christop]

"When the user installs or updates the app, the system grants the app all permissions that the app requests that fall under PROTECTION_NORMAL. For example, alarm clock and internet permissions fall under PROTECTION_NORMAL, so they are automatically granted at install time."

Based on the Android 5.1 source, there are a lot of permissions in the "normal" group, which will apparently now be accepted automatically at install time:

  $ curl -sL http://git.io/vklnX | grep -B2 'protectionLevel="normal"' | grep name | cut -d'"' -f2 | sort
  android.permission.ACCESS_LOCATION_EXTRA_COMMANDS
  android.permission.ACCESS_NETWORK_STATE
  android.permission.ACCESS_WIFI_STATE
  android.permission.ACCESS_WIMAX_STATE
  android.permission.BROADCAST_STICKY
  android.permission.CHANGE_NETWORK_STATE
  android.permission.EXPAND_STATUS_BAR
  android.permission.FLASHLIGHT
  android.permission.GET_ACCOUNTS
  android.permission.GET_PACKAGE_SIZE
  android.permission.GET_TASKS
  android.permission.KILL_BACKGROUND_PROCESSES
  android.permission.MODIFY_AUDIO_SETTINGS
  android.permission.PERSISTENT_ACTIVITY
  android.permission.READ_SYNC_SETTINGS
  android.permission.READ_SYNC_STATS
  android.permission.RECEIVE_BOOT_COMPLETED
  android.permission.REORDER_TASKS
  android.permission.RESTART_PACKAGES
  android.permission.SET_TIME_ZONE
  android.permission.SET_WALLPAPER
  android.permission.SET_WALLPAPER_HINTS
  android.permission.TRANSMIT_IR
  android.permission.VIBRATE
  android.permission.WAKE_LOCK
  android.permission.WRITE_SETTINGS
  android.permission.WRITE_SYNC_SETTINGS
  android.permission.WRITE_USER_DICTIONARY

Though note that the INTERNET permission is currently in the "dangerous" permission group, so I guess some changes have been made for Android M.

[Aldo_MX]

  Application YourTypicalMobileApplication is asking for access to the Internet
  to display advertisements powered by Google AdMob.

                                                             [ D̶E̶N̶Y̶ ] [ ALLOW ]

  (Do you think we would give you the option to easily cut our income?)

[socceroos]

Then please, oh please separate it out. Internet and Advertising. Shouldn't be hard.

[Manishearth]

> Shouldn't be hard.

How can the OS tell if an HTTP request is for the Internet or for Ads? It can't.

Though Google could special-case AdMob effectively owning the ad scenario for apps which don't use the internet for anything else.

[socceroos]

That's what I meant. It covers a good ~95% of all ads. Have any extras register for security exemption. Makes sense to me - in the context of not screwing the user over constantly.

[vardump]

Can't agree more. It always bothers me all apps can access my external storage by default.

But I have to use Android, because it's the most open established mobile ecosystem. Only system that supports the mobile web browser I find tolerable to use for instance (hint - it's not the default browser or Chrome). Only system that allows developers to map executable pages. Only system that allows me to customize user experience as I see fit, and not offer one size fits all. And so on.

[digi_owl]

I guess they consider external storage to be already handled by the Storage Access Framework.

As for Internet, they leave that out of their "improved" Play store permissions as well (and the M groupings seems like a carbon copy).

[wongarsu]

>As for Internet, they leave that out of their "improved" Play store permissions as well (and the M groupings seems like a carbon copy).

Why would they do that? On it's own "Internet" may not seem to be an important category, but I am willing to give apps many more permissions if I know that they can't phone home. For tools, the Internet permission is often the deciding factor for me.

[ufmace]

I'd like to see a modified internet permission that permitted access to only a specific domain. Maybe along with a policy prohibiting or discouraging using the all-internet permission for anything that didn't clearly need it, like say a web browser. Say the Twitter app only has permission to access URLs under twitter.com, and accessing any other URL domain is a separate permission.

I'm not sure if Google would go for it, but I suppose it would encourage devs to use Play services for ads and analytics, since it wouldn't need any extra internet permissions, while using an external service for either would.

[vardump]

A few years ago mobile virtualization was hyped a lot. What came of it? I'd love to be able to run multiple OS instances on same phone. Use one for private communication and others for fun and games (not that I play games, but the point).

[arthurfm]

There isn't any need for the OS to be virtualized now that Android supports dual-personas (i.e. Android for Work). [1]

[1] http://arstechnica.com/information-technology/2015/03/a-revi...

[mcintyre1994]

Nowhere near the same but android does support multiple accounts - might be worth looking into whether they're sandboxed enough to stop apps looking beyond the account they're installed on.

[on_and_off]

Crash reporting and analytics come to mind as reasonable applications of the default internet permission.

[zmmmmm]

Google should silo those into separate categories to generic "internet access". Same with ad access. Sending data to pre-whitelisted, registered and trusted sites that register with Google in advance should be in a different category to "upload to random server in china".

[hrktb]

Isn't there an entry point on the OS/Google Play side that allows the dev to get crash reports?

Also, I think analytics should be something fundamentaly optionnal, at least from a privacy POV.

[digi_owl]

Everyone with a pulse has asked themselves that already, and come up blank. All we have are potential conspiracy theories revolving around ad revenue for both Google and app devs.

[magicalist]

Except all the mobile operating systems do this?

[mappu]

I recommend AFWall+ for preventing the latter.

[e40]

What I see missing, that Xposed + App Ops gives me is the "Keep Awake"... having revoked this permission from almost all non-Google apps, my battery life is a full 50% longer than other people with my phone report.

[digi_owl]

Best i can tell, Doze is supposed to cover that automatically. But then Doze will wake the device up if a GCM priority notification comes down the wire. And i expect Facebook and the rest to start spamming those to make sure they get every nanosecond of your life to their servers.

[e40]

Yeah, I don't see Google allowing me to stop Facebook (and others) from constantly checking for updates, etc.

[devsquid]

Settings>Data Usage>Click app>Disable Background data.

Not ideal, but it works if its really an issue. Actually FB does not consume much bandwidth unless you are using it.

[e40]

Agreed. This is the main reason I root my phone, so I can run Xposed + App Ops.

[hyperion_]

Using the developer preview now there is no difference when installing new apps, so do developers all have to make manual changes in their apps for it to work, or will Google flip a switch at some point?

Currently you can change app permissions once an app is installed, but they gain all the permissions they ask for when installed.

If each app has to be updated by the developer for the changes to take place, it might take a while for this to have any large effect on the ecosystem.

[on_and_off]

The app needs to target M in order to access to these granular permission. An app targeting a lower API level will work in legacy mode where it gets its permissions at install time, like before. I guess it makes sense in order to give enough time to the devs to update their apps to this new system. As long as the checking/warning becomes more aggressive in N, I am fine with that choice.

[magicalist]

According to the session after the keynote, you'll still be able to at least go back and revoke permissions individually for apps targeting older API levels.

[biafra]

And they will most likely crash if you do, because they are not expecting a SecurityException. I prefer the CyanogenMod way to just give out empty data, if a permission is not given by the user.

[kllrnohj]

What you're calling the "CyanogenMod" way is actually what Google built, it's called AppOps. All CM did was expose it. The actual capability of permission revoking and handing out dummy data instead was all done by Google as part of AppOps and I assume that M is using that same system because it'd be silly not to.

[ufmace]

I just tried it on the AVD image. It gives you a warning when you revoke a permission for an app built on the older API.

[on_and_off]

yeah, but that way you can only remove the permission after the installation.

Facebook for example is known to siphon your contact list as soon as the app is installed, so even if you remove the permissions from the fb app, it is already too late.