Why do you care if there is a <perms> tag? What is stored in packages.xml is an implementation detail; all you should really care about is that applications in the system image must still explicitly request the permissions they need, and they have to follow the rules as anyone else: they can get permissions that are not protected, but can only be granted signature permissions where they are signed with the same cert. The only exception is the "signatureOrSystem" permission type, which means the permission can be granted to an app signed with the same cert (whether it is in the system image or a third party app), *or* to any app installed on the system image. There are a handful of such permissions, but it isn't the common case.
As for why there are no permissions stored in packages.xml: there is no need, because they can just be re-evaluated each boot when scanning the packages. It wouldn't make sense for the user to explicitly grant permissions to each application that is pre-installed on the device, so they can just be given whatever permissions they ask (as long as they are allowed to hold the permission as per above). If you use the package manager APIs to find out the permissions that are held by each app, you will see that the system applications are granted the permissions they request as per the rules. How much of this is cached in packages.xml or elsewhere across boots, or evaluated at each boot, is an implementation detail. On Sun, Jun 24, 2012 at 7:34 AM, Jason Meyer <jasonmeyer...@yahoo.de> wrote: > Hey everyone, > > I checked back all the details you gave me. However, my findings are > still not satisfactory. > > The shared UID bit turned out to be true - for some of the packages > stored in /system/app/, but unfortunately not for all. System apps > with a shared user ID usually get their permissions defined in a > section distinct for every shared user ID. There one can also find the > <perms> block related to that specific shared user ID. One example > would be "android.uid.shared", which is used by many Android OS apps. > > > However, there are apps which do not have a shared user ID, but a user > ID of their own - and still come without a <perms> block. One example > is the "/system/app/FileManager.apk" package, which is preinstalled on > my testing device. Every single system app not making use of a shared > user ID lacks a <perms> block. > > ... so for those, I'm back to square one ;) > > I still don't know where their permissions are stored, and it's > definitely not in the packages.xml file. Are permissions for those > just granted at will, without checking the packages.xml file? > > Could maybe an Android dev from Google provide a statement on this > matter? > > -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to android-developers@googlegroups.com > To unsubscribe from this group, send email to > android-developers+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en > -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
