A list of all Android permissions | Hacker News Reader

A list of all Android permissions

gist.github.com

134 pointsArinerron95 comments

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

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

> android.permission.WRITE_MEDIA_STORAGE

Oh how what a mess the intro of Linux localhost 3.8.11 #1 SAMSUNG EXYNOS5 (Flattened Recently built kernel. Unless If I'm not mistaken, this shell sudo bash cgpt --help if you play with cgpt, be VERY careful. ------------------------------------ android.permission.INTERNET android.permission.ACCESS_NETWORK_STATE android.permission.READ_EXTERNAL_STORAGE android.permission.WRITE_EXTERNAL_STORAGE android.permission.READ_PHONE_STATE android.permission.WAKE_LOCK android.permission.ACCESS_WIFI_STATE android.permission.ACCESS_FINE_LOCATION android.permission.ACCESS_COARSE_LOCATION android.permission.VIBRATE com.google.android.c2dm.permission.RECEIVE android.permission.GET_ACCOUNTS android.permission.CAMERA android.permission.RECEIVE_BOOT_COMPLETED android.permission.RECORD_AUDIO android.permission.GET_TASKS android.permission.CALL_PHONE com.android.vending.BILLING android.permission.READ_CONTACTS com.google.android.providers.gsf.pe android.permission.SYSTEM_ALERT_WINDOW com.android.launcher.permission.INSTALL_SHORTCUT android.permission.SET_WALLPAPER android.permission.ACCESS_LOCATION_ android.permission.WRITE_SETTINGS android.permission.USE_CREDENTIALS android.permission.BLUETOOTH android.permission.MODIFY_AUDIO_SETTINGS android.permission.SEND_SMS android.permission.WRITE_CONTACTS com.android.browser.permission.READ android.permission.CHANGE_WIFI_STATE android.permission.READ_CALL_LOG com.android.vending.CHECK_LICENSE android.permission.BLUETOOTH_ADMIN android.permission.FLASHLIGHT android.permission.RECEIVE_SMS android.permission.BROADCAST_STICKY android.permission.DISABLE_KEYGUARD com.android.browser.permission.WRIT android.permission.READ_CALENDAR android.permission.WRITE_CALENDAR android.permission.READ_LOGS android.permission.ACCESS_COARSE_LOCATION There might be a legitimate reason I hope that doesn't do what Aren't the runtime permissions We still need to declare the 'normal' It'd pretty much require Enjoy.

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.

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.

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.

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.

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.

I learned programming with JRuby SL4A on my smartphone. I can't imagine anyone doing this today. Gingerbread is without a doubt my favorite Android version. You had so much freedom back then!

https://github.com/damonkohler/sl4a

That's a great point. Thinking back to the introduction of iOS and Android, iOS was appliance-like in that it was tailored to one use case (phone), while Android felt like a general-purpose OS that just happened to run on a phone.

As you point out, the benefit of Android was never quite taken advantage of.

However, Google's upcoming Android laptops will hopefully push the issue to the fore. It would be amazing to have a more powerful alternative to iOS on the iPad Pro, more powerful in ways we notice everyday, rather than just being more powerful on paper.

The sad thing is that back when 3.0 (Honeycomb) shipped, most of the 10" or so Android tablets included a full size USB-A port. But then came 3.1, and the introduction of the above permission, and basically the major selling point of said port evaporated (i have a Toshiba Thrive sitting here that i basically shelved after said change).

If we observe Windows tablets, with the MS Surface at the forefront, many of them come with a easily accessible USB-A port (I recall Gigabyte tried to sell a tablet that came complete with a ethernet port even, but i think that series has since been discontinued).

What worries me is that Google introduced this change to placate big media. Because around the same time they made the big announcement that people could now buy movies and music via the Android Marketplace (later renamed Google Play).

What advantage does a A-port have over the current micro ports in a tablet? And now the new C port is slowly gaining more support, I bet the A-port will slowly vanish completely, or am I missing something here?

USB-A port = no fiddly adapters etc.

Counter-intuitively, those big fat USB-A sockets have a much lower minimum-cycle specification compared to Micro-B or USB-C ( 1500, 5000 and 10000 respectively ).

So the tiny, fiddly ports are more robust.

Don't worry, i'm sure folks would have also complained had they stuck with those ports and they broke.

> Toshiba Thrive sitting here that i basically shelved after said change

You can access your media if you use a file explorer and media player which support the new API.

> If we observe Windows tablets, with the MS Surface at the forefront, many of them come with a easily accessible USB-A port

And all of the applications running on it can access all of your media. Life is easy when there's only one single flat security domain.

https://xkcd.com/1200/

It's not to placate big media, but to increase security, as others have pointed out.

But the bigger point is that I don't think it's just the USB port that limited Android's flexibility. Android was supposed to be a more flexible, more powerful iOS. That didn't play out in ways the average end user cares about.

> Android felt like a general-purpose OS that just happened to run on a phone.

And that was its big issue. They used the firmware model for a general purpose OS. This keeps Android from having the simple install models we've come to expect with Windows/some Linux distros/MacOS. I wrote a thing on this a while back:

http://penguindreams.org/blog/android-fragmentation/

Note that Chromebooks are similar (and Android 7 adopts the update strategy of ChromeOS). There you have two system partitions, one in use and one on standby. A system update gets applied to the partition on standby, and on next reboot it becomes the used partition (unless the boot is deemed faulty).

BTW, event thought Chromebooks gets updates all the time the kernel and drivers are the same one as when they originally shipped. This means that older Chromebooks will not be able to run Android apps, as it is done using kernel provided containerization.

Does every vendor have their own image, or is there one universal image for chrome laptops? If it's the former, can you just put a stock image on it, or does each vendor embed their drivers?

Dunno. I guess you could look through the project site and see if they have more details.

https://www.chromium.org/chromium-os

Every device has its own kernel and drivers, which is signed and verified. See:

https://www.chromium.org/chromium-os/chromiumos-design-docs/...

If you can unlock your bootloader, you can build your own version of chromeos and the kernel, but trust me, it's not as good. You'll have a chromium-based OS, not chrome based-- it's a lot like the difference between Chromium vs. Chrome in Linux, only affecting the whole OS.

I haven't done it in a few years, but I imagine that with the Android integration, even if it builds, you'll have more of a stock AOSP experience sans any Google cloud features. Good for freedom and privacy, but if you're bothering to replace the OS like that actual Linux may be a better call.

But if you go for standard Linux, you may run into issues with hardware support, especially graphics acceleration... just sayin'. The closed-source graphics drivers written for ChromeOS may not play friendly with Xorg or whatever.

Aside from potential issues w such blobs, I don't see any reason you couldn't unlock the bootloader and try updating your own kernel...

Yea I know a few people who attempted open-source (mostly; drivers are still usually closed) phones sans Google/Amazon stores and services. They'd use F-droid/K9-mail/OpenStreepMaps/OwnCloud, etc. They mostly work, but you do lose a lot of the android ecosystem. One of my friends gave up after a year and went back to the Play Store/Gapps because she started writing her own Android apps to make up for what she was missing and just didn't have the time for it.

I didn't realize ChromOS was in the same boat. That's really shit. In traditional Linux, a lot of drivers get merged right into the tree. Even for proprietary drivers/blobs, we have linux-firmware. For the most part, the initrd files on Arch/Debian/Ubuntu can load a lot of modern hardware.

I wish Google Android/Chrome devs would get their shit together and stop this individual build madness. An initrd full of drivers and linux-firmware do not take up that much space, and many phones now have the footprint of tiny laptops vs the old <8GB tiny flash roms.

Google wields a heavy hand with their (no-so-)open handset alliance (OHA). They can get manufactures to at least commit their blobs to a standard google-firmware package and keep a fork of their Kernel that builds all major drivers into a standard initrd package. Manufactures could always strip out all the crap for their custom ROMS, but this would allow AOSP to just run, out of the box, like Windows 10 or Ubuntu, on a large chunk of hardware.

Google's decisions in Android structure feel asinine.

I think it's not so much as the vendors of the graphics card and such that only released closed blobs to go with the open drivers in the kernel. And while they may work with say, ChromeOS, getting them to work on Linux isn't as straightforward. Android has a similar issue, though most of the time people aren't jumping from Android to another OS..

Are you sure about that? I've got a Samsung chromebook (Snow) from about 3 years ago, and yet...

     localhost / # uname -a SMP Mon Sep 26 02:48:53 PDT 2016 armv7l ARMv7 Processor rev 4 (v7l) Device Tree) GNU/Linux things have changed from a few years back (when I last played with it), there are multiple (3) kernel partitions in ChromeOS:https://www.chromium.org/chromium-os/chromiumos-design-docs/...
...and you can manually select between them by using the "cgpt" command from the shell:
So on an ARM device, you could say:
     sudo cgpt add -i 6 -P 5 -S 1 /dev/mmcblk0 would mean to set partition 6 (a kernel) with a priority of 5 (compared to other partitions at boot), successful flag set to 1 on mmc block device 0-- (the internal mmc, where mmcblk1 is the external sdcard).  I think if that kernel fails, that flips the successful flag to 0 and it falls back to the next priority kernel on the reboot.  But like I said, it's been a while so don't quote me.See more here:  https://www.chromium.org/chromium-os/chromiumos-design-docs/...
Also, if you weren't aware, to get into the shell:
     ctrl-alt-T Also, if you're thinking of replacing kernels or whatnot, be aware that on most (all?) devices, the partitions are signed, so you'll have to turn off any checks first.

Well it was Google's excuse for how only certain Chromebooks of a recent vintage would be getting Android app support.

Maybe they meant the major version number of the kernel wouldn't get an upgrade, though I suspect maybe performance/memory limitations are the real issue.  It may be possible to backport whatever features are missing to an older machine's kernel and see...

Agreed, but my point was intended more in terms of what apps can do. Full access to USB, multitasking, users can install apps outside Google Play, a variety of hardware rather than just one or two models Apple deems good -- all these are advantages of Android when it comes to tablets, laptops or other devices to get work done. But the ecosystem hasn't evolved to take advantage of these, so the benefits are lost.

What about using the post-kitkat Storage Access Framework and adopting the user-granted permission to access removable storage?  That is, once your user manually grants access to a file or directory (in android 7) using the file/directory picker built into Android, your app can keep that permission for later and use it whenever it wants.http://developer.android.com/guide/topics/providers/document...
They also made a video explaining how it works:
https://www.youtube.com/watch?v=C28pvd2plBA
Info about scoped directory access in Android 7.0:
https://developer.android.com/training/articles/scoped-direc...
Incidentally I didn't see READ_EXTERNAL_STORAGE or WRITE_EXTERNAL_STORAGE in the list.

I have some bad experiences with mediastorage (the core of SAF) getting the state of the FS royally confused. Various apps used that path even before SAF, because it is also the backend for the Media Transfer Protocol support.Thing is that SAF only arrived with 4.4, and didn't properly handle anything more than single file access until 5.0. The the write_media_storage permission was introduced in 3.1. Thats some 5 releases and 2 years of goofing around before they sorted their own mess.
Oh and the external_storage permissions where there initially, but they seem to have edited it since in an effort to clear out some non-Android stuff.

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.

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

The hard part is the user interface, not the backend. The application needs to invoke a privileged UI where the user can choose which files or directories the application may access.(many storage media are formatted using FAT, so the media API is probably not implemented using Unix permissions)

I'm talking of allowing apps to mark things (like the WhatsApp data previously mentioned) to only be accessible by itself or some other app(s).As for FAT, I said in another comment that Google has already imposed MTP on us and Android's adoptable storage uses ext4 anyway, so they could easily require it on all removable storage where application data is stored.

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

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.

That was about whatsapp doing a major goof and putting private files in a "public" area (every app already had a private area for file storage) and failing to secure them properly (encryption is hard, apparently).

WhatsApp messed it up particularly bad, but it's not the only example. The point is that there was no private access to the SD card. If you had large files that did not fit on the internal storage, using the shared external storage was the only alternative. Developers abused that and ended up putting all sorts of private data on the SD card.

Lets try to not confuse "external storage" (effectively a partition on the emmc, but mounted under /sdcard for legacy reasons) and an actual SD card.Removable storage, SD, USB, etc, was moved from external_storage to media_storage with Android 3.1.
Note that external_storage was still about putting files in an area readable by any and all apps that had read_external_storage permission.
In other words, the change would do jack all to safeguard against idiots like the whatsapp app devs.

> The point is that there was no private access to the SD card.Sure there was! Simply generate a random key, store it in the (small) private storage area, and use it to encrypt whatever you want to write. Instant private area!

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/

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.

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.

Another reason to add Effect system to future versions of Java.

It does warn you for some permissions.

> coming up with a mapping of "API call => required permission"Surely that must be part of the documentation of each API call, right? Like, "You must enable android.permission.X or this call will fail"? If it is, why not just scrape the documentation, and if it's not, how does anyone develop for Android?
Disclaimer: I only read the abstract.

It's rarely on a per method call basis. In the documentation, it's usually on a package or class basis such as https://developer.android.com/reference/android/bluetooth/pa...

The linter will give you warnings on some permissions.But some of the permissions listed can't even be used without system permission, meaning your app has to be signed with the same keys the OS was (iirc more recently I've seen a device that didn't need this) and installed in a special system directory. Permissions like getting the users local MAC address...

I don't get the logic of doing this. For one thing, with the new runtime permissions model, introduced in Android 6, you need to request the permission from the user at runtime rather than in advance (in the play store when the app is installed).https://source.android.com/devices/tech/config/runtime_perms...
So starting with Android 6, the user can say "no way" to granting a permission when asked, or at any time after installation (via the app settings menu), and the app has to gracefully notice and/or handle the lack of permission without crashing or otherwise screwing up.  This means the app must be designed where the permissions-related stuff can be called asynchronously.  I wrote a bit about this in my question here:
https://stackoverflow.com/questions/32134299/can-you-request...
If just you start writing the app with every permission granted you're potentially going to have a huge headache when you go back to pin down the permissions you'll actually need-- now you need to go back and revise the logic so it can handle possible denials.  Probably wiser to do that as you go, no?
And that's just the base functionality-- there's a UI question too that would benefit some advance-thinking.  Do you want to hit the user with a huge list of permissions the first time they launch the app?  Or maybe only in groups when they do key operations.  Or perhaps individually. This is a question that may be informed by an early understanding of what permissions will be needed, so you know when to ask and what to do if denied.

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 ------------------------+---------+---------- | 2607544 |    92.90 | 2332429 |    83.10 | 1707550 |    60.83 | 1696178 |    60.43 | 1154963 |    41.15 |  989176 |    35.24 |  944675 |    33.65 |  798122 |    28.43 |  770878 |    27.46 |  734366 |    26.16 |  687083 |    24.48 |  676143 |    24.09 |  436581 |    15.55 |  429658 |    15.30 |  243793 |     8.68 |  235717 |     8.39 |  218079 |     7.76 |  200927 |     7.15 |  190848 |     6.79 rmission.READ_GSERVICES |  188162 |     6.70 |  176363 |     6.28 |  164649 |     5.86 |  156845 |     5.58 EXTRA_COMMANDS          |  131898 |     4.69 |  122783 |     4.37 |  110675 |     3.94 |  106272 |     3.78 |  102882 |     3.66 |   97892 |     3.48 |   97585 |     3.47 _HISTORY_BOOKMARKS      |   97147 |     3.46 |   97074 |     3.45 |   90001 |     3.20 |   79279 |     2.82 |   78199 |     2.78 |   74952 |     2.67 |   73898 |     2.63 |   67092 |     2.39 |   66887 |     2.38 E_HISTORY_BOOKMARKS     |   65765 |     2.34 |   61989 |     2.20 |   61327 |     2.18 |   60059 |     2.13

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

There's 126k android apps we have without that permission.Here's the top 250:
https://mixrank.com/playstore/apps?expiration=2016-11-03&pag...

Maybe i misunderstand what permission.INTERNET permission means, but i fail to see how Google Play Games is not using the internet.

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.

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.

I find it bothersome that basically any app could potentially portscan your network and sell the map.

Best to design your security model assuming all attackers have access to the output of a portscan in any case.

True, but there are significant privacy implications.

Hey. Mind sorting the gist list in order of most to least used? I'd really appreciate it.

Hi, see your company also tracks SDKs. Wonder how many/which top apps use Crashlytics?

We've found 33k+ iOS apps with Crashlytics. Here's the top 10:https://mixrank.com/appstore/apps?expiration=2016-11-03&sdk_...
We've found 49k+ android apps with Crashlytics. Here's the top 10:
https://mixrank.com/playstore/apps?expiration=2016-11-03&sdk...

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 |  770878 |    27.46 that 1 app in 8 needs access to the camera, but that also seems a high.
    android.permission.CAMERA                  |  436581 |    15.55

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.

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

It's READ_PHONE_STATE that worries me, correct me if I'm wrong but isn't that phone meta-data? (Who is calling, when, etc?)

You need this ominous sounding permission to intervene and pause an app when a call comes in.


  android.permission.BRICK' I think it does...

Used for enterprise wipe/disable.

Lol, that's exactly what I was thinking

I am not sure what the point of this list is ? the only ones we really need to think about going forward ? permissions, but they will be mostly invisible to the end-user, no ?for reference : 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).

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.

Sorry about that. Just edited out all of the non stock ones.

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

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

Sure. Which order, most common, or alphabetical?

alphabetical should be fine

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

Intents are the best permissions system.

Intents as in Android intents?

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

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.

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.

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.

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.

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.

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.

We experimented with a lightweight bootstrap service, but there was too much resistance from the manufacturers. 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

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?

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

Are they grouped or sorted in a certain way?

Not really.

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.

Google calls them permission groups: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 id="c12625614" class="scroll-mt-28 ">These are stock Android perms? Why are JuiceSSH and SuperSU perms included?
Sorry about that. Just edited it. Only stock Android perms now ;)
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... is much more useful. Linked to from my repo entry https://github.com/doridori/Android-Security-Reference/blob/...
Reply on news.ycombinator.com