| 007751276c210c39bd405ae9fa69854e67e80951 |
|
20-Aug-2013 |
Craig Mautner <cmautner@google.com> |
Merge "Notify ViewRootImpl when it's safe to modify Canvas." into klp-dev
|
| bc57cd1b248bf23e443581f9fe44167c94699ce8 |
|
20-Aug-2013 |
Craig Mautner <cmautner@google.com> |
Notify ViewRootImpl when it's safe to modify Canvas.
When Activity.convert{To|From}Translucent() is called the
ViewRootImpl is now notified when it is safe to convert the Canvas
from translucent to opaque and back to translucent. This will make
it possible to save resources when compositing opaque layers.
Fixes bug 10349536.
Change-Id: I7282aee1d54601fb00611d20be204bf164d873f6
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
| 46bfc4811094e5b1e3196246e457d4c6b58332ec |
|
17-Aug-2013 |
Romain Guy <romainguy@google.com> |
Fix hardware layers lifecycle
Bug #10075732
Hardware layers could survive across EGL terminate events.
Change-Id: Ie8565d55cb29fe6625fa1584d695edfecd37ab5e
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
| 4f09d517c5e61d4dfd34b89a7949897c86853881 |
|
01-Jul-2013 |
Craig Mautner <cmautner@google.com> |
Remove debug logging.
Bug has been fixed.
Change-Id: Ifda11ac6e83012498855e0c7254c99491b128f04
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
| e7c58b6d7d761b93e785b0a399e5b00fdb82f4ce |
|
13-Jun-2013 |
Craig Mautner <cmautner@google.com> |
Add debug for specific bug.
To be removed once the bug is fixed.
Change-Id: Ie273d4503bb0b534af0e9efe8f45c573766e9a74
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
| 8c84109b9fbbf473b225707a38261ff5f99d95fb |
|
24-Jun-2013 |
Dianne Hackborn <hackbod@google.com> |
Use FastPrintWriter... everywhere.
One problem this turned up is, because FastPrintWriter does
its own buffering, a lot of code that used to use PrintWriter
would fail -- if it pointed to a StringWriter, there was no
buffering, so it could just immediately get the result. Now
you need to first flush the FastPrintWriter.
Also added some new constructors to specify the size of buffer
that FastPrintWriter should use.
Change-Id: If48cd28d7be0b6b3278bbb69a8357e6ce88cf54a
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
| 8f303ad97007a9b38d6d927353c1fba812879ae5 |
|
14-Jun-2013 |
Craig Mautner <cmautner@google.com> |
Complete doDie() before executing addView().
If WindowManager.addView() is called soon after
WindowManager.removeView() then the MSG_DIE in the ViewRootImpl
mHandler queue may not have had time to execute. This will cause
WindowManagerGlobal to throw an exception since the DecorView
is being added before it has been removed.
This fix detects that situation by saving all Views that are queued
up for ViewRootImpl.doDie(). If addView() is called for one of these
Views then doDie() is called immediately and not called when MSG_DIE
eventually makes its way through the queue.
This change also makes doDie() non-reentrant by only allowing it to
carry out its functions the first time it is called. This keeps
dispatchDetachedWindows() from causing destruction by recursively
calling back into doDie(). This is usually caused by calling
dismissDialog() from within dispatchDetachedWindow().
Fixes bug 9404689.
Fixes bug 9406261.
Change-Id: Id4fc8054e273215d82366428fef51b9ba98385fe
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
| 92098c7c30bc76310a066b220e625fa9aa4b925d |
|
10-Jun-2013 |
Craig Mautner <cmautner@google.com> |
Dismiss immediately to maintain consistent state.
Fix bug introduced by deferring nulling of mParent.
In dismissDialog the removal was being put on a queue while the
state of the Dialog was being updated immediately. This meant that
if a show() was called before the remove was executed it would try
and add the DecorView a second time. Boom!
Fixes bug 9370301.
Change-Id: I576d1e207c786bc2e21dfd40cb94f2b63a020fe2
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
| 652fdfaf6f8131886dbc925d670e00e9d85e56da |
|
06-Jun-2013 |
Craig Mautner <cmautner@google.com> |
Replace arrays with ArrayList
The three arrays were being reconstructed and copied for each add
and each remove. By replacing them with ArrayList only three
constructions total are required. Also, the number of
System.arraycopy() calls is halved.
Change-Id: I0f8def1b517eb1bc5f930fcd5d3d1e0394071f0e
Conflicts:
core/java/android/view/WindowManagerGlobal.java
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
| 05eb730ca42eec3a40f916062af7442218135303 |
|
04-Jun-2013 |
Craig Mautner <cmautner@google.com> |
Delay removal of windows from WindowManager
When relaunching activities the window manager clears out all windows
by calling a ViewRootImpl.die() in a deferred fashion. Then it
immediately deletes the ViewRootImpl and its view from its list
of windows. When the die() is eventually executed it calls
dispatchDetachedFromWindow() which tries to remove the previously
removed windows causing an Exception to be thrown.
This change waits to remove the windows until after die() has been
completed. Fixes bug 8253030.
Change-Id: I5b41be1c6b776e32128c064267653db98bd95292
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
| f9e989d5f09e72f5c9a59d713521f37d3fdd93dd |
|
05-Apr-2013 |
Jeff Brown <jeffbrown@google.com> |
Queues, queues, queues and input.
Redesigned how ViewRootImpl delivers input events to views,
the IME and to native activities to fix several issues.
The prior change to make IME input event delegation use
InputChannels failed to take into account that InputMethodManager
is a singleton attached to the main looper whereas UI may be
attached to any looper. Consequently interactions with the
InputChannel might occur on the wrong thread. Fixed this
problem by checking the current thread and posting input
events or callbacks to the correct looper when necessary.
NativeActivity has also been broken for a while because the
default event handling logic for joysticks and touch navigation
was unable to dispatch events back into the native activity.
In particular, this meant that DPad synthesis from touch navigation
would not work in any native activity. The plan is to fix
this problem by passing all events through ViewRootImpl as usual
then forwarding them to native activity as needed. This should
greatly simplify IME pre-dispatch and system key handling
and make everything more robust overall.
Fixed issues related to when input events are synthesized.
In particular, added a more robust mechanism to ensure that
synthetic events are canceled appropriately when we discover
that events are no longer being resynthesized (because the
application or IME is handling or dropping them).
The new design is structured as a pipeline with a chain of
responsibility consisting of InputStage objects. Each InputStage
is responsible for some part of handling each input event
such as dispatching to the view hierarchy or to the IME.
As a stage processes an input event, it has the option of
finishing the event, forwarding the event to the next stage
or handling the event asynchronously. Some queueing logic
takes care to ensure that events are forwarded downstream in
the correct order even if they are handled out of order
by a given stage.
Cleaned up the InputMethodManager singleton initialization logic
to make it clearer that it must be attached to the main looper.
We don't actually need to pass this looper around.
Deleted the LatencyTimer class since no one uses it and we have
better ways of measuring latency these days using systrace.
Added a hidden helper to Looper to determine whether the current
thread is the indicated Looper thread.
Note: NativeActivity's IME dispatch is broken by this patch.
This will be fixed later in another patch.
Bug: 8473020
Change-Id: Iac2a1277545195a7a0137bbbdf04514c29165c60
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
| 945bfb6068d4ac1414a37a3ebe4dc4d02383e38e |
|
07-Jan-2013 |
Siva Velusamy <vsiva@google.com> |
Support hierarchy viewer commands via DDM
Hierarchy Viewer currently interfaces to the host via a socket
opened by ViewServer which resides in the WindowManagerService.
Since this has access to all windows, it is enabled only on
debug builds.
This CL adds necessary support to DDM to handle all the commands
required for Hierarchy Viewer. It only misses two commands that
are sent to the Window Manager (which we don't have access to
from the applications).
A future CL will remove the ViewServer functionality.
Change-Id: I1dae316a00737b0cae4e640ccc97bf9bb1d05973
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
| 6018aeec27914f138f36b00d8f00136a87562fd3 |
|
23-Oct-2012 |
Craig Mautner <cmautner@google.com> |
Add throwing InvalidDisplayException from addView.
Throw an InvalidDisplayException to addView if the display being
added to has been removed. Handle this exception in Dialog.show()
by removing the view after it has been added and rethrow the
exception from there.
Add javadoc to ViewManager.addView and Presentation.show explaining
the new exception and how best to handle it.
Bug: 7368565 partially fixed. It remains for the Videos app to
handle Presentation.show throwing the InvalidDisplayException.
Change-Id: Ib4303c9b3f7bf7a0cfa95d19bd60a0c128658c48
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
| 2d5618c22101cfc4d6478cfe1d846798389540c1 |
|
18-Oct-2012 |
Craig Mautner <cmautner@google.com> |
Allow getDisplayContentLocked to return null...
... and check for null returns. This prevents DisplayContent objects
from containing null Display references.
Bug: 7368565 fixed.
Change-Id: I830fb4c1349204c366193657a95a92c48ccee66c
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
| 98365d7663cbd82979a5700faf0050220b01084d |
|
20-Aug-2012 |
Jeff Brown <jeffbrown@google.com> |
Refactor for multi-display support.
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
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|