
A list of all Android permissions - Arinerron
https://gist.github.com/Arinerron/1bcaadc7b1cbeae77de0263f4e15156f
======
willvarfar
This will fall on deaf ears, but at Symbian we came up with what I think is a
better way of dividing things up:
[http://williamedwardscoder.tumblr.com/post/13316924653/bette...](http://williamedwardscoder.tumblr.com/post/13316924653/better-
permissions-in-android)

~~~
contingencies
And in terms of networking, I argued to Firefox OS that the standard
Android/iOS style system-wide link-layer oriented network permissions are
insane, and could be done better:
[https://bug945047.bmoattachments.org/attachment.cgi?id=84072...](https://bug945047.bmoattachments.org/attachment.cgi?id=8407268)
This is well supported by _smilliken_ 's top two permissions statistics posted
below, and _nitrogen_ 's point: "I find it bothersome that basically any app
could potentially portscan your network and sell the map."

------
digi_owl
> android.permission.WRITE_MEDIA_STORAGE

Oh how what a mess the intro of this one was.

Over night Android went from a potential production platform to a straight
media consumption platform, as now only system apps could write to removable
storage.

~~~
eeZi
Since nobody pointed it out yet: that change was done for security reasons,
not due to a political conspiracy. Media access was a big hole in the
otherwise fine-grained permission model.

Your camera app used to be able to access your WhatsApp backup folder and your
documents. It was just a flat file system. Developers would request the
permission even though all they needed was a caching folder or something, but
they could read and upload all of your documents, too.

This change, while breaking a bunch of applications until they migrate to the
new fine-grained API, was a necessary one.

~~~
mixedCase
Unix 40 year old permission system is enough to deal with this, this is no
excuse.

~~~
lokedhs
As far as I understand, media was (is?) stored on sdcards, which uses (can
use) FAT, which has no permissions support.

~~~
mixedCase
It uses ext4 on the mixed mode (which incorporates it as system memory), but
it should require ext4 for sd cards as well. They cut off USB mass storage
support so they have already crossed that line.

------
desdiv
The first thing I do when I start a new Android app project is copy and paste
this list-of-all-permissions into the project. This way I don't have to deal
with any of the permissions related stuff until I have a working MVP. Once you
have a MVP it's pretty easy to pin down the exact list of all the permissions
you actually need in one go.

On a related note, there's some research[0] into parsing the Android OS source
code and coming up with a mapping of "API call => required permission", and by
apply this mapping to the source code of your own app the list of required
permissions can be generated automatically. What do you guys think of this
approach?

[0] [http://pscout.csl.toronto.edu/](http://pscout.csl.toronto.edu/)

~~~
BHSPitMonkey
Seems like Android Studio should do exactly that kind of static analysis and
warn you if your manifest specifies too many or too few permissions. There
have been a few cases of companies releasing apps with catch-all permission
requests like you recommend, and then facing a minor PR crisis as reports of
the app's suspiciousness go viral.

This should be less relevant for apps using post-marshmallow-style permissions
which don't need to be granted on install.

~~~
barrkel
Static analysis will require too many permissions because of limitations on
the tractability of the analysis (the Halting problem). Instrumenting is more
reliable for a minimal set but isn't necessarily complete.

------
smilliken
At my company (MixRank), we do static analysis on apps for business
intelligence. We've collected lots of data on permissions, SDKs, integrations,
frameworks, etc. If anyone has any interesting queries they'd like me to run,
I can give it a shot.

Here's the most popular permissions we've identified:

    
    
                                permission                         |  apps   | pct_apps 
       ------------------------------------------------------------+---------+----------
        android.permission.INTERNET                                | 2607544 |    92.90
        android.permission.ACCESS_NETWORK_STATE                    | 2332429 |    83.10
        android.permission.READ_EXTERNAL_STORAGE                   | 1707550 |    60.83
        android.permission.WRITE_EXTERNAL_STORAGE                  | 1696178 |    60.43
        android.permission.READ_PHONE_STATE                        | 1154963 |    41.15
        android.permission.WAKE_LOCK                               |  989176 |    35.24
        android.permission.ACCESS_WIFI_STATE                       |  944675 |    33.65
        android.permission.ACCESS_FINE_LOCATION                    |  798122 |    28.43
        android.permission.ACCESS_COARSE_LOCATION                  |  770878 |    27.46
        android.permission.VIBRATE                                 |  734366 |    26.16
        com.google.android.c2dm.permission.RECEIVE                 |  687083 |    24.48
        android.permission.GET_ACCOUNTS                            |  676143 |    24.09
        android.permission.CAMERA                                  |  436581 |    15.55
        android.permission.RECEIVE_BOOT_COMPLETED                  |  429658 |    15.30
        android.permission.RECORD_AUDIO                            |  243793 |     8.68
        android.permission.GET_TASKS                               |  235717 |     8.39
        android.permission.CALL_PHONE                              |  218079 |     7.76
        com.android.vending.BILLING                                |  200927 |     7.15
        android.permission.READ_CONTACTS                           |  190848 |     6.79
        com.google.android.providers.gsf.permission.READ_GSERVICES |  188162 |     6.70
        android.permission.SYSTEM_ALERT_WINDOW                     |  176363 |     6.28
        com.android.launcher.permission.INSTALL_SHORTCUT           |  164649 |     5.86
        android.permission.SET_WALLPAPER                           |  156845 |     5.58
        android.permission.ACCESS_LOCATION_EXTRA_COMMANDS          |  131898 |     4.69
        android.permission.WRITE_SETTINGS                          |  122783 |     4.37
        android.permission.USE_CREDENTIALS                         |  110675 |     3.94
        android.permission.BLUETOOTH                               |  106272 |     3.78
        android.permission.MODIFY_AUDIO_SETTINGS                   |  102882 |     3.66
        android.permission.SEND_SMS                                |   97892 |     3.48
        android.permission.WRITE_CONTACTS                          |   97585 |     3.47
        com.android.browser.permission.READ_HISTORY_BOOKMARKS      |   97147 |     3.46
        android.permission.CHANGE_WIFI_STATE                       |   97074 |     3.45
        android.permission.READ_CALL_LOG                           |   90001 |     3.20
        com.android.vending.CHECK_LICENSE                          |   79279 |     2.82
        android.permission.BLUETOOTH_ADMIN                         |   78199 |     2.78
        android.permission.FLASHLIGHT                              |   74952 |     2.67
        android.permission.RECEIVE_SMS                             |   73898 |     2.63
        android.permission.BROADCAST_STICKY                        |   67092 |     2.39
        android.permission.DISABLE_KEYGUARD                        |   66887 |     2.38
        com.android.browser.permission.WRITE_HISTORY_BOOKMARKS     |   65765 |     2.34
        android.permission.READ_CALENDAR                           |   61989 |     2.20
        android.permission.WRITE_CALENDAR                          |   61327 |     2.18
        android.permission.READ_LOGS                               |   60059 |     2.13

~~~
pdkl95
I find it hard to believe that more than 1 app in 4 has a legitimate need for
(fine!) location data.

    
    
        android.permission.ACCESS_FINE_LOCATION    |  798122 |    28.43
        android.permission.ACCESS_COARSE_LOCATION  |  770878 |    27.46
    

There might be a legitimate reason that 1 app in 8 needs access to the camera,
but that also seems a high.

    
    
        android.permission.CAMERA                  |  436581 |    15.55

~~~
octo_t
not an android user, but plenty of iOS apps want to access the camera for
'ease of use' things.

* Banking apps/shopping want access to the camera to scan your debit/credit/gift cards, instead of having to type it out.

* messaging apps/email etc want access to the camera so you can msg/email photos

* games that are vaguely 'social' and want to have a real photo of you as an in-game avatar etc.

~~~
pdkl95
> Banking apps/shopping want access to the camera to scan your
> debit/credit/gift cards, instead of having to type it out.

I forgot about that type of use, which makes the camera usage rate a lot more
reasonable.

------
disruptalot

      android.permission.BRICK'
    

I hope that doesn't do what I think it does...

~~~
nashashmi
Used for enterprise wipe/disable.

------
on_and_off
I am not sure what the point of this list is ? Aren't the runtime permissions
the only ones we really need to think about going forward ? We still need to
declare the 'normal' permissions, but they will be mostly invisible to the
end-user, no ?

for reference :
[https://developer.android.com/guide/topics/security/permissi...](https://developer.android.com/guide/topics/security/permissions.html#normal-
dangerous)

The others ones are still there but pretty much an implementation detail now
for Marshmallow apps (I know M+ is a tiny market share at the moment, but it
will only increase).

------
TobbenTM
Why is this list "all" permissions? It contains non-Google stuff like Amazon
permissions, yet not for other platform like Symbol permissions. I'm confused.

~~~
Arinerron
Those other permissions were in there because whenthe script was gathering all
the perms, it also gathered the JuiceSSH perms and other app permissions. I
wrote a script to filter out everything but stock perms, and now it should be
right. ;)

------
giis
Just a small suggestion, can you make this list in sorted order?

~~~
Arinerron
Sure. Which order, most common, or alphabetical?

~~~
giis
alphabetical should be fine

~~~
Arinerron
Sure. I'll do that when I get home.

------
mynameislegion
Intents are the best permissions system.

~~~
BoorishBears
Intents as in Android intents?

~~~
Zigurd
I think he means: "Apps should be more modular and use other apps'
capabilities more." Which is true.

~~~
BoorishBears
The way Android has facilitated that (the intent system) is horrid, so in
reality the more apps try to use other apps, the more unstable they become.

~~~
Zigurd
Android has both high-level IPC via Intent filters and low-level IPC via bound
Service objects. Neither create instability. ACTION_SEND is widely implemented
without creating instability. But other verbs are underutilized: Setting
calendar events, picking contacts, etc. ACTION_EDIT should be almost as common
as ACTION_SEND. Making a cooperating suite of apps is a huge missed
opportunity in Android. Meanwhile I see plenty of bloaty apps that are
unstable because they are large and monolithic.

~~~
BoorishBears
Low-level IPC is practically inapplicable to apps made by different creators
working together. Not to mention it's no dream to work with.

I work with hardware that comes with stock AOSP, and getting a "daemon" style
service to run from boot without closing took several workarounds, even though
it should have been as simple as "START_STICKY" with a foreground service
Android's Service model is very clearly not meant to support such a simple
usecase. The most reliable way is actually to modify the image because only
system services are supposed to be allowed to do that.

Working with services that aren't reliably started can also be bad for UX even
if you don't have the usecase I had of needing a daemon because there might be
a high cost associated with starting up. People also don't want every service
showing a notification to stay alive.

After trying to model this complex device management system I was working on
in nice contained pieces we could maintain separately, I was forced to stuff
it into one monolithic app. Performance improved because we no longer needed
workarounds to keep the multiple services alive, just one was enough, and we
only needed one process to stay alive (a process which is always second from
the top in recent usage because our hardware only needs to run our app and a
2nd party one).

Intents are unstable because no one follows the standards for verbs properly.
Samsung's built in apps are notorious for crashing if you try to use extras.
Facebook won't crash, but it won't respect EXTRA_TEXT or EXTRA_SUBJECT
properly because they only want you sharing a URL. Pinterest crashes on
sharing some images that other apps don't.

I'd almost go as far as saying you can find a crash report that's app-specific
for any major app (Gmail, Facebook, etc.) that you'd expect to see receive a
share intent by googling "<insert app name> android intent crash". It's almost
always something with the app that's taking the intent not respecting the
intent contract properly.

~~~
Zigurd
It seems like 80% of your trouble comes from trying to subvert the "your
service won't start until you use it" solution to the "everybody is lazy
and/or anti-social and wants to start their service on boot" problem. In other
words, Google intended to make the life of an app author who wants this
extremely difficult and would have suggested that they attack the "because
there might be a high cost associated with starting up" problem instead. But,
yeah, if it is your device with your AOSP build, and you really really have
The Most Important Service, go ahead and compile it into the system.

On top of all that, the usual reason there is a "high cost to starting
something" is that it hits a server and hasn't cached the data it needs. The
OS can't solve that for you.

~~~
BoorishBears
That was really a digression of my main point of intents forming an unstable
API but our problem was 100% subverting your service won't start until you use
it, but Google's approach is insanely heavy handed. A saner solution would to
be to give a permission for daemon style services that comes with a warning to
the user about battery life and network implications.

Our service really is the most important service on the device because if our
service goes down the device is essentially "bricked" (these are embedded
android devices so we lose visibility on the installation), but adding our
service to the image means managing images for every device variation we use
(and some of those device's manufacturer's won't be happy to have someone else
managing said images since it means more work for them [build image, send it
to us, we modify it, send it back to them, they use it vs just building an
image and using it]).

It's a unique use case, but it's not hard to imagine more common software that
could take advantage of daemons, even if it's just to provide smarter
background processing than the "all-or-nothing" defaults provide (like
START_STICKY). Besides being rather unique to our use case, I'd also say it
doesn't have to do with apps from different creators working together...

And I don't think the network is involved most cases of expensive services,
because the OS (or more specifically, Google's services on most end user
devices) already help solve that with things like the GCMNetworkManager and
ConnectivityManager callbacks for optimizing network access.

~~~
Zigurd
Ok I see what your situation is. And I'm curious, because this is sort of my
thing. I don't think allowing greedy services with a big red warning would be
a good solution for you either because your users would tire of seeing the
warning, even if only at boot.

I would put a service-starter service in the device images. I see that might
be a problem, too, because it seems like you are only "lightly embedded," with
multiple hardware platforms. But this could be a really lo-impact thing for
your hardware partners and relatively clean. Alternatively, provide a modified
launcher, if you are not already replacing the launcher with your own embedded
app, that tickles the service on startup. There are probably other advantages
to having your own Home app if I understand your situation correctly.

Google has to be heavy handed because too much mobile development is crap, and
a low-bidder contract development shop wouldn't hesitate to take the anti-
social way to an implementation if they could. The road to hell is paved with
cheapass outsourcing.

~~~
BoorishBears
We experimented with a lightweight bootstrap service, but there was too much
resistance from the manufacturers. It'd pretty much require changing our
contract to have much more expensive terms because from their pov it crossed
the line from them providing pre-installed software (our apps) , to them
providing custom devices ("our image").

I also tried some tricks with replacing the launcher since we have full root
access, but the launcher process was getting killed almost as often as our
custom services.

Since I moved to a single-process model I've had fewer killed services, but we
still have the AlarmManager kicking them off just in case.

A lot of the moves Google's been making, from shutting down file uris for
content providers feel like they're meant to shut down the "easiest way out
for developers", things that are easy for devs, but bad for the average mobile
user, but they're also hurting Android for other usecases. I guess the plan is
to push Brillo for that, but being able to leverage Android's ecosystem on
embedded has some advantages

~~~
Zigurd
You don't need any special access to replace the launcher. They just need to
set your Launcher as default as part of the pre-load. Since I don't know your
product it's a little hard to say but the combination of a Home app that check
on configuration sanity and a watchdog, which it sounds like what you are
using AlarmManager for should do you.

Point of sale system?

~~~
BoorishBears
No, we do something like "bespoke" digital installations for different brands,
sometimes it's simple digital signage, sometimes it's stuff that's a little
more interactive, but we try and centralize the apps involved on a platform we
built on one specific Android device which has now spread out onto different
models for certain clients that had special requirements like large
touchscreens

------
jrobichaud
Are they grouped or sorted in a certain way?

~~~
willvarfar
Yes they can be. Android puts them into 'bins', e.g. all the network-related
ones together. Importantly, when an app upgrades and the new version wants new
permissions, these are silently granted if they are the same bin as existing
granted permissions.

Therefore, from a security perspective, there are far fewer coarser
permissions.

~~~
fattire
Google calls them permission groups:

[https://stuff.mit.edu/afs/sipb/project/android/docs/referenc...](https://stuff.mit.edu/afs/sipb/project/android/docs/reference/android/Manifest.permission_group.html)

You can list all the permissions in the system, or just those an app uses or
see all the "dangerous" groups from adb. For example:

    
    
         adb shell pm list permissions -g -d
    

Enjoy.

------
bcook
These are _stock_ Android perms? Why are JuiceSSH and SuperSU perms included?

~~~
Arinerron
Sorry about that. Just edited it. Only stock Android perms now ;)

------
kodroid
Um, why is this worthy of the hackernews front page? Is this not the
permissions extracted from the platform manifest with all the useful per-
permission information removed?
[https://github.com/android/platform_frameworks_base/blob/mas...](https://github.com/android/platform_frameworks_base/blob/master/core/res/AndroidManifest.xml)
is much more useful. Linked to from my repo entry
[https://github.com/doridori/Android-Security-
Reference/blob/...](https://github.com/doridori/Android-Security-
Reference/blob/master/permissions/app_framework_perms.md)

