| 446079600ece83b22cb91865bcbeb694292b0108 |
|
16-Mar-2017 |
Andrii Kulian <akulian@google.com> |
Separate global and override config sent to client
There is some flakiness in View#onConfigurationChanged callback -
if ViewRootImpl receives config update earlier than ActivityThread,
it may not detect the configuration change and skip inner updates.
Also now ViewRootImpl assumes that it receives the global config as
a param, but instead it gets merged config from WM. This means that
ViewRootImpl#sConfigCallbacks was sending incorrect values to the
recipients.
This CL switches to sending global and override configuration to the
client separately. Also in case if there is a corresponding activity,
it first updates it and waits for update callback to ViewRootImpl.
This way global config and override config for activity will always
be set first and resources will be updated before inner state of
ViewRootImpl is updated.
Bug: 35870157
Bug: 34164473
Test: android.server.cts.ActivityManagerDisplayTests
Test: testOnMovedToDisplayCallback
Change-Id: Ic9e7541cf25ecfac6ec90e48f7efb0ece91f657e
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindow.java
|
| b047b8bd7e363081e91ba6cbc8d09cd355624584 |
|
09-Feb-2017 |
Andrii Kulian <akulian@google.com> |
Report move to display for activities that handle config changes
When activity that is moved between displays handles all configuration
changes, it won't be restarted. This CL adds a callback to the client
to notify it about display change. Usually it will be followed by
onConfigurationChanged, except when configuration didn't actually change.
When activity is recreated, it won't receive onMovedToDisplay.
Bug: 34862802
Test: android.server.cts.ActivityManagerDisplayTests
Test: #testOnMovedToDisplayCallback
Change-Id: I9a9501cab788623ada15a31efb53e4b2378639fe
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindow.java
|
| 3787de16d24001eeb452e1c711d4290a396e67c9 |
|
21-Dec-2016 |
Vladislav Kaznacheev <kaznacheev@google.com> |
Implement pointer capture API
When in pointer capture mode, mouse pointer disappears and
further mouse events are dispatched to the focused view
in the window which has requested capture.
The captured events have the source SOURCE_MOUSE_RELATIVE
belonging to SOURCE_CLASS_TRACKBALL. They are
dispatched through dispatchCapturedPointerEvent /
onCapturedPointerEvent. There is also a new listener.
Pointer capture mode may only be granted to a currently
focused window, and will be canceled upon a window focus change.
Test: cts-tradefed ... --test android.view.cts.PointerCaptureTest
Bug: 30897034
Change-Id: I6e5934aa415ac2b6dda1cee173d0f23e5021af84
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindow.java
|
| fcd7e80b21cc9db6be00e37371401ea1d0938796 |
|
10-Mar-2016 |
Clara Bayarri <clarabayarri@google.com> |
Keyboard Shortcuts: plumb deviceId through
Bug: 27673736
Change-Id: Ie72807aa8c2bfd142b081a6a915e101c16d31473
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindow.java
|
| c87e2b46fb949f1ba5d72b842bad443b36fd9abc |
|
24-Feb-2016 |
Jorim Jaggi <jjaggi@google.com> |
Fix build
Change-Id: Id21200a8239908c18379d67639c090ccfd3772f2
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindow.java
|
| a4a58efe8203d63a9a6bf78b0fa9f2992b25871b |
|
27-Jan-2016 |
Jorim Jaggi <jjaggi@google.com> |
Fix app staying in drag resizing when undocking
When dismissing the docked stack, the fullscreen stack stayed in drag
resize mode because it got a relayout, but because the bounds didn't
change (it switches to the fullscreen layout a bit earlier) it never
called WM.relayoutWindow, so it stayed in drag resize mode indefinitely.
To fix this, introduce forceRelayout in Window.resized(), which makes
sure the client always calls relayoutWindow. Set this to true whenever
drag resizing is changing.
For some very weird reason this also broke that home button was not
responding anymore.
Bug: 26806532
Change-Id: I4b39c1c419a166aa7093c31226f2a4915f642328
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindow.java
|
| 2260a618424b1cbdb1a051e613bd9e24a25d8436 |
|
26-Jan-2016 |
Ian Pedowitz <ijpedowitz@google.com> |
Fix build and reorder methods to match ec6a447c86b03f5896fdb717de530c8abf8887f9
Change-Id: I39ee2864eda489bf0e485ea96d30e56b29500865
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindow.java
|
| 0a66b6bc9226c170f1a522f81aca04cf03fd41a2 |
|
26-Jan-2016 |
Filip Gruszczynski <gruszczy@google.com> |
Fix build.
Change-Id: I68d6fade1b2a44a3542182914e0cd5853f4f0a81
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindow.java
|
| b2d135694f5a2979e7acef48255a6ea10f749dd2 |
|
14-Jan-2016 |
Wale Ogunwale <ogunwale@google.com> |
Fix build breakage.
Bug: 22405482
Change-Id: I8fc522885801e9735544ec3820c8fdd4a4368d71
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindow.java
|
| 1a2f3ab485f8f3abfdeb10cf9cbe640bdfc1233f |
|
06-Nov-2015 |
Jorim Jaggi <jjaggi@google.com> |
Fix build
Change-Id: Ie716bbec49920af459ceddf8e51387ccf5946a7f
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindow.java
|
| 9c450411058ab9af71932c756fb0f478b3988f1b |
|
01-Oct-2015 |
Chet Haase <chet@google.com> |
Enable activity rendering during window animations
A change was made back in ICS that prevents the view hierarchy from rendering
during window animations. Specifically, it allows the hierarchy to render once (to draw
the results of its first layout), but further drawing is suppressed at the
ViewRoot/performTraversals level until the window animation is complete.
This change was introduced to avoid jank problems that were resulting from
thrashing the GPU by issuing drawing commands from multiple processes simultaneously,
and limited the number of rendering processes to mainly the system server (and
possibly the System UI), which allowed window animations to be much smoother.
This fix contributed to another source of jank, however, in which applications
which attempt to animate when they first appear will not render any frames of
animations until the window animation is done, resulting is a snapping to the resulting
state once the window animations are complete.
Meanwhile, hardware has gotten faster and GPUs have gotten better, and it is time to
revisit this logic. This change disables the earlier fix and allows view hierarchies
to draw normally, regardless of whether window animations are taking place.
Issue #22232939 Remove flag that prevents drawing during window animations
Change-Id: I4c960180771ff09a7088abd77b437586e835a991
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindow.java
|
| 2217f61e51ba4b19c56b19297c1e9cf74d7d860f |
|
26-May-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Revert "Revert "resolved conflicts for merge of 47249f2a to mnc-dev""
This includes the fix for the broken dialog windows. The outsets will
only be calculated and applied if the window is full screen, since
they don't make much sense otherwise.
This reverts commit 4bb6b751fbbb218e8a298db4aa008472a0aa8d31.
Change-Id: I977a85a78c990c1840784dc0be0dddd5a6d84e6b
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindow.java
|
| 4bb6b751fbbb218e8a298db4aa008472a0aa8d31 |
|
23-May-2015 |
Dianne Hackborn <hackbod@google.com> |
Revert "resolved conflicts for merge of 47249f2a to mnc-dev"
This reverts commit c7becb7ee78881646251ff4846e63eb6b96bf7ec, reversing
changes made to 8562b08f04c1309cf40db1e749d612b6824f1d12.
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindow.java
|
| c7becb7ee78881646251ff4846e63eb6b96bf7ec |
|
21-May-2015 |
Filip Gruszczynski <gruszczy@google.com> |
resolved conflicts for merge of 47249f2a to mnc-dev
This is a merge of chin support.
Change-Id: I436b751b3c4aaa6b46cfcdb475e02eedfa5a5635
|
| 3e11bf33a6094da92d97702213aa12c67b21c4d1 |
|
20-Apr-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Support for devices with a chin.
Information about the chin is now part of the config.xml instead of the
theme. It is retrieved by WindowManagerService and passed to the clients
as insets. Clients can adjust their behavior in a way that makes it
invisible to the user, that part of the surface doesn't actually exist.
Bug: 19908853
Change-Id: Iedf57bf3c848201b854f91ffeb3b59187d375c1f
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindow.java
|
| 2bf49b1a9f4898a3bb353a9b902b8e6c1642037a |
|
14-May-2015 |
Jorim Jaggi <jjaggi@google.com> |
Fix build
Change-Id: Ia9277c6c983758d301c89312e39b59a2db0b29c4
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindow.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/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindow.java
|
| 9c79504225f60c72c947220b6aca928f11279e1c |
|
29-Oct-2014 |
Craig Mautner <cmautner@google.com> |
Add enter-animation-done callback for system windows
Existing hidden methods allow activities to be notified when their
windows have completed animating in. This change adds that capability
to system windows using a ViewTreeObserver callback since system
windows lack an activity token.
The first subsystem to use this is the UserSwitchingDialog which was
previously using a 250 msec timeout to dismiss the dialog. That
deadline was often missed leaving the user with no dialog on the
screen during the transition.
Fixes bug 16661752.
Change-Id: I70789e0d9c07112f275e76fb82850926305f290d
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindow.java
|
| 9657804afb9eb628fa5485750c43e78458b2d002 |
|
02-Jul-2014 |
Adrian Roos <roosa@google.com> |
Fix layoutlib breakage due to I681b711f6f40a94c25b7acd3a44eb3539486afab
Change-Id: I141f49718c4d538875a68c00101c098fdd7e967b
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindow.java
|
| a5c8d586f6ceff252336f72c6e15efbf4785e794 |
|
12-Apr-2014 |
Jeff Brown <jeffbrown@google.com> |
Fix build break due to layout lib.
Change-Id: I87b40125adad0a799214f6ebf0dc04ec7903efbf
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindow.java
|
| c4aad01cbbb69c916ef323693e1fd0560b0eccba |
|
23-Feb-2013 |
Dianne Hackborn <hackbod@google.com> |
Formalize overscan metrics.
The window manager now maintains and reports a new formal
"overscan insets" for each window, much like the existing
content and visible insets. This is used to correctly
position the various UI elements in the various combination
of layout options. In particular, this allows us to have
an activity that is using fitSystemWindows to have the content
of its UI extend out to the visible content part of the screen
while still positioning its fixed UI elements inside the
standard content rect (and the entire window extending all
the way into the overscan area to fill the screen as desired).
Okay, maybe that is not written so clearly. Well, it made
my head hurt too, so suffer!
The key thing is that windows now need to know about three
rectangles: the overall rectangle of the window, the rectangle
inside of the overscan area, and the rectangle inside of the
content area. The FLAG_LAYOUT_IN_OVERSCAN option controls
whether the second rectangle is pushed out to fill the entire
overscan area.
Also did some improvements to debug dumping in the window
manager.
Change-Id: Ib2368c4aff5709d00662c799507c37b6826929fd
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindow.java
|
| 758143ecfedbe08cc6c4fed0ad8ad7a854194ca4 |
|
07-Aug-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Window position not reported if the window is not moved.
1.If a window is shown but never moved the window window
is never notified for its current location. Therefore,
accessibility nodes do not contain correct bounds in
screen coordinates.
bug:6926295
Change-Id: I7df18b095d33ecafffced75aba9e4f4693b0c393
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindow.java
|
| 105b78bb310a75dc44e0baa49fe7d20341cc0f15 |
|
11-Jul-2012 |
Craig Mautner <cmautner@google.com> |
Add missing interface method.
Fix broken build.
Change-Id: I6644df218e11a35330a985bdcb9ace33723330f5
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindow.java
|
| 85afd1b6f871d471fdff1980134676a5f1690525 |
|
13-May-2012 |
Dianne Hackborn <hackbod@google.com> |
Implement new window cropping.
The window manager now performs the crop internally, evaluating
it every animation from, to be able to update it along with
the surface position.
Change-Id: I960a2161b9defb6fba4840fa35aee4e411c39b32
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindow.java
|
| 5c58de3a523a384c47b0b1e0f5dd9728a74cd9f7 |
|
29-Apr-2012 |
Dianne Hackborn <hackbod@google.com> |
Add system insets to windows.
This will be used to determine which parts of a window a completely
hidden by system UI elements (status bar, nav bar, system bar) so
that they can be clipped out from rendering.
Change-Id: I2c6c6ac67dbdfeed82d2c089ef806fb483165bd9
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindow.java
|
| 12d3a94397c33fdb773a1eaaaa13cab80bf0c571 |
|
27-Apr-2012 |
Dianne Hackborn <hackbod@google.com> |
When a window is first shown only draw once while animating.
On some hardware allocating a new graphics buffer is quite
expensive, which blocks updates to the UI. This can cause
glitches when performing window animations.
To reduce these glitches, the view hierarchy will now only
allow itself to be drawn once if its window is being shown
while the window manager is animating, not resuming draws
until it is told that the animation is done.
Change-Id: Ie15192f6fddbd0931b022a72c76ddd55ca266d84
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindow.java
|
| bb9908b828a8cfd5965553be66faa6af89973697 |
|
08-Mar-2012 |
Romain Guy <romainguy@google.com> |
Dispatch screen state change events to Views
Bug #6120957
Using this new callback, views can interrupt and resume their
animations or other periodic tasks based on the current state
of the display.
Change-Id: I398f4abd421e9c5f207107bf1009a7b92cf45daa
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindow.java
|
| e0cf12fc4d5c9de464f899522a9e2ca77dbb865a |
|
08-Mar-2012 |
Romain Guy <romainguy@google.com> |
Fix the build
Change-Id: Ia86ba9b1c432ab3f8107557e95b12c9eedc4d9f7
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindow.java
|
| 46d43ccfd8cef75b4315828073c094cf1efb05ff |
|
03-Feb-2012 |
Xavier Ducrohet <xav@android.com> |
Make Layoutlib compile on Java 6.
Change-Id: Ic8f0e321c6c218de83664fc01f253a07fa80852c
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindow.java
|
| 9a230e01a1237749a8a19a5de8d46531b0c8ca6a |
|
06-Oct-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #5371530: SYSTEMUI_FLAG_HIDE_NAVIGATION reasserts itself immediately
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
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindow.java
|
| 7f9f99ea11051614a7727dfb9f9578b518e76e3c |
|
11-Aug-2011 |
Xavier Ducrohet <xav@android.com> |
Make some methods/fields package private so that layoutlib can access them.
Change-Id: I4aeadfbaf8a4f6a459fa19937c21ac23d9e5fb64
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindow.java
|
| 664644d9e012aa2a28ac96f305b1ce6499ec8806 |
|
24-Jan-2011 |
Joe Onorato <joeo@google.com> |
visibility ("lights out") API.
1. Views may setSystemUiVisibility() to recommend that
the system chrome (status bar or other UI) show or hide
itself. (This functionality was previously available only
via the FLAG_FULLSCREEN window flag for some SystemUI
implementations.)
2. Views may register a OnSystemUiVisibilityChangedListener
on a view, and find out when the system UI actually
appears or disappears, allowing apps to coordinate the
appearance of their own UI if desired.
Bug: 3241144
Change-Id: Ia1758d94099182d49a1e3688ea2738ae4995b829
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindow.java
|
| 071dee288ca726c7c15754c2559403b9cbf950bd |
|
11-Nov-2010 |
Xavier Ducrohet <xav@android.com> |
Misc fix in layoutlib bridge + View.isIneditMode as delegate.
Change-Id: Ideab29167e933203da99d4270cebcb777726201f
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindow.java
|
| c2e9651bf386a1f7bf7fc706cf5424950570470c |
|
10-Nov-2010 |
Xavier Ducrohet <xav@android.com> |
Layoutlib: New bridge implementation using the new API 5.
Since the new API prepare for stateful layoutlib, major
reorganization of the code.
New "android" sub-package for all extended android classes.
Also moved BridgeInflater in here so that all extended classes
are in this package. Only delegates and classes replacing
renamed classes are in their original android.* packages.
Also created full file for the empty implementations of
IWindow and IWindowSession.
New "impl" for the dirty work implementation.
Main package contains the basic implementation of the API.
Most of the code that was in Bridge is now in .impl.LayoutSceneImpl,
with the main init/inflate/render code split into the contrustrutor,
inflate() and render().
Change-Id: Ie15b15e5a1b2388cd6ef82e518345b1fc02ec981
/frameworks/base/tools/layoutlib/bridge/src/com/android/layoutlib/bridge/android/BridgeWindow.java
|