Split the DisplayManager into two parts. One part is bound
to a Context and takes care of Display compatibility and
caching Display objects on behalf of the Context. The other
part is global and takes care of communicating with the
DisplayManagerService, handling callbacks, and caching
DisplayInfo objects on behalf of the process.
Implemented support for enumerating Displays and getting
callbacks when displays are added, removed or changed.
Elaborated the roles of DisplayManagerService, DisplayAdapter,
and DisplayDevice. We now support having multiple display
adapters registered, each of which can register multiple display
devices and configure them dynamically.
Added an OverlayDisplayAdapter which is used to simulate
secondary displays by means of overlay windows. Different
configurations of overlays can be selected using a new
setting in the Developer Settings panel. The overlays can
be repositioned and resized by the user for convenience.
At the moment, all displays are mirrors of display 0 and
no display transformations are applied. This will be improved
in future patches.
Refactored the way that the window manager creates its threads.
The OverlayDisplayAdapter needs to be able to use hardware
acceleration so it must share the same UI thread as the Keyguard
and window manager policy. We now handle this explicitly as
part of starting up the system server. This puts us in a
better position to consider how we might want to share (or not
share) Loopers among components.
Overlay displays are disabled when in safe mode or in only-core
mode to reduce the number of dependencies started in these modes.
Change-Id: Ic2a661d5448dde01b095ab150697cb6791d69bb5
When the second user downloads a new wallpaper service, Wallpaper
service needs to query the correct user's package state to figure
out if it is available and bind to it.
Change-Id: Ifb95db1c859887f996f5b2e821b4b46510ee7016
Store the userId in the PendingIntentRecord.Key, so that it doesn't match
an identical pending intent from another user.
Change-Id: Icfc39e0f717c902dc3a60bdf5283a3402bbd2eaa
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
We now notify the user of a captive portal before switching to the network as default.
This allows background applications to continue to work until the user confirms he
wants to sign in to the captive portal.
Also, moved out captive portal handling out of wifi as a seperate component.
Change-Id: I7c7507481967e33a1afad0b4961688bd192f0d31
We also now send the correct broadcasts to each user.
You no longer need to be running the shell as root
to be able to create/remove users.
Also added some more man page material to the pm command, and
got rid of a bunch of showUsage() calls that now make error
messages completely buried because of how large the usage info
has become.
And the package manager now shows the user each historical broadcast
was sent to.
Change-Id: Iab42498e1352a0c023069139c80fc04d2d69ab4b
Cleaned up the implementation of Surface and SurfaceSession
to use more consistent naming and structure.
Added JNI for all of the new surface flinger display API calls.
Enforced the requirement that all Surfaces created by
the window manager be named.
Updated the display manager service to use the new methods.
Change-Id: I2a658f1bfd0437e1c6f9d22df8d4ffcce7284ca2
Adds support for always-on VPN profiles, also called "lockdown." When
enabled, LockdownVpnTracker manages the netd firewall to prevent
unencrypted traffic from leaving the device. It creates narrow rules
to only allow traffic to the selected VPN server. When an egress
network becomes available, LockdownVpnTracker will try bringing up
the VPN connection, and will reconnect if disconnected.
ConnectivityService augments any NetworkInfo based on the lockdown
VPN status to help apps wait until the VPN is connected.
This feature requires that VPN profiles use an IP address for both
VPN server and DNS. It also blocks non-default APN access when
enabled. Waits for USER_PRESENT after boot to check KeyStore status.
Bug: 5756357
Change-Id: If615f206b1634000d78a8350a17e88bfcac8e0d0
Was not properly handling creating DefContainerService when the installation was
for USER_ALL. Not a problem for Market installs.
Bug: 7061571
Change-Id: I4528b4c56e38effa137da56460e78c55b242ba45
Previous assumption -- that the drag window was defined at time of
DragState construction -- was false. The window, and hence the
Display, is not known until performDrag. This change delays assigning
DragState.mDisplayContent until the window/Display is known.
Fixes bug 7028203.
Change-Id: I5799005652c484ff0c45ab340ce3b9e4b784883e
The system depends on receiving reliable vsync signals from
surface flinger during the boot process. If it doesn't get them
because the screen is off then a hang may occur.
This isn't a problem when surface flinger manages the screen
blanking itself but it is a problem for devices that still
rely on early-suspend. When early-suspend is involved, the
screen may be off without surface flinger knowing. This is a
problem because surface flinger will only synthesize fake
vsyncs when it knows the screen is off, otherwise relying
on the hardware to generate vsync signals itself. Unfortunately,
the hardware won't generate vsync signals if the screen was
turned off by early-suspend, so we have a problem.
Bug: 6975688
Change-Id: Iaf4527f716bf4ea72cc3e6fdaf060855697b02f2
The GpsLocationProvider typically acquires a wake lock
before sending a message to its handler then releases it
after the message has been handled.
There were two cases where messages might be removed from
the handler, resulting in the wake lock being released.
There were also two cases where background tasks were being
started while not holding a wake lock for the duration.
Fixed these issues and marked the GpsLocationProvider handler
as asynchronous too so that it doesn't accidentally get
blocked by traversals if it happens to share a thread with some UI.
Bug: 7057752
Change-Id: I8e12fc91ae943e84db068c08ec809879537503c6
There are potentially very many Handlers owned by services
that should not be blocked by barriers introduced by UI traversals
occurring on the same thread (if that ever happens).
Add some convenience constructors to make it easy to switch
these Handlers over to being async.
Bug: 7057752
Change-Id: I64d9bffe81e7c52ada4cfad4e89d4340153f4688
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
queryIntentReceivers() needs the resolvedType string to be non-null
in order to find the receiver.
Change-Id: If473d7e08e79940c3e495bc7a9d136e4130599a1
This intent filter isn't used anymore, since GpsLocationProvider handles
the CONNECTIVITY_ACTION broadcasts now..
Change-Id: I593a9916aa6f8086b4d684cc3e25286c1cb137cc
Currently, the NTP and XTRA downloads block on the GPS provider thread.
This could potentially block the next tasks for over a minute of time.
If the upcoming task happens to be AGPS, AGPS will time out.
Placed the NTP and XTRA downloads in separate threads.
Bug: 6980618
Change-Id: I57a6aaf5348212bc1246813f6d941da7d5b19136
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
Generate the racoon and mtpd daemon arguments in system_server,
instead of accepting them from Settings.
Bug: 5756357
Change-Id: I42c1a644f6add477fe4222342640d7db15982cb8
