Make grantPermissionsLPw by refactoring some code into a new
function, isNewPlatformPermissionForPackage.
No functional changes.
Change-Id: I467dacfe1fcf7e77cef4cb6df54536eeaafd9064
We can get rid of an indention level by modifying an if/else
block slightly.
No functional changes.
Change-Id: I0404093ea9ebe7729417d825afb6e97e158ad23e
Make grantPermissionsLPw smaller by introducing a new doSignaturePermission
function.
Just a refactoring. No functional code changes.
Change-Id: Ia967fd93e3f7cf3e48fcd13be0b04994b76d36f3
Now that we are smarter about the initialization, we need
to do this after all packages are scanned.
Change-Id: I598f5ef84dcc83779bbff29e4c92136c63fb32de
A Device Owner cannot be uninstalled and is available to all users. It must
be registered before the device_provisioned flag is set.
Device admins can be disabled until used, but visible to device policy
manager, so that users wont be bothered with update requests.
Opened up a few related APIs for use by a system-installed Device Owner.
Change-Id: I847b5fe68c0f724863f778a67602b5bddc79d8e5
This patch set allows the PMS to parse the
mac_permissions.xml file which contains the
seinfo values. Each package that is installed
on the device will be assigned an seinfo value
based on policy. This seinfo value will help label
the app process and data directory. Modifications
include adjustments to ApplicationInfo.java
to store the seinfo tag per package as well as
adjustments to installd to communicate the seinfo
tag to libselinux.
Change-Id: I61ad1ea12fb6a9a6d0b108ec163bc4bf4c954b58
Signed-off-by: rpcraig <rpcraig@tycho.ncsc.mil>
Currently, grantPermission / revokePermission only handles development
permissions. This change extends these two functions to handle normal
and dangerous permissions.
A normal / dangerous permission can modified if it is marked as
optional (android:required="false") using the "am grant" / "am revoke"
commands.
Currently, this change is a no-op. The package parser code
does not currently honor <uses-permission android:required="false"> in
the application's manifest, and assumes a permission is always required.
This change sets the ground for future optional permissions work.
Change-Id: I34f02ffd714e8a9a37b9f87df89cef915b1b6780
Don't automatically grant all normal/dangerous permissions. Instead,
check the value of requestedPermissionsRequired to see if it's required.
If the permission is not required, then only grant it if the permission
was previously granted to the application.
Change-Id: I86b1fae530c006d353f9fa22137598bc88253805
You can now declare shared libraries in apks that are
on the system image. This is like the existing mechanism
of using raw jar files as shared libraries, but since they
are contained in an apk the library can actually be updated
from the Play Store. And this even (mostly) works.
There are some deliberate limitations on this feature. A
new shared library *must* be declared by an apk on the system
image. Installing an update to a system image apk does not
allow you to add new shared libraries; they must be defined
by everything on the base system image. This allows us to
get rid of a lot of ugly edge cases (shared libraries that were
there disappearing after an update is uninstalled for example)
and give some brakes on apps that happen to be pre-installed
on devices from being able to throw in new shared libraries
after the fact.
In working on this, I ran into a recently introduced bug where
uninstalling updated to system apps would fail. This was done
to allow for the new restricted users that don't have all
system apps, but conflicts with the existing semantics for
uninstalling system apps. To fix this I added a new uninstall
flag that lets you switch on the new mode if desired.
Also to implement the desired logic for limitations on declaring
new shared libraries in app updates, I needed to slightly tweak
the initial boot to keep the Package object for hidden system
packages associated with their PackageSetting, so we can look at
it to determine which shared libraries are allowed. I think
this is probably more right than it was before -- we already
need to parse the package anyway, so we have it, and when you
install an update to a system app we are in this same state
until you reboot anyway.
And having this fixed also allowed me to fix another bug where
we wouldn't grant a new permission to an updated app if its
system image version is updated to request the permission but
its version is still older than whatever is currently installed
as an update. So that's good.
Also add new sample code showing the implementation of an apk
shared library and a client app using it.
Change-Id: I8ccca8f3c3bffd036c5968e22bd7f8a73e69be22
PackageParser.updateApplicationInfo() has already interpreted the
various COMPONENT_ENABLED flags for us, no need to clobber them.
Bug: 8331767
Change-Id: If1363c5651a2f0326ee60e92517cfc0e6f256699
API and preliminary implementation for sharing primary user accounts with a secondary user.
AbstractAccountAuthenticator has new methods to retrieve and apply a bundle of credentials
to clone an account from the primary to a restricted secondary user. The AccountManagerService
initiates the account clone when it starts up the user and detects that the user has
a shared account registered that hasn't been converted to a real account.
AccountManager also has new hidden APIs to add/remove/get shared accounts. There might be
further improvements to this API to make shared accounts hidden/visible to select apps.
AccountManagerService has a new table to store the shared account information.
Added ability in PackageManager to install and uninstall packages for a secondary user. This
is required when the primary user selects a few apps to share with a restricted user.
Remove shared accounts from secondary users when primary user removes the account.
Change-Id: I9378ed0d8c1cc66baf150a4bec0ede56f6f8b06b
When a top-level permission group is specified, lookup the group id
by name instead of parsing the value as an integer. This matches
what we do when the group tag is a child of <permission/>.
Change-Id: I54954ae683cecdf72cf846f75383bf6ba862dc5b
Rework how the shell user is defined so that it is
associated with an actual apk, instead of being a free
roaming uid with special permissions assigned to it.
This allows us to correctly account for its operations
in app ops.
Implement a special case for the root user in app ops --
it is always allowed, always with the package name "root".
Add various code to take care of cleaning up package state
from app ops -- when packages are uninstalled, and during
boot if any packages currently being stored no longer exist.
Also fix a bug in the activity manager to correctly grant
permissions in all cases when onNewIntent() is being called.
Change-Id: Iae9f6d793ee48b93518c984ad957e46ae4582581
Restrictions saved as key/value pairs, mostly booleans right now
but might be expanded to other types later.
Save and restore restrictions in the user manager service.
Enforce some of the restrictions at the framework level. Some
are enforced (also) at the app level, such as in Settings.
Change-Id: Id11ffe129cb6a177e094edf79635727388c26f40
The file that defines default preferred apps is now more
robust. It is no longer a raw dump of the package
manager settings, but instead a more general list of a
target activity and filter. When reading it, the remaining
information (match value, set of potential matches) is
determined dynamically.
Change-Id: I0edc6e0d2ed3dd2a6e2238992f18f7fc1f51d8d4
Also add new ops for calendar and wi-fi scans, finish
implementing rejection of content provider calls, fix
issues with rejecting location calls, fix bug in the
new pm call to retrieve apps with permissions.
Change-Id: I29d9f8600bfbbf6561abf6d491907e2bbf6af417
...of Play Store is included
The issue is that the name of the play store apk on the system
image has changed, and the package manager has a bug when this
happens and it is being hidden by an updated version of the
application that is still a newer version. In this case it
doesn't do the normal scan of the system apk, but just leaves
its old disabled state. However if the code path has changed,
this will trip up other code that thinks the system apk has
disappeared (since when it checks for the existence of the apk
with the stored code path, it doesn't find anything).
The fix here is to add a special case to make sure the code
path is updated even if we are otherwise ignoring the hidden
system image package data.
Change-Id: Ic5118f94c078da7a30b53b9cadf7c9844f7ba866
The disabled state allows you to make an app disabled
except for whatever parts of the system still want to
provide access to them and automatically enable them
if the user want to use it.
Currently the input method manager service is the only
part of the system that supports this, so you can put
an IME in this state and it will generally look disabled
but still be available in the IME list and once selected
switched to the enabled state.
Change-Id: I77f01c70610d82ce9070d4aabbadec8ae2cff2a3
Take advantage of this to return better information about
packages filtered by permissions -- include the permissions
they have in the requested array.
Also fix issue #8026793 (Contact picture shows default pic
while searching for a contact in qsb) by using the base
package name of the Context when reporting the app name
of an operation. Otherwise you could make a resource-only
context for another application and do calls through that
and get reported as the wrong app.
Change-Id: I5e0488bf773acea5a3d22f245641828e1a106fb8
Pass targetSdkVersion to installd so it knows the appropriate
permissions to apply to the app's home directory.
Bug: 7208882
Change-Id: Ia62ed36b32ee5af01077fb10a586024411be8ed4
