IssueTracker

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

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.

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.

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

The problem here is that the PLUGIN can have a different description of the permission in its <permission> tag than the HOST.
You could even use descriptions that look like a boring android permission like INTERNET.

@mmurphy: That's the thing - at the time of PLUGIN's install, I did *not* see that permission. Could be my ROM though - running 4.2.2/SlimROM/Galaxy Nexus. Would be good if someone could confirm.

@domschuermann: But yes, different descriptions/icons/names are also a problem, and the solution to this isn't trivial.

Might I add, the permission level was kept at the default, and I signed the two packages with different signatures (one with a debug key, the other with a release).

Would anyone be able to confirm if the method I propose on this Stackoverflow post is 'secure' to use until this is resolved? If so, I'll copy the code to here.

http://stackoverflow.com/q/18573139/1256219

Thanks to #10 @@mmurphy for his comments on the above Stackoverflow post.

@Pent - Specific to your app, the work-around for me is to declare your custom permission in my manifest:

    <permission
        android:name="net.dinglisch.android.tasker.PERMISSION_RUN_TASKS"
        android:description="@string/tasker_description"
        android:label="Tasker"
        android:protectionLevel="normal" >
    </permission>

That way, if a user installs Tasker (app A) after my app (app B), the permissions are granted and avoids the user having to reinstall app B (http://stackoverflow.com/q/10620464/1256219), which of course is massive ball ache.

Declaring your/any custom permission to resolve this seems wrong in principle though. I tested declaring the above, without declaring:

     <uses-permission android:name="net.dinglisch.android.tasker.PERMISSION_RUN_TASKS" />

This did not work, which I assume is expected and a relief.

Until this issue is resolved, asking 3rd party developers to declare the same <permission> just doesn't feel right........ but I can't quite put my finger on why. I don't intend to do this and instead:

checkPermissions(this, getCallingActivity().getPackageName()); // get the package name from the sender first

private boolean checkPermissions(Context context, String callingPackage) {

    final List<PackageInfo> apps = context.getPackageManager().getInstalledPackages(PackageManager.GET_PERMISSIONS);

    for (PackageInfo pi : apps) {

        if (pi.packageName.equals(callingPackage)) {

            String[] permissions = pi.requestedPermissions;

            if (permissions != null) {
                for (String permission : permissions) {
                    if (permission.equals("com.package.a.permission.READ_APP_DATA")) {
                        return true;
                    }
                }
            }
        }
    }
    return false;
}

Now this issue has been assigned as a defect, I would urge the owner to get some feedback. I believe the Android permission system needs a radical overhaul as it is. With such a diverse set of users, the one-rule-fits-all can't continue - So getting this aspect right from the first fix would be a very good plan....

Over and out.

Is there any update on this bug ? I'm still hitting this issue for "normal" permissions and the suggested workarounds are not ideal.

Yes, this is the way permissions work.

Adding moltmann@ if he wants to resurrect this and try to figure out a way to fix this.

Yahoo!! Google finally come up with this solution that we much anticipated.

Perfect!

This is great news ! Thanks Google !

The programmatic control only allows for the creation and reading of rules, but it doesn't allow for checking if existing rules cause the data to be valid or invalid. Is it possible to add such logic?