Custom Permissions
from the CommonsWare Community archivesAt September 18, 2019, 1:26pm, booeyoh asked:
I am trying to figure out a way to handle an incoming broadcast inside App B. I want to make sure that it will only continue if it is originally broadcast from App A. I found a bunch of resources, the clearest of which was this article:
The thing that I am unclear on, in terms of using custom permissions, is where do I define the permission (App A or B) and where/how do I request the permission (App A or B). And how does this setup prevent App C from a malicious source from just requesting the same permission.
I am sure I am just missing something simple, but I can’t see it.
Also, I am not against using the same certificate/signature for permissions, since I am the developer of both App A and B, but I want to understand this first.
Thanks!
At September 18, 2019, 1:48pm, mmurphy replied:
Android is not particularly good at this.
IIRC, on Android 5.0+ you would need to have an identical <permission>
element in both apps, and both apps would need to be signed by the same signing key. You need the <permission>
in both as you do not necessarily know what order these apps are installed in. The same-signing-key restriction was added to Android 5.0 to combat some security flaws with apps redefining other apps’ permissions.
In your scenario, B would have a <receiver>
with android:permission
for your custom permission. A would have <uses-permission>
for that custom permission. And, you would want the <permission>
to have a protectionLevel
of signature
, so that only your apps can hold that permission.
The protectionLevel
of signature
would require the developer of App C to have your signing key and whatever password you used to protect it. Hire a ninja to defend the signing key.
At September 18, 2019, 3:29pm, booeyoh replied:
Thank you!! So it sounds like it isn’t advisable/possible to do this without the signature protectionLevel?
At September 18, 2019, 9:56pm, mmurphy replied:
Well, that gets directly to your App C concern. If you want to block App C from talking to App B, you are going to need to secure the broadcast with a permission that App C cannot hold. That eliminates normal
and dangerous
permissions, and signature
is the only other option available to app developers.
At October 2, 2019, 4:58pm, booeyoh replied:
Thanks! Another quick question. How do these permissions work with debug. Currently I am testing both App A and App B in debug mode, do I need to push both to release to truly test it?
At October 2, 2019, 9:09pm, mmurphy replied:
In terms of functionality, permissions are independent of build type. Permissions do not behave differently because you are in a release
build than in a debug
build.
However, for custom permissions, you cannot have both a traditional debug
build and a release
build installed at the same time defining the same permission, as they will not be signed by the same signing key by default. Options include:
- Using manifest placeholders (e.g.,
${applicationId}
) to customize the permission name, the way that we use them for customizing authorities in<provider>
elements - Just not having both
debug
andrelease
installed at the same time - Signing the
debug
build with yourrelease
signing key