8 ms·

A list of all Android permissions

134 points by Arinerron 10y ago

smilliken 10y ago
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
- qmarchi 10y ago
  Can you pull the list of apps that didn't match a specific filter? I'm curious to know what apps dont use permission.INTERNET
  - smilliken 10y ago
    There's 126k android apps we have without that permission. Here's the top 250: https://mixrank.com/playstore/apps?expiration=2016-11-03&page_size=250&permission_conjunctive=any&permission_exclude=643331&sharedby=scott%40deltaex.com&auth=e4a83c8e2a790d91 https://mixrank.com/playstore/apps?expiration=2016-11-03&pag...
    - EnigmaticLion 10y ago
      Maybe i misunderstand what permission.INTERNET permission means, but i fail to see how Google Play Games is not using the internet.
      - smilliken 10y ago
        See digi_owl's comment. In addition to that, Google Play Games does inter-process communication with Google Play Services which essentially has unfettered permissions.
- digi_owl 10y ago
  Iirc, since Android 6 (though really introduced in a earlier Play store update) quite a number of the network related permissions is accepted by default. This because Google switched to putting different permissions into bins, and the networking bin is accepted by default. Note also that these days a user is only notified if a update introduces a new bin requirement, not on every permission change.
  - nitrogen 10y ago
    I find it bothersome that basically any app could potentially portscan your network and sell the map.
desdiv 10y ago
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 10y ago
  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 10y ago
    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.
  - ungzd 10y ago
    Another reason to add Effect system to future versions of Java.
  - BoorishBears 10y ago
    It does warn you for some permissions.
  - deleted 10y ago
    [deleted]
jrobichaud 10y ago
Are they grouped or sorted in a certain way?
- Arinerron 10y ago
  Not really.
- willvarfar 10y ago
  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 10y ago
    Google calls them permission groups: https://stuff.mit.edu/afs/sipb/project/android/docs/reference/android/Manifest.permission_group.html https://stuff.mit.edu/afs/sipb/project/android/docs/referenc... 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.
giis 10y ago
Just a small suggestion, can you make this list in sorted order?
- Arinerron 10y ago
  Sure. Which order, most common, or alphabetical?
  - giis 10y ago
    alphabetical should be fine
    - Arinerron 10y ago
      Sure. I'll do that when I get home.
digi_owl 10y ago
> 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.
- dredmorbius 10y ago
  Yep. This is why I absolutely won't consider any Android devices in future. The hardware's been admirable, particularly with a folio-style case and bluetooth keyboard. Great battery life. The display is limited, but the best as can be hoped for. But the limitations on what I as a user can do drive me bloody bananas. It's a very short drive, and an entirely uninteresting challenge. Google, Samsung, and Logitech specifically have fucked this up hard and irretrievably.
  - eeZi 10y ago
    Android is still the (mainstream) mobile operating system which gives you the most freedom. What are you going to use instead? iOS? This is not a hostile limitation - it's a backwards-incompatible API change that the ecosystem hasn't fully adapted to.
    - dredmorbius 10y ago
      Quite honestly: nothing within the "mobile" ecosystem. A laptop running Linux. The mobile world isn't ready for non-trivial use. May never be, though I'm watching Ubuntu's progress.
      - eeZi 10y ago
        Agreed then. I'm a developer and I can't see myself developing on a mobile phone operating system anytime soon. But I still like my Android phone for taking notes, pictures, syncing PDFs and reading my mails. It's just two different use cases and different security/freedom tradeoffs. Not sure if I'd call Android a general purpose operating system.
  - 10y ago
bcook 10y ago
These are stock Android perms? Why are JuiceSSH and SuperSU perms included?
- Arinerron 10y ago
  Sorry about that. Just edited it. Only stock Android perms now ;)
TobbenTM 10y ago
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 10y ago
  Sorry about that. Just edited out all of the non stock ones.
- deleted 10y ago
  [deleted]
- Arinerron 10y ago
  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. ;)
kodroid 10y ago
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/master/core/res/AndroidManifest.xml https://github.com/android/platform_frameworks_base/blob/mas... is much more useful. Linked to from my repo entry https://github.com/doridori/Android-Security-Reference/blob/master/permissions/app_framework_perms.md https://github.com/doridori/Android-Security-Reference/blob/...
willvarfar 10y ago
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/better-permissions-in-android http://williamedwardscoder.tumblr.com/post/13316924653/bette...
- contingencies 10y ago
  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=8407268 https://bug945047.bmoattachments.org/attachment.cgi?id=84072... 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."
on_and_off 10y ago
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/permissions.html#normal-dangerous https://developer.android.com/guide/topics/security/permissi... 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).
disruptalot 10y ago
android.permission.BRICK' I hope that doesn't do what I think it does...
- nashashmi 10y ago
  Used for enterprise wipe/disable.
- Arinerron 10y ago
  Lol, that's exactly what I was thinking
mynameislegion 10y ago
Intents are the best permissions system.
- BoorishBears 10y ago
  Intents as in Android intents?
  - Zigurd 10y ago
    I think he means: "Apps should be more modular and use other apps' capabilities more." Which is true.
    - BoorishBears 10y ago
      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 10y ago
        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 10y ago
        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.

134 points by Arinerron 10y ago

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

qmarchi 10y ago
Can you pull the list of apps that didn't match a specific filter? I'm curious to know what apps dont use permission.INTERNET
- smilliken 10y ago
  There's 126k android apps we have without that permission. Here's the top 250: https://mixrank.com/playstore/apps?expiration=2016-11-03&page_size=250&permission_conjunctive=any&permission_exclude=643331&sharedby=scott%40deltaex.com&auth=e4a83c8e2a790d91 https://mixrank.com/playstore/apps?expiration=2016-11-03&pag...
  - EnigmaticLion 10y ago
    Maybe i misunderstand what permission.INTERNET permission means, but i fail to see how Google Play Games is not using the internet.
    - smilliken 10y ago
      See digi_owl's comment. In addition to that, Google Play Games does inter-process communication with Google Play Services which essentially has unfettered permissions.
digi_owl 10y ago
Iirc, since Android 6 (though really introduced in a earlier Play store update) quite a number of the network related permissions is accepted by default. This because Google switched to putting different permissions into bins, and the networking bin is accepted by default. Note also that these days a user is only notified if a update introduces a new bin requirement, not on every permission change.
- nitrogen 10y ago
  I find it bothersome that basically any app could potentially portscan your network and sell the map.

desdiv 10y ago

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 10y ago
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 10y ago
  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.
- ungzd 10y ago
  Another reason to add Effect system to future versions of Java.
- BoorishBears 10y ago
  It does warn you for some permissions.
- deleted 10y ago
  [deleted]

jrobichaud 10y ago

Are they grouped or sorted in a certain way?

Arinerron 10y ago
Not really.
willvarfar 10y ago
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 10y ago
  Google calls them permission groups: https://stuff.mit.edu/afs/sipb/project/android/docs/reference/android/Manifest.permission_group.html https://stuff.mit.edu/afs/sipb/project/android/docs/referenc... 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.

giis 10y ago

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

Arinerron 10y ago
Sure. Which order, most common, or alphabetical?
- giis 10y ago
  alphabetical should be fine
  - Arinerron 10y ago
    Sure. I'll do that when I get home.

digi_owl 10y ago

> 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.

dredmorbius 10y ago
Yep. This is why I absolutely won't consider any Android devices in future. The hardware's been admirable, particularly with a folio-style case and bluetooth keyboard. Great battery life. The display is limited, but the best as can be hoped for. But the limitations on what I as a user can do drive me bloody bananas. It's a very short drive, and an entirely uninteresting challenge. Google, Samsung, and Logitech specifically have fucked this up hard and irretrievably.
- eeZi 10y ago
  Android is still the (mainstream) mobile operating system which gives you the most freedom. What are you going to use instead? iOS? This is not a hostile limitation - it's a backwards-incompatible API change that the ecosystem hasn't fully adapted to.
  - dredmorbius 10y ago
    Quite honestly: nothing within the "mobile" ecosystem. A laptop running Linux. The mobile world isn't ready for non-trivial use. May never be, though I'm watching Ubuntu's progress.
    - eeZi 10y ago
      Agreed then. I'm a developer and I can't see myself developing on a mobile phone operating system anytime soon. But I still like my Android phone for taking notes, pictures, syncing PDFs and reading my mails. It's just two different use cases and different security/freedom tradeoffs. Not sure if I'd call Android a general purpose operating system.
- 10y ago

bcook 10y ago

These are stock Android perms? Why are JuiceSSH and SuperSU perms included?

Arinerron 10y ago
Sorry about that. Just edited it. Only stock Android perms now ;)

TobbenTM 10y ago

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 10y ago
Sorry about that. Just edited out all of the non stock ones.
deleted 10y ago
[deleted]
Arinerron 10y ago
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. ;)

kodroid 10y ago

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/master/core/res/AndroidManifest.xml https://github.com/android/platform_frameworks_base/blob/mas... is much more useful. Linked to from my repo entry https://github.com/doridori/Android-Security-Reference/blob/master/permissions/app_framework_perms.md https://github.com/doridori/Android-Security-Reference/blob/...

willvarfar 10y ago

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/better-permissions-in-android http://williamedwardscoder.tumblr.com/post/13316924653/bette...

contingencies 10y ago
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=8407268 https://bug945047.bmoattachments.org/attachment.cgi?id=84072... 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."

on_and_off 10y ago

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/permissions.html#normal-dangerous https://developer.android.com/guide/topics/security/permissi... 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).

disruptalot 10y ago

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

nashashmi 10y ago
Used for enterprise wipe/disable.
Arinerron 10y ago
Lol, that's exactly what I was thinking

mynameislegion 10y ago

Intents are the best permissions system.

BoorishBears 10y ago
Intents as in Android intents?
- Zigurd 10y ago
  I think he means: "Apps should be more modular and use other apps' capabilities more." Which is true.
  - BoorishBears 10y ago
    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 10y ago
      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 10y ago
        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.