Assigned
Status Update
Comments
sh...@google.com <sh...@google.com>
ap...@google.com <ap...@google.com> #2
My application offers 'suggested applications' that it can install and then use the functionality of, acting as a plug-in. Tasker is one of those.
My only work-around is to prompt the user to reinstall my application after the suggested applications have been installed, so permissions are detected.
It's of course a horrible 'solution'. Have starred the issue.
brandall
My only work-around is to prompt the user to reinstall my application after the suggested applications have been installed, so permissions are detected.
It's of course a horrible 'solution'. Have starred the issue.
brandall
ap...@google.com <ap...@google.com> #3
ap...@google.com <ap...@google.com> #4
Using the terminology from the original issue report, one workaround is for App A *and* App B to define the same <permission>. This gets a bit dicey in plugin situations, where App A is not written by the author of App B, only because App A would need all relevant resources (e.g., internationalized strings). OTOH, it works.
ap...@google.com <ap...@google.com> #5
This has security implications as well. Consider the following:
---
App HOST allows access to personally-identifying information through a permission.
App PLUGIN can get access to this information by defining the <permission> as well, and using its own permission.
However, if HOST is not already installed, this permission is not shown to the user when PLUGIN is installed.
When HOST is later installed, PLUGIN now has access to HOST's data, even though the user was never aware of it.
---
Perhaps this is a separate bug. The expected behavior is, if an app has a <uses-permission>, that permission should be shown to the user REGARDLESS of whether the permission exists in another app or doesn't.
---
App HOST allows access to personally-identifying information through a permission.
App PLUGIN can get access to this information by defining the <permission> as well, and using its own permission.
However, if HOST is not already installed, this permission is not shown to the user when PLUGIN is installed.
When HOST is later installed, PLUGIN now has access to HOST's data, even though the user was never aware of it.
---
Perhaps this is a separate bug. The expected behavior is, if an app has a <uses-permission>, that permission should be shown to the user REGARDLESS of whether the permission exists in another app or doesn't.
ap...@google.com <ap...@google.com> #6
It doesn't work this way. Permissions are granted at install time *only*, so if you install HOST after PLUGIN, PLUGIN doesn't get any extra permissions. Of course, if they are using sharedUserId you get the union of both sets of permissions, but that's a different story.
sh...@google.com <sh...@google.com>
da...@gmail.com <da...@gmail.com> #7
Perhaps it's not meant to work this way, but I just tested and it does. I installed PLUGIN first (which has both <permission> and <uses-permission>), which obviously doesn't work correctly because HOST is not installed. Then I installed HOST (which has the same <permission> defined). PLUGIN now has access to HOST.
lp...@google.com <lp...@google.com> #8
#9: However, you were presented with the custom permission at install time of PLUGIN, as you had <uses-permission>. The exception to this is signature-level permissions, which are never presented to the user, as the signature match alone is sufficient.
Description