The activity manager now keeps track of which users are running.
Initially, only user 0 is running.
When you switch to another user, that user is started so it is
running. It is only at this point that BOOT_COMPLETED is sent
for that user and it is allowed to execute anything.
You can stop any user except user 0, which brings it back to the
same state as when you first boot the device. This is also used
to be able to more cleaning delete a user, by first stopping it
before removing its data.
There is a new broadcast ACTION_USER_STOPPED sent when a user is
stopped; system services need to handle this like they currently
handle ACTION_PACKAGE_RESTARTED when individual packages are
restarted.
Change-Id: I89adbd7cbaf4a0bb72ea201385f93477f40a4119
Ensure that only applications with
android.Manifest.permission.PACKAGE_VERIFICATION_AGENT can call application
verification APIs, like PackageManager.verifyPendingInstall and
PackageManager.extendVerificationTimeout
Bug: 7049083
Change-Id: I5fc28b37e864d67cd319a1ed9d03a90dd15ad052
UserManagerService is now closely tied to PackageManagerService,
sharing the same locks. There is no longer direct access of
Installer by UserManagerService, instead the package manager is
back to solely owning it.
Creating a new user now correctly only installs system apps for
that user.
Fixed some misc bugs, where we were getting nulls when
querying content providers and instrumentation in uninstalled
users, incorrect locking, etc.
Change-Id: Ife69b6e373d0cf7c5cfc03fc588e36b43ad5d8b0
This add a new per-user state for an app, indicating whether
it is installed for that user.
All system apps are always installed for all users (we still
use disable to "uninstall" them).
Now when you call into the package manager to install an app,
it will only install the app for that user unless you supply
a flag saying to install for all users. Only being installed
for the user is just the normal install state, but all other
users have marked in their state for that app that it is not
installed.
When you call the package manager APIs for information about
apps, uninstalled apps are treated as really being not visible
(somewhat more-so than disabled apps), unless you use the
GET_UNINSTALLED_PACKAGES flag.
If another user calls to install an app that is already installed,
just not for them, then the normal install process takes place
but in addition that user's installed state is toggled on.
The package manager will not send PACKAGE_ADDED, PACKAGE_REMOVED,
PACKAGE_REPLACED etc broadcasts to users who don't have a package
installed or not being involved in a change in the install state.
There are a few things that are not quite right with this -- for
example if you go through a full install (with a new apk) of an
app for one user who doesn't have it already installed, you will
still get the PACKAGED_REPLACED messages even though this is
technically the first install for your user. I'm not sure how
much of an issue this is.
When you call the existing API to uninstall an app, this toggles
the installed state of the app for that user to be off. Only if
that is the last user user that has the app uinstalled will it
actually be removed from the device. Again there is a new flag
you can pass in to force the app to be uninstalled for all users.
Also fixed issues with cleaning external storage of apps, which
was not dealing with multiple users. We now keep track of cleaning
each user for each package.
Change-Id: I00e66452b149defc08c5e0183fa673f532465ed5
Create a new verifier API to extend the timeout for a giving package,
including the resulting action (allow or deny) upon the timeout occuring.
Bug: 6901038
Change-Id: I351f7944327f863aff1d7dd1227be74652fa1511
Introduce API to get per-user storage information, keep track
of services associated with users, and various small cleanup.
Change-Id: I5d4e784e7ff3cccfed627d66a090d2f464202634
This change passes the originating URL and accompanied referrer to
package verifiers, when available.
Bug: 6544677
Change-Id: I9ebc71bc13f549bd88267e444816151a99bda000
Split WindowManagerImpl into two parts, the WindowManager
interface implementation remains where it is but the global
communications with the window manager are now handled by
the WindowManagerGlobal class. This change greatly simplifies
the challenge of having separate WindowManager instances
for each Context.
Removed WindowManagerImpl.getDefault(). This represents the
bulk of this change. Most of the usages of this method were
either to perform global functions (now handled by WindowManagerGlobal)
or to obtain the default display (now handled by DisplayManager).
Explicitly associate each new window with a display and make
the Display object available to the View hierarchy.
Add stubs for some new display manager API features.
Start to split apart the concepts of display id and layer stack.
since they operate at different layers of abstraction.
While it's true that each logical display uniquely corresponds to a
surface flinger layer stack, it is not necessarily the case that
they must use the same ids. Added Display.getLayerStack()
and started using it in places where it was relatively easy to do.
Change-Id: I29ed909114dec86807c4d3a5059c3fa0358bea61
So each user can have their own set of intent resolution preferences.
ResolverActivity now launches the activity on the correct user, and
persists the preference for the correct user.
Bug: 6961905
Change-Id: I6d3a8a9af89bc649277d4fc8d0f367ee123f8392
Use AtomicFile for usermanager files.
Added a MANAGE_USERS permission that apps (signature permission) can use
to create/query/modify/remove users.
Change-Id: I5cf232232d0539e7508df8ec9b216e29c2351cd9
This allows you to, say, make a Context whose configuration
is set to a different density than the actual density of the device.
The main API is Context.createConfigurationContext(). There is
also a new API on ContextThemeWrapper that allows you to apply
an override context before its resources are retrieved, which
addresses some feature requests from developers to be able to
customize the context their app is running in.
Change-Id: I88364986660088521e24b567e2fda22fb7042819
Moved a bunch of methods from PackageManager to UserManager.
Fix launching of activities from recents to correct user.
Guest creation APIs
Change-Id: I0733405e6eb2829675665e225c759d6baa2b708f
Added a new method to Context: startActivityAsUser() requiring the
INTERACT_ACROSS_USERS_FULL permission.
Show the correct Recents list, based on current user.
Added a getRecentTasksForUser() in ActivityManager. Hidden and requires
the INTERACT_ACROSS_USERS_FULL permission.
Change-Id: If5b56465efdd3ead36601a3b51ed4af157bbf35c
- You can now use android:singleUser with receivers and providers.
- New API to send ordered broadcasts as a user.
- New Process.myUserHandle() API.
For now I am trying out "user handle" as the name for the numbers
representing users.
Change-Id: I754c713ab172494bb4251bc7a37a17324a2e235e
Change the default value of android:exported to true
for applications which target a newer API version.
This will help stop inadvertent content provider
exposure to untrusted apps.
Bug: 3306452
Change-Id: I8cb34e823aef9551319951ce92217345c54cee63
Preloaded drawables now have a density associated with them, so we
can load the correct drawable if we are using a different density.
Window manager now formally keeps track of the density for each
screen, allowing it to be overridden like you can already do with
size, and relies on this density to drive itself internally and
the configurations it reports.
There are a new set of Bitmap constructors where you provide a
DisplayMetrics so they can be constructed with the correct density.
(This will be for when you can have different windows in the same
app running at different densities.)
ActivityThread now watches for density changes, and pushes them
to the DENSITY_DEVICE and Bitmap global density values for that
process.
A new am command allows you to change the density.
- Expose the existing Context.sendBroadcast() as
Context.sendBroadcastAsUser().
- Add new android:singleUser attribute for services.
- Add new INTERACT_ACROSS_USERS_FULL permission for full
system-level access to cross-user interface (allows
sendBroadcastAsUser() to send to any receiver).
- Add new INTERACT_ACROSS_USERS_FULL permission for
more restricted cross-user interaction: this is required
for android:singleUser, and allows you to use
sendBroadcastAsUser() but only to send to your own
receivers.
Change-Id: I0de88f6718e9505f4de72e3f45d29c0f503b76e9
This change passes the originating URL and accompanied referrer to
package verifiers, when available.
Bug: 6544677
Change-Id: If9ff6663ad7f3426b7aea2aceb1413b689788138
This puts in most of the infrastructure needed to allow us to
switch between different densities at run time. The main remaining
uses of the global are to initialize the Bitmap object (not sure
what to do about that since it doesn't have anything passed in
the constructor to get this information from), and being able to
load drawables if we need a different density than what was preloaded
by zygote.
Change-Id: Ifdbfd6b7a5c59e6aa22e63b95b78d96af3d96848
Since applications can have Account providers, they need to be delayed
until after PackageManagerService says everything is mounted.
Otherwise the accounts associated with that provider will be removed
immediately when startup happens.
Bug: 6820670
Change-Id: Iba81765260421649f706624d0605a40ebc1347b1
The purpose of this change is to remove direct reliance on
SurfaceFlinger for describing the size and characteristics of
displays.
This patch also starts to make a distinction between logical displays
and physical display devices. Currently, the window manager owns
the concept of a logical display whereas the new display
manager owns the concept of a physical display device.
Change-Id: I7e0761f83f033be6c06fd1041280c21500bcabc0
Changes to make Bluetooth Service part of the system_service.
These changes may be temporary.
Changes to update to the new disable API.
Change-Id: If89dba17e6e6c6daa53c37684221763a2da076e9
Conflicts:
services/java/com/android/server/pm/PackageManagerService.java
FLAG_ACTIVITY_CLOSE_SYSTEM_DIALOGS was a mistake.
Instead, and the infrastructure for the status bar to take care
of closing and hiding things itself when you press these buttons,
just like it does for the main Intent of the notification.
Bug: 6717667
Change-Id: I1b22186e0cedc05f46a1a3ec78053a72afaf61b1
