As it turns out, it used to be possible for there to be multiple
input events simultaneously in flight in an application. Although
it worked, it made it hard to reason about what was going on.
The problem was somewhat exacerbated by the introduction of a
queue of "InputEventMessage" objects as part of an earlier latency
optimization.
This change restores order from chaos and greatly simplifies the
invariants related to input event dispatch within the application.
Change-Id: I6de5fe61c1fe2ac3dd33edf770d949044df8a019
Make surface management between SurfaceView and the window manager
much more controlled, to ensure that SurfaceView always gets to report
the current surface is destroyed before the window manager actually
destroys it.
Also a small tweak to allow windows that have a wallpaper background
to still have a preview window. This makes launching home after it
has been killed feel much more responsive.
Change-Id: I0d22cf178a499601a770cb1dbadef7487e392d85
- getting rid of blue glow (5529032)
- moving app icon position
- show message if there are no recent apps (5533332)
- fixing rare IllegalStateException on orientation change (5584344)
Change-Id: I2210e584957869c8f02339e6841daf39364a9dad
This came up from bug #5601885: Memory increase (leak?) in system_server
Stingray MR1
This isn't *really* a leak in the system process -- it is a leak in an
application process that is causing the system process to keep around
a bunch of ActivityRecord objects longer than it should, until that app
process is ultimately killed.
Unfortunately these days leaking an ActivityRecord also often means
leaking a thumbnail, which is a big slab of memory.
So make the activity manager better about this, using a weak reference
from the handle the object has so we can still clean away most of the
state associated with the ActivityRecord even if the client side leaks
its own reference.
Change-Id: Idbab45e09749cdfb54899203da7981e7b3576e25
...should not be restarted when rotating screen on xoom
This was a side-effect of a previous fix to compute the screen layout
config class based on the actual space available to the application, not
the raw display size. On a device like Xoom, the system bar causes us
to switch between LONG and NOTLONG depending on whether the system bar
is on the short or long side of the screen.
To fix this, we now compute the screen layout class the same way
"smallest width" is computed: looking at all of the possible rotations
and using the smallest of them all. In addition to preventing the device
from toggling between long and notlong on a Xoom-like screen, this will
also avoid other possible undersireable behavior like changing screen
layout size when rotating.
This does mean that Xoom is no longer considered a long screen even when
in landscape, because it is not a long screen in portrait.
Change-Id: I85f90a16294ef5a7de94d5b9231abbc6f914fe90
Previously, the input dispatch rate was capped by default to 55.
This worked fine for systems with a refresh rate of 55 or lower. But on
devices with a higher frame rate (such as stingray at 60 fps), we do not
receive events as fast as the rendering system wants to redraw the frames, so
we would occasionally miss events between frames, resulting in a visual
stutter during drag operations where the dragged object would essentially
stay still for a frame.
This fix increases the default rate to 90, or 1.5 times the highest typical
refresh rate of our devices.
Change-Id: Id8622185b3da93f9f6505157d2e6f3f33e36bd04
The ScreenShot layer is now created hidden. The screenshot itself
is aquired during the transaction when the layer is made visible.
This guarantees the screenshot and the layer happen atomically
with respect to screen updates.
Bug: 5534521
Change-Id: Ida23e1f13d5716ec83b78a15712e0646d6cf8729
- IME service now switches between visible and perceptible depending on
whether it is being showm, allowing us to more aggressively free its
memory when not shown.
- The activity display time is no longer delayed by the activity
transition animation.
- New -R (repeat) option for launching activities with the am command.
- Improved some documentation on Loader to be clear about some methods
that apps should not normally call.
- FrameworkPerf test now allows you to select individual tests to run.
Change-Id: Id1f73de66dc93d63212183958a72119ad174318b
Introduce a new concept of "B" services. All running services are
classified as either A or B. B services are later in the LRU list.
Their oom_adj is after the home app. This allows us to better pick
services to kill based on how long they have running, and should
reduce the amount that we end up killing the home app.
This temporarly turns on a debug log when the oom_adj of a process
is changed. Sorry, I know it is noisy. This is needed to try to
track down why some processes are being killed.
Also add a flag to the SyncManager's service binding to allow the
syncing process to be more aggressively killed if it has done UI.
This is to address cases we have seen where sync is causing an 80MB
gmail process to be kept around, preventing other process from running.
Now what will happen is that the syncing process will aggressively be
killed by the system, and can then be restarted in a much lighter-weight
state.
Do a little tweak in the power manager to allow us to still do smooth
brightness changes even when the fancy TV off animation is in use.
And get rid of a debug log in the window manager that was accidentally
left in.
Change-Id: I64a8eeaaa1f096bab29c665fbff804c7f1d029e2
Swiping the home screen causes the WindowManagerService to do
a bunch of work to keep the wallpapers in sync. First, it lays out
and places all windows. Also, it notifies the SystemUI process that
the wallpaper position has changed.
The layout/place operation is too much work - we only need to set
the position values for the wallpaper, not relayout the whole system.
The notification mechanism must exist, but should be optional. Most
wallpapers don't care (especially static ImageWallpapers). So we'll
give them a new API (WallpaperService.Engine.setWantsOffsets()) to
allow wallpapers to opt out of this process and avoid the performance
overhead.
Change-Id: I66c38375438937f14f6f5550565b28eb204b1e06
Fix a few places where we would unfreeze the screen too early.
Now that we are no longer relying on surface flinger freezing, we
can't depend on it keeping the screen frozen until surfaces get
drawn.
Change-Id: Icb03bf30c9599a5e2016817bfa5ca6458adc7249
If an app takes the 5-second ANR timeout before responding to a
drop, but then recovers, we were inappropriately throwing an
exception back at it for having acknowledged the drop after we'd
abandoned the operation out from under it. Now we let such
responses slide without taking any punitive action: the app is
still okay, and the drag/drop operation was cleanly terminated
already anyway.
Bug 5045618
Change-Id: I0b7e76c61f0f8c97e41280b542a470a7d3c8d86f
It is no longer sufficient to check the value of
internal.R.bool.config_showNavigationBar to determine if a
navigation bar (separate from the status bar) is shown on a
device, because the emulator needs to be able to override
this value (now possible by setting qemu.hw.mainkeys to "1"
or "0", for navbar or no navbar, respectively).
This logic is now contained in PhoneWindowManager, and any
clients wishing to know whether the system has a software
nav bar should consult the new hasNavigationBar() method.
Bug: 5404945
Change-Id: I119d32a8c84b88b2ef46f63244e7f11dc5de0359
A LayerScreenshot is a special type of layer that contains a screenshot of
the screen acquired when its created. It works just like LayerDim.
Make sure to call compositionComplete() after rendering into a FBO.
Bug: 5446982, 5467587, 5466259
Change-Id: I5d8a1b4c327f9973d950cd4f4c0bca7f62825cd4
A LayerScreenshot is a special type of layer that contains a screenshot of
the screen acquired when its created. It works just like LayerDim.
Bug: 5446982
Change-Id: I7814aff2380e7e146937f2b641907be2a30c76cc
...dev.bootcomplete flags is set before boot animation is out
Also:
- Fix crash in recent apps if the intent for an old app didn't
happen to have the new task flag set.
- Fix issue where a crash in system UI would cause the crash
dialog to be displayed below it, effectively locking the UI. Now
the crash dialog for persistent processes is shown above everything
else.
Change-Id: I0312001a92beeae5f644c7c3e5c5e19f6716df36
The window manager now uses the app screen dimensions to compute
the various configuration properties, as it should.
This means that prime is official a "not long" device. Poor prime.
It probably feels inadequate now.
Because it is.
Oh and all that other stuff? Debugging logs. Turned off. And
why the heck not, debugging logs are great.
Change-Id: Iaaf8ef270d986d34fd046d699ef4c0ecea1981fc
Bug: 5011907
Introduce a 150ms delay in handling volume down keys
while waiting to see if a power key will follow.
Don't trigger the screenshot chord if both volume up and
volume down are pressed together.
Don't trigger the long-press power menu if volume keys are
also pressed.
Require the user to press both keys in the chord within
the debounce time and continue long-pressing them in order
to trigger the screenshot action.
Change-Id: I248968d37b73c09d6d08e7f62667c443eba32da0
This change merges the ISurfaceComposer::setOrientation functionality
into ISurfaceComposer::setTransactionState. It enables the window
manager to atomically update both the display orientation and the
position and size of the windows in a single transaction with
SurfaceFlinger.
Bug: 5439574
Change-Id: I18a8ccc564d7d760ef8afb2d015ccdb7a7963900
...the "Complete action using" dialog
When an application goes idle, it sends back to the activity manager
the configuration it last used, to make sure the two don't get out
of sync. Fix a bunch of edge cases here in dealing with that, and
be sure to also send the current configuration when launching an
activity so the client is always up-to-date when launching.
Also a small fix to not show the upgrading dialog during first boot.
Change-Id: I14ed366a87cd689d1c78787369e052422290ac6f
The PhoneWindowManager is now responsible for hiding and showing
the nav bar.
For hiding, it just moves it off the screen (easy way to get a
nice slide animation on and off). At the same time, we use a
new WM facility to put up a fake input window to capture all
touch events.
When a touch event is received, we force the system UI to clear
the navigation hiding bit so it will be shown again.
This removes a bunch of code from the system UI for hiding and
showing the nav bar. Also removes the code calling from userActivity()
to the system UI, which was bad. (Also no longer using userActivity()
fixes bugs around re-showing the nav bar due to key presses and
other wrong things.)
Change-Id: I8c3174873b5bcaa36a92322a51e8f7993e88e551
This cleans up how ui flags are managed between the client and window manager.
It still reports the global UI mode state to the callback, but we now only clear
certain flags when the system goes out of a state (currently this just means the
hide nav bar mode), and don't corrupt other flags in the application when the
global state changes.
Also introduces a sequence number between the app and window manager, to avoid
using bad old data coming from the app during these transitions.
Change-Id: I40bbd12d9b7b69fc0ff1c7dc0cb58a933d4dfb23
This is another place where we are messed up by the stupid default
Configuration having a 1.0 font scale. Argh.
Change-Id: Iaa2550d4edab92fb8a52f98fbb9fd8ef5fab94b5
This change ensures the wallpaper is rendered into an opaque surface
which avoids a glClear() in SurfaceFlinger. This should save quite
a bit of work on every frame when panning the workspace in launcher.
Change-Id: I9c1b8c324edf29826d5dbb1fb39d883e43375310
Bug: 4981385
Changed the orientation listener to notify the policy whenever
its proposed orientation changes, and changes the window manager
to notify the orientation listener when the actual orientation
changes. This allows us to better handle the case where the
policy has rejected a given proposal at one time (because the
current application forced orientation) but might choose
to accept the same proposal at another time.
It's important that the proposal always be up to date. A proposal
becomes irrelevant as soon as the phone posture changes such
that we can no longer determine the orientation with confidence
(such as when a device is placed flat on a table).
Simplified the orientation filtering. Now we just wait 200ms
for the device to be still before issuing a proposal. The idea
is that if the device is moving around a lot, we assume that
the device is being picked up or put down or otherwise in
the process of being moved. We don't want to change the rotation
until that's all settled down. However, we do want to tolerate
a certain amount of environmental noise.
(The previous confidence algorithm was also designed along
these lines but it was less direct about waiting for things
to settle. Instead it simply made orientation changes take
longer than usual while unsettled, but the extra delay was often
too much or too little. This one should be easier to tune.)
Change-Id: I09e6befea1f0994b6b15d424f3182859c0d9a530
...Should Skip Unsecure Lockscreen (ICS)
Also while I am in there, clean up logging of intent objects to include
even less sensitive information, while showing the true Intent in dump
output (since apps can't get to that).
Change-Id: I35fed714645b21e4304ba38a11ebb9c4c963538e
Bug: 4981385
Simplify the orientation changing code path in the
WindowManager. Instead of the policy calling setRotation()
when the sensor determined orientation changes, it calls
updateRotation(), which figures everything out. For the most
part, the rotation actually passed to setRotation() was
more or less ignored and just added confusion, particularly
when handling deferred orientation changes.
Ensure that 180 degree rotations are disallowed even when
the application specifies SCREEN_ORIENTATION_SENSOR_*.
These rotations are only enabled when docked upside-down for
some reason or when the application specifies
SCREEN_ORIENTATION_FULL_SENSOR.
Ensure that special modes like HDMI connected, lid switch,
dock and rotation lock all cause the sensor to be ignored
even when the application asks for sensor-based orientation
changes. The sensor is not relevant in these modes because
some external factor (or the user) is determining the
preferred rotation.
Currently, applications can still override the preferred
rotation even when there are special modes in play that
might say otherwise. We could tweak this so that some
special modes trump application choices completely
(resulting in a letter-boxed application, perhaps).
I tested this sort of tweak (not included in the patch)
and it seems to work fine, including transitions between
applications with varying orientation.
Delete dead code related to animFlags.
Handle pausing/resuming orientation changes more precisely.
Ensure that a deferred orientation change is performed when
a drag completes, even if endDragLw() is not called because the
drag was aborted before the drop happened. We pause
the orientation change in register() and resume in unregister()
because those methods appear to always be called as needed.
Change-Id: If0a31de3d057251e581fdee64819f2b19e676e9a
The key thing was to fix isVisibleOrBehindKeyguardLw() so that it
wouldn't count a window as not visible if it was just currently
in the process of drawing due to an orientation change.
Also improve logic in deciding when to turn screen on to better ensure
the screen is in a stable state, in particular treating screen off
as a frozen screen and not allowing it to turn on until the
update of the screen due to any config change is done.
Change-Id: If82199f3773270b2d07f9c7de9da2dad8c7b28d7
Rework how we decide when it is okay to turn on the screen by having
the policy call back to the power manager when it knows the lock screen
has been drawn.
Change-Id: Ie8f3f72111dcf7f168723e6dce24e0343b4afe5d
PhoneWindowManager now takes full responsibility for deciding where the
navigation bar goes. This gets rid of a bunch of race conditions with
determining layout while the nav bar is moving itself at the same time
the window manager is computing a new configuration.
Note that this breaks the "nav bar on left" option. The current nav
bar code could also be cleaned up some more to completely drive its
behavior based on onSizeChanged() happening during relayout.
Change-Id: I1651d74c3464ba0d588aab3049e099c78420146a
