| 7eec37989f1d030d8f933712e6cb2bff8d9e4104 |
|
15-Feb-2017 |
Phil Weaver <pweaver@google.com> |
Suppress a11y shortcut on emergency dialer
Suppressing whenever the keyguard is locked, not just when
it's showing. This should reduce false triggering.
Bug: 34820720
Test: Verfied that shortcut no longer activates on emergency
dialer or lock screen.
Change-Id: Ic43c11798f04217c2871efe7d0fa21dbf61fd953
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
| 7039cbc6f3a596aee6851014019849490f358f13 |
|
04-Jan-2017 |
Vladislav Kaznacheev <kaznacheev@google.com> |
Add content description and tooltip to menu item
Bug: 34076597
Test: manual
Change-Id: Ide32463252457721286c929ab2f8f7bae241835d
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
| 42a99377f54309111d4acc3d5660bb4b188353ff |
|
25-Sep-2016 |
Gopal Krishna Shukla <gshukla@codeaurora.org> |
Merge "Provide synchronization to setview to avoid NPE" am: b05b93a674 am: 810c31fdca am: 621e87d72f
am: 260af96306
Change-Id: I1907b2252ae2fa25667b3a0484f6852660c74da3
|
| f7abcda5f22cde86666aeedbf1cc2a99b47ec2c2 |
|
06-Jul-2016 |
Gopal Krishna Shukla <gshukla@codeaurora.org> |
Provide synchronization to setview to avoid NPE
If setView() will be called from two different threads
then mView property of a View object may have inconsistent
value. For instance, setView() may set mView to null causing
NullPointerException. Synchronize root.setView() as well to
avoid this.
Change-Id: I5f9cf47ece5d4aca575bd8644ecfcee0ed43d843
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
| 45faba516e200760e977e8ceb76f079ee8aa7415 |
|
28-Jun-2016 |
Stan Iliev <stani@google.com> |
Fix wording regarding ThreadedRenderer
ThreadedRenderer is not synonymous with hardware rendering, so
remove references to hardware rendering when referring to
ThreadedRenderer.
Change-Id: Ic66a482ccf05f556ebe6ec194ce4f858f75bbb8b
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
| eac0ea5cdfade6bfd2a1e40e67c2a45d4c37ab9e |
|
12-May-2016 |
Andrii Kulian <akulian@google.com> |
Close leaked windows when trying to preserve main one
When app has several windows and activity is relaunched + we try to preserve
main window - other windows just stayed around until removed by timeout or
replaced by app. There was a problem when one of the windows registered
broadcast receiver and set its own timer to remove it. In this case all
receivers were removed by framework because windows were considered leaked
and apps' timer caused crash when trying to remove registered receiver.
This CL removes all windows expect the main one, which we're trying to
preserve in this case.
Bug: 28337135
Change-Id: Ib8790cc8c61801f11d871ba3803bb0ebc3d3be01
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
| d136e51a99df5275eaafdde407e89e78c02b829b |
|
10-Mar-2016 |
Jeff Sharkey <jsharkey@android.com> |
Defuse Bundles parsed by the system process.
It's easy for apps to throw custom Parcelables into Bundles, but
if the system tries peeking inside one of these Bundles, it triggers
a BadParcelableException. If that Bundle was passed away from the
Binder thread that delivered it into the system, we end up with a
nasty runtime restart.
This change mitigates this trouble by "defusing" any Bundles parsed by
the system server. That is, if it encounters BadParcelableException
while unpacking a Bundle, it logs and delivers an empty Bundle as
the result.
Simultaneously, to help catch the system process sticking its
fingers into Bundles that are destined for other processes, a Bundle
now tracks if it's "defusable." For example, any Intents delivered
through ActivityThread are marked as being defusable, since they've
arrived at their final destination. Any other Bundles are considered
to be "in transit" and we log if the system tries unparceling them.
Merges several Parcel boolean fields into a flags int. Add better
docs to several classes.
Bug: 27581063
Change-Id: I28cf3e7439503b5dc9a429bafae5eb48f21f0d93
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
| 0ffd49cbe0ab4c13fd5528abacade898a8cff481 |
|
13-Feb-2016 |
Jorim Jaggi <jjaggi@google.com> |
Always consume bottom insets when navigation bar is force shown
When an app requests SYSTEM_UI_FLAG_LAYOUT_HIDE_NAVIGATION but we
force show the navigation bar, we need to treat for the app like
there is no virtual navigation bar on the device. Because if you
combine it with FLAG_HIDE_NAVIGATION, you'd expect the navigation
bar gets hidden but it doesn't, so there could be content that
overlaps with the navigation bar.
Bug: 27157904
Change-Id: I088e02eae2e723c35e9cb4873de6b1325458533b
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
| 4846ee3cc378001128680f2a3309c7e60bfcac75 |
|
07-Jan-2016 |
Jorim Jaggi <jjaggi@google.com> |
Optimize window relayouts when dragging divider
- Communicate the resize mode to ViewRootImpl. If it is a docked
divider resize, do not call relayout for every traversal.
- Do not call Task.resizeWindows() unconditionally when changing
Stack bounds. It might be just a move.
- However, not calling relayout breaks layout bounds while
relaunching. To fix that, do the following:
-- Inform ViewRootImpl that the activity just relaunched, and force
a relayout call in the next traversal so the client can pick up
the unfrozen bounds.
-- When unfreezing the bounds, cause a traversal in window manager.
Bug: 25015474
Change-Id: Iab9a445dabce4f6ec1e25957038fe40a4be65246
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
| 51aaf906f9f5fb2f117f5ccfae8be6974f7cb903 |
|
03-Dec-2015 |
John Reck <jreck@google.com> |
Nuke HardwareRenderer abstract base
Bug: 17303292
Change-Id: I4a272ea4f695f4f9993e8be640fdd8530b691be0
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
| f4abc2b701c23978e8bd5e4fc3e183e519aede4a |
|
13-Nov-2015 |
Chong Zhang <chz@google.com> |
Need to updateSurface if surface size was changed in relayoutWindow
On some chips, SurfaceControl.setSize will not take effect for several
frames. We have to also do a updateSurface/invalidate (which destroys
and creates the EGLSurface) to get the size right.
Keep track of SurfaceControl size changes in window manager, and pass
that to ViewRootImpl, so that a updateSurface is done either the surface
itself or its size is changed.
Note that we don't use frame size change to trigger updateSurface, because
frame size could be different from the surface size that window manager set.
For example during drag resizing, the surface size is fullscreen although
frame size changes constantly. Doing updateSurface upon frame size change
could cause us to do many unnecessary updateSurface.
bug: 25583942
Change-Id: I1989613a187bb6ef1c179bd2800c6a7b01fcdb3a
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
| 63a35e2343468a04e360f0514c6c9dc03068c185 |
|
06-Nov-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Fix minor problems when resizing/maximizing docked window.
When maximizing the transition should originate from visible bounds, so
the first frame matches what is visible to the user. When switching to
the big surface, we only need to increase the layer by one, instead of
having artificially large value. If we use the large value, it will
cause a flicker over system windows.
Also includes some cleanup, like static imports and necessary logging.
Bug: 24913915
Change-Id: I84d7594622aa639e2008c662f941edf9c20b3202
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
| 0275e397f482a1f25745a66c5db68c3a6c863951 |
|
17-Sep-2015 |
Chong Zhang <chz@google.com> |
Place surface at screen't top-left when doing drag resizing
Instead of letting the client render to (0,0) and moving the surface
around, put the surface at a fixed location, and let the client render
to the screen position within the surface.
This fixes the window shaking problem when resizing by dragging window's
top-left corner. The frame rect used in last draw is lagging window
manager's latest bounds for the window, moving the surface's position
would make the window's bottom-right corner appears moving (while it's
supposed to be stationary).
bug: 23793966
Change-Id: Ideb152fc48502f8e9672235f10b044889235e7df
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
| d70b9e7aea9c7b0691f3ac1326752f91d5049458 |
|
27-May-2015 |
Alan Viverette <alanv@google.com> |
Move ApplicationInfo hardware acceleration to public flags
Bug: 21342038
Change-Id: I5af826f3f2921eef24725c909304243c67f3da78
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
| 827e0facfefd0c0033dcfb1747b4fa6f80f9e0e2 |
|
07-May-2015 |
Jorim Jaggi <jjaggi@google.com> |
Make sure the app can draw a frame before unlocking
- The mechanism to stop windows drawing while window animator was
animating was somehow flaky. It relied on the fact that the client
would call relayout() whenever the animating state changed. This is
mostly the case, but not for lockscreen animations. Instead, we now
use a push model, where window manager tells the app that the state
has changed.
- In addition, it only stopped drawing if that window was animating,
but then only resumed drawing after all windows have finished
animating. Now, we do this per window, so we only stop drawing for
windows that are currently animating.
- We resume the top activity now at the very beginning of the
unlocking sequence. This gives the app a chance to draw a frame
before the user sees anything. If it's to slow, then we just use the
outdated framebuffer.
Bug: 19964562
Change-Id: Ifef8abd189a3146d854b81b9b948861e4d38c155
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
| 41725dedc33906aaafee36b2d6523596e2a8a52e |
|
09-Apr-2015 |
George Mount <mount@google.com> |
Disable input during Activity Transition.
Bug 19437530
While the actual Activity Transitions are running,
input is stopped, except for the "back" button.
Change-Id: I112e6252b9de05ece10a6267681fee5487e5ef6b
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
| 9b0ab65ed46be992dd71b5f811bb972168e51c36 |
|
18-Mar-2015 |
Alan Viverette <alanv@google.com> |
Enable/disable hardware rendering on windows by application tag
Previously, hardware rendering cannot be enabled or disabled
on windows created without a parent activity (e.g. by services)
by setting the <application> tag, "android:hardwareAccelerated"
in AndroidManifest.xml. It's enabled by default in Android L
from the commit, 5e1565ead6dbb7d5c414522591f61b16a23de1c3.
This patch provides a way of setting hardware rendering for
that case.
Change-Id: I60ee9566e99db39cd661fe6f196f43c3968b311a
Signed-off-by: Dohyun Lee <dohyun.lee@lge.com>
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
| ba6adf66d3c44c0aa2fd8a224862ff1901d64300 |
|
19-Feb-2015 |
John Reck <jreck@google.com> |
Initial attempt at jank-tracking stat collection
Is a bit naive, perhaps overly aggressive, but sorta works
Change-Id: I01a774e00dbe681439c02557d9728ae43c45ce50
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
| a7bb6fbeab933326d58aa806d8194b7b13239d34 |
|
04-Feb-2015 |
Dianne Hackborn <hackbod@google.com> |
First quick implementation of auto assist data.
Introduce new AssistData class that contains all data
the framework automatically generates for assist. Currently
populated with a very simple tree structure representing
the app's view hierarchy.
Reworked how we populate the class name for accessibility
info, so this is provided through a new method call on View
that subclasses can override. This method is also used
to populate the class name in AssistData.
Change-Id: Ibd0acdc8354727d4291473283b5e4b70894905dc
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
| 3c0e7e908f1f90677ae3937199e37c162f81b2f9 |
|
13-Jan-2015 |
Wale Ogunwale <ogunwale@google.com> |
am 00c85656: am 42b0d10a: am 1ea6afe1: Merge "Don\'t allow windows with invalid types to be added." into lmp-mr1-dev
* commit '00c8565614d3555e723ff3d8dad3af92d69d81ea':
Don't allow windows with invalid types to be added.
|
| 74bf065e43a3075ffcaf9fcdc1ef423a1e14b761 |
|
12-Jan-2015 |
Wale Ogunwale <ogunwale@google.com> |
Don't allow windows with invalid types to be added.
Bug: 18950225
Change-Id: Ia7ead72d036c7628e0a97f8fe9fef2a35525e4df
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
| 9ecb73c7d89164529fdf8462187f0a3e9a0ed136 |
|
15-Dec-2014 |
Alan Viverette <alanv@google.com> |
Don't force hardware acceleration for services on low-end GFX
BUG: 18732678
Change-Id: I136135a91296de3e7d4c089b61019a5395de4a5b
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
| 8ccf071ab83510c8ef7b4d311d894d5c4a352f6c |
|
20-Nov-2014 |
Alan Viverette <alanv@google.com> |
Merge "Move default token handling into WindowManagerImpl" into lmp-mr1-dev
|
| 7c9746d4ef8ab3c500b501ab32933c5172a856ab |
|
20-Nov-2014 |
Alan Viverette <alanv@google.com> |
Move default token handling into WindowManagerImpl
BUG: 18451795
Change-Id: I1fc6db988ad879fded5318f33d08a4f09da38907
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
| 0d1c27a713cb49de8f6f4fd0a129baa883153921 |
|
03-Nov-2014 |
Chet Haase <chet@google.com> |
Fix seeking and scaled duration behavior
The animation scaled was not being factored in early enough in the
activity lifecycle. Also, setCurrentPlaytTime() was not accounting for
the scaled duration correctly. Finally, added setCurrentFraction() as
a more general-purpose seeking facility.
Issue #18222006 Animator duration scale ignored in some situations
Issue #17951668 add ability to seek fraction, not just time
Change-Id: Idad401f5ff5026d7046c36eee09d78a4793215dc
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
| d2fa5143910c74fd126359f74b08de84b0f7cf2a |
|
05-Nov-2014 |
Alan Viverette <alanv@google.com> |
Use default token instead of wrapped window manager
BUG: 18248602
Change-Id: Id7f06c896dc71db3564fa21d3704222557613035
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
| 955d8d69ea6caabce1461dc25b339b9bf9dc61a6 |
|
08-Oct-2014 |
Dianne Hackborn <hackbod@google.com> |
Put in real "code" (aka marketing) name.
Change-Id: Idb3976edfae37293ed75cb5b869b4b42d8042bbe
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
| ccf2fa00314b91c7d25e0edf48e0e2b51dbc4e63 |
|
25-Sep-2014 |
John Reck <jreck@google.com> |
Missing null check
Bug: 17642023
Change-Id: I874b76e1e184a59dec714191d759c1045b7b9814
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
| 73840ea3670f1c117843acc6069635c80ba2ffd2 |
|
22-Sep-2014 |
John Reck <jreck@google.com> |
Aggressively trim memory for system_process
Bug: 16978006
Don't HWUI-accelerate KeyguardScrim
Aggressively trim memory as soon as a ViewRootImpl
dies or has its visibility changed.
Change-Id: Ie1b7c9d30653456bd2e9f309128174f972999368
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
| 5e1565ead6dbb7d5c414522591f61b16a23de1c3 |
|
30-Jul-2014 |
Alan Viverette <alanv@google.com> |
Enable hardware rendering for system process
Also enables hardware rendering by default on windows created
without a parent activity (e.g. by services).
BUG: 16240470
Change-Id: I906d48cb07af50fa02dae4f4ecdb5e65211fc6ef
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
| f47a594f5250b1914c36423ee6b371f0b8db09d0 |
|
01-Jul-2014 |
John Reck <jreck@google.com> |
Fix onTrimMemory for HardwareRenderer
Also fixes detachFunctor possibly drawing after return
Bug: 15189843
Bug: 15990672
Change-Id: I64c48cb674c461a8eeaba407b697e09f72c98ce3
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
| eb94fa7975b1e8742f3b00cec6bd4f9d6b329e3a |
|
04-Jun-2014 |
Dianne Hackborn <hackbod@google.com> |
Improvements to low power mode.
Add new public API for monitoring low power mode.
BatteryService now puts device in to low power mode when
battery level is low.
Window manager now watches low power mode to turn off
animations.
Modifying the animator scale now gets propagated to all
processes.
Change-Id: I8fa566994764ddd4e1977631e28381ab9409f8ee
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
| fe5e7b7346a54537b980796ceeca66bfdbd05561 |
|
24-May-2014 |
John Reck <jreck@google.com> |
Enable debug stuffs
Bug: 14596762
* dumpsys gfxinfo implemented
* profile GPU visual_bars implemented
Change-Id: Icb948a9d5af5989b5615504d0d76ade64b93ef5b
/frameworks/base/core/java/android/view/WindowManagerGlobal.java
|
| 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
|