Moved a bunch of methods from PackageManager to UserManager.
Fix launching of activities from recents to correct user.
Guest creation APIs
Change-Id: I0733405e6eb2829675665e225c759d6baa2b708f
TYPE_DREAM windows are now considered for relevant window
flags alongside application windows.
Bug: 6961616
Change-Id: Idee3303276a8b69c7f07de1d6acdce64c6e1b863
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.
If the rotation sensor has been disabled we were substituting the
last app rotation for the sensor value. This fix uses the last
sensor value delivered before the sensor was disabled. Only use
the last app rotation if we never have received a valid sensor
value.
Fixes bug 6387946.
Change-Id: I50743c30ee2b4455e9848d3a619809be97eec3c8
Enable feature in config. Expose Dream in public api for unbundled apps.
Unhide package. Add isDreaming() method to service.
Re-arrange the Dream api a bit. (use onStart as hook for subclasses).
Coordinate properly with power manager.
Replace old dock mode (don't fire old intent).
Change-Id: I1318d20cc1613e5d862f2913f2fcdc9719302cf7
Bug: 6921930
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
This fixes a bug where keyguard would always change orientation
when enabled from config_enableLockScreenRotation. Now it follows
the user preference.
Change-Id: I0437d11e1984d22cdadddc57deb47d800fb86aa1
- We now pass a more robust battery status object to methods that handle battery updates.
- Consolidated battery decision code into BatteryStatus object (e.g. charging, low, charged)
so it can be shared.
- Consolidated SIMStateCallback into common KeyguardUpdateMonitorCallback object to reduce complexity.
- Consolidated user changes into common callback using KeyguardUpdateMonitorCallback.
- Fixed a race condition caused by launching LockSettingsService after WindowManagerService.
Change-Id: I6b2a328f8581f35593e41348693b92ab66d02429
These have been created to reduce the size and complexity
of frameworks/base.
mms-common was created by moving all of
frameworks/base/core/java/com/google/android/mms
to:
frameworks/opt/mms
telephony-common was created by moving some of
frameworks/base/telephony
to:
frameworks/opt/telephony
Change-Id: If6cb3c6ff952767fc10210f923dc0e4b343cd4ad
This fixes a bug introduced by If6cb3c6ff952767fc10210f923dc0e4b343cd4ad
that accidentally reverted I019d1d8c65c55cbf4d10d4928e1d2b2b242162a6
Change-Id: Ia006bf31387162a520374f3bc9acb6e69197b106
These have been created to reduce the size and complexity
of frameworks/base.
mms-common was created by moving all of
frameworks/base/core/java/com/google/android/mms
to:
frameworks/opt/mms
telephony-common was created by moving some of
frameworks/base/telephony
to:
frameworks/opt/telephony
Change-Id: If6cb3c6ff952767fc10210f923dc0e4b343cd4ad
The sound effect volume attenuation calculation is wrong: the
division by 20 was always returning 1 or 0.
In AudioService, rename the sound effect attenuation value to
follow the naming conventions for static variables.
Change-Id: I3c36d50f4470ff09ca98cb944aefb5ad0f968782
Make sure that all cases where we remove an activity from the history
stack, we call resumeTopActivityLocked() to cause the home activity
to be launched if the stack is now empty.
Also fixed a problem where some timeouts would not be removed when destroying
an activity, and a race condition in boot that would cause the
PhoneWindowManager to initially start out with the home key not working.
Bug: 6381224
Change-Id: If046bb01aed624b0d9ee3bbaaba68ed6b98fd1d0
In the course of the window manager refactoring into a separate
layout state, we introduced a bad interaction between the two
sides of the world. This resulting in multiple hops needed between
the two sides after an application has said it is finished drawing
its window, until the window/app transition is actually started.
Especially since these hops require going through the anim side
which is vsynced (so will delay its operation until the next frame),
this could introduce a notable delay until the window is first shown.
Fix this by re-arranging the code to make one straight path from
when a window reports it is shown to us starting the app transition
that is waiting for it. This change also includes various improvements
to debugging code that was done while working on it.
Change-Id: I7883674052da1a58df89cd1d9b8d754843cdd3db
KeyguardViewMediator.onScreenTurnedOn is not called if the device is
booted into the power-on state. In this case mScreenOn remains false
and the lockscreen will always appear after outgoing calls. This fix
ensures that onScreenTurnedOn is called when the device is powered
up in the on state.
Fixes bug 6709173.
Change-Id: I7557d8f002307b9125bc53b13bc3cb4c5c9b2758
...or settings from lock screen
When a window is drawn, the code to determine whether it should now
be shown was calling WindowState.isReadyForDisplay(). Part of the
condition of this function is that it is not ready if a policy is
forcing the window to be hidden -- which is the case when the lock
screen is shown. As a result, we wouldn't show the window at that
point, so wouldn't tell the activity manager that the token's windows
are visibible, and wouldn't tell the lock screen to go away.
This adds a new variation WindowState.isReadyForDisplayIgnoringKeyguard(),
which is the same as the original method but ignores the policy visibility
for app windows. This allows windows to be go through the complete
path of handling when the window is finally drawn and telling the
activity manager about it, even if behind the lock screen. By making it
a separate function, we don't impact any other code that is calling the
old function and may be relying on its behavior.
Also cleaned up a little of the dumpsys output. Most important, the
new ANR section is now moved to the top, since we want
"adb shell dumpsys window" to still give a nice summary of what we
normally care about -- the window stack and important global state.
Change-Id: Ica3ea85ce46f3f5f5cd2cc30fbd9de13d3885a57
This change allows market apps and 3rd parties to supply an activity
that responds to ACTION_ASSIST (e.g. market apps).
It also adds a test app to respond to the ASSIST intent and force
the intent disambiguation dialog to appear.
Change-Id: I5a78863c6a9546d18c66275187d178f6a1c9ee17
