TL;DR: If your Android application can be used by other Android applications, don't use
custom permissions to control this interaction.
If you're writing an Android application that exposes functionality that other applications can use, it's tempting to add your own custom permissions to control access to that functionality. By adding a
tag to your
AndroidManifest.xml, you can give a name and description for the permission, and can apparently leave it up to Android to handle the UI aspects of policing this permission.
But it's not that simple. Firstly, notice that the Android installer doesn't have any mechanism to indicate or enforce dependencies. The consequence of this is that an app that uses your
BLOOP_FUNCTION might get installed before your app is.
The next thing to notice is that the Android package manager only exposes permissions to the user at the point an app is installed, and that unknown permissions are not presented to the user. This actually makes some sense – at this point, all the PackageManager knows is the internal name for the permission (e.g.
com.example.myapp.ACCESS_BLOOP_FUNCTIONALITY), not anything user-visible.
If the user installs the other app, then later installs your app, then the user has never been asked to approve your custom permission, and
false. The permission is still visible if you manually enumerate the permissions of the other app (using
GET_PERMISSIONS).requestedPermissions), but that doesn't really help – any attempt by the other app to access an activity or service thatrequires the permission will be rejected.
So the only hope is to try to detect the situation, and request that the user re-install the other application – hardly a palatable option.