The InputMethod window was being assigned to the bottommost
window as a fall-through situation when no window could receive
input. This fix changes that so that if the bottommost window
cannot receive IME input then the InputMethod will be unassigned.
In most ANRs associated with bug 10689184 mInputMethodTarget
was assigned to the Wallpaper window and the InputMethod was
placed directly above it. When the ANR occurred the window that
was awaiting focused was then always placed immediately above the
InputMethod. This fix will keep that situation from happening.
Change-Id: Ic247e8132a907f2712a9f8a89e43c099142ec851
Make it a little easier to diagnose input dispatch timeouts by
providing the detailed reason as the ANR annotation in the log.
Bug: 10689184
Change-Id: Ie18fd9ad066b0673d1f57c030e027ad0085f4650
- Deprecates SurfaceTexture.OutOfResourcesException, it wasn't used
- Make all JNI code throw only Surface.OutOfResourcesException
- Get rid of redundant SurfaceControl.OutOfResourcesException
Bug: 10566539
Change-Id: I58126260771b9ccff6a69c672ce7719b9f98138d
Previously the code was adding a window based only on the tasks on
the stack belonging to the window being added. But if a window from
another stack was on top the window would be added out of order.
In particular when there was a dialog over the launcher app and the
device was rotated, the launcher window was being added over the
dialog. This caused the launcher icons to obscure the dialog and for
the dialog buttons to be untouchable.
Fixes bug 9984067.
Change-Id: I9a57eb641d118f4a90e98af8ca77127ab5364e79
Previously it was constrained to displayInfo.appWidth/appHeight
which comes from PWM.getNonDecorDisplayWidth/Height, which includes
the nav bar.
Also adjust window layout to entire screen.
This allows wallpaper to extend into the navigation bar region,
important if the nav bar is hidden or transparent.
Bug:10505328
Change-Id: Ia6057b9c57b476a48f3b2d8b6368fd631e944a3e
Prevent spurious ANRs in the case where an input event is simply
undeliverable because there is no window at the touched location.
Previously, we would assume that we were just waiting for an
application to start and become available to handle the event but
this assumption is no longer valid.
Monkeys in particular have a tendency to inject events outside
of the boundaries of the display which results in spurious ANRs.
So we should just reject them.
Bug: 9774124
Change-Id: I5c40ce4c942f0557593a229dc5253a0e0bdb8466
- When a new display is added, display add event triggers handleDisplayAddedLocked in
WindowManagerService asynchronously.
- After creating virtual display, application can move on and call addWindow before
handleDisplayAddedLock is called.
- Application's addWindow leads into creating a new DisplayContent, and a window will be added there.
- But when handleDisplayAddedLocked is called later, it will create a new DisplayContent for the
display, and the window added by the application will be lost.
- This CL tries to fix the issue by checking the presence of DisplayContent before creating a new
one.
bug: 9975297
Change-Id: I9fac7ffb57c3e1effa8f0e950539cfae73e7e1c6
The new wallpaper positioning associated with multiple activity stacks
put animation backgrounds in front of the wallpaper. This caused
hideous jank. Testing for visible wallpaper and moving the background
behind it fixes the jank.
Fixes bug 10078282.
Possibly fixes bug 10247094.
Change-Id: I3f4e07accd7276d59725192081904b791f77781f
Once content has been drawn another pass through layout is required
to set mHasContent in the LogicalDisplay. Previously this pass was
occuring because of a delayed animation step. When timing of that
step changed that pass occurred before the draw completed. This is
why Presentations were immediately displayed in jb-mr1 and not
jb-mr2.
Fixes bug 10154780.
Change-Id: I0075c5a73d5cdf972e73fdd59c1fde46df64e245
Fix several problems in the way that the overscan was plumbed in
which could result in information not being delivered to applications.
There was also a violation of certain invariants regarding the
immutability of returned DisplayInfo objects.
Bug: 10213771
Change-Id: I21184a14305e44278b5e81353bf95d511e8517fb
SurfaceControl.closeTransaction() will block until the transaction
takes effect and this happens at the next vsync -- in practice
it means this call blocks for ~15ms.
Immediately after that we ask the choreographer to schedule the
next frame, which will happen at the next vsync. depending the
timing, this would cause the window manager to animate at 30 fps
instead of 60.
This is fixed here by calling the choreographer before we
call closeTransaction().
In the near future, we should be able to fix this by using
an offseted vsync for the window manager and it won't need
closeTransaction() to block at all.
Bug: 10209014
Change-Id: I33d0c5ecfc25154b2859f3023a8cda6e641826bf
Devices can be configured to remain in their default landscape or
portrait orientation by setting config_forceDefaultOrientation true
in overlay/.../values/config.xml.
Activities that desire to run in the non-default orientation are
supported by creating a logical display within the physical display.
Transitions to and from the activity perform a crossfade rather than
the normal rotation animation.
Also, improve SurfaceTrace debug output.
Fixes bug 9695710.
Change-Id: I053e136cd2b9ae200028595f245b6ada5927cfe9
Fix a problem where we would not respect the device's
override display density/size if those had been reset at
some point (to an empty string).
Tweak the tuning of low RAM devices to consider 480x800 as
the base line resolution. That is our target these days.
Improve output of oom and meminfo to include this tuning
information.
Change-Id: Ic9a85b0391b075178c4ac17e64086ef21889f430
PhoneWindowManager.setInitialDisplaySize() uses Resources to determine
the height of the Status and Navigation bars. Previous to this CL the
Configuration was being updated after setInitialDisplaySize() was
called which caused the Status and Navigation Bar heights to use the
initial size and density and not the override values. This fix moves
the updateConfiguration after the override values are read in but
before setInitialDisplaySize() is called.
Fixes bug 9966940.
Change-Id: If5b033f520e14f32080d0f2aebbdc6bdae714f88
- Make sure Home activity goes in the correct task and on the correct
stack.
- Do not allow different users to be in the same task.
- Do not set stacks aside for each user.
Fixes bug 9775492.
Change-Id: I0e7954e917aac8482a1015a36923e02914e2b692
Add properties ro.config.density_override and ro.config.size_override
to provide build-time virtual screen sizes. A device with no
override set with "wm size" will use the size specified by the property.
"wm size reset" will go back to the physical size.
Change-Id: I07a585eb2e0f91365fac2b64c53de3af138a2a85
If a window's task stack has no sibling, restore old behavior
of allowing frame to go below the nav bar.
Bug:9884905
Change-Id: Ifc38901a6633cf431dba8740a65258d0618c0fd0
Remove DisplayContentsIterator and AllWindowsIterator. These were cute
but they take up valuable resources. Iterate over ArrayList members
in their place.
Change-Id: I1d8a3b040175cb88b98f6a7e97cab06d17d5706b
Remove DisplayContentsIterator and AllWindowsIterator. These were cute
but they take up valuable resources. Iterate over ArrayList members
in their place.
Change-Id: Ie0c537608532cfb36f34d976cc6eacd21bad98cd
fixScale(float) method has been extracted from the code but the original
code has been kept in place. Because of this, the animation scale is
"fixed" twice which is not necessary. This patch, simply call
fixScale(float) once and stores the result of it in the scale variable.
Change-Id: I50aeacbc2c13ebbf447506ae4309d50c0e313837
- This window type can be used for Presentation created on top of virtual
private display.
- There can be PRIVATE_PRESENTATION specific policy / behavior, but for now,
there is nothing special.
Change-Id: I9fde0f0376e57fcc60000d3a3f8657a21ef58993
Rename convertToOpaque to convertFromTranslucent. Add the
counterpart to Activity.convertFromTranslucent() for returning from
opaque to a translucent Activity. The caller should wait until
TranslucentConversionListener.onTranslucentConversionComplete() is
called before actually changing the background to translucent.
Change-Id: Id04b026bcc4dd8bad9a33a7af126e1bb28fb9c03
