When an application's user data is cleared, the keystore entries need to
be cleared as well. Previously we were only clearing entries when the
application was uninstalled for all users. Now we cover the case of
multiuser as well.
Bug: 8566369
Change-Id: I201c92d0893f0d18e87970dcd59ef6cd904584dc
If someone explicitly installs an update to a system-bundled package,
we infer that this means they actually want to use the new code.
Bug 7467302
Change-Id: If2dc6f764bafbb3a5c94cbdd32273c030fd784b9
Some permissions are associated with gids, so we need to
kill any running processes if their permission is revoked.
We will do this for any permission being revoked, since
the association between gids and permissions can change
over time.
Change-Id: Ieb7408e032539c4f21eb089d65a7a7e6c289f010
Add a hook into PackageManagerService so that when app IDs are
completely removed, we erase all entries from keystore for those UIDs
that have gone away.
(cherry picked from commit 95e3ee3971)
Bug: 3020069
Change-Id: I374258ccc103f8cb3e238f2bf0d1afda0659db94
This has the full filter functionality, but is currently only
able to block Activity intents. Logging intents, or blocking
service/broadcast intents is not yet implemented.
Change-Id: Ied3d8dedf982e17bcbdff3e328eeb87477954df7
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
