1

For quite a while I'm collecting app details. My site meanwhile covers about 13k apps, and has a list of permissions with explanations. A few weeks ago I started recording "unknown permissions" as well (i.e. permissions apps are requesting, but which are not covered by my list). Analyzing that now (mostly app specific (<package_name>.*) or manufacturer specific (e.g. com.sec.* for Samsung, com.htc., com.sonyericsson. etc) permissions), I found a list of very strange permissions requested quite frequently – which were nowhere documented.

Are there any insights here? I will list them ordered by most used and with a comment of what I figured up to now – and hope you can give me some additional details on at least a few of them:

  • WRITE_INTERNAL_STORAGE: wrongly deduced from WRITE_EXTERNAL_STORAGE?
  • ACCESS_GPS: pre-Android-1.0 and long obsolete
  • ACCESS_LOCATION: pre-Android-1.0 and long obsolete
  • STORAGE: also a remains from pre-1.0 – or picked the permission group instead ??? (used by e.g. com.yuilop)
  • READ_INTERNAL_STORAGE: wrongly deduced from READ_EXTERNAL_STORAGE?
  • NETWORK: also a remains from pre-1.0 – or picked the permission group instead ??? (used by e.g.: com.koushikdutta.backup)
  • PERMISSION_NAME: copy-pasta?
  • LOCATION: no such permission (or also pre-1.0 – or picked the permission group instead?)
  • SYSTEM_OVERLAY_WINDOW: that's what SYSTEM_ALERT_WINDOW permits: using overlays ;)
  • RECORD_VIDEO: wrongly deduced from RECORD_AUDIO, and should probably be CAMERA? Also see here
  • ACCESS_COURSE_LOCATION: definitely a typo. And ACCESS_COARSE_LOCATION (which was meant) most likely not needed, if noone noticed :)
  • READ_APN_SETTINGS: wrongly deduced from WRITE_APN_SETTINGS ???
  • BROADCAST_PACKAGE_REPLACED: probably wrongly deduced from BROADCAST_PACKAGE_ADDED and BROADCAST_PACKAGE_REMOVED ???
  • GET_CLIPS / READ_CLIPS / WRITE_CLIPS: ??? obviously refers to clipboard actions, but I've never heard of those perms. Developers manual on copy paste does not mention any permission for this. Despite of that, a screenshot from AppOps found in this blog article clearly shows a „Read clipboard“ permission.
  • WRITE_LOGS: probably wrongly deduced from READ_LOGS
  • BROADCAST_PACKAGE_CHANGED: probably wrongly deduced from BROADCAST_PACKAGE_ADDED and BROADCAST_PACKAGE_REMOVED ???
  • CHANGE_WIFI_AP_STATE: ???

There are several more (over 100 altogether), but these are the ones used by multiple apps. Note that in the Manifests of affected apps, they are prefixed by android.permission. (e.g. android.permission.WRITE_INTERNAL_STORAGE). Any clues?

Where do people get those ideas from, when a search for the explicite name doesn't turn up anything, I wonder … Most confusing is that several of the above are even suggested here at SO to fix issues – despite of being mentioned in other posts as definitely not existing.

EDIT: Being asked to name some example apps:

Just to ensure those apps are not declaring those permissions, I've picked some .apk files (MyBackup, GPS HUD) and ran aapt d badging against them. Found no single declaration, all only named by uses-permission:.

PS: Sources I usually consult for finding details on permissions include, next to a Google search, a.o. Github, Android Source, Android Cross Reference, Android Developers, and several more. I had no luck with the above.

Community
  • 1
  • 1
Izzy
  • 1,364
  • 3
  • 32
  • 65
  • 1
    `X_CLIPS` appears to have been spread by the my-clips project referenced in [this question](http://stackoverflow.com/q/19963785/507761) and the answers there. Everything else looks to fit your explanations, mostly broken versions of existing permissions. That said, I'm not sure "insights into why people make odd mistakes" is really a good question for SO. – Matthew Read Mar 04 '16 at 21:35
  • Full ack to your last sentence, @MatthewRead – that was rather a comment. Please interpret "insights" as referring to the "permissions" only – otherwise it would be "primarily opinion-based" ;) // Thanks for the pointer on `*_CLIPS`, will check that now. – Izzy Mar 04 '16 at 21:38
  • @Izzy please clarify that these are prefixed with `android.permission`, and also 1 or 2 apps that use it. There's a possibility that 3rd-party devs created those permissions for their related apps, but didn't adhere to naming guideline (it's free to create any name for new permission, no enforced policy)... or they just deduced from existing permissions but didn't realize that those don't exist. – Andrew T. Mar 04 '16 at 23:18
  • @AndrewT. Done. And no, unlikely they've created them to protect their own APIs. In some cases, they most likely deduced them (`_INTERNAL_STORAGE` would be an example for that). – Izzy Mar 04 '16 at 23:31

0 Answers0