| 32f37ab0237df02dc1cb3b342860699587800db7 |
|
15-Jun-2017 |
Robert Carr <racarr@google.com> |
ViewRootImpl: More null checks for performTraversals.
Let's first understand how mView could become null. Notice
at the beginning of performTraversals, there is a check that
mView != null, and so it is nulled while we are in the function.
mView is package private and there are only two places which assign
to it, ViewRootImpl#setView and ViewRootImpl#doDie. setView is guarded
by mView == null. But mView was not null (per the check at the beginning
of performTraversals) and so mView is being nulled by doDie().
doDie() only has 3 callpoints:
1. ViewRootImpl#die(). Here though, calling it is guarded by
!mIsInTraversal. !mIsInTraversal is unconditionally set at the
beginning of performTraversals, and so this isn't our caller.
2. ViewRootHandler, handling MSG_DIE. This runs on the same thread
as performTraversal, and so it can't be our nuller.
3. WindowManagerGlobal#addView. This must be our nuller.
We see WindowManagerGlobal#addView will call doDie in the case that
we attempt to add a view which we had previously set to be removed
but deferred removal of. Now we can construct a reasonable sequence
for getting here:
1. requestLayout(). Perform traversals ends up on handler.
2. removeView(). MSG_DIE ends up on handler, View ends up in mDyingViews
3. performTraversals is executed by the handler
4. From a callback initiated by performTraversals (e.g. measure)
the client calls WindowManagerGlobal#addView on the view which
was just removed.
5. We are still in performTraversals so MSG_DIE hasn't been processed
yet. This means that WindowManagerGlobal will perform the doDie
immediately nulling mView.
6. We return to performTraversals and crash.
We can see shortly after the offending call to doDie, a new ViewRoot will be
constructed and so whatever traversal we are doing on the old one doesn't
seem particularly important. It doesn't seem that we can do any better
than letting it fall through without crashing.
Bug: 38421184
Test: go/wm-smoke. Feed to the monkeys.
Change-Id: I55f310a3533175c9df4a82878be5a60fd01b80c1
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 46b01655b3448706797dfadc3d9a7c6495bb6e5c |
|
08-Jun-2017 |
Bryce Lee <brycelee@google.com> |
Revert "Coordinate configuration changes and window frame size."
This reverts commit afb45bba8379df530182dae882ec70329423dcfe.
Bug: 32839232
Fixes: 62424393
Change-Id: Ifaa0176e18100ec85b8c81268a26fb16ffe9b5f3
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| afb45bba8379df530182dae882ec70329423dcfe |
|
27-Apr-2017 |
Bryce Lee <brycelee@google.com> |
Coordinate configuration changes and window frame size.
Previously, it was possible for the view hierarchy to be measured,
laid out, and drawn around a window frame size that did not match
the current configuration. This stems from new configurations not
always propagating back from WindowSession#relayout, which is
called from ViewRootImpl.
This changelist makes WindowManagerService#relayoutWindow always
return the latest configuration. It also adds rotation to the
configuration.
Fixes: 32839232
Test: go/wm-smoke
Test: Open Camera while rotating phone to landscape. Added
temporary logs to detect inconsistencies between measurements
and reported rotation on draw.
Change-Id: I39daca338b4f87eff1a509eb99493f01e710ced1
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 3e04f091365294a7eea927d6b1c138f126f77c5d |
|
03-Jun-2017 |
John Reck <jreck@google.com> |
Workaround glitches from SOFT_INPUT_ADJUST_PAN
Change-Id: I1ee0c7d434eb03667bd5e838ea891db73651a994
Fixes: 62073166
Test: Repro app in bug
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 49cd9f882c3853a615c517b00311a9512d68edf9 |
|
26-May-2017 |
Robert Carr <racarr@google.com> |
ViewRootImpl: More careful draw accounting.
The strategy of beginning the count at 1 isn't enough
and we need to explicitly debt each request to report
draw. Imagine the case where a ViewRootImpl reports draw
multiple times, while we are waiting for a SurfaceView draw
completion callback. Without the explicit draw debt, the ViewRoot
would be counted as drawing for the SurfaceView and we could
notify the WM too early.
Test: Open Chrome a few hundred times. go/wm-smoke.
Bug: 38324871
Change-Id: I5762a98d1cc808125033ba3d1db8a3ea39a9e071
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 4bc839e2670d326d42400b51cbc0652361cc7072 |
|
17-May-2017 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "ViewRootImpl: Guard against null in performMeasure" into oc-dev
|
| 001e55a17a8ff58ae80409369601ba860f8e8832 |
|
16-May-2017 |
Robert Carr <racarr@google.com> |
ViewRootImpl: Guard against null in performMeasure
In particular we are seeing this in the call sites from performTraversals
in monkey crashes. I don't have exact repro but it seems like a feasible
state to get in to...for example...WindowManagerGlobal#addView can trigger
removal of a dying view immediately without respect for the mIsInTraversal
flag when it calls doDie(). This means we can dispatch detached from window
setting mView == null while performing a traversal. There's some question
about why this doDie is even required but...seems a little nerve wrecking
to change at the moment and it seems best to just guard against null for now.
Test: Monkeys will test.
Bug: 37343098
Change-Id: I94f2569c1ef70819c083f2b2b34b59622e6c6260
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| f5b6818009a70d77a272ca9b7b2aa167507dfd07 |
|
16-May-2017 |
Rob Carr <racarr@google.com> |
Merge "Preserve non-floating state when entering pinned stack." into oc-dev
|
| 63e4503991b52862efb17d42950d986dca90976b |
|
11-May-2017 |
Phil Weaver <pweaver@google.com> |
Add null check to a11y call.
No good will come from posting that a null View has
changed. Adding a null check so the failure will happen
when the bad call is made, rather than later when we
try to act on it in a handler.
Bug: 38122973
Test: Ran accessibility unit and cts tests.
Change-Id: I1e9aaf2a18180fcdfd0fbc0e5b716eb96446af33
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 18f622f08ce84bfb1a6cf19bca33d3ef0ad4aca9 |
|
08-May-2017 |
Robert Carr <racarr@google.com> |
Preserve non-floating state when entering pinned stack.
When transitioning between the fullscreen and pinned states
we often have a situation where we go from having a navigation and
status bar in the window to not. We'd like to use the source bounds
animation to crop these out rather than a sudden jump or scaling
but in order to do so we need to ensure they last until the end
of the animation. We track this state, and return the appropriate
value from isFloating. Furthermore, we add support to the bounds
animation to use the content frame as a source bounds when there
is no source bounds present, this means that we can crop out the
navigation and status bar so they will be invisible by the end of
the animation.
Bug: 37531386
Test: Manual
Change-Id: I72c549e3a3318534428d17b68ebee5832c32e6d7
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 26d709fdfa473f1722b1ee08562262cb4cfeaaac |
|
21-Apr-2017 |
Phil Weaver <pweaver@google.com> |
Allow a11y listeners to specify handlers
This follows recommended practice for listeners, and also
allows ViewRootImpl to register for callbacks on its own
handler, which can prevent crashes in apps that have
different threads managing the UI at different times (for
example the system process).
Bug: 37542371
Test: Adding CTS tests for new APIs. A11y CTS still passes.
Change-Id: I65db025275e153c20b20567346246d5bc13bf418
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| f4c31bf67b60e24dfd56249bbcfdc640f2d842ce |
|
19-Apr-2017 |
Evan Rosky <erosky@google.com> |
Merge "Handle edge-case where no focusables exist" into oc-dev
|
| 5b860719a30862a457f8c8aa9222272a3b43a433 |
|
18-Apr-2017 |
Evan Rosky <erosky@google.com> |
Handle edge-case where no focusables exist
cluster navigation was previously crashing if there was
nothing focusable..
Bug: 37438383
Test: Added CTS: ContentPaneFocusTest#testNoFocusablesInContent
Ran against support-v7-demos Toolbar demos to verify
crash didn't occur
Change-Id: Ia1382cec138a948d080aeded4d38735983df2152
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 8802eac3d8831e7af867f19d0bb1df3daa603140 |
|
17-Apr-2017 |
Winson Chung <winsonc@google.com> |
Account for content insets in source rect hint for transition into PiP
- As a part of transitioning into PiP, we remove the content insets, and
as a result, we also need to adjust the source hint rect for the change
in insets as well.
Bug: 37418994
Test: Enter PiP from YT, ensure no jump at the end
Change-Id: I74219b05c91d3c8b8466dd8fff4d6dd692f08725
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 414ebc6ac8dcc972cc97f637e21ac09e59bef112 |
|
12-Apr-2017 |
Robert Carr <racarr@google.com> |
ViewRoot: More surgically fix child-life time.
A more targeted version of "ViewRootImpl: Fix child lifetime".
In this version we avoid hijacking the window visibility callback
and introduce a new path.
Our contract has been that at any time after returning from
onStop, the WindowManager may destroy the clients Surface. We
see in setWindowStopped, we set the stopped state on the hardware
renderer in order to prevent further use of the Surface. However
there is nothing synchronously dispatching this change to child views
and so SurfaceView is not necessarily informed to release it's Surface
in time. Typically SurfaceView will be informed through the
onWindowVisibilityChanged callback. The signal producing this
is emitted from SystemServer prior to onStop but has to pass
through the clients handler thread. It seems this has always been
broken, and we have always had intermittent reports of EGL_BAD_ALLOC
scenarios. I speculate that elevation of WindowManager scheduling during
app close scenarios is perhaps making this more severe, as it seems to
ensure the WindowManger will win the race to destroy the Surface before
the client handler thread process onWindowVisibilityChanged (unless
the FIFO timeout is surpassed).
Test: Put Chrome in PiP. Turn screen off. No Crash!
Bug: 36561071
Change-Id: I9233ba8151c7f577b1d1044afc0c2ac3a65be4b4
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 16e5089eb5b58fb065ec05ee8a6afe229f48bf50 |
|
11-Apr-2017 |
Bryce Lee <brycelee@google.com> |
Revert "ViewRootImpl: Fix child lifetime."
This reverts commit ba29dbc3b38d9efb743d6fa7f9f8c4bb75c38b28.
The original commit causes apps such as phone and clock to not wake the
device.
Fixes: 37197491
Change-Id: I1b45cafbcbf12991d8e1e716e4d1751cd077c556
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| ba29dbc3b38d9efb743d6fa7f9f8c4bb75c38b28 |
|
07-Apr-2017 |
Robert Carr <racarr@google.com> |
ViewRootImpl: Fix child lifetime.
As far as I can tell this has always been broken. We've always had
intermittent reports of buffer-queue-abandoned as well (a recent bug
came with some reports from N). During onStop SurfaceView relies on
onWindowVisibilityChanged, to trigger a visibility change. At this
point SurfaceView will emit the SurfaceDestroyed callback in order to
stop the client from further use of the Surface. The contract we've
been using with ViewRootImpl is at any point following
Activity.performStop returning the WindowManager was free to destroy
the Surfaces. This is why in setWindowsStopped we destroy the hardware
resources for the ViewRoot. However we aren't dispatching anything to
the SurfaceView. The WindowManager will send an app visibility
notification, but that would go through the handler. This means by the
time we return from Stop, there is no guarantee that the
onWindowVisibilityChanged callbacks have been invoked at all. It
seemed most sensible to dispatch the visibility callbacks directly. We
also ensure that getHostVisibility will return false after this point,
so that performTraversals will not reverse our visibility request if
it occurs again prior to the window visibility notification from the
WindowManager. We also guard against emitting a second window
visibility changed callback in the traversals. I don't know at this
point what value the window visibility notification provides but I
don't feel excited about removing it in this CL at this point in
the development cycle.
Test: Put Chrome in PiP. Turn screen off. No Crash!
Bug: 36561071
Change-Id: Id1673561b2299d477b2761b3ac6afa14eabbf7fb
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| baa9a3f4b9d7390ef8ad41cb4ae7f97b09b0caf3 |
|
04-Apr-2017 |
Evan Rosky <erosky@google.com> |
Merge "More finishing-up of cluster implementation" into oc-dev
|
| cdc8ada9c91ff593ed480a48ae8cd6a1c529924a |
|
30-Mar-2017 |
Wale Ogunwale <ogunwale@google.com> |
Fix issue with not forwarding config. changes on the window size
Coding error inroduced in ag/1965162 where we were no longer setting
the config. if the dispatchResized() call originated from a different
process.
Fixes: 36544847
Test: Change languages and confirm that the status bar changed to the
new language.
Change-Id: I91d73c9f506f28cf1ba13a55f86f87a1aff80e0b
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 01f46a29cee4f77a4f349879a7a01cc704cf3ba9 |
|
17-Mar-2017 |
Evan Rosky <erosky@google.com> |
Expose initial focus feature flag for testing
Bug: 34520588
Test: View_FocusHandlingTest
Change-Id: I7a20a6e9c57fc61bd2562307f4e7f8dee1979a40
(cherry picked from commit 9a0ea38671f1721b940e0a1ba94226d1ebae397d)
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| bd10c52f5efc73f7ffdd611beb14cdd7ce785016 |
|
28-Mar-2017 |
Evan Rosky <erosky@google.com> |
More finishing-up of cluster implementation
Implemented the nextClusterForward attribute (didn't do anything
before).
Fleshed out javadoc links.
Clusters now share sorting with normal focus.
Added sound on cluster navigation.
Bug: 34362469
Bug: 34363357
Bug: 34362653
Bug: 34361907
Bug: 34363159
Test: Added CTS to verify clusters behave the same as normal focus
wrt user-specified ordering. Tested manually that cluster-
nav generates sound.
Change-Id: I810acc058d9c1fad4a085d9b7f267e9ec14b33e7
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 76d779374a92f502579e72f822cf815e54be33ea |
|
29-Mar-2017 |
Rob Carr <racarr@google.com> |
Merge "SurfaceView: Make surfaceRedrawNeededAsync work with WM bypass." into oc-dev
|
| 8508bb2f10f8da49fff402d04ee81b2fba15ad19 |
|
28-Mar-2017 |
Robert Carr <racarr@google.com> |
SurfaceView: Make surfaceRedrawNeededAsync work with WM bypass.
Prior to SurfaceView bypassing the WM, the WM would see that
the app had multiple windows and wait for them all
to finish drawing before beginning any animation, or similar operations.
Now that SurfaceView is invisible to the WM we have to replicate this
two-way latching in ViewRootImpl.
Bug: 36492285
Test: Launch Chrome over and over.
Change-Id: Ie72c2d394f1bb0eb8551e6f63bb1c19a5df43afd
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| e5c58eefb1c28d56e6b4768cf624af137a867d21 |
|
28-Mar-2017 |
Andrii Kulian <akulian@google.com> |
Add Configuration param to onMovedToDisplay
To be consistent with other multi-window callbacks adding
Configuration param to the onMovedToDisplay, so that app
developer can handle configuration change at the same time
when it receives a notification about move.
Bug: 36649499
Test: android.server.ActivityManagerDisplayTests
Test: #testOnMovedToDisplayCallback
Change-Id: I80c765473bfc09ea1fb7aa4e2e77baf3b21606b8
(cherry picked from commit 2c32a11a71e2a1602b188b710b1916d919d99edb)
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 42b0676d616e306c6c5f6325b27b401fc7e32c8c |
|
17-Mar-2017 |
Alan Viverette <alanv@google.com> |
Merge "Revert "Changing initial and default focus behavior""
|
| cfd6c85d4203ca2530ddff048654b365b346eefd |
|
17-Mar-2017 |
Evan Rosky <erosky@google.com> |
Revert "Changing initial and default focus behavior"
This is a soft revert.
This reverts commit 37df2dbab124452e04bf14784df9ab5c2f64e434
Change-Id: I7ac08c0ef514f7ce7a0b750e501a5333f4ffb6d2
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 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/core/java/android/view/ViewRootImpl.java
|
| 42794029ce95b44abd04c8b73353cedfd6d7b531 |
|
15-Mar-2017 |
Evan Rosky <erosky@google.com> |
Merge "Changing initial and default focus behavior"
|
| f00cd14f17c0acd6bffe78947d32ea0a2900d139 |
|
03-Mar-2017 |
Phil Weaver <pweaver@google.com> |
Basic accessibility support for picture-in-picture
Exposing actions from the PIP InputConsumer to accessibility,
stripping all actions from a covered PIP app, and adding the
InputConsumer's actions on the PIP app's root view.
We were also using an "undefined" accessibility ID to mean
three different things: a root view, a host view of a virtual
view hierarchy, and a truly undefined view. I've introduced
new values for cases where the id could be defined.
Also gathering all window IDs into one place to reduce the
chance of collisions.
Bug: 34773134
Test: In progress. Current cts passes.
Change-Id: I97269741a292cf406272bf02359c76c396f84640
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| d5c7dd6da810a6b89151b337bea79fd817e6b72a |
|
08-Mar-2017 |
Robert Carr <racarr@google.com> |
Modify SurfaceView to use SurfaceFlinger child surfaces.
Here we have SurfaceView bypass the WindowManager and speak
directly to SurfaceFlinger using child surfaces. We also
implement some logic in the WM to handle child surfaces
in various Surface replacement scenarios.
For those following along in the revert Saga, this
also includes the follow up CLs to the original CL.
- Surface inset calculation
- Animation fixes.
The error causing the revert was an incorrect JNI signature
around deferTransactionUntilSurface. I've noted it inline.
Bug: 28858420
Bug: 31518219
Bug: 34888808
Bug: 35588318
Bug: 35396882
Test: Existing tests still pass (except for the ones that don't and will be deleted).
Change-Id: Ie56b6f7ab16f32d7fc459b8eba26594337ad55de
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 5aec7b90310ba05f9816fd89030ba41ce48c568e |
|
08-Mar-2017 |
Wonsik Kim <wonsik@google.com> |
Revert "Modify SurfaceView to use SurfaceFlinger child surfaces."
This reverts commit cd4aeef88052571365d4e193a2c41e2e6d145491.
Bug: 36027342
Bug: 36015884
Change-Id: Ifd5b69caf64d65a8cd6570b7fe1fb6abe90e30b8
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| cd4aeef88052571365d4e193a2c41e2e6d145491 |
|
03-Mar-2017 |
Robert Carr <racarr@google.com> |
Modify SurfaceView to use SurfaceFlinger child surfaces.
Here we have SurfaceView bypass the WindowManager and speak
directly to SurfaceFlinger using child surfaces. We also
implement some logic in the WM to handle child surfaces
in various Surface replacement scenarios.
For those following along in the revert Saga, this
also includes the follow up CLs to the original CL.
- Surface inset calculation
- Animation fixes.
The error causing revert was a deferTransactionUntil(-1)...-1
cast to uint, defer transaction until MAX_UINT.
Bug: 28858420
Bug: 31518219
Bug: 34888808
Bug: 35588318
Bug: 35396882
Test: Existing tests still pass (except for the ones that don't and will be deleted).
Change-Id: Ib37236950a1dd3c4f9f4b58fd41ef9003c0557ef
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 3896db14751f16f4053e8fa4a82c3d6803054e5b |
|
03-Mar-2017 |
Jeff Tinker <jtinker@google.com> |
Revert "Modify SurfaceView to use SurfaceFlinger child surfaces."
This reverts commit 693f3432ae77d1fcfaaf9d168de861192aacb4c4.
P0: When playing encrypted content the Fugu displays a blank screen.
Test: with topic "surfaceview-without-wm" reverted, encrypted playback
works on ToT oc-release. See repro steps in 35917840#12.
bug:35917840
Change-Id: I37fa1e427daff3a1c18ed1c92d035421d891f67c
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 37df2dbab124452e04bf14784df9ab5c2f64e434 |
|
25-Jan-2017 |
Evan Rosky <erosky@google.com> |
Changing initial and default focus behavior
This changes initial focus behavior such that by default,
nothing is focused; and, if nothing is focused, the first focus
navigation will send focus to the default focus rather than
whatever happens to be in the upper-left. This also slightly
tweaks the behavior of the <requestFocus /> tag to make it
easier to use.
This addresses a common problem where developers create dummy
focusable views or make viewgroups focusable(InTouchmode) to
prevent other views from gaining focus on activity start.
In order to have something focused at activity start, developers
now must explicitly provide a <requestFocus /> tag. However,
this tag now requests "default" focus so that, when used in
tandem with the focusedByDefault attribute(s), it can be placed
at the root of the hierarchy to mimic the initial focus behavior
before this CL.
This will only take effect when targetApi >= 26.
Bug: 34520588
Bug: 33016720
Test: Added/Updated CTS tests. Also built some test-apps to verify.
Change-Id: I3e7fb7289f6dd53023ec24087f84c41526eaab2e
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 693f3432ae77d1fcfaaf9d168de861192aacb4c4 |
|
19-Dec-2016 |
Robert Carr <racarr@google.com> |
Modify SurfaceView to use SurfaceFlinger child surfaces.
Here we have SurfaceView bypass the WindowManager and speak
directly to SurfaceFlinger using child surfaces. We also
implement some logic in the WM to handle child surfaces
in various Surface replacement scenarios.
Bug: 28858420
Bug: 31518219
Bug: 34888808
Bug: 35588318
Bug: 35396882
Test: Existing tests still pass (except for the ones that don't and will be deleted).
Change-Id: Icb7259365b51ebe8c7f6c7cd4f9ba29f9fce08a4
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 956545b07ff921b281401049a971e19ad01a4cc9 |
|
27-Feb-2017 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Exit touch mode on mouse/stylus click"
|
| b2048d4247806dc0c12314e65e36561bd1bb47c4 |
|
24-Feb-2017 |
Evan Rosky <erosky@google.com> |
Merge "Add focusdirection annotations to cluster methods"
|
| 609bf65668181d93502a57575f6f20281f2494b8 |
|
10-Feb-2017 |
Bryce Lee <brycelee@google.com> |
Update DisplayAdjustments in Display from Resources.
Previously, a copy of DisplayAdjustments was provided during Display
construction. If the Display instance is held, the adjustments would
not update. However, the DisplayInfo would, leading to a mismatch.
This changelist adds a reference to the Resources, which can be
queried to provide the latest adjustments.
Fixes: 33430498
Test: manual from bug repro steps.
Test: make -j32 cts; cts-tradefed; run cts --module CtsAppTestCases --test android.app.cts.DisplayTest#testRotation
Change-Id: Ida2ed3990add885d06b011494af24b055343f3fa
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 5722331efeaa362e27585026e953c2fda677c516 |
|
08-Feb-2017 |
Evan Rosky <erosky@google.com> |
Add focusdirection annotations to cluster methods
Bug: 34361917
Test: Still compiles
Change-Id: I47b5e9472524708544d567444b3fbcc93bc45119
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 7614cdf9c39039e6aaf5a896006445046003215a |
|
21-Feb-2017 |
Vladislav Kaznacheev <kaznacheev@google.com> |
Exit touch mode on mouse/stylus click
Bug: 35625345
Test: android.cts.view.ViewTest#testTouchMode
Change-Id: Ib31425c3da2c42a4df91735be4057d2aa8db7480
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| df1742ed47da1e9b61afeae16fa448d5302a8aa0 |
|
20-Jan-2017 |
John Reck <jreck@google.com> |
Overhaul GraphicsStatsService
* LRU cache of recently-used is dead, replaced
disk storage
* ASHMEM size is read from native by the system service,
no longer requires keeping a sizeof() in sync with a
constant in Java
* Supports dumping in proto format by passing --proto
* Rotates logs on a daily basis
* Keeps a history of the most recent 3 days
Bug: 33705836
Test: Manual. Verified log rotating works by setting it up to
rotate every minute instead of day. Confirmed /data/system/graphicsstats
only has the most recent 3 entries after several minutes
Change-Id: Ib84bafb26c58701cc86f123236de4fff01aaa4aa
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 1228e2cb8350ba202836660927c194f39e074e6f |
|
17-Feb-2017 |
Evan Rosky <erosky@google.com> |
Merge "Fixed default-cluster and empty-cluster navigation behavior"
|
| 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/core/java/android/view/ViewRootImpl.java
|
| 3ac6463724734b983170328ea0e6cad40eb79502 |
|
14-Feb-2017 |
Evan Rosky <erosky@google.com> |
Fixed default-cluster and empty-cluster navigation behavior
Cluster navigation would get stuck if:
- there was an empty cluster (nothing to focus)
- there were views NOT in a cluster and the global
default-focused view was in a cluster.
This will skip over empty clusters during cluster navigation
and when the default "cluster" is active, it will try to
focus a non-clustered focusable instead of the global default
(and if there aren't any non-clustered focusables, it will
skip over the default "cluster" as it now does with actual
clusters.
Bug: 35273052
Bug: 34361282
Test: Added/Updated CTS tests and checked behavior in a test app.
Change-Id: I0b4d55707203f6a0453f25313f940927d59a9b31
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| a21f3e782a977c86d0a750b8cbc0a3ba49e8f569 |
|
13-Feb-2017 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Do not enter touch mode on non-touchscreen events"
|
| 75e5029e4659d4a286c89bc9bc1981cc196028e6 |
|
13-Feb-2017 |
Vladislav Kaznacheev <kaznacheev@google.com> |
Do not enter touch mode on non-touchscreen events
Currently ACTION_DOWN and ACTION_SCROLL cause
entering touch mode regardless of the event source.
This is especially awkward for mouse.
This should only happen when the event source is
SOURCE_TOUCHSCREEN.
Bug: 35314124
Test: android.cts.view.ViewTest#testTouchMode
Change-Id: I2205d4240be4afcbd9a3ac5558e701f7cac51926
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 22dac1c8df4ec212e8195a69d2de15d313d724fb |
|
13-Feb-2017 |
Yohei Yukawa <yukawa@google.com> |
Introduce @SoftInputModeFlags annotation
Doing this allows us to annotate integer values that should corresponds
to WindowManager.LayoutParams#softInputMode.
Test: There should be no behavior change. RetentionPolicy.SOURCE
annotation should change nothing in production code.
Test: checkbuild
Bug: 32784563
Bug: 35079353
Change-Id: I96300b090edce327d0515c740183abe91ded6bac
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 651ea36f5aaf5751b16bc98899c31fe2ef3cd5c3 |
|
09-Feb-2017 |
Peeyush Agarwal <apeeyush@google.com> |
Merge "Extend MenuItem to allow modifier keys for shortcut"
|
| f10db8e444b4ce70e2324429ad342c4e6f0674e0 |
|
08-Feb-2017 |
Evan Rosky <erosky@google.com> |
Merge "Separate cluster-focus and default-focus."
|
| e631e32a1a771a36267af3f8af8b64e9365bc19e |
|
19-Oct-2016 |
Peeyush Agarwal <apeeyush@google.com> |
Extend MenuItem to allow modifier keys for shortcut
Before this, CTRL was the default modifier for MenuItem shortcuts.
Now, It's possible to specify the modifier in XML or via MenuItem
methods.
The modifier list includes META, CTRL, ALT, SHIFT, SYM and FUNCTION.
WIP on support library implementation
Bug: 32165848
Test: Run the tests using following commands:
> cts-tradefed run cts-dev -m CtsViewTestCases -t
> android.view.cts.MenuTest#testPerformShortcut
> cts-tradefed run cts-dev -m CtsViewTestCases -t
> android.view.cts.MenuInflaterTest#testInflateShortcutModifiersFromXml
Change-Id: I7db4607d4657451934761914efe4c250de109653
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| c2e28932d22faece6e7179c78d4e7656dc63052c |
|
08-Dec-2016 |
Phil Weaver <pweaver@google.com> |
Provide text locations to accessibility services.
Bug: 30170631
Test: New CTS tests on linked CL.
Change-Id: I723e3777189c8df71c59dada00abdf339ebc983d
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 53fcf11cf5a308ef68fc852f971f12e3afcf04d9 |
|
26-Jan-2017 |
Evan Rosky <erosky@google.com> |
Separate cluster-focus and default-focus.
Now properly cleans-up cluster-focus and default-focus chains
on view-removal (was only cleaning 1 level previously).
Separated cluster-focus and default-focus concepts.
Made default-focus robust to changes in default-focusable
views (previously un-marking a default focus wouldn't reassign
default focus to still-existing default focusables).
Cluster-focus falls back on default-focus when no saved
cluster-focus exists.
Bug: 34394367
Test: Associated CTS tests.
Change-Id: I903c22ded5643d0d4ca3bc5427b38833742aa354
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| b27aba9a92a023386fb25a85a989f5a0f7a18aaa |
|
31-Jan-2017 |
Chris Craik <ccraik@google.com> |
Merge "Replace invalidateChild/invalidateChildInParent"
|
| 9de95db4f28f88c37b1443d20b308ce02407fd74 |
|
19-Jan-2017 |
Chris Craik <ccraik@google.com> |
Replace invalidateChild/invalidateChildInParent
Fixes: 34361503
Test: CTS: android.view.cts.ViewGroupTest
APCT: android.view.ViewInvalidateTest
Simplify and unify HW accelerated invalidate/damage codepaths, since
both simply walk up to ViewRootImpl and schedule a traversal.
Adds a new overridable method 'onDescendantInvalidated' for observing
subtree rendering updates.
Change-Id: I7ef1f914c3411317692451787b3810b23e019591
/frameworks/base/core/java/android/view/ViewRootImpl.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/core/java/android/view/ViewRootImpl.java
|
| 516f9e68f37fee8d87d02445e43637ed9874de6c |
|
24-Jan-2017 |
Evan Rosky <erosky@google.com> |
Changed cluster kb navigation shortcut to meta+[shift]+tab
Bug: 34509826
Test: Verified new shortcut worked in test app
Change-Id: I2e454a1291dbee9f6ca549d6ed2973248ff24d15
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| b5ced2200767280026ee57857edaebc02d081216 |
|
18-Jan-2017 |
Vadim Tryshev <vadimt@google.com> |
Eliminating sections.
Per new UX spec, sections are eliminated, and clusters change
their behavior. Full list of their properties:
* They serve as stops in cluster-navigation loop
* There exists a default cluster (which is the unmarked space)
* Default/stored focus is local to a cluster
* Initial focus search can enter a cluster
* Tab/arrow navigation is not affected by clusters
Bug: 32151632
Test: Manual and CTS tests.
Change-Id: Iacc4f37aec3dc61a6f6ce35681fa6b8fa974f0ed
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 6c7dcd8a46f1c43257512451a773ae53a3de4336 |
|
17-Jan-2017 |
Andrii Kulian <akulian@google.com> |
Merge "Relayout window when rotated landscape <-> seascape"
|
| b2e37802995e710c4a4d7b28e35c0b584ad2be7a |
|
11-Jan-2017 |
Andrii Kulian <akulian@google.com> |
Relayout window when rotated landscape <-> seascape
When 180 degree rotation happens there is no real configuration
change, so an application window could miss an update, which
caused visual artifacts.
In this CL layout is forced when rotation changes.
Test: Unit tests in ag/1778638.
Bug: 33607506
Change-Id: Ia1e3375212bade9061d6e1d9679604e67c50da20
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 393a954d5fe885bbe08e1816a50da41c4d9eed50 |
|
12-Jan-2017 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "API for setting default focus per cluster."
|
| 5ca739817dbd7d73f1d232597c0e2898cbee79c7 |
|
05-Jan-2017 |
Vadim Tryshev <vadimt@google.com> |
API for setting default focus per cluster.
UX spec requires us to allow apps to specify default focus per
cluster.
This change introduces a boolean attribute for Views to do so.
API is designed for cases when the view hierarchy is inflated,
manually constructed, as well as for hybrid scenarios.
The implementation piggybacks the recently introduced logic for
saving/restoring last focus in a cluster. To accommodate new needs,
the focus-saving were rename-generalized in this CL.
Bug: 32151632
Test: Manual checks; CTS are coming after feature freeze.
Change-Id: Ia92600c3a886db9a0d4df9dd9fd0e3479e68e7a4
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 5df7f1ab6183d5abe50b1bfe00cc86eec23f8cf0 |
|
10-Jan-2017 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Provide non-blocking SurfaceView draw notification path."
|
| 6f225cae06a49bf2c34716b3418d7b64d0feb232 |
|
10-Jan-2017 |
Chris Craik <ccraik@google.com> |
Merge "Revert "Revert "Fast-path for ViewGroup#invalidateChild, invalidate tests"""
|
| 25cfa134835e3791bdb6572f5e25cf4599015678 |
|
16-Nov-2016 |
Robert Carr <racarr@google.com> |
Provide non-blocking SurfaceView draw notification path.
SurfaceView needs to notify the window manager that
drawing has been completed, so that animations and such
can begin. Currently this is implemented through
having the SurfaceView user block in surfaceRedrawNeeded
(called from UI thread) until a frame has been completed.
This blocking can be unnecessary serialization during startup, and
also clumsy to implement for some users.
Test: GLSurfaceView and takeSurface API Demos, android.server.cts.SurfaceViewTests
Bug: 31850030
Change-Id: Idda02098a635f25cf392f2d59a3abbe54a1d64d4
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 3f06c6de08b9e0c7ab1fd1774783ca355e994f06 |
|
09-Jan-2017 |
Chris Craik <ccraik@google.com> |
Revert "Revert "Fast-path for ViewGroup#invalidateChild, invalidate tests""
Bug: 33797688
This reverts commit 1cb8b08ae459fddc860e5863b0ec30a70682654e.
Change-Id: I322b550d65d48be4a99faf1790d138d26a996d7e
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 311a5b54979afee7e07bf31600182584fde15b4f |
|
06-Jan-2017 |
Vadim Tryshev <vadimt@google.com> |
Using official names for clusters and sections.
Per the bug, “clusters” and “sections” are already the official names,
and for a general name for both, we use “keyboard navigation
groups”.
Bug: 33708251
Test: N/A.
Change-Id: Ieb1d2e8a1ad758f902b0a925fbe5d187e0f7ea06
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| c587433dd178b634f4f7a0453d192bb8b47b37da |
|
04-Jan-2017 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Introducing teleportation between sections."
|
| 8957f2ddda08e891475e64552ffa225ca2fccedb |
|
22-Dec-2016 |
Vadim Tryshev <vadimt@google.com> |
Introducing teleportation between sections.
The key combos differ from the ones in the spec because key combos
including Meta key don’t get delivered to apps. To fix this, I’ll
implement necessary plumbing after the feature freeze. Meanwhile,
temporary combos are used.
Given that the section and cluster teleportation have a lot in common,
I’m not introducing new methods, but adding a param to the cluster
teleportation ones. I should have also changed the names to something
like findNextKeyboardNavigationCluster => findNextFocusGroup, where
“FocusGroup” is a generalized name for clusters and sections.
However, that name depends on b/33708251, so I’m not doing it now. I
don’t rename existing identifiers, and using “focusGroup” for new
ones. Admittedly, this creates mess that will be resolved based on
the outcome of the mentioned bug.
Bug: 32151632
Test: Manual checks; CTS are coming after feature freeze
Change-Id: I01b5d6e5a9689b8f643fa4af695d2ce61265f374
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| e40fb27f32bc3717c006267f48231c4e62d7bb07 |
|
04-Jan-2017 |
Vladislav Kaznacheev <kaznacheev@google.com> |
Fix custom pointer icon caching in ViewRootImpl
Currently if the pointer leaves a window which has
a custom pointer icon, the pointer icon is not updated
upon re-entry.
Bug: 33824962
Test: manual
Change-Id: I3e40413117b8aa2a1bde47394ef9318a03a7e135
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 01d8c49e040b223d2c4961eb65b5e00f1a967ecf |
|
15-Dec-2016 |
Vadim Tryshev <vadimt@google.com> |
Restoring last focused view when teleporting to a cluster.
The UX spec requires each cluster to remember which view was last
focused in it, and focus on it upon the teleportation to this
cluster.
This CL implements saving and restoring the focus.
It also introduces a public API so that an app could switch to a
cluster as if it was teleported to.
Bug: 32151632
Test: Manual checks; CTS are coming after feature freeze.
Change-Id: I0dc816776386015a7f1235f93e3dd9c03dfffcd6
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 01b0c9ed4e173f0c140a6575049e2964ae1a919f |
|
22-Nov-2016 |
Vadim Tryshev <vadimt@google.com> |
Teleportation between clusters.
Per the UX spec, key combos for quickly jumping between clusters are
Meta+Right and Meta+Left. However, these events don’t get delivered
to the app, and I’ll have to implement this plumbing after the
feature freeze. For now, the temporary combos are Ctrl-Shift-”-”
and Ctrl-Shift-”+”.
In addition to the key combo processing, the CL adds public APIs for
teleportation; they are similar to the API for moving the focus.
Bug: 32151632
Test: Manually checking that teleportation works. CTS test will be
added after the feature freeze.
Change-Id: I622156b9e4cc7c44e61623081d6d079bbe04fd02
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| f847ee3c3d68e58b0a1a545bd7358ebb32f6948a |
|
21-Nov-2016 |
Vladislav Kaznacheev <kaznacheev@google.com> |
Implement tooltip support in View
Adding View.setTooltip/getTooltip and 'tooltip' layout attribute.
Following Material Design spec for styles and behavior.
Bug: 31515376
Test: cts-tradefed run singleCommand cts -m CtsViewTestCases
--test android.view.cts.TooltipTest
Change-Id: I2d2527f642cd7446ffc88d4beffc7b81d7a2f6d6
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| dc589ac82b5fe2063f4cfd94c8ae26d43d5420a0 |
|
11-Nov-2016 |
Sudheer Shanka <sudheersai@google.com> |
Update usage of ActivityManagerNative.
- Remove references to ActivityManagerProxy.
- Add isSystemReady to ActivityManager.
Bug: 30977067
Test: cts/hostsidetests/services/activityandwindowmanager/util/run-test android.server.cts
adb shell am instrument -e class com.android.server.am.ActivityManagerTest,com.android.server.am.TaskStackChangedListenerTest \
-w com.android.frameworks.servicestests/android.support.test.runner.AndroidJUnitRunner
Change-Id: I07390b6124fb1515821f5c0b37baf6ae74adc8fa
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 964c68e03a3a5034ab2a3533be450cc9abf9b2cb |
|
28-Oct-2016 |
Phil Weaver <pweaver@google.com> |
Send accessibility event on window title change.
Forcing the layout params to be sent to
WindowManagerService, and from there to accessibility
to generate the event.
Bug: 27857482
Test: Adding corresponding CTS.
Change-Id: I24fc97e16b95799259e4c472b6f1052a1dd00a56
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| c7c4dbb1475378eb3bc17819188b91a2ab1253bf |
|
28-Oct-2016 |
Winson Chung <winsonc@google.com> |
Removing forced layout when the window is translated.
Test: Manual, ensure that the accessibility focus is still visible on
a moved window (enable talkback, focus a view, then move the
window).
Change-Id: Ifd67afe355cac2f1df01ddd16f960282f4d36132
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| c097209f919123558857ad1a10de90e43ee24d6a |
|
03-Oct-2016 |
TreeHugger Robot <treehugger-gerrit@google.com> |
Merge "Making old apps passing null ClipData to startDrag work again."
|
| 697331784b0988b9691d78aacb18ff825504d4cd |
|
01-Oct-2016 |
Vadim Tryshev <vadimt@google.com> |
Making old apps passing null ClipData to startDrag work again.
This is for compatibility; see the bug.
Bug: 31865195
Test: manually rant an old app
Change-Id: If2f55ffd424b31f18610b96dd30bca87408e3df0
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| a61efa4c3364846b022d87a3c95f5f570a61aec6 |
|
29-Sep-2016 |
Vadim Tryshev <vadimt@google.com> |
Some fixes in ClipData and ClipDescription delivery.
See the bug.
Bug: 31809803
Test: Ran Drag/Drop CTS
Change-Id: Ie48a172bc465cd33e176801865e54e8aded4ce55
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 0f986b51fcba714ac4c014b83d9a7c3ffb06b6ff |
|
21-Sep-2016 |
Vadim Tryshev <vadimt@google.com> |
For pre-N apps, cascade LOCATION and DROP events. am: 45bee6b24c am: 140adada42
am: 1b060c3ab5
Change-Id: I1a450cf52cc0715092e1578454c4a4bb8a857ba7
|
| 1ee3bfb798f28f8ece43cd13e0747bc23a540150 |
|
21-Sep-2016 |
Vadim Tryshev <vadimt@google.com> |
For pre-N apps, keep entered all parents of an drag-entered child. am: ef12811560 am: f0550a6bd1
am: 72193e13c5
Change-Id: I27ce678e332e9caa5e977e40d18aabf6d9c76b55
|
| 45bf9dee0d7dc49ebfecbe73efd8dc55be98b27e |
|
21-Sep-2016 |
Vadim Tryshev <vadimt@google.com> |
Eliminating the black hole effect with location/drop events. am: 1edc6daf1d am: 32394cee01
am: 416384e06d
Change-Id: I6d9ea65abf3bcaa3150e6c0f26d2ff184efda095
|
| 140adada42088665894097e9e9985a9eb88a5880 |
|
21-Sep-2016 |
Vadim Tryshev <vadimt@google.com> |
For pre-N apps, cascade LOCATION and DROP events.
am: 45bee6b24c
Change-Id: Ib9a0e17fcc1d76911ee89dda46d99de1449ff295
|
| f0550a6bd141ccd75c22a01254fa25e5df977f98 |
|
20-Sep-2016 |
Vadim Tryshev <vadimt@google.com> |
For pre-N apps, keep entered all parents of an drag-entered child.
am: ef12811560
Change-Id: Ia086b1525d658d3374174e11a0a06551b8e4910a
|
| 32394cee01e509347339312711cffdd471b9777b |
|
20-Sep-2016 |
Vadim Tryshev <vadimt@google.com> |
Eliminating the black hole effect with location/drop events.
am: 1edc6daf1d
Change-Id: Ib32d77e7c28867753827a5d8100e628d6d8ee963
|
| 45bee6b24c8d181eafce339dc90d11b5e1bec74e |
|
19-Sep-2016 |
Vadim Tryshev <vadimt@google.com> |
For pre-N apps, cascade LOCATION and DROP events.
To restore the pre-N behavior, if a view returns false from its
LOCATION or DROP event handler, the event goes to its parent.
Bug: 31559942
Change-Id: I322099ae1e8a5cbbcf8814f2cd274fbae53b6848
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| ef12811560d4fcce3410eaa4d972dc39001efd4d |
|
16-Sep-2016 |
Vadim Tryshev <vadimt@google.com> |
For pre-N apps, keep entered all parents of an drag-entered child.
The bug complains that parents of a view under the drag location
don’t get drag events.
This is first of a 2 CLs that will restore the old functionality
(modulus fixing bugs) for pre-N apps.
This CL restores pre-N "nested" model of the entered state for
pre-N apps. It also makes possible restoring "nested" model for
LOCATION and DROP (implemented in a follow-up CL)
The CL replaces (for pre-N) generation of ENTER/EXIT events that
happens at the moment of changing the drag focus with generation
folowing the recursive delivery of coordinate-bearing events.
Bug: 31559942
Change-Id: Iead6bde9c1f88819b30afc78c1f424f7c1b64d51
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 1edc6daf1d13ec472da2aae2a2a88d130c495cb7 |
|
16-Sep-2016 |
Vadim Tryshev <vadimt@google.com> |
Eliminating the “black hole” effect with location/drop events.
Currently, a container view that doesn’t accept events, but has a
child that accepts events, prevents its parent from receiving
LOCATION/DROP events while the drag is over the container (but not
the child). This is a bug.
With this fix, such a container will prevent the parent from
invoking a (second) LOCATION/DROP event only if the event was really
delivered to any of its descendants.
To know whether the event was delivered, I added
DragEvent.mEventHandlerWasCalled member.
EXITED/ENTERED events are now generated upon delivery of the event
that has coordinates in it.
Current view that has drag focus is now global to reflect the fact
that it’s one per process.
Bug: 31469490
Change-Id: I248e8d1de87b7734853136eb4719f7571cea91d5
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| d94094e06277e002c2eb8bfd2ffd1e0bb98833d4 |
|
08-Sep-2016 |
John Reck <jreck@google.com> |
Illegal behavior -> Exception
Throw an IllegalStateException if the contract
of OnDrawListener is violated.
Change-Id: Ic86f6a0c8cd69ee7a8daa0ba135a3df76f56a213
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 93521c004356fda4da7eac12cd2c5cde40778d4d |
|
06-Sep-2016 |
Phil Weaver <pweaver@google.com> |
Stop double notifying a11y about Toasts. am: 532c7999c5 am: de13bcf08b
am: 6e56bb4c14
Change-Id: Ia95d2eb44f3deee794986a420a622fb1c7de9e15
|
| de13bcf08bb04f2c83f9db5d36db65e6a6120c87 |
|
06-Sep-2016 |
Phil Weaver <pweaver@google.com> |
Stop double notifying a11y about Toasts.
am: 532c7999c5
Change-Id: If8d025884b8a941386cd472403c1c93fee5a70af
|
| 85d18cce6d023afcdcb5de482a384c593a58a578 |
|
06-Sep-2016 |
Phil Weaver <pweaver@google.com> |
Merge "Stop double notifying a11y about Toasts." into nyc-mr1-dev
|
| 8c52bf51a2682c1a1faf3a134ce603edc0837884 |
|
31-Aug-2016 |
Adam Powell <adamp@google.com> |
Fixes for ImageView drawable visibility dispatch am: 06f9eb8b62 am: fd86f7fdfd am: ee2f4d890e
am: 393279da8f
Change-Id: I7e42805b096de31e388cd86ee87b44f312841aed
|
| 532c7999c52ed41bcc83461608044b799b6317d2 |
|
30-Aug-2016 |
Phil Weaver <pweaver@google.com> |
Stop double notifying a11y about Toasts.
TalkBack was speaking all Toasts twice because we were
sending both NOTIFICATION and a WINDOW_STATE_CHANGE events
when Toasts were displayed.
Stop sending the WINDOW_STATE_CHANGE event for toasts.
Bug: 30570188
Change-Id: I26c6dc50350dfd4daf2a706b94fadcf5d1e03557
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| ee2f4d890e8efcc3971853fd9b6638cec045bff2 |
|
27-Aug-2016 |
Adam Powell <adamp@google.com> |
Fixes for ImageView drawable visibility dispatch am: 06f9eb8b62
am: fd86f7fdfd
Change-Id: I155ed970c7f58895419778f01eebc5babb141c33
|
| 06f9eb8b621550ae1d39822fda38011a3ed5bdb9 |
|
25-Aug-2016 |
Adam Powell <adamp@google.com> |
Fixes for ImageView drawable visibility dispatch
Some apps rely on their drawables not getting not-visible hints via
setVisible when the window visibility changes. This manifests as
additional animations, such as crossfading from placeholders when the
window becomes visible again.
Apps should be able to handle this case in the future now that we have
more detailed reporting via onVisibilityAggregated, but to keep
existing apps working as-is, ImageView now operates in a compatibility
mode for targetSdkVersion < N and will only dispatch visibility
signals based on the same triggers used in M. New apps get the more
detailed signals.
Fix a bug where window visibility dispatch via onVisibilityAggregated
would double-dispatch "not visible" when the window is transitioning
from GONE => INVISIBLE or INVISIBLE => GONE.
Make the growing set of compatibility check fields in ImageView
static, matching the pattern from View.
Bug 30216207
Change-Id: I88875260bf6aaa23687c7d51353de8d633383531
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 10b133cc9e6392e4a6acd7f85d90ede464c3e957 |
|
23-Aug-2016 |
Adam Powell <adamp@google.com> |
Only dispatch window visibility aggregation for targetSdk >= N am: 64e1ba4398 am: 02abbe8d4c am: ca3a267478
am: 7cc5539a03
Change-Id: I241adaa27bb952d2b826721100944d569ac57149
|
| ca3a2674786de6c03742accc3e7776d19ed60e4d |
|
23-Aug-2016 |
Adam Powell <adamp@google.com> |
Only dispatch window visibility aggregation for targetSdk >= N am: 64e1ba4398
am: 02abbe8d4c
Change-Id: I66f8610e52f2aaf06b02fa8d369692fc2f89ee17
|
| 64e1ba4398aad1b08a24b15a1d094eb2e9cc1e61 |
|
22-Aug-2016 |
Adam Powell <adamp@google.com> |
Only dispatch window visibility aggregation for targetSdk >= N
Some existing apps treat drawable visibility notifications as a signal
to crossfade from a placeholder to the new image for the purposes of
scrolling onscreen via a recycling collection view or similar. Since
dispatchVisibilityAggregated is now called for window visibility
changes and ImageView informs its drawable of the visiblity change,
the extra call triggers a repeat fade-in in some existing apps when
you return them to visibility.
These apps should pay attention to the second parameter of
Drawable#setVisible, which signals that animations should not restart
in response to a visibility change. Updating to targetSdkVersion=24+
will enable the new behavior.
Bug 30216207
Change-Id: I27ce9f09bc7544863f7f7980c273650949db21cc
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 854d3f2ec2c50769b0ded4053c461c0a971a840f |
|
11-Aug-2016 |
Vladislav Kaznacheev <kaznacheev@google.com> |
Enable StrictMode.detectFileUriExposure() for drag and drop
Call ClipData.prepareToLeaveProcess/prepareToEnterProcess
at appropriate moments to check for StrictMode violations.
Bug: 30772435
Change-Id: I5c84c6c7b3d04094563623156616390d3df6879e
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| e481885e18a7c4b8748c2fc43a96874f936f8775 |
|
31-Jul-2016 |
Prashant Malani <pmalani@google.com> |
Let Rotary encoder events skip IME am: fecbc67e0d
am: a6bc98c003
Change-Id: Iecf4f32e56e3fac398b8ded665285af5e3632d2f
|
| fecbc67e0d39bc3b575be83d1bfc27de0504b47a |
|
23-Jul-2016 |
Prashant Malani <pmalani@google.com> |
Let Rotary encoder events skip IME
Rotary Encoder input events don't need to go through the IME, and hence
should skip it. This will save IPC round trip time, and cut down on
latency.
Bug: 29207649
Change-Id: I8b5062b9c409b338b2254232a2e0f7819d9b71de
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| cd84cfab79ac01b4329846b11136ca9e7c107d92 |
|
27-Jul-2016 |
Vladislav Kaznacheev <kaznacheev@google.com> |
Make DragEvent.getClipDescription() return null for ACTION_DRAG_ENDED
This is required to bring the DragEvent behavior in line with JavaDoc.
Bug: 30407098
Change-Id: I87b7f3ed3fe56681ca54a44e5cdeaf32966ad495
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| f2034d645524d50914972653a7260adb98b64846 |
|
15-Jul-2016 |
Vladislav Kaznacheev <kaznacheev@google.com> |
Merge \\"Always return valid ClipDescription for ACTION_DRAG_EXITED\\" into nyc-mr1-dev am: 278676bdeb
am: b604ade452
Change-Id: Ie779f0a6ca15f6f190a6361bddc4982b522004cd
|
| 7fe1f798bf45da33fa8012d9b28ffccebde32076 |
|
15-Jul-2016 |
Vladislav Kaznacheev <kaznacheev@google.com> |
Always return valid ClipDescription for ACTION_DRAG_EXITED
Bug: 30148704
Change-Id: I5f5cbb35a343e6ef61bed9ff92e3921a4ecce0c0
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 0aaf42755056778c3b950efb99b9124b50755c79 |
|
25-Jun-2016 |
Phil Weaver <pweaver@google.com> |
Behave if the same view gets a11y focus twice.
In some corner cases, ViewRootImpl#setAccessibilityFocus
can be called twice for the same view. Make sure we're
actually changing views before clearing accessibility focus
to avoid inconsistent state.
Bug: 29637593
Change-Id: I5dc6f05bdeaec55c352417bfca92c11bd03c3c10
(cherry picked from commit da4692774c74b51818a2df1dc7534d8d13d62634)
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 9c68b2b076286ef2f1fe3355755e53aa341fbef7 |
|
13-Jul-2016 |
Chong Zhang <chz@google.com> |
Merge \\"Revert changes to force layout after insets changes\\" into nyc-mr1-dev am: 185131442b
am: 12fad318b1
Change-Id: I881ff5642a7b1b748d948345728acd3ceb4b9855
|
| 75eccbd0ff315ee02890d22917801151c779cfb1 |
|
13-Jul-2016 |
Chong Zhang <chz@google.com> |
Revert changes to force layout after insets changes
Alternative fix for b/29391054 ag/1152795 sends an MOVE message to
client which also force a layout, so we no longer need to force
it after the insets change in the traversal.
Reverting the following two related fixes as it does more
measures than necessary.
bug: 29391054
bug: 29533997
bug: 29634368
Revert "Fix layout issue after insets changed"
This reverts commit 76fdbb72c93a431e14357e0ea3d5a83edfa75c5e.
Revert "Do a forceLayout if pending insets is changed after relayout window"
This reverts commit 71f2c31469ed9628d744d20b86eaf188cfdf686d.
/frameworks/base/core/java/android/view/ViewRootImpl.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/ViewRootImpl.java
|
| 4192eac03a125ae8d6437a2c5097844b9d72a82e |
|
27-Jun-2016 |
Phil Weaver <pweaver@google.com> |
Merge "Behave if the same view gets a11y focus twice."
|
| da4692774c74b51818a2df1dc7534d8d13d62634 |
|
25-Jun-2016 |
Phil Weaver <pweaver@google.com> |
Behave if the same view gets a11y focus twice.
In some corner cases, ViewRootImpl#setAccessibilityFocus
can be called twice for the same view. Make sure we're
actually changing views before clearing accessibility focus
to avoid inconsistent state.
Bug: 29637593
Change-Id: I5dc6f05bdeaec55c352417bfca92c11bd03c3c10
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 9a327642df3992708a9b03b84562d7a420834a76 |
|
25-Jun-2016 |
Adam Powell <adamp@google.com> |
Merge \\"Fix layout issue after insets changed\\" into nyc-dev am: 119f1715b3
am: 242a44395e
Change-Id: Iab3e11ed6346ed538f3206faa32d15e6e227efef
|
| c43c9e052e0928abd9648a442a5b1acfa21a8fc7 |
|
25-Jun-2016 |
Adam Powell <adamp@google.com> |
Merge \"Fix layout issue after insets changed\" into nyc-dev
am: 119f1715b3
Change-Id: I343dc8ad193ad83a8c0628c104836bd392cd07d5
|
| 76fdbb72c93a431e14357e0ea3d5a83edfa75c5e |
|
24-Jun-2016 |
Adam Powell <adamp@google.com> |
Fix layout issue after insets changed
Fix a regression where a change in insets would forceLayout on the
view hierarchy but not run the measure/layout as a result. This would
cause layout requests to become stalled until a window-level relayout
event.
Bug 29634368
Change-Id: Ia3f32f5891c8b32c06c13f95ebd0572233572b04
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| ce71c120df5386401ddaec61030e24fe8b398c1a |
|
22-Jun-2016 |
Adam Lesinski <adamlesinski@google.com> |
Merge \\"ContextImpl: Keep DisplayAdjustments and Display in sync\\" into nyc-dev am: 0bf31c3fa6
am: a72a6aae37
Change-Id: I8c85a4bb67d470c5bba5bcf81915e4684019027b
|
| e894efa9b6b40865d6d5666a5d776ba4e7185156 |
|
22-Jun-2016 |
Adam Lesinski <adamlesinski@google.com> |
Merge \"ContextImpl: Keep DisplayAdjustments and Display in sync\" into nyc-dev
am: 0bf31c3fa6
Change-Id: Id0d16d2f9d69b87d4b4c01370eeceafe329d1817
|
| 4ece3d6bb18a609afcd0e82f0340b7d36ba24eea |
|
17-Jun-2016 |
Adam Lesinski <adamlesinski@google.com> |
ContextImpl: Keep DisplayAdjustments and Display in sync
Make sure that when our Resources get updated, that DisplayAdjustment
and Display properly reflect the potentially new screen dimensions.
Bug:28388969
Change-Id: I340550ea094ece87abc8790dd46aaa60ab3cedd3
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| b0e28cf5b331fa847a381018cdf0bde5fd0f8960 |
|
18-Jun-2016 |
Chong Zhang <chz@google.com> |
Merge \"Do a forceLayout if pending insets is changed after relayout window\" into nyc-dev
am: 2756d0707f
Change-Id: I72a8192317ebaa7c036416a65b415c2471f449de
|
| 788f4309acf618f305ea0ca3b6564a8120da8c40 |
|
17-Jun-2016 |
Chong Zhang <chz@google.com> |
Merge \\"Do a forceLayout if pending insets is changed after relayout window\\" into nyc-dev am: 2756d0707f
am: dba235d91a
Change-Id: I1a9758b62322aecaea79c879f82b1793bae67061
|
| 71f2c31469ed9628d744d20b86eaf188cfdf686d |
|
17-Jun-2016 |
Chong Zhang <chz@google.com> |
Do a forceLayout if pending insets is changed after relayout window
We might have a pending MSG_RESIZED_REPORT, but if it's executed after
relayoutWindow, mPendingInsets will already be the new value and it'll
not forceLayout. So we need to forceLayout here to make sure the measure
cache is cleared.
bug: 29391054
Change-Id: I73793b1427b89e75700369ec3b37053a6a732f0d
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| b3b6d96ed42d94e57c5d45f191e60be975404ef3 |
|
10-Jun-2016 |
John Reck <jreck@google.com> |
Merge \\"Don\\'t call surfaceCreated for just changed surfaces\\" into nyc-dev am: e4b1fb94e3
am: 93ff5124c6
Change-Id: I7b53bc90c0f4edbf1482924d02fd6361884a7860
|
| b8dac11e5ae981c824e3c31de079134f4aee9a3b |
|
10-Jun-2016 |
John Reck <jreck@google.com> |
Merge \"Don\'t call surfaceCreated for just changed surfaces\" into nyc-dev
am: e4b1fb94e3
Change-Id: I488da6f9f779ddf64beb6ac12d1481d2bfd69821
|
| 208c47cfb0b1aaec7a3f8478b672da3c9c75306d |
|
10-Jun-2016 |
John Reck <jreck@google.com> |
Don't call surfaceCreated for just changed surfaces
Fixes: 29223302
If the surface only changed we want to just call onSurfaceChanged,
not onSurfaceCreated.
Change-Id: I65c8b210a7e34eaa2862020335ee7f6ef56eeac2
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 718cd3eb70703c43f29ca37907bbf0e153d8cca0 |
|
18-May-2016 |
Doris Liu <tianliu@google.com> |
Handle hidden RT VectorDrawable animators
This CL changes the target of VD specific animators to VectorDrawable,
instead of RenderNode. The benefit of doing so is that animators can
now detect whether the animation is meaningful by checking whether
their VD target is in the display list. If not, that means the VD is
not drawing for the current frame, in which case we can be smarter
and more power efficient by removing the animator from the list and
posting a delayed onFinished listener callback.
By setting VD as the animation target, when an ImageView decides to
update its drawable from one AVD to something else, we'll be able
to detect that the previous AVD is no longer in the display list,
and stop providing animation pulse to the stale AVD, which is
something we couldn't do previously. This change also
handles the case where one AVD instance could be drawn in two
different views.
Bug: 27441375
Change-Id: Iaad1ed09cfd526276b95db0dd695275c28e074e8
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 67254723297442a7ac6a2479ec7f72f38f310c3c |
|
02-Jun-2016 |
Chong Zhang <chz@google.com> |
Fix scroll amount calculation in ViewRootImpl
When calculating scroll amount, we should check whehter focus
is visible using before-scrolling position.
It's possible that the view is already scrolled, then visible
insets changes (eg. IME went away). Previous scroll position
still makes the focus visible, but it will leave the focus
in a bad position when it should be scrolled back.
bug: 29025892
Change-Id: I091f16bebc4c1e5ba831616c51ab2ac75d4c4b3c
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| e78ba24c176fd6a0c54eaf7e52be545952ba1ab7 |
|
26-May-2016 |
Tenghui Zhu <ztenghui@google.com> |
Merge "Update the light center when the root view's layout changed" into nyc-dev
|
| 778e3b91acad6da04341d439f0c66a4fd09def4f |
|
16-May-2016 |
Michael Wright <michaelwr@google.com> |
DO NOT MERGE Remove Pointer Capture API
The underlying implementation needs to be completely rethought. If a
process crashed while you were in pointer capture mode, you were
pretty much stuck in it. If the mouse happened to move outside of
your bounds right before you called the API, you'd never actually get
an event (whatever it was hovering over would). There's no easy way
for the system to tell you when you enter or exit this mode because
it doesn't actually track who the current request is from.
These are all solvable, but not in the N time frame. Maybe next time.
Bug: 26830970
Change-Id: I03efd63c499b86dc278491ca3284566c1965581f
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| f9d9ce7705475874c82af04eb9b208a7fb556792 |
|
13-May-2016 |
Michael Wright <michaelwr@google.com> |
DO NOT MERGE Rename PointerIcon and Pointer Capture APIs
This is a response to API council feedback.
Bug: 26830970
Change-Id: Ia2d284b5c1ab8365bedfdc37d129be4b8146036b
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 2757128940c35d8007e1817b32e7128e2569ad6e |
|
13-May-2016 |
Teng-Hui Zhu <ztenghui@google.com> |
Update the light center when the root view's layout changed
b/26208900
Change-Id: I0594b2801d54a489e7d858b7a0f9549fcc30f9a0
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 44aabe4b7240a9a03678b4a66bdd5f46a9dfb29a |
|
10-May-2016 |
Chong Zhang <chz@google.com> |
Disable keep_screen_on traces
bug: 28692100
bug: 27522448
Change-Id: Ic077e8985f1f21bc111287813fb2992ed01df909
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 6afe594461930e83cbf5ecf181bf43fcba0060dd |
|
05-May-2016 |
Chong Zhang <chz@google.com> |
Merge "Debug traces to facilitate screen timeout debugging" into nyc-dev
|
| 4ffc3180121b36eec2577b3c311ad4da44c3af56 |
|
05-May-2016 |
Chong Zhang <chz@google.com> |
Debug traces to facilitate screen timeout debugging
bug: 27522448
Change-Id: I4d51be316e4aedecffb7001126849d7c6136d517
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| d86fb2ce37b6b812992a28e7210a82f169d1cdcf |
|
04-May-2016 |
Chet Haase <chet@google.com> |
Force second measure pass when there is a configuration change
It's possible for a call to updateConfiguration() to happen in the middle
of performTraversals(), after the measure phase has happened, but before
the layout phase. During the configuration call, it's possible for views to
have requestLayout() called on them. This can result in the request flag
not getting cleared, because views that have had layout requested, but which
have not yet been measured, may not be told to layout.
The correct flow should be that any code path causing requestLayout() (which
could be anything that calls out to user/app code) should happen before the
measure phase (or cause a second measure to occur). For now, causing the second
measure to occur is a low-risk simple change that fixes the immediate problem.
Issue #28152259 Calling requestLayout from inside View.onConfigurationChanged can cause problems
Change-Id: I3b532eeacc3784d8d21193d01ddd7fa15ac0684e
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 1bccabf3c443afb17531f863beda10d626667d1f |
|
28-Apr-2016 |
Robert Carr <racarr@google.com> |
Fix ViewRoot inset adjustment after initial setup.
If the insets change, "mWidth/mHeight" won't change
as it's based on the window frame (not the surface size),
we need to track when the insets change and call
HardwareRenderer.setup with the new values.
Bug: 28257246
Bug: 28368990
Change-Id: Ida304b57c4671d010d1cf7b370674c9453841c97
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| b2594850870ba950067962d41c481f9bbfafeaf1 |
|
26-Apr-2016 |
Robert Carr <racarr@google.com> |
Fix bugs with takeSurface and preserveWindows.
When reusing a ViewRoot and DecorView as we do with preserveWindows
there are two issues with SurfaceHolders. First, we update the
SurfaceHolder callbacks when we call ViewRootImpl.setView. In the
case of preserved window relaunch, the DecorView is reused and there is
no call to setView. We need the ActivityThread to notify the ViewRoot
that something has changed. Secondly, we were assuming the only time
a new surface would be created for the purposes of SurfaceHolder
notification was when we previously did not have a valid surface.
Instead we need to check if the native Surface object has changed each time we
get a result from relayout.
Bug: 28331264
Change-Id: If1b4aab9b2ba579fa040e2a3ab4471842476d82f
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 0d6222d96d72199f607e3ca5b3d696212372bf47 |
|
19-Apr-2016 |
Jorim Jaggi <jjaggi@google.com> |
Fixes for resize thread
- Make sure to draw navigation bar/status bar background before the
main render node. This is to avoid any flickering when entering
resizing mode, so you rather overdraw than underdraw.
- Draw the first frame from the main thread directly to increase
chance that all drawing commands are processing within a single
frame.
Bug: 27864358
Bug: 28003586
Change-Id: I033f57cdbcb2c16ea93134c041095a415d5c25b4
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| d6a25c2b3e7fd5a98741e2f770cf54d539b29258 |
|
14-Apr-2016 |
John Reck <jreck@google.com> |
Merge "Revert "Revert "Make stopped state a first-class thing""" into nyc-dev
|
| 8afcc76920499d0a384dba1470c5a377f80ed768 |
|
13-Apr-2016 |
John Reck <jreck@google.com> |
Revert "Revert "Make stopped state a first-class thing""
This reverts commit eab3f2658aa41d37c3b05d49a2ce4e3f4ed85399.
Fixes first-frame issue, mReportNextDraw needs to override
mStopped
Fixes: 28118961
Fixes: 27286867
Change-Id: I5c811759637d08ba9f3b342016d1b3006986d5a2
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 3fb1c81394f98b025b488774916b7580f9e31dab |
|
13-Apr-2016 |
Wale Ogunwale <ogunwale@google.com> |
Merge changes Ieefeb843,Ic2a94b09 into nyc-dev
* changes:
Update surface insets on window elevation changes.
Fixed bug with cropping out drop shadow for pinned stack.
|
| 52546e46353f455d6a5bd070da6095868d7fc8bd |
|
13-Apr-2016 |
Michael Wright <michaelwr@google.com> |
Merge "Crash early when requesting a keyboard shortcut helper..." into nyc-dev
|
| 53b854ad7de5c22e03383b0f6538a493f601b7c9 |
|
13-Apr-2016 |
Michael Wright <michaelwr@google.com> |
Crash early when requesting a keyboard shortcut helper...
with a null IResultReceiver.
We're seeing Dialer crashes in this code path but they happen in the
main Handler loop so we can't see where the request with the null
request is coming from. Crashing earlier will hopefully give us a
stack trace that we can use to diagnose the issue.
Bug: 27963013
Change-Id: I60e4ef2ef328fa69790bbcaa4f196c02f7443296
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 825fa4d5ae7b2907ee1769d09e6333306de2a92e |
|
11-Apr-2016 |
John Reck <jreck@google.com> |
Merge "Revert "Make stopped state a first-class thing"" into nyc-dev
|
| eab3f2658aa41d37c3b05d49a2ce4e3f4ed85399 |
|
11-Apr-2016 |
John Reck <jreck@google.com> |
Revert "Make stopped state a first-class thing"
This reverts commit 945961f78a78eced823d5ba78505c781b079703d.
Change-Id: Iebc1d49fac33380233f8785fc39bec6c30a5e714
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| af93306a3db9c0a04d74809901cc297834bbba87 |
|
09-Apr-2016 |
Phil Weaver <pweaver@google.com> |
Merge "Reduce unnecessary accessibility cache clearing." into nyc-dev
|
| e37cfab6c65ec0997b07089e70fa0ad47d2fbd83 |
|
08-Apr-2016 |
Phil Weaver <pweaver@google.com> |
Reduce unnecessary accessibility cache clearing.
Tracking if accessibility focus is being cleared because it is being
set to another view in the same window. In this case, leave
accessibility focus on the window.
This change greatly reduces the amount of cache re-indexing.
Previously we flushed the cache every time accessibility focus moved.
Bug: 28077283
Change-Id: If80899d36e7f58b22635f844bdd4ea37a55b875e
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 945961f78a78eced823d5ba78505c781b079703d |
|
08-Apr-2016 |
John Reck <jreck@google.com> |
Make stopped state a first-class thing
Bug: 27286867
WindowManager has committed to stopped state
controlling the lifecycle of the Surface, so
make that a first-class thing in HWUI as well.
This makes it more resistent to things like
a rogue updateSurface() happening while mStopped=true,
leading to bad things down the line. Instead let
the surface be changed/updated as often as desired,
and just block any attempt to draw on that surface.
Also removes some unnecessary makeCurrent()s, as
EglManager ensures that we *always* have a valid
GL context now (using a pbuffer surface if there is
no window surface set)
Change-Id: Iead78ddebc7997e8fdb0c9534836352f5e54b9bd
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 246c209e4fe704c0745224be0ab05225e8431d11 |
|
07-Apr-2016 |
Wale Ogunwale <ogunwale@google.com> |
Update surface insets on window elevation changes.
Window manager factors in the surface insets when calculating the
right crop for a window surface. Without the surface insets been
updated and new param forwarded to window manager, the window crop
will not be the right size and the window drop shadow might not show.
Bug: 27364161
Change-Id: Ieefeb8435543f3137672a065269cdeefca371111
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 26952d748eaab23330c660fa0d7f5c0450dc1d06 |
|
02-Apr-2016 |
Jorim Jaggi <jjaggi@google.com> |
Do not call forceLayout if not needed
If the relevant frames for the app don't actually change, there is
no reason to call forceLayout and force a layout pass.
Bug: 27864358
Change-Id: I2add8cc5791023937afc154e6e50bbf7efb35adb
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 44b49f070aafe8ad44efae87341121cce49ff11c |
|
25-Mar-2016 |
John Reck <jreck@google.com> |
Add a callback for rendernode parentcount=0
Bug: 27709981
Fixes: 22565656
Change-Id: I1cb4461baf9069dc4e7ca6de10d5862578c107f4
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 75c21ca948aabbcd8b87196e966771b1dd976686 |
|
29-Mar-2016 |
Jorim Jaggi <jjaggi@google.com> |
Revert "Start drawing immediately"
This reverts commit 3127c2a471dbefda916701d9b3837ce109ea7d49.
The original CL caused various issues for which we don't have the
time/not willing to take the risk.
Bug: 27864389
Bug: 27451341
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 16b631923ddf7a32d055e06d1dea70964f85e5a6 |
|
26-Mar-2016 |
Jorim Jaggi <jjaggi@google.com> |
Cleanup window callbacks locking
- Also get rid of USE_MT_RENDERER, because there is no point in
having a flag if the other path never gets tested.
Bug: 27738239
Change-Id: Ic76115962940e72f2c59b8d291d078d15f8d493c
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| aaa38c9f1ae019f0fe8c3ba80630f26e582cc89c |
|
28-Mar-2016 |
Yohei Yukawa <yukawa@google.com> |
Ensure IC#finishComposingText() is called on the correct Handler.
This attempts to reland previously reverted CLs [1][2] due to an
unexpected regression (Bug 27824691).
The Bug 27868748 we want to address by this CL is that currently
InputConnection#finishComposingText() can be called on the root view's
Handler no matter what Handler is associated with
ControlledInputConnectionWrapper. Actually the root cause of
Bug 6789252 is the same, but there we worked around it by not calling
InputConnection#finishComposingText() in certain situations [3].
With this CL we should be able to logically revert that workaround.
This CL also removes redundant IMM#mServedInputConnection. This is safe
because the following two fields have the same lifetime.
- InputMethodManager#mServedInputConnection
- InputMethodManager#mServedInputConnectionWrapper
We do not need to maintain both of them. This also allows us to use a
strong refecente in IInputConnectionWrapper#mInputConnection instead of
a WeakReference. To understand why this is safe, we need to understand
how things previously worked, which is as follows:
1. InputMethodManager#mServedInputConnection becomes non-null.
-> IInputConnectionWrapper#mInputConnection.get() is guaranteed to
be alive.
2. InputMethodManager#mServedInputConnection becomes null or another
object.
-> IInputConnectionWrapper#mInputConnection.get() may not be alive.
Since we know exactly when InputMethodManager#mServedInputConnection is
updated, in theory we do not need to use WeakReference here, and
with this CL we do not use WeakReference anymore. Actually the initial
commit [1] accidentally removed the last strong reference to the active
InputConnection and WeakReference could be null at any time, which was
what we observed in Bug 27824691.
[1]: I1181e067aa5bedbdf0c7ec1bcec479257aea511c
afb6558c8f5e0ee797b252558d7e529e3d946d8f
[2]: Ibe94f115e607a198d12ecd3d4e4f91a7d9469c98
16e2c7b59aacf44df7aaa0d04e0228240907487f
[3]: I66f51da1299532793ef8fa700f35b0811670f235
4e5184f929d2498714bc7734fe10b9b8810cb071
Bug: 27868748
Change-Id: If2a03bc84d318775fd4a197fa43acde086eda442
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| c39c7b0ce2b80fbadfd58245c106cc513b83eac2 |
|
24-Mar-2016 |
Jorim Jaggi <jjaggi@google.com> |
Add shadow during resizing in docked mode
Bug: 27738239
Change-Id: I48c45bd97c2aa7f3d7bbb5b1ba650fbe408bd0bf
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| cdf90bb6747aa100305def66a7984522600d803e |
|
24-Mar-2016 |
Yohei Yukawa <yukawa@google.com> |
Merge changes I16312592,Iadfc226e into nyc-dev
* changes:
Revert "Remove redundant IMM#mServedInputConnection."
Revert "Make sure to call back reportFinish() on the desired Handler."
|
| 1fa5f594a26b00aa137703bb21e186910c1242c6 |
|
24-Mar-2016 |
Yohei Yukawa <yukawa@google.com> |
Revert "Make sure to call back reportFinish() on the desired Handler."
This reverts commit 16e2c7b59aacf44df7aaa0d04e0228240907487f.
It turns out that I1181e067aa5bedbdf0c7ec1bcec479257aea511c caused
a serious regression Bug 27824691. To revert that CL, we have to revert
this one first.
Bug: 25332806
Bug: 27824691
Change-Id: Iadfc226eb91cc969b77c9d98e04ec3c76fe86ead
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 3e5bf786b7ca36fa0cc150fcd8d0e7a69ecb9db0 |
|
24-Mar-2016 |
Clara Bayarri <clarabayarri@google.com> |
Merge "Keyboard Shortcuts: plumb deviceId through" into nyc-dev
|
| fcd7e80b21cc9db6be00e37371401ea1d0938796 |
|
10-Mar-2016 |
Clara Bayarri <clarabayarri@google.com> |
Keyboard Shortcuts: plumb deviceId through
Bug: 27673736
Change-Id: Ie72807aa8c2bfd142b081a6a915e101c16d31473
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 16e2c7b59aacf44df7aaa0d04e0228240907487f |
|
23-Mar-2016 |
Yohei Yukawa <yukawa@google.com> |
Make sure to call back reportFinish() on the desired Handler.
Before exposing #reportFinish() as a public API, we have to fix an
existing bug that my previous CL [1] for Bug 26945674 forgot to take care.
Currently BaseInputConnection#reportFinish() is always called by using
the root view's Handler. We should move the logic to call
BaseInputConnection#reportFinishInputConnection() from ViewRootImpl to
IInputConnectionWrapper to make sure that the method in question can
always be called on the desired Handler.
To make things simple, instead of explicitly calling #reportFinish()
from IMM, this CL let ControlledInputConnectionWrapper#diactivate()
internally call #reportFinish() as needed. This makes it easier to make
sure that #reportFinish() is called after all the queued method calls
are handled.
[1]: Id9e579bb3e2966986cdcb1c34bc8cacfeca2e1a9
612cce92ad96eda1146c3abd2afa7aaa4d4f2b3f
Bug: 25332806
Change-Id: Ibe94f115e607a198d12ecd3d4e4f91a7d9469c98
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 9c146bfee788c5b5d95cc732916be1a0d1ecd162 |
|
16-Mar-2016 |
Adam Powell <adamp@google.com> |
Refinement for onVisibilityAggregated
Change the args for onVisibilityAggregated to a single boolean for
visibility to the user. Also fix an ordering bug that could trigger a
view background drawable call to setVisible before the view would
respond true to verifyDrawable, which caused issues with some apps.
Bug 27461617
Bug 27689884
Change-Id: I58bdc7c4364264f7fa0863689ba2b76df904ef81
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 41d9690c3e3588dd273308279b9e609c2c6da3c7 |
|
15-Mar-2016 |
Adam Powell <adamp@google.com> |
Add View#onVisibilityAggregated
There's a common misconception (even across the framework) that
View#onVisibilityChanged determines and reports visibility on 'this'
up to the changed view and the total visibility within the
window. Knowing this is useful for things like starting/stopping
animations. onVisibilityChanged only reports the visibility for the
specific changed view, not the effects that would have down the tree.
Add onVisibilityAggregated to report what some code thought it was
getting already, and move ImageView and ProgressBar over to using it.
Bug 27461617
Change-Id: I433f41de453e27a53f907f1d9805350f30f31de9
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| e4f131a595cd9ef57c4abb679c23fb03b4062e47 |
|
07-Mar-2016 |
Wale Ogunwale <ogunwale@google.com> |
Disabled debug logs
Disabled log points that were enabled for b/27286867
Bug: 27286867
Change-Id: I1a5fe82dfc3e85adef12be8b52277be6131f5d73
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 6cf85afcb1e0e410e8e168c999e40fad3797d6ab |
|
29-Feb-2016 |
Andrii Kulian <akulian@google.com> |
Merge "Reset pointer icon when view is not present" into nyc-dev
|
| 33c1bc586c4b2dde2d54c16cd9c7b8bc366e5096 |
|
29-Feb-2016 |
Andrii Kulian <akulian@google.com> |
Reset pointer icon when view is not present
Sometimes pointer change request is delivered after view is detached from its
ViewRootImpl. E.g. when popup is present click outside to close it.
Bug: 27292939
Change-Id: I925728af334a1e1ae53f7e530d639e50b0c37f2b
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| fc736869aced442057e5a2c16a9591dca1f93295 |
|
27-Feb-2016 |
John Reck <jreck@google.com> |
Switch to pbuffer surface sooner
Bug: 27286867
If the system/app is slow, it might take too long to
stop drawing. Switch the ordering of destroying stuff so
that we switch to the pbuffer surface first, then do
cleanup
Change-Id: If64a3dbb71bb9fd53567231590436a89b2f1a09e
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| f4db3d253ef533f6992217fcbb3119a091172d94 |
|
26-Feb-2016 |
John Reck <jreck@google.com> |
Don't lose mInitialized in onStop()
Bug: 27350647
Change-Id: I74e6427ac4030645c416efb24948efdbdc90fa1c
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 26d02d29e37564c2b01e0c73f9b5cd93af34de75 |
|
25-Feb-2016 |
Jorim Jaggi <jjaggi@google.com> |
Use actual window size for layout
When doing the actual layout pass, desiredWindowWidth/Height might be wrong,
because window manager has the final say how large the surface is, so use
that size.
Bug: 27342700
Change-Id: I4f74fdef66ba7aa88b86f8c95fb391b1cc847beb
/frameworks/base/core/java/android/view/ViewRootImpl.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/ViewRootImpl.java
|
| d9b1607bd92153a2d3ed01437d603f695cf7dcb6 |
|
23-Feb-2016 |
John Reck <jreck@google.com> |
destroyHardwareResources in onStop()
Bug: 27286867
This hopefully makes everything fully-deterministic. It should
also fix some old annoyances around Bitmap lifecycle as they will
be released earlier in onStop() instead of waiting for
dispatchDetachedFromWindow() which may never happen.
Change-Id: I6e871760650780e327c0e42f62950c1052dd8019
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 90776de6bbcd7dd40cb2690d4441fbafe29747d9 |
|
22-Jan-2016 |
Joe LaPenna <jlapenna@google.com> |
Allow button events in ambient.
See thread: "key presses & Ambient"
Bluetooth media button presses and Stem buttons were being rejected in ambient. This change allows those keys while disabling touch events while in ambient.
BUG: 25964771
BUG: 26524301
Change-Id: I914edd447c38678a06d27677be4597c0ee384635
(cherry picked from commit 7528f57c4ddbde1c6d0a2a352bd8a1af43711013)
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 527905e195e28df970b63b2e4a9dcdc0464e547c |
|
17-Feb-2016 |
Vladislav Kaznacheev <kaznacheev@google.com> |
Do not call IWindowSession.updatePointer icon from pointer handler
Currently if View.setPointerIcon is called from inside a pointer
event handler this will cause a redundant round-trip to the server
which can be easily avoided.
Bug: 27107871
Change-Id: Ia641818c3700c0d96d0c32e020b91af58dccfa2a
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| c662d8e94620c84b2fa57bfd6e45690f0c349d89 |
|
06-Feb-2016 |
Jorim Jaggi <jjaggi@google.com> |
Make sure we call reportResized exactly once when drag starting
If there was another layout happening before the app called
relayoutWindow(), we were issuing multiple reportResized calls,
leading to multiple relayoutWindow() calls, slowing everything
down.
Change-Id: I1f3da04bb7581c655567e1d1a6fe0f8c83c0ffda
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 9511b0f1e9ac629a4a747a0c9373d33ab33cfc32 |
|
30-Jan-2016 |
Jorim Jaggi <jjaggi@google.com> |
Fix bug where surface was not clipped off during resizing
When dragging the divider in a way such the task size goes through
the following transition
- Half size
- Full screen
- Half size
the surface wasn't clipped off anymore. This was because in full
screen configuration, computeDragResizing() == false thus when
going full screen -> half size, we reset the draw state to
DRAW_PENDING to get notified when it has finished drawn. However,
this also broke clipping.
In order to fix this, we always put the window into a resizing mode
no matter whether the bounds are fullscreen or not.
However, this introduces an ugly flickering on the navigation bar,
when going into docked mode, because the app doesn't draw navigation
bar background in resize mode.
To fix that, we calculate the presence of navigation bar whether the
window is fullscreen, and not just whether it's resizing. For that,
we need to calculate the presence in BackdropFrameRenderer, by using
the insets just sent by window manager.
Change-Id: Idf56df4ae7fefe67d068bc2eeda8dc4d83bbefb7
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| f648108f83d4e74811919e9811efb8fcc184b8a3 |
|
03-Feb-2016 |
John Reck <jreck@google.com> |
Have RT drive window positioning
Bug: 22802885
Change-Id: I6beed5474d3a943b16e9097f7bd61ce3cbd37505
/frameworks/base/core/java/android/view/ViewRootImpl.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/core/java/android/view/ViewRootImpl.java
|
| 3127c2a471dbefda916701d9b3837ce109ea7d49 |
|
27-Jan-2016 |
Jorim Jaggi <jjaggi@google.com> |
Start drawing immediately
We used to have a condition to start drawing only in the second traversal,
which added a delay of about 10-15ms. We believe that we don't need this
anymore, because we have other means of synchronizing the app transition
animation with the app drawing - we wait for all surfaces to be drawn
in window manager.
Bug: 21035872
Change-Id: I5094a1377817dc7e0a2392cc8f522e99cd7b4d6e
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| c3bc45ec042dead6e9a7191a5d25ae2867acde25 |
|
26-Jan-2016 |
Yigit Boyar <yboyar@google.com> |
Merge "Fix requestRectangleOnScreen"
|
| 92b26c5bffd92a8e2251f60a6663e9eba4d5aa2d |
|
25-Jan-2016 |
Vladislav Kaznacheev <kaznacheev@google.com> |
Merge "Restore correct mouse pointer after drag and drop"
|
| d62d5e9accc76952d737f9c58a97f898807713e5 |
|
20-Jan-2016 |
Yigit Boyar <yboyar@google.com> |
Fix requestRectangleOnScreen
This CL fixes a bug in View#requestRectangleOnScreen where the
position was not being moved from child's coordinate space to
the parent's coordinate space properly.
I've also added more documentation to clarify the API.
Bug: 25787435
Change-Id: Id821fa178e04016f6fb830d0bd2abde046581465
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| ec6a447c86b03f5896fdb717de530c8abf8887f9 |
|
22-Jan-2016 |
Vladislav Kaznacheev <kaznacheev@google.com> |
Restore correct mouse pointer after drag and drop
This CL introduces IWindow.updatePointerIcon method.
When the drag is complete, this method is called on the window
directly under the pointer.
Same method can be used in the future to update mouse pointer
when a window appears or disappears.
Bug: 24415739
Change-Id: Ia7b0522448cb3cd754da5e24696060d3b3bf2e50
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| c8680438c0481b9c1e2b0bc856f900057ea14ba2 |
|
23-Jan-2016 |
Vladislav Kaznacheev <kaznacheev@google.com> |
Merge "Change mouse pointer when drag and drop is active"
|
| ba761124e624ffed2681a9e171cd3f7d8c6ed59e |
|
22-Jan-2016 |
Vladislav Kaznacheev <kaznacheev@google.com> |
Change mouse pointer when drag and drop is active
Mouse pointer is set to STYLE_GRAB when the drag has started and
reset to STYLE_DEFAULT when the drag has ended.
Resetting the pointer shape to the one defined by an underlying
view will be handled in a separate patch.
Bug: 24415739
Change-Id: I8df0a08c5701a34a48f10ec6b43c2cf2e6362d61
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 6c09ff556014052bb1b4047f59d4ebba21d4a8c3 |
|
21-Jan-2016 |
Matt Wu <mattwu@google.com> |
Merge "Set WindowSession's touchmode when in local focus mode,"
|
| 1937a4c68a586e75501a90253c90b213a4d6167f |
|
20-Jan-2016 |
Filip Gruszczynski <gruszczy@google.com> |
Update width available for dialogs on all configuration changes.
Bug: 26504275
Change-Id: I7a0399e4af77ab02df8b3dff68adcf37b36d7ca7
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 2e95a488e0a12d4263d101e888fdd89fd123aec3 |
|
15-Jan-2016 |
Jorim Jaggi <jjaggi@google.com> |
More optimization while dragging docked divider
- Make sure mPendingBackdropFrame gets also set when if the window
triggers a relayout on it's own, so it doesn't call into window manager
all the time.
- Set the insets of the docked divider to empty so we don't trigger a
layout when we are just moving it - it doesn't need it in any case.
- Send a window move message to the divider when it moved
- Update attach info in all move cases, update light center
The whole resize operation now only takes around 4ms per frame, and
leaves a lot more resources for the apps to do configuration changes.
Bug: 25015474
Change-Id: Ica48129570a0fc858a89c21f46abf3442efb0224
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 844e1712df100e0a357d7f86b10cb78e6593b9fb |
|
14-Jan-2016 |
Jorim Jaggi <jjaggi@google.com> |
Don't relayout when windows move during resize
Not needed and just increases system load.
Bug: 25015474
Change-Id: Iaf871389527237b5cbc88c03b2f060629b6351dc
/frameworks/base/core/java/android/view/ViewRootImpl.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/ViewRootImpl.java
|
| f6525ceebcc8839c5158104f5f7e242a9a134a42 |
|
15-Jan-2016 |
Chong Zhang <chz@google.com> |
Fix missing dialog windows
Use the size in the configuration (not the display size) to set the
dialog size.
bug: 26490549
Change-Id: I8e17482ddcc39fae1d6fd7b0a8e1954b21dac5c8
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| d6bc96dbc71d2657815deb2cd44780da99ea3f1f |
|
14-Jan-2016 |
Matt Wu <mattwu@google.com> |
Set WindowSession's touchmode when in local focus mode,
since relayout window can query window manager for isInTouchMode().
Bug:24848552
Change-Id: Icda267d617c09dfd2b22af4019b8313181c4c661
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 75e097965cc273d33192555b0e65de3dbc1753ce |
|
29-Jul-2015 |
Clara Bayarri <clarabayarri@google.com> |
Request Keyboard Shortcuts for SysUI Dialog via Window
Keyboard shortcuts are requested via WindowManager, and
the request pipes through to the view root and the window
callback.
Bug: 22405482
Change-Id: Ic0071e91c7b554be3ac9df71e9539ee8a60e822e
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 8c1ee9d8f5607b236b1ca0764206279ba47d843b |
|
12-Jan-2016 |
Filip Gruszczynski <gruszczy@google.com> |
Use full display size for calculating volume dialog size.
Bug: 26485500
Change-Id: I25ef29a3d611617b4dc59a315b072fafb3f3f825
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 34dab0b3d9d461d441f9c63a39565c8734620cd3 |
|
22-Dec-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Use activity dimensions instead of display to calculate dialog size.
This adjusts the code for measuring and laying out dialog windows, which
used display dimensions as a basis for calculating the dialog
dimensions. Because of this dialogs would be too large in multi window
mode, where the parent bounds are far smaller than full display. This
switches to using dimensions for configuration received from activity
manager.
Mind, this is still not working as needed, because the resources return
minimal size of the dialog as if it was displayed on a full display,
rather than within activity bounds.
The CL also introduces better logging tags in ViewRootImpl and
DecorView. These normal approach works reasonably well when there is a
single activity on the display. However, when multiple windows are
displayed, it becomes impossible to determine which view root/decor view
logged what. This adds a suffix, that allows to identify the owner.
Bug: 26251921
Change-Id: I515a1ff9a81ee5ad086773196db71915e88a25eb
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 0fe356e83ed3e92f0227313313fb5df2cf8503d7 |
|
05-Jan-2016 |
Jorim Jaggi <jjaggi@google.com> |
Fix unnecessary relayouts
Make sure mPendingBackDropFrame is always up-to-date.
Bug: 26396351
Change-Id: Icb61f3581ee75e94d45fc0f8ae0895535bb130ea
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 56cd51a70411d60fac0b3987f5c5543e6a3ea8ef |
|
19-Dec-2015 |
Jun Mukai <mukai@google.com> |
Merge "Introduce pointer capture API."
|
| db3631f8c116629d01d411188c754a3985b2c222 |
|
18-Dec-2015 |
Daniel Koulomzin <dkoulomzin@google.com> |
Merge "Making ViewRootImpl drop input events when the Activity is in ambient mode." into cw-e-dev am: cbef517d02 am: 898e330aae am: 94794af6be
am: 3f66df086a
* commit '3f66df086a210bc0dec7a0bd86081f6f79b3a712':
Making ViewRootImpl drop input events when the Activity is in ambient mode.
|
| 3f66df086a210bc0dec7a0bd86081f6f79b3a712 |
|
18-Dec-2015 |
Daniel Koulomzin <dkoulomzin@google.com> |
Merge "Making ViewRootImpl drop input events when the Activity is in ambient mode." into cw-e-dev am: cbef517d02 am: 898e330aae
am: 94794af6be
* commit '94794af6bee35c249857f0440c361d589b77aa5d':
Making ViewRootImpl drop input events when the Activity is in ambient mode.
|
| 347e5d498f4c216d588e98776a386d8bdf93d05c |
|
03-Dec-2015 |
Jun Mukai <mukai@google.com> |
Introduce pointer capture API.
This depends on I4189eb4d93f50c2865b7a325727be5ceebcc71f8 of
frameworks/native.
Bug: 5452473
Change-Id: Ie21e521f3e5c581f976dc0feb5d84bfa48b046cd
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 087ae471c209cd93a29791054e50afffcbe6ffd2 |
|
16-Dec-2015 |
Daniel Koulomzin <dkoulomzin@google.com> |
Making ViewRootImpl drop input events when the Activity is in ambient
mode.
WearableActivityController tells ViewRootImpl about ambient mode.
Bug: 25912259
Bug: 25973146
Bug: 25714113
Change-Id: Idcca2b254db3145039f50f2a7dfd38a224ec287e
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| d4eaef7f4c5a5d281de4fff272cd33e892e26264 |
|
30-Oct-2015 |
Jun Mukai <mukai@google.com> |
Make public pointer icon API with custom icons.
BUG: 25778347, 23804184
Change-Id: If138b97c750c912e9848412c27b65004899961eb
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 4610eeff9c6c4789705b6550a57333150d39e970 |
|
03-Dec-2015 |
Chet Haase <chet@google.com> |
Revert "Add support for partial view layouts"
This reverts commit c55d5072ac52cee1811b52406419228fa81119ce.
There were several bugs related to incorrect handling of various
layout issues (layout not being run on containers/views that needed
it), reverting to take another run at it outside of master.
Issue #25980198 requestLayout() sometimes doesn't result in measure/layout for view
Change-Id: Ic0e159cbcf6171652d8fd1bee9ae44a3977cea04
/frameworks/base/core/java/android/view/ViewRootImpl.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/ViewRootImpl.java
|
| ca98419f77400ba99527b7910550dd3a47b43ef2 |
|
25-Nov-2015 |
Alan Viverette <alanv@google.com> |
Avoid concurrent modification for pending partial layout views
Bug: 25871867
Change-Id: I696a441704bad65203633bd34dafc7a56162007a
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 4f639749639393791caa69a35630611b695ba255 |
|
18-Nov-2015 |
Vladislav Kaznacheev <kaznacheev@google.com> |
Implement View.updateDragShadow
The new method allows changing the drag shadow image
while the drag is in process.
It has to be called on a View in the same window (under the
same ViewRootImpl) that the view which started the drag.
Bug: 25520420
Change-Id: I57e752626a4a6a86d42c597c09dbd7ec77f42f30
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 82063913ae6d3b158cb0c599141e473b691363a8 |
|
20-Nov-2015 |
Vladislav Kaznacheev <kaznacheev@google.com> |
Implement View.cancelDragAndDrop
View.cancelDragAndDrop cancels a drag operation initiated by
View.startDragAndDrop.
It has to be called on a View in the same window (under the
same ViewRootImpl) that the view which started the drag.
Bug: 24415683
Change-Id: If9a265fd8cc4d26b207d582d0d02d5c9ae78eba1
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 87ab07e9a78c8af4d806a8b35f6d5cdf9e44b47f |
|
19-Nov-2015 |
Vladislav Kaznacheev <kaznacheev@google.com> |
Merge "Revert "Implement View.cancelDrag""
|
| 54d6b95e86e9b248dd313ab72f4db6a681480d1e |
|
19-Nov-2015 |
Vladislav Kaznacheev <kaznacheev@google.com> |
Revert "Implement View.cancelDrag"
This reverts commit 93cf731b26e2ab4db49bd80f60675b03e40512f3.
This is required because adding View.cancelDrag conflicts with existing app code.
Change-Id: I323fc5d2144266781d3168fe033c53cb5b37050e
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| c55d5072ac52cee1811b52406419228fa81119ce |
|
19-Dec-2014 |
Adam Powell <adamp@google.com> |
Add support for partial view layouts
Traditionally, when a view called requestLayout it would force
recursive requestLayout calls for all parent views up the
hierarchy. This meant that there was no way to determine at traversal
time whether a parent view itself needed layout, or if just one of its
descendants did.
Add a ViewParent method requestPartialLayoutForChild(View). This lets
a caller state that a particular child of a given parent needs a
remeasure and relayout at its current measured size and position
within that parent. This can help prevent the full-tree relayout often
caused by otherwise trivial changes. Partial layouts are processed
after any pending "full" relayout during ViewRoot traversals, but
before drawing.
Add a ViewGroup method requestLayoutForChild(View). This lets a
ViewGroup decide whether it is more appropriate to request a
traditional relayout or a partial layout for itself or just the child
that changed.
Add a ViewParent method findDependentLayoutAxes. This allows a caller
to check if the ViewParent's layout is dependent on a specific direct
child view along one or both axes. Called recursively, this can be
used to determine if a change in a child view can be isolated to a
partial layout, even if its direct parent's own layout is tied to its
other ancestors. (e.g. MATCH_PARENT, LinearLayout weights)
Implement ViewGroup#requestPartialLayoutForChild to call new
ViewParent method findDependentLayoutAxes and based on the result,
either request a full layout for itself or a partial layout for the
child in question.
Implement findDependentLayoutAxes for common framework ViewGroups. A
private implementation in ViewGroup is available for use by framework
classes that will deal with basic LayoutParams. These implementations
specifically check for derived LayoutParams classes and abort the
optimization if they find something beyond their expected parameter
types.
Change-Id: I0a1a9b79293d17d4fae8d9892b96d3586f9401ae
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 93cf731b26e2ab4db49bd80f60675b03e40512f3 |
|
06-Nov-2015 |
Vladislav Kaznacheev <kaznacheev@google.com> |
Implement View.cancelDrag
View.cancelDrag cancels a drag operation initiated by
View.startDrag.
It has to be called on a View in the same window (under the
same ViewRootImpl) that the view which started the drag.
Bug: 24415683
Change-Id: Iae5ff3534b6c747ae174f170fdd01ff4d3b1c312
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 1a4dfe593aafda057ac9cb3086b84588d88cd09f |
|
15-Nov-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Synchronize recents to freeform transition.
Recents to freeform animation must hang on the first frame and inform
Recents to hide its views. This mirrors the transition from freeform
to Recents, where the animation needs to hang on the last frame.
We need a special window flag for recents to force a redraw after the
animation launches. At this point Recents will become not visible
from the perspective of the activity manager, which would prevent
further drawing. We make recents ignore that and instead depend on
window visibility which will change after recents exit animation
finishes.
Bug: 24913782
Change-Id: Ief743b7e6fcebb3d8789d4745fb122ac607c1cf0
/frameworks/base/core/java/android/view/ViewRootImpl.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/ViewRootImpl.java
|
| 8c0886fe2e7dc97d8c3173053e773afadab1ebf3 |
|
12-Nov-2015 |
Wale Ogunwale <ogunwale@google.com> |
Merge "Avoid configuration of callback being reset after relayout." am: cbcafde45e am: 0170fb8281
am: f98a6f4101
* commit 'f98a6f41019bf41d57d0681c2e1d6859f8704091':
Avoid configuration of callback being reset after relayout.
|
| 164725c652d56e3ab04185dba6a06df351f721b8 |
|
12-Nov-2015 |
riddle_hsu <riddle_hsu@htc.com> |
Avoid configuration of callback being reset after relayout.
mPendingConfiguration is a parameter of IWindowSession.relayout.
And IWindowSession.aidl declared "out Configuration outConfig",
it will always create a new configuration for remote side to write.
If remote side does not write (WMS does not have config change),
the new default configuration will be returned.
In original code passes mPendingConfiguration to updateConfiguration
directly, then callbacks (sConfigCallbacks) receive the same
instance of mPendingConfiguration. And because the implementation
of callback may use the configuration after relayout has reset
the configuration to default, then it may have timing that results
"showing hybrid of portrait and landscape modes" which try to fix
in commit e36d6e27.
To avoid this, always create a copy to updateConfiguration.
MSG_RESIZED_REPORT from dispatchResized also did the same thing.
Related commit:
e36d6e277e49475076b7872d36ea6a5c5b996e9d
694f79b5d1196640d1beb680b7d1fc68e6e77cbd
Change-Id: Ic1abd596e384918224b3a7020583d9a04641cccc
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| d153c4f6f014ea37212cf268d9de8b6abb7240fe |
|
07-Nov-2015 |
Chong Zhang <chz@google.com> |
Fix flicker when releasing drag of divider
bug: 25564523
Change-Id: I9c19f40f27cc80b8e6e0e98a0d6455941bd624e7
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| a7262a8956ae06cb83e26b6b81f4a1ff6f40907e |
|
03-Nov-2015 |
Jorim Jaggi <jjaggi@google.com> |
Immediately start resizing when touching docked divider
Before, the surface was made full-screen only after
a certain amount of time. Now, immediately make the surface
full-screen, as soon as the divider is touched, to make
resizing much snappier.
Bug: 24507122
Change-Id: I9425785fca4e62964a959a432c80a81d346602c5
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 253a20fad8703e21c7298fe66e0f3f53d4e63c14 |
|
03-Nov-2015 |
Jorim Jaggi <jjaggi@google.com> |
Fix black holes and flickering in docked resizing
When we start a resize with the docked stack divider,
set the surface background to be full-screen, and use
the traditional surface clipping/positioning in window
manager to adjust the size. This ensures that we don't
have any black holes because of asynchronicity (except
at the very beginning, but this can be worked around
later), and the position of the right/bottom activity
is always in sync with the position of the divider.
Also fix a bug in NonClientDecorView where the first
request to draw was dropped (because the thread hasn't
started up yet), and the main thread was waiting for it
indefinitily.
Bug: 24507122
Change-Id: I623bd48d5be64fac2fba45241b84f265944d200d
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 64e516f5fa56d71bf6b5076e5620c30dc5810ba1 |
|
29-Oct-2015 |
Rob Carr <racarr@google.com> |
Sync SurfaceView position changes to parent render.
In order to provide pixel perfect movement of SurfaceViews
'within' other views (e.g. scrolling) we need to be able to
synchronize the attached (parent window) painting with the
movement of the SurfaceView (recall, SurfaceViews are positioned
behind their attached windows and the parent must render a
transparent region for the SurfaceView to appear). Provide
a new WindowManager method to reposition an attaching window
(that is to say, a window which has an attached window like
SurfaceView) and defer the transaction until the parent frame.
SurfaceView is hooked up to use this for movement. This is still
'racy' in the hardware accelerated case as the render thread
could be on either side of dequeing the frame we are working on.
Bug: 22802885
Change-Id: I025d2bdcbe15c1c11047cc0dbca2cf2b7d67c632
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 9a4450ba6c5f3fd35817685dd8b08065b08c852e |
|
27-Oct-2015 |
Keisuke Kuroyanagi <ksk@google.com> |
Add null check for MotionEvent#getDevice.
MotionEvent#getDevice can return null when the device is
unknown.
Change-Id: I902a96300307e3b2d3b324a2998e470254388e27
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 76c4a129250f7515fdbe9b25182e11b40dbf416a |
|
20-Oct-2015 |
Jun Mukai <mukai@google.com> |
Do not update pointer icon shape for HOVER_EXIT event.
EXIT event does not have to udpate the pointer icon shape, because
when it immediately moves to another window, its HOVER_ENTER will
handle the icon shape.
Also HOVER_EXIT can happen after the HOVER_ENTER of the new window,
and in that case updating pointer icon at HOVER_EXIT will overwrite
the pointer icon for the new window.
Bug: 24415739
Change-Id: I08fc72cc69bbc3a6eef36d501d93e8e9ad36df85
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 41aab00c3e762c6b648483ee7b45b162e4da7f7f |
|
02-Oct-2015 |
Jun Mukai <mukai@google.com> |
Allow changing mouse cursor for the edges of resizable window.
Bug: 23193951
Change-Id: I38662a61ff829e5b441e1c8b9f472eb0d75904e4
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 1db5397d88e722b1ab82ccb2b429ceec1179ccd8 |
|
12-Sep-2015 |
Jun Mukai <mukai@google.com> |
Allow changing mouse pointer icon for the current context.
Right now, it only supports I-beam on EditText, but further
rules will come in the future.
The png files for the icons are from chromium.
Bug: 24180385
Change-Id: I8de4ec8a5412b4830c08aa232c5083841c5c751c
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 8dbd9ad68248a921637c4b2b866e86854b5860f6 |
|
09-Oct-2015 |
Chong Zhang <chz@google.com> |
Fix missing frame or wrong frame position when resize starts
When multi-thread renderer is used, delay the report to draw to the
first doFrame in ResizeFrameThread. Otherwise we could unfreeze the
window before the frame is drawn.
Also when content draw bounds is updated for the first frame, let
content draw before ResizeFrameThread so that the bounds get applied.
bug: 24715185
Change-Id: I5485dc0be3eae24c555bcc31ee8f71523b68ca8d
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 980ee47ffe675af566da2a48b855591f26fed3e0 |
|
06-Oct-2015 |
Skuhne <skuhne@google.com> |
Resolving incorrect rendering of content while resize
The staged content bounds need to be set by the content renderer
and not by the resize thread.
Bug: 24671393
Change-Id: I8f84ec01a4ac6c1e783cc6208ca77ca6c01ba838
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| a42521ca0a537823311cec67f3c70cb546ae71db |
|
06-Oct-2015 |
Chong Zhang <chz@google.com> |
Merge "Make window callbacks non static member of ViewRootImpl"
|
| dcee1dea6bc7c5265cb4d2778bcb18724d68bfbe |
|
06-Oct-2015 |
Chong Zhang <chz@google.com> |
Make window callbacks non static member of ViewRootImpl
Move add/removeWindowCallbacks to onAttachedToWindow/onDetachedFromWindow.
There might be more than one windows in an app process, the window
callbacks need to be per window, not global.
bug: 24679461
Change-Id: I216ff27b2a41ecfe7399a8161df362bebc0ac96a
/frameworks/base/core/java/android/view/ViewRootImpl.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/core/java/android/view/ViewRootImpl.java
|
| b816087962aba0019b022303330f03b897b580ed |
|
22-Sep-2015 |
Skuhne <skuhne@google.com> |
Rendering the window frame with a second thread
Using a multi threaded render node to render the window frame
asynchronously from the application relayout.
Bug: 22527834
Bug: 24400680
Bug: 24459827
Bug: 24409773
Bug: 24537510
Change-Id: I1010fc6a8b6e38424178140afa3ca124433ab7e4
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| ed3912692f0ba8a647d795462e20fcdb67adbacb |
|
01-Sep-2015 |
Oren Blasberg <orenb@google.com> |
Make context menus show as popup menus.
This means that right-clicking/long pressing on a view that is registered for
context menu will show the context menu as a popup menu instead.
Bug: 20016398
Change-Id: I96fea60435fff2f981d288521f490f8ff24ada15
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 23d62fd37dc22247ef1b55c5b9bc58d1c307081a |
|
21-Sep-2015 |
Chong Zhang <chz@google.com> |
Do not do setSurface on window size changes
Surface should only be invalidated when surface generation changed
(which we're already doing). Window size change doesn't always imply
a surface change. During a drag-resizing action, the window size is
constantly changing but the surface remains the same. setSurface
could take 12ms+ each frame and cause frame drops.
bug: 23793966
Change-Id: Iac0456122e8916cf06b1a7a0940584ab4bf4065d
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 64bf97ad0ab52932055c007e9c15e2c2d946bcc7 |
|
18-Sep-2015 |
Alan Viverette <alanv@google.com> |
Send WINDOW_STATE_CHANGE when window becomes visible or gains focus
Previously we would only send STATE_CHANGE events when the window was
added and then received input focus.
Bug: 23974711
Change-Id: Ic25ed64e024f69818c34574d7f57413699088d99
/frameworks/base/core/java/android/view/ViewRootImpl.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/ViewRootImpl.java
|
| 73f6d605436280be1f5900e887c56df2756dde9f |
|
14-Sep-2015 |
Alan Viverette <alanv@google.com> |
Include window type in relevant BadTokenExceptions
Bug: 23980921
Change-Id: Idb0f2d1fd0fd0c8525c6566c538c4cc6b5bb148b
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| bea0c7daa6611d8b96e1271f8854f500a87342fc |
|
01-Sep-2015 |
Alan Viverette <alanv@google.com> |
Keep local run queue in View to avoid posting to wrong thread
Previously any call to post() while a view was detached would stash the
runnable on a thread-local RunQueue. If the post() call happened off the
UI thread to which the view would later be attached, this would result
in the runnable either failing to run or running on some other UI thread.
Bug: 22828132
Change-Id: I5289ee91ea4b56c45f003a387a9f7f0e6dc050f9
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 762320e7d1605372b8f662a69b04d06b93ee86f4 |
|
28-Aug-2015 |
Jorim Jaggi <jjaggi@google.com> |
am f757bed7: am 7b933895: am e3238e53: am b774e554: Optimize fp touch to wake: Shortcut for report next draw
* commit 'f757bed7f7fa72528ab2d7225139d9d6f3b1021a':
Optimize fp touch to wake: Shortcut for report next draw
|
| b774e554f32fd65cac30b43d1cf679403ef4af82 |
|
24-Aug-2015 |
Jorim Jaggi <jjaggi@google.com> |
Optimize fp touch to wake: Shortcut for report next draw
When telling window manager that Keyguard window is in the correct
state for a fp-touch-to-wake sequence, it takes more than 1 frame at
the moment because the signal that WM is waiting for the next draw
is delayed by one frame because it is posted at the end of the
runnable queue.
To correctly fix this, we should post it at the beginning at the
queue, but this is way too risky this late. Instead, add a isolated
SysUI hack to report it faster.
Bug: 23401557
Change-Id: Icf64101e27611c7c01d108123021b22186f1e70c
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| e248bd1b2c3fcf8088429507e73b31f45ee2544b |
|
05-Aug-2015 |
John Reck <jreck@google.com> |
Serializing display lists
This is a WIP prototype
Change-Id: Id4bfcf2b7bf905221c3734b7b6887c9b2efd37e6
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 932cc254161c8001244f3f01728faab71c0dfba9 |
|
04-Aug-2015 |
Yohei Yukawa <yukawa@google.com> |
am 94381db0: am f4b8c343: am 9aebdb4c: am d7d14033: am 2d34a8b7: Merge "Revert "Do not forceLayout when window is resized"" into mnc-dev
* commit '94381db0dd29bcb7d6bf1f266644c7032b2bffcb':
Revert "Do not forceLayout when window is resized"
|
| 2d34a8b7181635c0ff0b1f2390d70e3ac6960f00 |
|
04-Aug-2015 |
Yohei Yukawa <yukawa@google.com> |
Merge "Revert "Do not forceLayout when window is resized"" into mnc-dev
|
| f6f1a7ec9935c32e6c1155333de94ac9cd544442 |
|
01-Aug-2015 |
Dianne Hackborn <hackbod@google.com> |
am 628b4125: am bc2a8843: am b97c5ddd: am 9b36f526: am c1836bb0: Merge "Change MNC codename to just M." into mnc-dev
* commit '628b4125843b93dc7f3ed0c9bbea76ff470d2eed':
Change MNC codename to just M.
|
| 0e3de6cacaffcfeda4d6353be61e2f1f9ed80705 |
|
30-Jul-2015 |
Dianne Hackborn <hackbod@google.com> |
Change MNC codename to just M.
Change-Id: I4281d200ff6560791c47cf9073ceea1cb509361e
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| d2e5647681fd09f6ceedd016a554148fe1f087c5 |
|
29-Jul-2015 |
Yohei Yukawa <yukawa@google.com> |
Revert "Do not forceLayout when window is resized"
This reverts commit I1e9ef807094b1e0afb32d13fd68b67c3957b15c3,
since it causes a layout jank in Voice IME.
Bug: 18573811
Bug: 22390291
Change-Id: Iaeb1e463d6f316df7bf214ac9439d4230dcac114
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| d261e8360370f72e2272dcd0a6bd2c86460439a8 |
|
28-Jul-2015 |
Filip Gruszczynski <gruszczy@google.com> |
am 6a5791d1: am 95275dc7: am 5a8e31ef: am 3bb0bb3a: am f63800dd: Merge "Remove unnecessary relayout call from traversals." into mnc-dev
* commit '6a5791d163e9f8dab1efb3e2a713ee521c347b32':
Remove unnecessary relayout call from traversals.
|
| 9b621a72e2f74fecc1b9b6f8b8d766561e067843 |
|
27-Jul-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Remove unnecessary relayout call from traversals.
All the necessary information (most importantly outsets) arrives in
addWindowToDisplay that is happening a few lines earlier.
Bug: 22073222
Change-Id: I483e98808877f32812c0e959cdfc14b4e0ca5e62
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 8d94835b4901fb01804bee3a1be8d05dbf510f65 |
|
16-Jul-2015 |
Derek Sollenberger <djsollen@google.com> |
Remove unused HardwareLayer and associated code for generic views.
bug: 20461288
Change-Id: I4efa9e31a42682a8a90438d52c9c665a582f950c
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 6ef57e974144e05e83ee1bd00f705f0f409f48b3 |
|
07-Jul-2015 |
Chris Craik <ccraik@google.com> |
Merge "Don't update DisplayLists when dumping" into mnc-dev
|
| 356b5fe0864b15365e2690605abee342989cbab0 |
|
07-Jul-2015 |
Chris Craik <ccraik@google.com> |
Don't update DisplayLists when dumping
bug:22234438
Updating the displaylist is invalid since this debug method isn't
called on the UI thread, and it defeats the purpose of seeing what
the hierarchy is currently rendering.
Change-Id: I10c5cc6dbae8d304559dfc6e863b0ede158d554f
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| c5af4f8421926ea17cf51a9a53f91f5fec467588 |
|
02-Jul-2015 |
Jorim Jaggi <jjaggi@google.com> |
Don't prevent windows from drawing when they are just moving
Bug: 21292010
Change-Id: I0cf459d75e9749afa58a4b8649457b3908c8adeb
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 2987f616faca534a792686a53304c9932634310c |
|
01-Jul-2015 |
Filip Gruszczynski <gruszczy@google.com> |
resolved conflicts for merge of 300ccf4a to mnc-dev
Change-Id: Ia315e314bfde0c066a2c25d93f8cbdc71fee0a14
|
| 0ec1328f85a08a610868856c688ebb8196c79c17 |
|
25-Jun-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Calculate outset hint when adding window.
Outsets aren't dynamic so they are a great candidate for a hint when the
window is added through the window manager. Thanks to this during first
view hierarchy measure or wallpaper window layout they are immediately
available and don't require multiple measure/layout passes.
Bug: 21593814
Change-Id: I573c15ffbbe4fcd8a6ed9c5e4fcd6cfbbcd7434f
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| ece0f4f5198e9e9cb60e96f036baf22c73411bec |
|
11-Jun-2015 |
Dianne Hackborn <hackbod@google.com> |
Fix APIs.
Issue #21039494: API Review: android.os.PowerManager.isDeviceIdleMode()
Issue #21347000: API Review: android.content.IntentFilter
Issue #20654534: API Review: android.app.assist
Also allow use of ActivityManager.setWatchHeapLimit on any platform
build as long as the calling app is debuggable.
Change-Id: Ic597e596fa772fcdf2553b64f444b3d9269e8b92
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| e22c59b2913578c24e86673576d009d34306f6be |
|
22-May-2015 |
Chris Craik <ccraik@google.com> |
Trace each stage of Choreographer driven frames
bug:21374535
Change-Id: I332dac216defbc4517441e2a9cdffdf71731f1e6
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 99bcc3eee23ed8bd15bd108d068d6f9f694e4393 |
|
01-Jun-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Merge "Revert "Revert "resolved conflicts for merge of 47249f2a to mnc-dev""" into mnc-dev
|
| 9607fbe9d70dd350e5f4a5f3862fa95816780c94 |
|
29-May-2015 |
Doris Liu <tianliu@google.com> |
Fix calls to Rect.intersect() in package android.view
This CL checks for the return value for Rect.intersect() for whether
there is actually an intersection before taking the return intersected
rect. In the case of no intersection (Rect.intersect() returns false),
an empty rect will be used as the intersection.
bug: 7368679
Change-Id: Ib874345210c8f62550627544d717e958d46cfe13
/frameworks/base/core/java/android/view/ViewRootImpl.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/core/java/android/view/ViewRootImpl.java
|
| 2232adddc56bb8764a95bbde0c05e0f02f6a1db5 |
|
27-May-2015 |
Alan Viverette <alanv@google.com> |
Offset accessibility focus rect for view root's scrollY
Previously we were only partially transforming the focus rect into
window coordinates, so it was offset when the window was panned (for
example, when the IME was showing).
Bug: 20113389
Change-Id: I41f5ed20cb1404232b7042d37ca2fc725f9ee476
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 75a857cec5f3500954a76f251e81535378ba293a |
|
26-May-2015 |
Alan Viverette <alanv@google.com> |
Merge "Handle error states when refreshing accessibility node" into mnc-dev
|
| 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/core/java/android/view/ViewRootImpl.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/core/java/android/view/ViewRootImpl.java
|
| 97bf518f7b818d297a500204627d1ad06127bff1 |
|
20-May-2015 |
John Reck <jreck@google.com> |
Merge "Reduce wasted buffer allocations" into mnc-dev
|
| 63005e6e5b1ee6d32a217ce8b4d8f0d13987fc39 |
|
20-May-2015 |
John Reck <jreck@google.com> |
Reduce wasted buffer allocations
Bug: 20170924
Don't pre-allocate buffers if there is a SurfaceView or other
View that has requested transparent regions. This doesn't fully
address the problem of allocating buffers when there's a full
screen SurfaceView but it at least gets back to KitKat levels
of only having 1 wasted buffer instead of 3 (the 1 being
a result of the fact that it will still draw one frame of emptiness
forcing a buffer dequeue).
Change-Id: Ied9553186bc7b111d180b63f87b92bd317cb4b97
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 25acc7e78c5d981da6565399df4fad7bced4de76 |
|
19-May-2015 |
Alan Viverette <alanv@google.com> |
Handle error states when refreshing accessibility node
Bug: 21281869
Change-Id: Idce90f5e23b102b9c66f288906eedb5b6a5b098d
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| c2cc6fff1bac2afd73840b64976b146bdcd4435c |
|
19-May-2015 |
Yohei Yukawa <yukawa@google.com> |
Merge "Keep IMM#mCurRootView synchronized with the actual window focus." into mnc-dev
|
| 01f280d376218c5a007fc29f70b876375ad24204 |
|
19-May-2015 |
Adam Powell <adamp@google.com> |
Migrate uses of config_windowIsRound to Configuration.isScreenRound
Move existing code that previously relied on config_windowIsRound to
use the new Configuration.isScreenRound() method. Also move the system
property override for emulators over to the initial setup of a Display
so that the configuration property is consistent with existing
expectations.
Remove config_windowIsRound from symbols.xml. The symbol now only
exists as a default value redirect for overlays already configured to
supply this value.
Change-Id: I24e6564030a6051c3ac7262868983b43e13eee65
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 2a576d9ec1ec353ee2278f2da01e685b6b7b24ee |
|
15-May-2015 |
Alan Viverette <alanv@google.com> |
Merge "Invalidate old accessibility bounds on CONTENT_CHANGE" into mnc-dev
|
| 2cc4a4755fcd41900e042c75cc47879d46acecda |
|
15-May-2015 |
Alan Viverette <alanv@google.com> |
Merge "Adjust light source for window position" into mnc-dev
|
| a7ea65e239581c84c3ae80f42f5a1827d48fc876 |
|
15-May-2015 |
Alan Viverette <alanv@google.com> |
Invalidate old accessibility bounds on CONTENT_CHANGE
Bug: 20950124
Change-Id: Id19924358b538f9b7754de3a0c019433817dc1fc
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 5f05965f546fa42750f1a8314f8a2da01fd6bfb4 |
|
15-May-2015 |
Yohei Yukawa <yukawa@google.com> |
Keep IMM#mCurRootView synchronized with the actual window focus.
Currently IMM#mCurRootView is always cleared every time when
IMM#finishInputLocked() is called. We have been doing this since
Iad09cf5dbb7f6f156fd39ed243431432e00f8945 so as not to hold the
strong reference to a DecorView so long time (Bug 6413553).
Strictly speaking, the attached window may continue holding
input focus even after IMM#finishInputLocked() is called.
In this state IMM#focusIn() might have unexpectedly rejected
focus-in event but presumably this might not be obvious, or might
not occur at all because in some situations IMM#finishInputLocked()
has never been called even when the attached view loses input
focus.
In order to fix Issue 20820914, however, we need to call
IMM#finishInputLocked() exactly when the attached view loses
input focus. To make it easier to diagnose any unexpected
regressions, this CL only changes the handling of
IMM#mCurRootView, while the next CL Id6afc8fc64512225578c62557b96
plumbs IMM#focusOut() to IMM#finishInputLocked().
Manually tested following scenarios.
- Repro steps in Bug 6413553. Made sure that IMM#mCurRootView
is cleared after switching back from the current application to
the previous application with back key.
- Test application that calls WebView#showFindDialog(). Made sure
that LatinIME works fine when switching text fields. This is
non-trivial because android.webkit.FindActionModeCallback is
changed in this CL.
- Repro steps in Bug 21144633. Made sure that we can enter
recipient's name in the messaging app.
Bug: 20820914
Change-Id: I219394178e4172bc47864297f1418e677dba25e5
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 50210d912925aef14e4ce69be82e4949122a3cd9 |
|
15-May-2015 |
Alan Viverette <alanv@google.com> |
Adjust light source for window position
Bug: 16523629
Change-Id: I2f3fed1edcac0a3cfd5034aded45e08ececfebaf
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 159c3d8a8b99c9a7c9d7cb3013a622fdf2c6c04a |
|
14-May-2015 |
Wale Ogunwale <ogunwale@google.com> |
Revert "Update IME focus when the active view is losing the focus."
This reverts commit 97c381304207013fd95c7806df4dcca0c69006c0.
This causes issue with the right IME window getting focus.
Bug: 21144633
Change-Id: I4c75b6e7dd87c10f008444d2059164b52a8f4335
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 1b2e5c11b6a89d56d5058907c3b0c88bf0170857 |
|
14-May-2015 |
Michael Wright <michaelwr@google.com> |
Merge "Revert "Revert "Add new MotionEvent actions for button press and release.""" into mnc-dev
|
| 5bd69e6e6164c59a0423edd0d5243fc8c07e6af3 |
|
14-May-2015 |
Michael Wright <michaelwr@google.com> |
Revert "Revert "Add new MotionEvent actions for button press and release.""
This reverts commit 96238051621ba2dc8a1c20fa48a00ec6ec4735d6.
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 3d5286983447262f12b78785391681b20a71f6b2 |
|
14-May-2015 |
Michael Wright <michaelwr@google.com> |
Merge "Revert "Add new MotionEvent actions for button press and release."" into mnc-dev
|
| 96238051621ba2dc8a1c20fa48a00ec6ec4735d6 |
|
14-May-2015 |
Michael Wright <michaelwr@google.com> |
Revert "Add new MotionEvent actions for button press and release."
This reverts commit ec0ce51b733f10c620cb9447b074f022d042e31d.
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 07b83f1c9e8a7692a985aa2d13ac13fc5521aa4b |
|
14-May-2015 |
Michael Wright <michaelwr@google.com> |
Merge "Add new MotionEvent actions for button press and release." into mnc-dev
|
| ec0ce51b733f10c620cb9447b074f022d042e31d |
|
08-May-2015 |
Michael Wright <michaelwr@google.com> |
Add new MotionEvent actions for button press and release.
Introduce ACTION_BUTTON_PRESS and ACTION_BUTTON_RELEASE as actions to
signal a button press or release. If these actions happen
simulanteously with a DOWN or UP event then they're explicitly
ordered to happen after the DOWN or preceding the UP in order to send
them to the most recently targeted view.
Also, introduce new stylus button constants that differ from the
constants we use for mouse buttons.
Bug: 20704355
Change-Id: I5b75e5c5e692171c1c117ee687dd185a0d9dd15c
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 951f23478d79fb232e93a750d9050adce7a67874 |
|
14-May-2015 |
John Reck <jreck@google.com> |
am d955dceb: am 862540cd: Merge "Revert "DO NOT MERGE Backport of limited jank-tracking metrics"" into lmp-mr1-dev
* commit 'd955dceb4f38f214e62024e808b2b1a21be41940':
Revert "DO NOT MERGE Backport of limited jank-tracking metrics"
|
| 645edef4834c2911386b659cc775840fb7479e01 |
|
14-May-2015 |
Jorim Jaggi <jjaggi@google.com> |
Merge "Make sure the app can draw a frame before unlocking" into mnc-dev
|
| 5ad7fe4930b5566836debffc8976802c186b6ee3 |
|
14-May-2015 |
Yohei Yukawa <yukawa@google.com> |
Merge "Update IME focus when the active view is losing the focus." into mnc-dev
|
| e869835d6a884434842838fce6d17c770fa1ef8b |
|
14-May-2015 |
John Reck <jreck@google.com> |
am a5b28b92: am 69355eaa: Merge "DO NOT MERGE Backport of limited jank-tracking metrics" into lmp-mr1-dev
* commit 'a5b28b92b14d0949d43be6198fedc31872ad07f6':
DO NOT MERGE Backport of limited jank-tracking metrics
|
| 25607a6642d7c8bb134c7576e11bd79b5c4d233d |
|
13-May-2015 |
John Reck <jreck@google.com> |
Revert "DO NOT MERGE Backport of limited jank-tracking metrics"
This reverts commit 2614bd225f84f7a23e6b30fc6b47bede153e5f4c.
Change-Id: I344b4cbaa0bb0caf50bceb806d1446ee27ea52d8
/frameworks/base/core/java/android/view/ViewRootImpl.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/ViewRootImpl.java
|
| 97c381304207013fd95c7806df4dcca0c69006c0 |
|
12-May-2015 |
Yohei Yukawa <yukawa@google.com> |
Update IME focus when the active view is losing the focus.
Despite the fact that IMM#focusOut() are called from many focus
mangement logics, the reality is that IMM#focusOut() has done
nothing more than 6 years. This would not a big problem as long
as IMM#focusIn() is called immediately after IMM#focusOut().
However, situations where only IMM#focusOut() is called,
following fields continue keeping object references.
- IMM#mServedView
- IMM#mNextServedView
- IMM#mServedInputConnection
- IMM#mServedInputConnectionWrapper
Even worse, if the IME is showing software keyboard, it will not
be dismissed.
With this CL, IMM#focusOut() starts cleaning up the active IME
session when the associated view loses focus.
This CL also removes IMM#mCurRootView because it is indeed
necessary for above change. The problem when only introducing
above change can be understood as follows.
1. IMM#mCurRootView is correctly set from ViewRootImpl.
2. IMM#focusIn() is called. InputConnection is established.
3. IMM#focusOut() is called, which triggers
IMM#finishInputLocked() because of above change, which
internally clears IMM#mCurRootView.
4. IMM#focusIn() is called but IMM#mCurRootView is still null.
Because of this the focus-in event is ignored and the
software keyboard does not show up anymore.
In this CL, we simply check view.hasWindowFocus() instead.
As far as I've tested, this change looks to be working well.
Bug: 20820914
Change-Id: Ib4bd70ce0305a6bde6a929bcc6ad20a2b8402a97
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 3dec0d47215b56e3bd3e6f3287cf2c966bf8c22f |
|
11-May-2015 |
George Mount <mount@google.com> |
Merge "Disable input during Activity Transition." into mnc-dev
|
| ed9af066b2407a36699fae2e475c4d1b53d2ca1d |
|
08-May-2015 |
Dianne Hackborn <hackbod@google.com> |
Merge "Fix issue #20655182: API Review: ViewAssistStructure" into mnc-dev
|
| 49b043f37d7231b1544cb72e1bfb616e5a00688d |
|
07-May-2015 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #20655182: API Review: ViewAssistStructure
Fix the various view assist related APIs.
Also remove the blockAssist view attribute, and instead use
the window's FLAG_SECURE to drive blocking of the entire
hierarchy (which is semantically correct, and will protect
existing apps that have already indicated they need it).
Change-Id: I6beebc86b202809cba0a356cae9607d8d0fb5e78
/frameworks/base/core/java/android/view/ViewRootImpl.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/ViewRootImpl.java
|
| 6711f3b34c2ad9c622f56a08b81e313795fe7647 |
|
07-May-2015 |
Adam Powell <adamp@google.com> |
Move PhoneWindow and friends back into internal package
PhoneWindow, PhoneLayoutInflater and PhoneFallbackEventHandler decided
to @hide out over in the android.view package after the policy jar was
disbanded. Give them a more appropriate home over in framework that
doesn't imply that they should be accessed from other internal layers
of abstraction.
Bug 19606548
Change-Id: Id07b791d178fa447010b49b24726b52208838e88
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 31a2d063df5111e730abe7d07be064690deedc34 |
|
01-May-2015 |
Chris Craik <ccraik@google.com> |
Revert "Revert "Merge getDisplayList and updateDisplayListIfDirty""
Fixes breakage from HwAccelerationTest
This reverts commit b2847afde24aac22c8fb804cdce0c24b8a7c40c4.
Change-Id: I762b3c9020fc1d06bac61ffa8b956049147515b1
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| b2847afde24aac22c8fb804cdce0c24b8a7c40c4 |
|
01-May-2015 |
Chris Craik <ccraik@google.com> |
Fix build.
Revert "Merge getDisplayList and updateDisplayListIfDirty"
This reverts commit f85d064b536d9b2028a83e21d98eac9b40b74e95.
Change-Id: I8b1566aba67c385d72759ea2aea16edcd8477813
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| f85d064b536d9b2028a83e21d98eac9b40b74e95 |
|
01-May-2015 |
Chris Craik <ccraik@google.com> |
Merge getDisplayList and updateDisplayListIfDirty
bug:17767704
Change-Id: I5dffc0fa343d5d67d5fe59c78eca77bb8645ce0e
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 34457f51e0a19555a7b9c6df6803ee1aa04c51b8 |
|
25-Mar-2015 |
Alan Viverette <alanv@google.com> |
Fix ViewRootImpl handling of content changes, fix ViewPager parenting
Previously content changes were only handled if they came directly from
the focused host, which meant that changes that occurred higher in the
tree were ignored. As a result, scrolling in ViewPager that contained
virtual nodes would fail to update the focus position.
Change-Id: I028bd8c670f1210339da331626e1986c5b5d4b87
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| b4f01b966bd2ebf89623f9c65462b8b8b7034461 |
|
24-Mar-2015 |
John Spurlock <jspurlock@google.com> |
Remove the ability to disable audio service.
Running in a configuration without audio service is not fully tested.
Remove the configuration option for now. Also remove unused delegation
layer in SoundPool.
Bug: 19891112
Change-Id: I47be0e32d54b8ef8fa25cf47b85eacf8a4969500
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| daf5c0ebd0aa4f73fcf2c9fecd8ce9d36e3db4fc |
|
24-Mar-2015 |
Griff Hazen <griff@google.com> |
Merge commit '583c7c56' into master
Change-Id: I89c2c63005fbb6b1c058b2022f4469be5244505f
|
| 43c410eaacf7d287c6c3f5621e6e0b96501004dc |
|
18-Mar-2015 |
Chris Craik <ccraik@google.com> |
Merge "Remove HardwareCanvas"
|
| 2614bd225f84f7a23e6b30fc6b47bede153e5f4c |
|
19-Feb-2015 |
John Reck <jreck@google.com> |
DO NOT MERGE Backport of limited jank-tracking metrics
Bug: 19821830
Cherry-pick of ba6adf66d3c44c0aa2fd8a224862ff1901d64300
Cherry-pick of e70c5754d01f2ab0ff47ea3eabaa88aca5ed2a36
Change-Id: Id342fa0ab345f204bec58acf45ce72f6de950cfb
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| a0938021718867edd267d4905f3c17ef2944aa65 |
|
13-Mar-2015 |
Griff Hazen <griff@google.com> |
Allow emulator to select a window outset bottom
And clean up some copied around code.
Bug: 17440607
Change-Id: I5cf9c58b49110c4be1a77dc9c410fedc6b99aef3
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 4423d91de5300d3fd318bf5bc2d4d7e5bb856abf |
|
02-Mar-2015 |
Clara Bayarri <clarabayarri@google.com> |
Add a type parameter to startActionMode() calls.
This requires adding a new method to View and Window.Callback to pass
down the type as a parameter.
For compatibility purposes, the new method implementations keep the
type and call the old method, in case clients have subclassed it.
Change-Id: If5d857f131e33be8cc6a8814f2e9c4e85ad2da25
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| c6ee744a90a4a84df93b6631ca7df8736ef320e1 |
|
12-Mar-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Merge "Allow polling for WindowInsets."
|
| 3d4e7efe37a4b0dfc5807444e8c3b98a28953377 |
|
27-Feb-2015 |
Jeff Brown <jeffbrown@google.com> |
Move sync barrier methods into MessageQueue.
The methods were previously defined on Looper but on reflection
they actually make more sense on the MessageQueue instead since
the Looper class is primarily concerned with thread lifecycle
rather than the actual messages themselves.
Change-Id: Iff356b94754fc9960774fa17e3eec9604229cba6
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 954289d9a9b1a26b1621037a427269bdbd67d5bc |
|
27-Feb-2015 |
Filip Gruszczynski <gruszczy@google.com> |
Allow polling for WindowInsets.
Change-Id: I36feb2403b1bcf6de5d8808734c46999a38e7403
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| f6829a0a618b4523619ec53c996b04d67e3186b9 |
|
10-Mar-2015 |
Chris Craik <ccraik@google.com> |
Remove HardwareCanvas
Change-Id: I239646a7f00f09d3f76fe6b6162eed86bc0d6e77
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 08c7116ab9cd04ad6dd3c04aa1017237e7f409ac |
|
28-Feb-2015 |
John Spurlock <jspurlock@google.com> |
Remove unused imports in frameworks/base.
Change-Id: I031443de83f93eb57a98863001826671b18f3b17
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| df4943d5e08360223e2b8c16d4b578a229cad411 |
|
24-Feb-2015 |
Jorim Jaggi <jjaggi@google.com> |
Merge "Do not forceLayout when window is resized"
|
| 1fb55286438967f82e305a8449c0528a7cd07fce |
|
24-Feb-2015 |
Chad Jones <chadj@google.com> |
resolved conflicts for merge of 57bb5f5c to master
Change-Id: Id5dfe7fc919305658312771a031c0764cef5515c
|
| c2932a1be3e320679034212698aff376d5104dbe |
|
21-Nov-2014 |
Jeff Brown <jeffbrown@google.com> |
Hold a wake lock while dozing when display updates are pending.
When the display state is DOZE or DOZE_SUSPEND, assume this means
that the AP may go to sleep at any time so hold a wake lock for
a little while starting when traversals are scheduled to ensure
that the AP remains awake long enough to draw and post the frame
to the display hardware.
This patch is somewhat approximate but should be good enough for
most devices today.
Note that the implementation uses the window manager to ensure that
the window which wants to draw is actually visible before acquiring
the wake lock. There is a cost to this test (a round-trip) which
should not be significant today since we do not expect apps to draw
more than one frame or two while dozing. However, if we wanted to
support animations in general, we might want to optimize it or
eliminate the check altogether (since we can already account for
the app's use of the wake lock).
Another way to implement this functionality might be for the view
hierarchy to listen for the power manager to report that it has entered
a non-interactive power state before deciding to poke draw locks.
This would be somewhat more accurate than watching the display state.
Also, the draw lock timeout logic could be implemented more directly
instead of using an ordinary timed wake lock.
Bug: 18284212
Change-Id: I84b341c678303e8b7481bd1620e634fe82cc4350
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| df570c6e66d98536597737f863430510b6336ffe |
|
20-Feb-2015 |
John Reck <jreck@google.com> |
Merge "Initial attempt at jank-tracking stat collection"
|
| 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/ViewRootImpl.java
|
| 72d6f219438e232fcfe0b732d1adb0dbac79dbac |
|
20-Feb-2015 |
Craig Mautner <cmautner@google.com> |
Permit layout when stopped if reporting draw
When a device was woken up in a different orientation than what it
went to sleep in, the window manager would force a resize to get it to
predraw in the new orientation. The predraw was done in the old
orientation however because layouts are skipped when the activity was
stopped.
This change allows layouts to proceed when the activity is stopped if
the flag to report resize events is true.
Fixes bug 18444400.
Change-Id: Ib2def3449dd67918f6fb838bdb1fe5cc6ec57f8e
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 87a0bfdfa8184d072c86cb9183a8438f2dd4150d |
|
16-Feb-2015 |
Jorim Jaggi <jjaggi@google.com> |
Do not forceLayout when window is resized
WindowManager uses a resize message when forcing a window to be
redrawn, which then triggered a full layout pass, which is
excessive and unnecessary. A normal requestLayout() should suffice
for this case.
Bug: 18573811
Change-Id: I1e9ef807094b1e0afb32d13fd68b67c3957b15c3
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 7c72668f19d404b01412abc67937b1b5c660df71 |
|
07-Feb-2015 |
Wale Ogunwale <ogunwale@google.com> |
Adjust activity display metrics based on stack configuration.
Apps normally use context.getResources().getDisplayMetrics()
or getWindowManager().getDefaultDisplay() to get information
about the screen dimensions. Not all the screen space is available
for apps in a multi-window environment, so we limit the dimensions
of the display object exposed to the app to that of the containing
stack.
Bug: 19225079
Bug: 19354838
Change-Id: I8dc3a6c9b99ecedcca28fc4ddaba9f31feb4f871
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| b10e33ff804a831c71be9303146cea892b9aeb5d |
|
04-Feb-2015 |
Jorim Jaggi <jjaggi@google.com> |
Split up android.policy into framework.jar and services.jar 1/3
Change-Id: Ifd69f1f3dd308a7e17a1442e2f3950da8b03cec4
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| d9852a9ced736b2deb2c8842c6dc6fc59cfbab3c |
|
10-Feb-2015 |
Svetoslav <svetoslavganov@google.com> |
am cf2c8545: am 5521f39f: am c73cfa0f: Accessibiltiy: missed update to the previous patch.
automerge: c052b0e
* commit 'c052b0efcef4c8656a972155c6a88135f79ed808':
Accessibiltiy: missed update to the previous patch.
|
| c73cfa0ffba344a83d61e2f4eb9715152a2807b8 |
|
10-Feb-2015 |
Svetoslav <svetoslavganov@google.com> |
Accessibiltiy: missed update to the previous patch.
Change-Id: I4c47d38f5e137dcc1c6db0561b3824a26572027d
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| c66ee745dc84699a25be53b8ce7a41c56aa5031d |
|
10-Feb-2015 |
Baligh Uddin <baligh@google.com> |
am 2083173a: am fbf9666f: am b2ba6dfc: Merge "Accessibility: Handle a missed case when clicking focused views." into lmp-mr1-dev
automerge: a314754
* commit 'a3147545751266f3e58fdadffc4f71e87228c420':
Accessibility: Handle a missed case when clicking focused views.
|
| f33fe1f4860d4cbc49633162cf6441d315550cc9 |
|
07-Feb-2015 |
Svet Ganov <svetoslavganov@google.com> |
Accessibility: Handle a missed case when clicking focused views.
The special logic for clicking on views in accessibility mode should not
prevent event interception and if a view interceptes the gesture we must
clear the special flag and do normal event dispatch. Also once we have a
view handling the touch gesture we do not need the special flag as we
know what will handle the event. This tightly follows standard event
dispatching.
bug:19252492
Change-Id: I0c9764c5050ec73f5f7980f3f0340dd9509a725a
/frameworks/base/core/java/android/view/ViewRootImpl.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/ViewRootImpl.java
|
| 7e760ee59d77f0e8cbdd4c64c1d4bf0b89113878 |
|
03-Feb-2015 |
Svetoslav <svetoslavganov@google.com> |
Fix broken activation of the selected view in accessibility mode. automerge: ded133c automerge: b6b526e
automerge: f8acd7a
* commit 'f8acd7a961f3a36712519d0f925f86f3da8d0b7c':
Fix broken activation of the selected view in accessibility mode.
|
| ded133c446fa9d0d23e6bde19a66fb2ce3980491 |
|
31-Jan-2015 |
Svetoslav <svetoslavganov@google.com> |
Fix broken activation of the selected view in accessibility mode.
We were using an approximation to determine where to send a pair of down
and up events to click on the view that has accessibility focus. We were
doing reverse computation to figuring out which portion of the view is
not covered by interactive views and get a point in this region. However,
determining whether a view is interactive is not feasible in general since
for example may override onTouchEvent. This results in views not being
activated or which is worse wrong views being activated.
This change swithes to a new approach to activate views in accessibility
mode which is guaranteed to always work except the very rare case of a
view that overrides dispatchTouchEvent (which developers shouldn't be
doing). The new approach is to flag the down and up events pair sent
by the touch explorer as targeting the accessibility focused view. Such
events are dispatched such that views predecessors of the accessibility
focus do not handle them guaranteeing that these events reach the accessibiliy
focused view. Once the accessibiliy focused view gets such an event it clears
the flag and the event is dispatched following the normal event dispatch
semantics.
The new approach is semantically equivalent to requesting the view to perform
a click accessiblitiy action but is more generic as it is not affected by
views not implementing click action support correctly.
bug:18986806
bug:18889611
Change-Id: Id4b7b886c9fd34f7eb11e606636d8e3bab122869
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| b59041595b08a7aca8d425fc6e6b16583a275f12 |
|
30-Jan-2015 |
Alan Viverette <alanv@google.com> |
Merge "Add transition support to PopupWindow"
|
| 5435a30ae552391f14009c4459731ae149675b18 |
|
29-Jan-2015 |
Alan Viverette <alanv@google.com> |
Add transition support to PopupWindow
Allows framework-added windows to manually specify surface insets, which
enables us to wrap the popup window's elevated content view with a root
view, which in turn allows us to use the Transition API for popup window
transitions.
Fixes a bug where the root view's render node forced clipping.
Bug: 13211166
Change-Id: I303dfa55a052cdf5d3b1485422529123e3cc867a
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 7dbc3bfdd9447a0ebbcce4e3acdae7d8047e67de |
|
29-Jan-2015 |
Alan Viverette <alanv@google.com> |
Clear accessibility focus when the window loses visibility
AccessibilityInteractionController checks window visibility during focus
search and when performing an action, which prevents the framework from
clearing focus when windows lose visibility. This change ensures that
focus will already have been cleared, which matches the behavior of the
other properties checked during focus search (view detachment and view
visibility).
Bug: 19169643
Change-Id: I795ed27ce8dfb7ecb1462943c81c5b14973a8d7a
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 69c22e82e9c3e95f4689a57320de3199ffd29262 |
|
13-Jan-2015 |
Adam Powell <adamp@google.com> |
Merge "Add API for nested pre-processing of a11y events; fix ResolverDrawerLayout" into lmp-mr1-dev
|
| 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/ViewRootImpl.java
|
| b6ab098bad4b126eaaaa3aaa5a512fefc4e0749b |
|
08-Jan-2015 |
Adam Powell <adamp@google.com> |
Add API for nested pre-processing of a11y events; fix ResolverDrawerLayout
Add API for handling nested pre-processing of accessibility events
similar to nested pre-scroll or pre-fling. This allows custom views to
delegate a nested scroll to a parent via the accessibility system.
Use this functionality to allow opening the ResolverDrawerLayout via
accessibility commands.
Bug 18827274
Change-Id: Icd5a502605b78a861bb03e7b11923841a72eb9ab
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 01a5ea35fbba4c5bb1d7790ae1677a2fa752e042 |
|
03-Dec-2014 |
John Reck <jreck@google.com> |
Resume RT-animations after a pauseSurface
Bug: 18203577
The issue occurs as a result of performTraversals() both doing
a window relayout call *and* early-returning because it's not dirty.
To fix this pauseSurface() returns whether or not the RT-side is
"dirty" to force ViewRootImpl to do a draw even if mDirty is
otherwise empty.
Change-Id: I534f367e75d18d273ebf14df3927f5c464ef6bef
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| b13de07f0b26953115f4315bc7417ca87c70594b |
|
20-Nov-2014 |
John Reck <jreck@google.com> |
If the surface is lost, release it
Bug: 18403246
Surface#isValid() is used throughout ViewRootImpl to
determine Surface validity. However, this will return true
until Surface#release() is called, even if the underlying
BufferQueue is abandoned. We have a very strong signal
from EGL that the Surface is now dead, so use that signal
to call Surface#release() so ViewRootImpl's isValid() usage
will be valid.
Change-Id: Ib355560ef4ca7625c3c784174863d2d55267d93d
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| c3672cd3f7e2bd87d6de9dada499de82b62fae84 |
|
06-Nov-2014 |
Wale Ogunwale <ogunwale@google.com> |
Cancel or drop key events if activity is stopped.
After an activity instance state is saved due to onStop()/onPause(),
there is a small window where it can still get key events like the
back button since we still allow the ActivityThread to handle
pending messages (like memory trim request) before informing the
activity manager that we are done. If the activity is stopped,
we will now drop non-terminal input events and set the cancel
flag on terminal events.
Bug: 18151331
Change-Id: I370d7c871530eea4b16fa42428d0248f1a87abb6
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 37d7a68de7e353c31a3a4736054cd86f0e002eaf |
|
06-Nov-2014 |
Adrian Roos <roosa@google.com> |
Fix inset hinting when adding window
Windows with FLAG_DRAWS_SYSTEM_BAR_BACKGROUNDS were
getting an incorrect content inset hint, because the
hinting didn't see the adjusted systemUiVisibility.
Also adds hinting for the stable insets.
Bug: 17508238
Change-Id: If9647277feb6811b15665b801accd896c51dbd12
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 2cd23e6b9d8fcdf5dfd052fb2ed0cd80f1d278ba |
|
05-Nov-2014 |
Alan Viverette <alanv@google.com> |
Fix hasSurfaceInsets check when creating hardware renderer
BUG: 17729606
Change-Id: I8c7092428b790e0ff3bbf84b64ba385ef2b2f521
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 93cad8c4d41f2256d0bfaa455686acf8442d97ff |
|
04-Nov-2014 |
Alan Viverette <alanv@google.com> |
Pass surface insets from window attributes rather than params
Params only gets set in certain situations, whereas the actual window
attributes always contain the correct surface insets.
BUG: 18214798
Change-Id: Ib5236ccf3f120b26c5abc8671bf29cb3dc269186
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 808fe6f99fba753e0ec4c5e90de0ff7a2140e8a6 |
|
03-Nov-2014 |
Adrian Roos <roosa@google.com> |
Merge "Fix colored status bar panning issues" into lmp-mr1-dev
|
| 159da3dba8811017c683fcee26c795be1948b0c4 |
|
30-Oct-2014 |
Craig Mautner <cmautner@google.com> |
Merge "Add enter-animation-done callback for system windows" into lmp-mr1-dev
|
| 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/core/java/android/view/ViewRootImpl.java
|
| 66c0adcfd4351518512df2f3e81526d2d67d6d65 |
|
29-Oct-2014 |
Alan Viverette <alanv@google.com> |
Merge "Ensure accessibility focus rect is drawn correctly" into lmp-mr1-dev
|
| 2b12b58f942e34e8c0cc5095cca71dbaaa029624 |
|
29-Oct-2014 |
Alan Viverette <alanv@google.com> |
Create translucent hardware renderer if surface insets are non-zero
BUG: 18160604
Change-Id: Ie4483b9841bd91778659d83b154f69e777fa1dfc
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 0e7ae4efe8f424fa1ced8f7e5f3d8ae78066592b |
|
01-Oct-2014 |
Adrian Roos <roosa@google.com> |
Fix colored status bar panning issues
Bug: 17695293
Change-Id: I6a1267f8dff27e7b78ab312a71648ef16ab9483b
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 632af849240f54f91b2b4fde77d3a51c4d045f74 |
|
28-Oct-2014 |
Alan Viverette <alanv@google.com> |
Ensure accessibility focus rect is drawn correctly
Reverts previous change that draws it as part of View.draw() and ensures
that the display is always redrawn if a view has accessibility focus.
Correctly removes focus from views with accessibility focused ancestors.
Also reverts the focus indicator to use a solid line since the dotted
line looked janky.
BUG: 17675993
Change-Id: I25718334cc1ae1c2cd19d3c23af1c18c6a67504c
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| b3ba1d4e717d6292df4273108f0da61dac4f7b10 |
|
27-Sep-2014 |
Svetoslav <svetoslavganov@google.com> |
Accessibility node provider getting invalid virtual view id.
If the virtual child id is not specified we should ask the node
provider to create a node info for the hosting view bu passing
the special host node id.
bug:17664111
Change-Id: I9c2d3195ad813eed7ea4108fe0d7ccb9cc32a1a0
/frameworks/base/core/java/android/view/ViewRootImpl.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/ViewRootImpl.java
|
| 61375a8bb5e112d4e79ee4240699ffe7e3f4c8e5 |
|
18-Sep-2014 |
John Reck <jreck@google.com> |
Revert "Make starting window hw-accelerated"
Bug: 17516789
This change corresponds to a sudden influx of bad surface crashes.
Reverting to see if stability returns as this was an optimization
CL
This reverts commit 29ff1bc57ac2c995c56f15ed6e56e5fb247b2a44.
Change-Id: I7835e89017161d94ad05fe46d81bd437c3dae3a7
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 4f52b3420684e85252a7341d906e47145855b6ec |
|
11-Sep-2014 |
Chet Haase <chet@google.com> |
Make starting window hw-accelerated
An earlier fix in L disabled hw acceleration for the starting window
after the system process became hw accelerated. This was done to preserve
the old behavior of the starting window having some default behavior
(in particular, being filled with a default color). However, this ends up
being a memory and performance problem on some platforms (memory because
some platforms have backing store for software surfaces, performance
because it takes far longer to create a screen-size software surface than
a hardware surface).
The fix is to allow the starting window to inherit the hw acceleration
behavior of its process, and to detect when we are drawing the contents
of that starting window and to fill it with a default color (black).
Issue #17443449 use hardware rendering for app preview window
Change-Id: I8be8111d9e38c51fbbc07185acca065815ce26dc
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| bb8c4834613207cf880e8491b33eb495cc268548 |
|
09-Sep-2014 |
Dianne Hackborn <hackbod@google.com> |
Merge "Add new wallpaper features for insets and offsets." into lmp-dev
|
| 067e5f68b9216b233df1c6529db182ff9b2887ab |
|
08-Sep-2014 |
Dianne Hackborn <hackbod@google.com> |
Add new wallpaper features for insets and offsets.
Issue #17394151: WallpaperService / Engines need to get notified
of WindowInsets
Issue #17394203 Wallpapers need a system API to be shifted in order
to support burn in protection
Adds a new API on WallpaperManager to set additional offsets to
make wallpapers extend beyond the display size.
Insets are now reported to wallpapers, to use as they may. This
includes information about the above offsets, so they can place
their content within the visible area. And to help with this, also
expose the stable offsets APIs in WindowInsets which is also very
useful information for the wallpaper.
Another new API on WallpaperManager to set a raw offset to apply
to the wallpaper window, forcing it to move on the screen regardless
of what the wallpaper is drawing.
Fix wallpapers when used with overscan enabled, so they still extend
out across the entire screen. Conveniently, the above new window
insets information is very useful for this case as well!
And a new wallpaper test app for all this stuff.
Change-Id: I287ee36581283dd34607609fcd3170d99d120d8e
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 7498efdc5e163d6b4a11db941c7d13c169d37284 |
|
04-Sep-2014 |
Svet Ganov <svetoslavganov@google.com> |
Clicking on partially coverd views by other views or windows.
In touch exploration mode an accessibility service can move
accessibility focus in response to user gestures. In this case
when the user double-taps the system is sending down and up
events at the center of the acessibility focused view. This
works fine until the clicked view's center is covered by another
clickable view. In such a scenario the user thinks he is clicking
on one view but the click is handled by another. Terrible.
This change solves the problem of clicking on the wrong view
and also solves the problem of clicking on the wrong window.
The key idea is that when the system detects a double tap or
a double tap and hold it asks the accessibility focused node
(if such) to compute a point at which a click can be performed.
In respinse to that the node is asking the source view to
compute this.
If a view is partially covered by siblings or siblings of
predecessors that are clickable, the click point will be
properly computed to ensure the click occurs on the desired
view. The click point is also bounded in the interactive
part of the host window.
The current approach has rare edge cases that may produce false
positives or false negatives. For example, a portion of the
view may be covered by an interactive descendant of a
predecessor, which we do not compute (we check only siblings of
predecessors). Also a view may be handling raw touch events
instead of registering click listeners, which we cannot compute.
Despite these limitations this approach will work most of the
time and it is a huge improvement over just blindly sending
the down and up events in the center of the view.
Note that the additional computational complexity is incurred
only when the user wants to click on the accessibility focused
view which is very a rare event and this is a good tradeoff.
bug:15696993
Change-Id: I85927a77d6c24f7550b0d5f9f762722a8230830f
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| f0c758be0d27910d026bee176eef9434c15fc3cd |
|
04-Sep-2014 |
Svetoslav <svetoslavganov@google.com> |
Update accessibility focused virtual view bounds.
We keep track of the accessibility focused virtual view in order to
draw the accessibility focus highlight. We were not updating this
virtual view when the view tree changes in a way that may affect
the virtial view's bounds in the screen.
bug:17211255
Change-Id: I69dd949b91ed9c8242521332081d50d75cac6921
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 9ae9ed24aa252acbc2e6288068b991dd5291967b |
|
03-Sep-2014 |
Svetoslav <svetoslavganov@google.com> |
Fix AccessibilityNode's isVisibleToUser behavior.
The isVisibleToUser property of an AccessibilityNodeInfo specifies
whether the user can see the source view. It is used by accessibility
services to figure out whether to focus on a view. This property
was giving a wrong value if the view is covered by another window
such as the keyboard. As a result the user hears one thing but when
double taps interacts with the overlaid window which is another thing.
bug:15938254
Change-Id: Ib9feb20ea422a24a512c47ed1234961ae0386a7f
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 4c5a27b5f667ebc7cb2b188655820ad3fddedb52 |
|
28-Aug-2014 |
John Reck <jreck@google.com> |
Merge "Animator stuff" into lmp-dev
|
| 119907cd2575c56b1ebf66348b52e67aaf6a88d8 |
|
14-Aug-2014 |
John Reck <jreck@google.com> |
Animator stuff
Bug: 17228458
Change-Id: Id884a429a512f9cd2be0ed16dbd0f10e92b4440d
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| f14d924cd706438b52ba2bf7a698ea1645fe6399 |
|
26-Aug-2014 |
Filip Gruszczynski <gruszczy@google.com> |
Allowing isRound and outsetBottom properties to be passed to ActivityView.
We remove requirement for having display id == 0 or allow circumventing it
through a flag.
Change-Id: Ia4671614b51894393d47e681cc72718d394230f6
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 997aa40645a1ccdd30c88ba6d5b7bb389fcec72c |
|
19-Aug-2014 |
Alan Viverette <alanv@google.com> |
Draw accessibility focus in View rather than ViewRootImpl
This ensures that the focus rect position is correct when running in
render thread accelerated mode. Also adds a missing call to draw the
overlay.
BUG: 16796647
BUG: 17063342
Change-Id: I377e5eaea89d3f20c8c7e82c264a0f106021d58b
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 99421aed1f57195254b36cf10e23c92219d72270 |
|
13-Aug-2014 |
Alan Viverette <alanv@google.com> |
Merge "Invalidate root render node when accessibility focus moves" into lmp-dev
|
| 1dd0e0fae2135a0aaf8c9f3686e70d3544597bec |
|
12-Aug-2014 |
John Reck <jreck@google.com> |
Don't use libhwui to draw starting window
Bug: 16735410
Change-Id: I763c10b9d34eadcb768ad580d2387b1e825cbd53
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| f6cf1a02537959c5953553000cb7151c0554a333 |
|
11-Aug-2014 |
Alan Viverette <alanv@google.com> |
Invalidate root render node when accessibility focus moves
BUG: 16796647
Change-Id: Ibfc6ec4aa50c6354ea095a35470dd54e768d911b
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| dbed893ba88b76f88ea51d8666653458955cdc67 |
|
07-Aug-2014 |
Alan Viverette <alanv@google.com> |
Preserve surface insets when view layout is updated
Also makes canvas save & restore in threaded renderer a little safer.
BUG: 16654228
Change-Id: Ie0d49450ed408cffd0b859c08e524b6f904c77ca
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| ac89416c77a1fab6921aa31a999ccefc1223be7c |
|
21-Jul-2014 |
Alan Viverette <alanv@google.com> |
Always apply surface insets
Change-Id: I9d8ad0c7fcf7a1016e01c2332f45614da5d2cf0c
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 7bf379c8af399626d5b8b568fe1d4f96f56badcc |
|
16-Jul-2014 |
Dake Gu <dake@google.com> |
ActivityTransition: fix wrong width/height applied to sharedelement.
transform screen position/size to position/size in parent of sharedelement.
fixed bug of transformMatirxToLocal() and transformMatrixToGlobal() that gets
Change-Id: I4c7b12f1ada7004ab7594961df4079be4ca4c909
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 6712495297a549b546ba781c6858c18f4cc9484b |
|
17-Jul-2014 |
Chris Craik <ccraik@google.com> |
Merge "Simplify ViewRootImpl's AttachInfo usage" into lmp-dev
|
| d36a81f392946bbc84a5a97f911a337b8ed6770b |
|
17-Jul-2014 |
Chris Craik <ccraik@google.com> |
Simplify ViewRootImpl's AttachInfo usage
Change-Id: I4230e95ed5a52c8c5fae7d7b8d58827925db13ba
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| b72be59a6a5ca5fae3ede2470f1662598098b666 |
|
17-Jul-2014 |
Adam Powell <adamp@google.com> |
Add nested pre-fling for nested scrolling
Nested pre-fling allows a nested scrolling parent to consume a fling
operation before the child view does. If a parent has been consuming
nested pre-scroll events in a particular direction, this is generally
a good indication that it should also consume the resulting fling at
the end.
Bug 15538504
Change-Id: I88e8753a96c9b41815c3be530cafab8345164e64
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 889fc94ffa70633e510e812b9da86723f4eee384 |
|
17-Jul-2014 |
Chris Craik <ccraik@google.com> |
Merge "Add accessibility text contrast setting" into lmp-dev
|
| cce47eb580d666ead1f6095d1e3b65233592bbaa |
|
17-Jul-2014 |
Chris Craik <ccraik@google.com> |
Add accessibility text contrast setting
b/14624452
Adds a feature which draws all text (in the HW accelerated standard
path) in a high contrast mode. Text is drawn at full alpha, and either
white or black (depending on its original color) with a starkly
contrasted outline beneath it.
Change-Id: I943f624b6367de35367cced3b2a8298f2bc62377
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| a51cab9288fea0a8c8ce9a4ccdb834a11984b32c |
|
17-Jul-2014 |
Alan Viverette <alanv@google.com> |
Fix software dirty region, don't add insets to software windows
BUG: 16324957
Change-Id: Ia99619b7c314fbfce60a5ef8ac16b54680332899
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 0a97330b98dd633b58dcfff405d94476c89e867d |
|
16-Jul-2014 |
John Reck <jreck@google.com> |
Fix root RenderNode damage calculation
Bug: 15888445
Change-Id: I281ec9271c9889673dcdfcb6d31e341a7b47b7de
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 49a22e82025ea947d81681a0abb7ef00600eac3b |
|
13-Jul-2014 |
Alan Viverette <alanv@google.com> |
Add window elevation for dialogs, clean up surface insets API
BUG: 13211941
Change-Id: I9d605d0b2fb24f9bf8e73fbecd520b6b52ae5751
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 58c42c3596a2b79184c9a6b7beffc6e94cce112c |
|
13-Jul-2014 |
Alan Viverette <alanv@google.com> |
Specify light and shadow properties in theme
BUG: 15859361
Change-Id: I65c9aa8c7ad7a709504c879d96158efba040d3ce
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| ccb11e183763db5cbaca96abe461adf480ed8e44 |
|
09-Jul-2014 |
Alan Viverette <alanv@google.com> |
Add API for specifying popup window shadows and shadow insets
BUG: 14569120
BUG: 13211941
Change-Id: Ia21596b25a0471344d42d59377074f67fce00042
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| fa10423fa00f3495e451016acba9b6848eb995c9 |
|
21-Jun-2014 |
Adrian Roos <roosa@google.com> |
Add stable insets for stable system windows
Adds a new kind of inset that only accounts for stable system
windows like the system or navigation bar.
Bug: 15457292
Change-Id: I681b711f6f40a94c25b7acd3a44eb3539486afab
/frameworks/base/core/java/android/view/ViewRootImpl.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/ViewRootImpl.java
|
| 918ad523b2780e0c893f3d2a32d4ec13f2a7e921 |
|
27-Jun-2014 |
John Reck <jreck@google.com> |
More cleanups
Change-Id: Id5967944b949a2aec57e4fe9fdcdc04c11b8c35a
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 9970aee6e8858f2f9efe329aa0ab68b56ed1659e |
|
24-Jun-2014 |
Hui Shu <hush@google.com> |
Remove the return value of invokeFunctor
BUG: 15513308
Change-Id: I900800a6c63f15bf68afaf66b34303039038d3c2
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 3b20251a355c88193c439f928a84ae69483fb488 |
|
23-Jun-2014 |
John Reck <jreck@google.com> |
No-fail invokeFunctor
Bug: 15513308
Bug: 15449247
Change-Id: I13a29f9c8d4975cdda6dcb33b6332c2555ff0f7c
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 8dab261d81e84b0a5cac3fc525d4c4bc0077bacd |
|
22-Jun-2014 |
Michael Kolb <kolby@google.com> |
am c6ffc840: am 270c099f: Merge "Move emulator check & save system properties access" into klp-modular-dev
* commit 'c6ffc840c4e34a61b537e1fc3e90b111d4150244':
Move emulator check & save system properties access
|
| c0fcf109f04e56617680b41d69b7d952ac4bea0b |
|
21-Jun-2014 |
Michael Kolb <kolby@google.com> |
am 71f65485: am db9fed74: Merge "Make WindowInsets.isRound work with emulator" into klp-modular-dev
* commit '71f65485bf47c8bfbae2b3a0a9573b311668b4a2':
Make WindowInsets.isRound work with emulator
|
| c6ffc840c4e34a61b537e1fc3e90b111d4150244 |
|
21-Jun-2014 |
Michael Kolb <kolby@google.com> |
am 270c099f: Merge "Move emulator check & save system properties access" into klp-modular-dev
* commit '270c099faf63868dcc21836a84de778337ff3be9':
Move emulator check & save system properties access
|
| 71f65485bf47c8bfbae2b3a0a9573b311668b4a2 |
|
21-Jun-2014 |
Michael Kolb <kolby@google.com> |
am db9fed74: Merge "Make WindowInsets.isRound work with emulator" into klp-modular-dev
* commit 'db9fed74c2bbf97157683b47f3cbdcd04c729839':
Make WindowInsets.isRound work with emulator
|
| 437d31390b564bbf31f7034930a33b2a86d1ae26 |
|
20-Jun-2014 |
Michael Kolb <kolby@google.com> |
Make WindowInsets.isRound work with emulator
Bug: 15775489
Change-Id: I53a14ccd3be776d46c9cea43c0d5d3f41674dd75
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 22dfdcb7eea428e041b66cb6dc430dc0582e861a |
|
21-Jun-2014 |
Michael Kolb <kolby@google.com> |
Move emulator check & save system properties access
Bug: 15775489
Change-Id: I375aee36b212ae044101a65b65c51e6f889fd263
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 9d7ee60e5e9fab801a21c8bf174ef1e8175ccdd2 |
|
17-Jun-2014 |
John Reck <jreck@google.com> |
Remove incorrect isEnabled() check
Bug: 15683945
invokeFunctor() does not require isEnabled() to be true
to execute. Specifically it does not care if HardwareRenderer
has a Surface or not, as it will fall back to a pbuffer surface
if available. If there is no context at all, it will invoke
with kModeProcessNoContext.
Change-Id: Ie6abe566b92c8fa33bb7a673fc3b9fa9ce913446
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| b8802b1293c05a14399005aeaeb93b82ec2e2f27 |
|
17-Jun-2014 |
John Reck <jreck@google.com> |
Add atlas map pointer validation
Bug: 15425820
This just prevents the crash, it's still unclear how bad pointers
are getting into the map in the first place
Change-Id: I3acffaae09548ec48973035b7fcf5f35606bad60
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 816f71b7e0dc263362e9fc8d251c8d1944bff17c |
|
13-Jun-2014 |
John Reck <jreck@google.com> |
Merge "Move LayerType to RenderNode"
|
| 25fbb3fa1138675379102a44405852555cefccbd |
|
12-Jun-2014 |
John Reck <jreck@google.com> |
Move LayerType to RenderNode
Change-Id: Icb79a5015cb0362b1f3a66d09007450730135a97
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| f7174e87b6007000777b0124de9cef70d8618788 |
|
12-Jun-2014 |
Svetoslav <svetoslavganov@google.com> |
Fix backwards compatibility for introspected windows.
1. The APIs for introspecting interactive windows were reporting only
the touchable windows but were missing the focused window. The user
can interact with the latter by typing, hence it should always be
reported. Also this was breaking backwards compatibility as if the
focused window is covered by a modal one, the focused window was not
reporeted and this was putting the active window in a bad state as
the latter is either the focused window or the one the user is touching.
2. Window change events are too frequent as on window transition things
are chanign a lot. Now we are trottling the windows changed events
at the standard recurring accessibility event interval.
3. Fixed a wrong flag comparison and removed some unneded code.
buy:15434666
bug:15432989
Change-Id: I825b33067e8cbf26396a4d38642bde4907b6427a
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| e4267ea4f20740c37c01bfb6aefcf61fddc4566a |
|
04-Jun-2014 |
John Reck <jreck@google.com> |
Even FASTER damage calculations!
* Now with more native!
* Less matrix math thanks to bulk-property-update support!
* Zero JNI on the View.damageInParent() path!
* Fully aware of RT-driven animators!
* Likely full of new and exciting bugs!
* But it also fixes at least 1 existing invalidate bug!
Change-Id: Ie0773f85a60850ff2668370c58defef2e8aa079f
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 84a4c887a07c1c2939443f4e0587d7f1ac109e4b |
|
30-May-2014 |
John Reck <jreck@google.com> |
Remove GLRenderer
Change-Id: I180286417c1a354fc7eb1eadb1884ac6add0795c
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 2cfc0e543f69750b4ccc9d5f52b384e525cf9e77 |
|
30-May-2014 |
John Reck <jreck@google.com> |
am 894bb170: Merge "Enable debug stuffs" into lmp-preview-dev
* commit '894bb1701ae15b87af1e3bfe865fe191081cc806':
Enable debug stuffs
|
| 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/ViewRootImpl.java
|
| d04d303e5d8521403514cf960a694e566df19536 |
|
23-May-2014 |
John Reck <jreck@google.com> |
resolved conflicts for merge of 1f6c973b to master
Change-Id: I0d0a72f1d737fa80ac4c258c1f9fc52ef85724bd
|
| a5dda645da738da7b4ae15e28fa7d93d3b04b94f |
|
23-May-2014 |
John Reck <jreck@google.com> |
Bag of scheduling tweaks
Bug: 15118640
* Prevent over-stuffing the queue by dropping frames
* Prevent double-drawing in one pulse by RT by deferring
vsync registration until post-draw so that it catches
the next vsync pulse instead of the current one
* Bias vsync race condition towards the UI thread
* Fix queueDelay to actually work
Change-Id: Ibf584258bd93ebcbba058bd976dc8b307f1c6155
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 2a89b08eb1d48208f52eeaf12cb8b687abe81e1c |
|
23-May-2014 |
Michael Wright <michaelwr@google.com> |
Merge "Add ability to request unbuffered dispatching."
|
| 797b95b26bbb7557678af78b9a2a61830158920f |
|
21-May-2014 |
Chris Craik <ccraik@google.com> |
Define light position (using new lighting spec) in Java
Also updates the relative shadow strengths.
Change-Id: I6cac7275d38df98aea9f0dda463cd7207102986a
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| d27a69c40d285c8911dac19c22926ec279110e51 |
|
17-May-2014 |
Michael Wright <michaelwr@google.com> |
Merge "Add InputStage debugging logs"
|
| 9d744c731295e6ba9b0031f3fb63b0df13e591d8 |
|
19-Feb-2014 |
Michael Wright <michaelwr@google.com> |
Add ability to request unbuffered dispatching.
While in general input batching has a lot of benefits, some apps would prefer
the input system not batch at all. This is typically because they do some of
the batching as part of their own input processing, as is the case with Chrome.
Bug: 12973909
Change-Id: I2e0c2b4c51bacc06f88245c528aa8849e4c4dab2
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 44ac42a6c9c3aa2614ef2369cda2e3de989c1fe0 |
|
16-May-2014 |
John Reck <jreck@google.com> |
Add missing fence()
Bug: 14995924
Change-Id: I991fe74f01468b1b7e34aee0455dc419637f5c8d
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 06a7925a2e5ac604b57c3b2855010558fd7bc46b |
|
06-May-2014 |
Michael Wright <michaelwr@google.com> |
Add InputStage debugging logs
Change-Id: I0cd606b0c43ec9ab34f006b750e77bc312f66439
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| ae493d967ff47312f7b6d80fdd67377c73214a5e |
|
08-May-2014 |
John Reck <jreck@google.com> |
Merge "Allow all loopers to be RT-accelerated"
|
| 030d619aaab044491381e72f222cc9ba8dabcc19 |
|
08-May-2014 |
John Reck <jreck@google.com> |
Allow all loopers to be RT-accelerated
Bug: 14445956
Change-Id: I03e92642aa118db5c7fefa1f09c3a5bde6ea671d
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| ef27453cf71e331e4076df5e5c665b06d5c3e050 |
|
07-May-2014 |
John Reck <jreck@google.com> |
Merge "Cleanup attachFunctor"
|
| 832b151465ed81c43e59891d5eebe62128b21fbb |
|
07-May-2014 |
John Reck <jreck@google.com> |
Cleanup attachFunctor
Bug: 13961296
Change-Id: Id48d11bfcc234afd1fd7e4fdd409a50e7208c81d
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 63a06673253914510bbeebd500655008682dade1 |
|
07-May-2014 |
John Reck <jreck@google.com> |
Implement TODO(romainguy)
Bug: 14277445
Change-Id: Id52d6f7fcc023000adcc440bd4da67d9a673536b
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 0a7e8f99970f8adaeaa895343ff0d1863900e9e3 |
|
02-May-2014 |
Alan Viverette <alanv@google.com> |
Fix build, also always draw accessibility focus rect
BUG: 13873026
Change-Id: Ie8c0b9d6ef10968f64fb33a89e010b9b15e93f8b
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| e02bfb6fbdaee62694c589758d6ac5f52addd90c |
|
01-May-2014 |
Michael Wright <michaelwr@google.com> |
Merge "Add unhandledInputEvent API to ViewRoot"
|
| b36e4f944fe28ce68182f9ec91e5341866b49084 |
|
01-May-2014 |
Adam Powell <adamp@google.com> |
Add support for hiding action bars on scroll.
Also tweak the nested scrolling API around nested flings and fix a bug
where recursive nested scrolling would stop prematurely.
Change-Id: I561226db878b2493970440a6af3e2332c56a1913
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 899d70568b565280dd33fa8892e25c5511f95769 |
|
24-Apr-2014 |
Michael Wright <michaelwr@google.com> |
Add unhandledInputEvent API to ViewRoot
Update WebViewClient to use it instead, and add a new public API,
onUnhandledInputEvent. Note that WebViewClients won't receive this
call back until WebView is updated to use it.
Bug: 14279909
Change-Id: Ied49791b469849f5c4cf4471f2b26c56b03f4961
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 19db0f036aa889ff05220b630262461e333faa85 |
|
29-Apr-2014 |
Jae Seo <jaeseo@google.com> |
Merge "Dispatch input events to the TV input"
|
| 6a6059a29edf31e65541b3d8927a46f5846fb0a2 |
|
18-Apr-2014 |
Jae Seo <jaeseo@google.com> |
Dispatch input events to the TV input
TvInputManagerService now creates an InputChannel pair and passes one
end to the app and the other end to the service. Then the TvInputManager
in the app creates an InputEventSender around one end of the channel to
send events and the service creates an InputEventReceiver around the
other end of the channel to receive events.
Most of the newly added code here was borrowed heavily from the IME.
Change-Id: I0bd83847cba0033ccb6f4b6dad267ebeaf5e9c7c
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| ae738a7a45d710115f8aedacf218d4bfa0b25698 |
|
28-Apr-2014 |
Bo Liu <boliu@google.com> |
Add invokeFunctor call to ViewRootImpl
BUG: 13961296
Change-Id: Ief8eea0b4c79a64ea76d75daaec176f1b8438581
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 10ba27734ee6274a772be8d6b1faa703ee3a3d6b |
|
15-Apr-2014 |
Adam Powell <adamp@google.com> |
Nested scrolling!
or, "Excuse me, Egon, you said crossing the streams was bad."
Add API for driving a nested scroll from the most deeply nested
applicable scrolling view. The deepest scrolling view dispatches
high-level scrolling events up to cooperative parent views.
Augment ScrollView to support nested scrolling. Next up, more public
framework scrolling views.
Change-Id: I53b5e207fcdece796e08c8592ddb4496b96f600e
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 05e858400adee0f579b1e27e321b48bd55843fbd |
|
23-Apr-2014 |
John Reck <jreck@google.com> |
Add missing try/finallys
Change-Id: I32be65f5a46768449f26b69f72f502acd1e72769
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 3da2834f0ee77268e0076ad1e24f319635c38b89 |
|
23-Apr-2014 |
Michael Wright <michaelwr@google.com> |
Add ViewRootImpl#unhandledInputEvent API stub.
Doesn't actually work yet for non-KeyEvents.
Change-Id: I3482ff780a9a7aef8ae27436f91a3619490b369f
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 49d8fa473970265a182549cc1673719e5101320e |
|
21-Apr-2014 |
Adam Lesinski <adamlesinski@google.com> |
am a281be67: am 370cda70: Merge "Allow InputEvents to propagate w/o IME" into klp-modular-dev
* commit 'a281be67030a834d455a84ce62c173140564211a':
Allow InputEvents to propagate w/o IME
|
| a281be67030a834d455a84ce62c173140564211a |
|
21-Apr-2014 |
Adam Lesinski <adamlesinski@google.com> |
am 370cda70: Merge "Allow InputEvents to propagate w/o IME" into klp-modular-dev
* commit '370cda7074a02139fa5374bbdd94c37be376ca7a':
Allow InputEvents to propagate w/o IME
|
| c0f6eed40fd2fc0922de34d691d31f0e320ca9b7 |
|
29-Oct-2013 |
Adam Lesinski <adamlesinski@google.com> |
Allow InputEvents to propagate w/o IME
If no IME was present, InputEvents such as KeyEvents
would simple be dropped instead of going through
to the Activity's View hierarchy.
Change-Id: I9de25bdbf5d1564b77b25679e19dae18591a8c1c
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| f4399e7243c35bef3eabfd20582246818a0bbbd3 |
|
18-Apr-2014 |
Michael Kolb <kolby@google.com> |
resolved conflict for merge from d42eeab2 to master
Change-Id: I41bd238f0628110c923b79259de4cd11a783340c
|
| d42eeab20fea37fbf92b5c1a4f6f194ab9303083 |
|
18-Apr-2014 |
Michael Kolb <kolby@google.com> |
am 4abbd0a6: Merge "Populate isRound from config.xml to WindowInsets" into klp-modular-dev
* commit '4abbd0a685cb418eb3cfc1f030d3091ef394a7e3':
Populate isRound from config.xml to WindowInsets
|
| 6642e51ac5d0351f02fc929817603d7371e08e10 |
|
17-Apr-2014 |
Michael Kolb <kolby@google.com> |
Populate isRound from config.xml to WindowInsets
Change-Id: I41b3aef1322a7cdccdcbc679eb753e0a1e561fad
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 3d678ad462ee237d86efd9d985eb518817761e05 |
|
17-Apr-2014 |
Adam Powell <adamp@google.com> |
am 973ddaac: DO NOT MERGE Add isRound to WindowInsets
* commit '973ddaacaef255b8659d35cfe4151dd5b7436138':
DO NOT MERGE Add isRound to WindowInsets
|
| 2accbf904f0dfa42f1a776d2e1ea7b01898929c0 |
|
17-Apr-2014 |
Adam Powell <adamp@google.com> |
Revert the revert of adding isRound to WindowInsets after early merge
This reverts commit 01ebfbd0a0a3a89b563ab6c8c346c669eca39a1a.
Change-Id: I3d5a3523a1505cc3bfd0172c7282a8eda21ae206
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 01ebfbd0a0a3a89b563ab6c8c346c669eca39a1a |
|
17-Apr-2014 |
Michael Kolb <kolby@google.com> |
Revert "Add isRound to WindowInsets"
This reverts commit e5244b5638535964103ca1dfc867442a64243db1.
Change-Id: I6371c718e2189968699e980fd0e7ba91c486aca6
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 973ddaacaef255b8659d35cfe4151dd5b7436138 |
|
16-Apr-2014 |
Adam Powell <adamp@google.com> |
DO NOT MERGE Add isRound to WindowInsets
isRound allows a view to determine whether the window it is contained
within obscures the corners of the window content. This allows views
aware of this property to adapt their layout accordingly.
Switch ViewRootImpl to use dispatchApplyInsets instead of
fitSystemWindows.
Change-Id: Ic3e3936b73815b2593cb9720af1a309fbd18406e
Conflicts:
core/java/android/view/ViewRootImpl.java
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| e5244b5638535964103ca1dfc867442a64243db1 |
|
16-Apr-2014 |
Adam Powell <adamp@google.com> |
Add isRound to WindowInsets
isRound allows a view to determine whether the window it is contained
within obscures the corners of the window content. This allows views
aware of this property to adapt their layout accordingly.
Switch ViewRootImpl to use dispatchApplyInsets instead of
fitSystemWindows.
Change-Id: Ic3e3936b73815b2593cb9720af1a309fbd18406e
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 15b0bef9250e084bfbceb388716d28ed62ca018f |
|
12-Apr-2014 |
Jeff Brown <jeffbrown@google.com> |
am 9e2fde9c: am d912e1f6: Use the display\'s actual state in the view hierarchy.
* commit '9e2fde9c8a3557d6e8d1f3971a421ecdf5c2ce07':
Use the display's actual state in the view hierarchy.
|
| 9e2fde9c8a3557d6e8d1f3971a421ecdf5c2ce07 |
|
12-Apr-2014 |
Jeff Brown <jeffbrown@google.com> |
am d912e1f6: Use the display\'s actual state in the view hierarchy.
* commit 'd912e1f6a111fb33118d116bd72da1a328041bca':
Use the display's actual state in the view hierarchy.
|
| d912e1f6a111fb33118d116bd72da1a328041bca |
|
12-Apr-2014 |
Jeff Brown <jeffbrown@google.com> |
Use the display's actual state in the view hierarchy.
Previously, the view hierarchy would suppress drawing whenever the
PowerManager.isScreenOn() method returned false. However, this method
really describes the interactive state of the device rather than the
actual display state. This is especially a problem when there are
multiple displays but it also breaks drawing while in doze mode.
This change makes the view hierarchy consider the actual state of the
display instead on an individual basis.
Bug: 13133142
Change-Id: I69870b6b14a3504607a30562aa48c3452f777c1f
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| bc0cc0220b830df54c8ed41d0b53daffd7f6c991 |
|
12-Apr-2014 |
John Reck <jreck@google.com> |
Support onHardwarePostDraw in ThreadedRenderer
Bug: 13958485
Change-Id: Ie9c7af7cee582850a7f0a3d891aa3685c230cfc7
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 8e1f918738abf70a4dc86dbb12b386a9deea37f8 |
|
10-Apr-2014 |
John Reck <jreck@google.com> |
Merge "Switch DisplayListData to a staging model"
|
| 8de65a8e05285df52a1e6f0c1d5616dd233298a7 |
|
10-Apr-2014 |
John Reck <jreck@google.com> |
Switch DisplayListData to a staging model
Bug: 13912977
Change-Id: I5b2f664e797be22a58300964f57ceb4fab60528c
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| f7d9c1dc84671d4e99657ef071d275700d85bb11 |
|
09-Apr-2014 |
John Reck <jreck@google.com> |
Fix ThreadedRenderer.setEnabled()
Bug: 13914116
Fixes lifecycle issues around setEnabled where ThreadedRenderer
was reporting as being enabled before it had a Surface. This is
incorrect.
Also fix some EGL lifecycle issues
Change-Id: I12ebb279707f9b533a570b61d68735d858b560bf
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 28ad7b52e038ef0cdd89f753d9839444a434b299 |
|
08-Apr-2014 |
John Reck <jreck@google.com> |
Fence on draws that are reported
Change-Id: Ib2ec16cbda40f40df1710bdc868869ea8301f17e
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 55da62288dcec75c34721a59d71f917dcb8a62b4 |
|
03-Apr-2014 |
Ben Murdoch <benm@android.com> |
am 14424043: am 369a0057: Merge "Update ViewRootImpl for 64bit functor type."
* commit '14424043b9c20edf639004e05fe8e9264a2e66f5':
Update ViewRootImpl for 64bit functor type.
|
| a8b937115ac3bf047c8fc6c750f052fd633c5dd8 |
|
02-Apr-2014 |
John Reck <jreck@google.com> |
Merge "Revert "Force-enable hardware acceleration for apps""
|
| dd58e797aa453f468232c6a5949a37e4691f309e |
|
02-Apr-2014 |
John Reck <jreck@google.com> |
Revert "Force-enable hardware acceleration for apps"
This reverts commit 2a0901107443685ef2f2a55d0b62ddcc6cf183ba.
Change-Id: I47c58b7251411432bd6a3eeb6fe567385b1c084f
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| cf61c9b71faa053f407430fde043b4672c501340 |
|
02-Apr-2014 |
Ben Murdoch <benm@google.com> |
Update ViewRootImpl for 64bit functor type.
Change-Id: Ie9020f0276c58ebf0977e4aef725fbc26aaf67b2
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 64a12e177de64ae5d907e3020ea3f37cc96ee325 |
|
29-Mar-2014 |
Chris Craik <ccraik@google.com> |
Update several stale RenderNode variable names
Change-Id: I61c8c66f5a79e3a89ae0d3cffbfd351c05bd6a2b
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 2a0901107443685ef2f2a55d0b62ddcc6cf183ba |
|
27-Mar-2014 |
John Reck <jreck@google.com> |
Force-enable hardware acceleration for apps
Change-Id: Ie45581fac2b6b71aeb7b652485915e2518372efc
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 1b10869f39978a864cfcc4efc73aefc312d8ed79 |
|
19-Mar-2014 |
Michael Wright <michaelwr@google.com> |
Generate and respect ACTION_CANCEL for joystick fallbacks. DO NOT MERGE
Also change MotionEvent.PointerCoords bit packing and unpacking
methods to be consistent with BitSets which are now used on the
native PointerCoords object.
Bug: 11480300
Change-Id: Ib18c99b94ac555104c69eac526860aa501e89e03
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 9adca065148f704187866c53cceda8e0050b1f35 |
|
19-Mar-2014 |
Michael Wright <michaelwr@google.com> |
Respect ACTION_CANCEL for joystick fallbacks
Also change MotionEvent.PointerCoords bit packing and unpacking
methods to be consistent with BitSets which are now used on the
native PointerCoords object.
Bug: 11480300
Change-Id: Ic6c7ebda5c545d07ea1ed259ca1f1184ccf85f29
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 845535a76d5348847a827d981ef361d0b18e68ad |
|
21-Mar-2014 |
Bo Liu <boliu@google.com> |
Convert a attach/detach functor in ViewRootImpl to x64
Change-Id: I93c1df8abd0ecd1686e392cada099f9864926d33
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 8e3feb15c5aec2c72b0ef120a1da325e1e8f0dda |
|
24-Feb-2014 |
Svetoslav <svetoslavganov@google.com> |
Added accessibility APIs for introspecting interactive windows.
1. The old introspection model was allowing querying only the active window
which is the one the user is touching or the focused one if no window is
touched. This was limiting as auto completion drop downs were not inspectable,
there was not way to know when the IME toggles, non-focusable windows were
not inspectable if the user taps them as until a screen-reader starts
introspecting the users finger is up, accessibility focus was limited to
only one window and the user couldn't use gestures to visit the whole UI,
and other things I can't remember right now.
The new APIs allow getting all interactive windows, i.e. ones that a
sighted user can interact with. This prevents an accessibility service
from interacting with content a sighter user cannot. The list of windows
can be obtained from an accessibility service or the host window from an
accessibility node info. Introspecting windows obey the same rules for
introspecting node, i.e. the service has to declare this capability
in its manifest.
When some windows change accessibility services receive a new type
of event. Initially the types of windows is very limited. We provide
the bounds in screen, layer, and some other properties which are
enough for a client to determined the spacial and hierarchical
relationship of the windows.
2. Update the documentation in AccessibilityService for newer event types.
3. LongArray was not removing elements properly.
4. Composite accessibility node ids were not properly constructed as they
are composed of two ints, each taking 32 bits. However, the values for
undefined were -1 so composing a 64 long from -1, -1 prevents from getting
back these values when unpacking.
5. Some apps were generating inconsistent AccessibilityNodeInfo tree. Added
a check that enforces such trees to be well formed on dev builds.
6. Removed an necessary code for piping the touch exploration state to
the policy as it should just use the AccessibilityManager from context.
7. When view's visibility changed it was not firing an event to notify
clients it disappeared/appeared. Also ViewGroup was sending accessibility
events for changes if the view is included for accessibility but this is
wrong as there may be a service that want all nodes, hence events from them.
The accessibility manager service takes care of delivering events from
not important for accessibility nodes only to services that want such.
8. Several places were asking for prefetching of sibling but not predecessor
nodes which resulted in prefetching of unconnected subtrees.
9. The local AccessibilityManager implementation was relying on the backing
service being ready when it is created but it can be fetched from a context
before that. If that happens the local manager was in a broken state forever.
Now it is more robust and starts working properly once the backing service
is up. Several places were lacking locking.
bug:13331285
Change-Id: Ie51166d4875d5f3def8d29d77973da4b9251f5c8
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| f666ad7046c0b1b255835f75aeb7d1391067df93 |
|
15-Mar-2014 |
John Reck <jreck@google.com> |
Rename DisplayList->RenderNode
Change-Id: Idcca6f26ba6282594789962f5edb3ed53a290fef
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| ecc7ca53852a395157ac1b45ee6aa4fe13ade3d1 |
|
06-Mar-2014 |
Michael Wright <michaelwr@google.com> |
resolved conflicts for merge of fa2e53cc to master
Change-Id: Idc54765c28ab7c6c810095aba1ba21d7695e08d5
|
| 44fd8d24f761f82d21e9b00932648a1b6bf91449 |
|
26-Feb-2014 |
John Reck <jreck@google.com> |
DisplayList overhaul
Change-Id: I53418d580c98f706e971545cff81b9921c12cc5f
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| f9a901e1018408ddf9e21105695b2bd5814db1fb |
|
28-Feb-2014 |
John Reck <jreck@google.com> |
Avoid running functors after detach
Bug: 10861732
Change-Id: Ida55fff716c37c6ab1c98eef02582282de0034f6
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| bdffc3ad05180d716cc4b808b292e2262f0cd461 |
|
27-Feb-2014 |
Michael Wright <michaelwr@google.com> |
Revert Japanese special case fallback keys.
Reverts commits 4567e40eb04589d211af82f2dcb16cb3955c605e and
a977707d6e7006d11cfde045f187e777b31b9e04, which added special case fallbacks
for game controllers in the Japanese locale.
Bug: 12923922
Change-Id: I229126e589e11fb5de86772ef9c59d09723af941
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| e56e9df5f12b2714d79415e2c5b3f30d58ca7c12 |
|
22-Feb-2014 |
John Reck <jreck@google.com> |
Add back resize buffer
Bug: 12825810
Change-Id: Ic2329c30524010f54778101853b30f8f8d9eeb6c
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 40c3ddd3a2462bc41e5fbf4932373ebd83961a6f |
|
20-Feb-2014 |
Michael Wright <michaelwr@google.com> |
Merge "Make deliverInputEvent tracing asynchronous"
|
| d2c3adc9c95683d70d1ce798447a86131602b80b |
|
19-Feb-2014 |
Michael Wright <michaelwr@google.com> |
Make deliverInputEvent tracing asynchronous
Change-Id: I640ed4003194d6d4b202680e5c8fffc81749d60f
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 19b6bcfd83eb7fb92ebd06d2fec89e308311f1d0 |
|
15-Feb-2014 |
John Reck <jreck@google.com> |
Support HardwareLayers in RenderThread
Also has a few HardwareLayer lifecycle fixes
Change-Id: I6308cb05f8f199eed72189ace768013a46815941
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 8a5dbac349ed5bced0d9509aa5bdcf707df40da2 |
|
13-Feb-2014 |
Michael Wright <michaelwr@google.com> |
Remove Japanese button swap
Bug: 12923922
Change-Id: I4960d8189e751514a595823d7ed9b273e3ff8eb8
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 04fc583c3dd3144bc6b718fcac4b3e1afdfdb067 |
|
06-Feb-2014 |
John Reck <jreck@google.com> |
Refactor HardwareLayer
Defer all the things!
Groundwork to allow hardware layers to work in a renderthread world
Change-Id: Ib3aa47525f393083621254a743dbaa6352f933bd
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 8eea3ea5591e59f55cbb4f6b2b7e9363a285ced3 |
|
04-Feb-2014 |
Alan Viverette <alanv@google.com> |
Add APIs for obtaining themed Drawable from Theme, Context
BUG: 12611005
Change-Id: Ic0057be4e4c2d0c61ce02a019b3f7d0625e3a016
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 4f02bf4eef6af47f35c70c4dda5b7b9523d89ca0 |
|
04-Jan-2014 |
John Reck <jreck@google.com> |
Native-side proxy
Remove RemoteGLRenderer
Remove reflection-based control
Change-Id: If17c2bbb61c7141986d88c4763def77ed1074985
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 223622a50db319d634616311ff74267cf49679e7 |
|
17-Dec-2013 |
Alan Viverette <alanv@google.com> |
Add reveal drawable, APIs for forwarding Drawable focus and touch
Hotspot APIs are hidden pending finalization of how we handle IDs.
BUG: 11416827
Change-Id: Iecacb4b8e3690930d2d805ae65a50cf33482a218
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 7d2edfc073b4a87f9584e12b0c6e80cffea730f5 |
|
11-Dec-2013 |
John Reck <jreck@google.com> |
Merge "Unbreak display list debug dumping"
|
| 630491973269da1b260e69d6a3f9490b97705037 |
|
11-Dec-2013 |
John Reck <jreck@google.com> |
Unbreak display list debug dumping
Change-Id: I1c6a79f047b29fa60907f6e128cb843a45b88bff
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 4a8e5a05bbb344c96bca12bb8d4a768cabbdbce5 |
|
10-Dec-2013 |
Michael Wright <michaelwr@google.com> |
Merge "Generate locale-aware gamepad fallbacks for webview"
|
| cec24ae16e9a0a7c3075f1a8d9149bb7fb3813fc |
|
05-Nov-2013 |
John Reck <jreck@google.com> |
RenderThread work
Hacky prototype needs a private API to enable
Change-Id: I21e0ddf3cdbd38a4036354b5d6012449e1a34849
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 916b649d06ed34c16b2ee9047f086dff184c03ee |
|
04-Dec-2013 |
Michael Wright <michaelwr@google.com> |
Generate locale-aware gamepad fallbacks for webview
Since WebView's input handling is asynchronous its KeyEvents get
re-injected to ViewRootImpl via dispatchUnhandledKey. Make sure these
events generate the new synthetic, locale-aware keys before
using the kcm fallbacks.
Bug: 11193726
Change-Id: I2605f15130ba4bb4ad23c7ad1f3e5edfbc4be99d
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| fed3f728b7fea15c73d4fda551bd0433dd4f85eb |
|
14-Nov-2013 |
Alan Viverette <alanv@google.com> |
Generalize mapping between local and global View coordinates
Change-Id: Ib7f5d51debe2e9773d9ef2fa60a33379b229371a
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 3083579424785e55ca8f82856a6553ee983c3ffb |
|
07-Nov-2013 |
John Reck <jreck@google.com> |
More refactoring
Merge GlRenderer and Gl20Renderer
Move GLRenderer to its own file
Move native methods from HardwareRenderer to GLRenderer
Change-Id: Ib4680b03dd98101b2a428062cc94774ff73baa75
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 79d81e68aa61fe7b00cdcba433f9f58f255cb368 |
|
05-Nov-2013 |
John Reck <jreck@google.com> |
Remove dead code
Change-Id: I242eacf68067ffe353802f07d6bfe5bb152fe9d0
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| efdb985f2eabde8cf9dab3f51254865d59d305f7 |
|
01-Nov-2013 |
Michael Wright <michaelwr@google.com> |
am 9730fbc0: am cd250cc8: am 17d28ca3: Check view and focus invariants after calling into app
* commit '9730fbc0ea71ee0c41c94cf2772cc9884455c4e1':
Check view and focus invariants after calling into app
|
| 17d28ca3d76e943e30bdaafb98596cf35bb45087 |
|
01-Nov-2013 |
Michael Wright <michaelwr@google.com> |
Check view and focus invariants after calling into app
When we dispatch input events into the actual application, make sure
the input invariants we rely on haven't changed. If they have, we
drop the event and log why.
Bug: 11399505
Change-Id: Id772e41ca41dc332bb02725ab486e3b10a73c220
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 0160bcbe531eebe882999f041348ce0182fc5bab |
|
29-Oct-2013 |
Michael Wright <michaelwr@google.com> |
am 0116f08b: am 961cc671: am 3f836741: Merge "Speculatively schedule input consumption" into klp-dev
* commit '0116f08b387d237c334b10bb0266426e1ab3c793':
Speculatively schedule input consumption
|
| 62ce65d6edbc2c34c63b0e2f2fef9cb08e28c783 |
|
25-Oct-2013 |
Michael Wright <michaelwr@google.com> |
Speculatively schedule input consumption
With the new tuned vsync offset, vsyncs are likely to occur shortly
after the input is received, meaning we will empty the input queue,
and thus won't schedule input consumption until more input is
received. If an application then speculatively posts draw commands to
the main looper faster than 60 hz, it will eventually end up blocking
in eglSwapBuffers. Since we're blocking in eglSwapBuffers, we won't
even schedule consumption until after the current frame (8-16ms), and
it's entirely likely we won't actually get around to consuming input
until after the next frame (another 16 ms of latency). This means we
can often go 16-32ms without processing any input events, causing
very noticeable amounts of jank.
Rather than waiting for the next input event to schedule input
consumption, speculatively schedule it every frame as long as we've
consumed some motion batch during this frame.
Bug: 11398045
Change-Id: I25e46308e00e9f9de00a1d8906f6b0e0f2e845b4
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| b1eb620219de034b28a0130b07ca05140c4ff830 |
|
18-Oct-2013 |
Jeff Brown <jeffbrown@google.com> |
am 83bf4404: am 3e3296e5: am 82f31701: Merge "Log view root, input and looper state in bug reports." into klp-dev
* commit '83bf440440309a394f792e3d8a6acb98197d9d7c':
Log view root, input and looper state in bug reports.
|
| 5182c780a8b42acd46a06d693ab63a0dd78c6d70 |
|
16-Oct-2013 |
Jeff Brown <jeffbrown@google.com> |
Log view root, input and looper state in bug reports.
Bug: 10948648
Change-Id: I956cce2a0fb516c02f9bbbc021f6238bcb226891
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| b45bdac3407a25122e37175ba0b5d8e04dfa0b1d |
|
15-Oct-2013 |
John Spurlock <jspurlock@google.com> |
am 5a87a4e3: am 30408434: am f8033360: Merge "Give IMEs the entire screen to use for measuring purposes." into klp-dev
* commit '5a87a4e3554872dced265ee32551656f0a9643ac':
Give IMEs the entire screen to use for measuring purposes.
|
| f8508272adb93b5377edfeb69e85442c3d9ed6d2 |
|
15-Oct-2013 |
John Spurlock <jspurlock@google.com> |
Give IMEs the entire screen to use for measuring purposes.
IMEs recently gained the ability to layout out under the nav bar,
but our core measuring logic does not give height=WRAP_CONTENT windows
the entire screen height when computing desired window height.
Since IMEs can be identified by type, let them use the entire screen
height for measuring purposes, to properly handle the cases where
space is constrained, making that unaccounted-for nav bar height
important.
Bug:11215678
Change-Id: I1d0b73454c0c629e7d669b9de70641c7e8c4d333
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 9d343c26063b8981294d85e0a42819b628c022d7 |
|
14-Oct-2013 |
Dianne Hackborn <hackbod@google.com> |
am f2896e28: am 9e4403d4: am ef53fcc3: Merge "Fix issue #11199654: Action bar enter animation skips frames when cleared by the system" into klp-dev
* commit 'f2896e2897cace31d82d917f73b787a9d87b21cb':
Fix issue #11199654: Action bar enter animation skips frames when cleared by the system
|
| 021d243d6d113b114d5e71931e728f2aacb9ca14 |
|
14-Oct-2013 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #11199654: Action bar enter animation skips frames when cleared by the system
We have become too aggressive about not allowing windows to draw while windw
animations are running, basically not allowing any drawing in any window when
there is any window animation. So if you did a relayout while the status bars
were being animated, your window would stop drawing until that status bar
animation was complete.
This change relaxes those rules in two ways:
- A particular window will only be told to stop updating when *it* is
currently involved in a window animation. So animations in status bars
will not stop app windows from update, and vice versa.
- If a window receives input events while it is in the "do not update"
state, we will immediately terminate that state and start allowing it to
draw. If the user is actually interacting with a window, we don't want
to wait to show feedback.
Change-Id: I72574eec048aee53115b46a78686cf27f42c42f7
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 13431ad822a6479c8512ea4a6ab799e2f5b46d97 |
|
07-Oct-2013 |
John Spurlock <jspurlock@google.com> |
am 4818db0f: am b88ede00: am d5102f19: Merge "Transparent system ui flags -> Translucent WM flags." into klp-dev
* commit '4818db0fc5dec465a2cdb76c0faff4750a3a3fff':
Transparent system ui flags -> Translucent WM flags.
|
| bd95740648372449a4d5c164d7050eee352d4c24 |
|
03-Oct-2013 |
John Spurlock <jspurlock@google.com> |
Transparent system ui flags -> Translucent WM flags.
Migrate View.SYSTEM_UI_FLAG_TRANSPARENT_(STATUS/NAVIGATION) to
WindowManager.LayoutParams.FLAG_TRANSLUCENT_(STATUS|NAVIGATION).
Add associated public attrs for both new window flags:
windowTranslucentStatus
windowTranslucentNavigation
Introduce convenient four new themes that set translucent decor:
Theme.Holo.NoActionBar.TranslucentDecor
Theme.Holo.Light.NoActionBar.TranslucentDecor
Theme.DeviceDefault.NoActionBar.TranslucentDecor
Theme.DeviceDefault.Light.NoActionBar.TranslucentDecor
Update PhoneWindowManager mechanism to plumb these values back to
SystemUI to drive bar mode state.
The new translucent flags come from the top fullscreen window, not
the focused window, so translucency does not change when opening
dialogs.
Imply some window-level system-ui visibility if one or both of these
new flags are present, specifically:
FLAG_TRANSLUCENT_STATUS implies LAYOUT_STABLE, LAYOUT_FULLSCREEN
FLAG_TRANSLUCENT_NAVIGATION implies LAYOUT STABLE, LAYOUT_HIDE_NAV
Rename all associated variable & resource names to use the term
translucent instead of transparent. (Retain the term semi-transparent
for the transient bar style).
Recents activity allowed to inherit translucent decor state via the
new PRIVATE_FLAG_INHERIT_TRANSLUCENT_DECOR. Compensating changes
to use the full screen area more appropriately.
Update keyguard to use new WM flags.
Update docs and various api artifacts.
Sanity-check fixes:
- Toasts and alerts given stable layout.
- Suppress nu-gradient when in transient (hidey) mode.
- New translucent flags use top-fullscreen window, dialogs don't clear.
Bug:10674960
Bug:11062108
Bug:10987178
Bug:10786445
Bug:10781433
Change-Id: If667a55bea4cf5e008549524b9899197fab55ebe
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 38dc2ad85e4572d6e56f0a98edd97945312f708c |
|
04-Oct-2013 |
Adam Lesinski <adamlesinski@google.com> |
am b2db2fbc: am 6d90862f: am d65825ab: Merge "Private flags are masked in correct variable" into klp-dev
* commit 'b2db2fbce33dbcfa52ccb20267ad4897c558c34f':
Private flags are masked in correct variable
|
| 95c42974f719d1fac90fc0438eac778e9795681f |
|
02-Oct-2013 |
Adam Lesinski <adamlesinski@google.com> |
Private flags are masked in correct variable
Newly added private flags were being masked in the public flag variable
as opposed to the correct privateFlags variable.
bug:11033280
bug:11043194
Change-Id: Idda3a70a083457f3f1b7d4b46d231f4a7e704cf0
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 49e43291b2120884320441e9519f5f3c74d40cb2 |
|
02-Oct-2013 |
Adam Lesinski <adamlesinski@google.com> |
am 234c6c8a: am ff7cba54: am 42e9b631: Merge "Make room for new public flags" into klp-dev
* commit '234c6c8aafa4abc440d5bf38aac058b96ba1434c':
Make room for new public flags
|
| d09d5f9e4cb9cd03c47eab0f1e9256dc1e2a7527 |
|
02-Oct-2013 |
Jeff Brown <jeffbrown@google.com> |
am 10478213: am 5e65adaf: Merge "Reset insets when inset computer is removed." into klp-dev
* commit '10478213759a486524000c4164e4176437afa2d7':
Reset insets when inset computer is removed.
|
| 6a591f585909415a1da431a2cc76b7732724037d |
|
02-Oct-2013 |
Adam Lesinski <adamlesinski@google.com> |
Make room for new public flags
Moved two hidden flags to private
bug:11033280
Change-Id: Icca867b073aff643eefdaf84df68de86bb6b05ac
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 2e05ec3235150a93a3459cd260be45f02dadbe84 |
|
01-Oct-2013 |
Jeff Brown <jeffbrown@google.com> |
Reset insets when inset computer is removed.
When an inset computer is registered with the view tree observer,
we report content insets to the window manager. When an inset computer
is subsequently unregistered, we must take care to clear these insets.
This patch remembers whether the previously computed insets were
non-empty so that it can force insets to be reset when needed.
Bug: 10840662
Change-Id: I4cce5ba64cc5234b98363b025ac4bb42e64349f1
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 04fa5918453695e674c2c7ca094a992616409424 |
|
30-Sep-2013 |
Michael Wright <michaelwr@google.com> |
am edb444b4: Merge "Add missing constructor parameter to KeyEvent" into klp-dev
* commit 'edb444b44419def54292cf8325c22697213153fa':
Add missing constructor parameter to KeyEvent
|
| a977707d6e7006d11cfde045f187e777b31b9e04 |
|
27-Sep-2013 |
Michael Wright <michaelwr@google.com> |
Add missing constructor parameter to KeyEvent
When in the SyntheticKeyHandler, a missing constructor paramater caused the
wrong contstructor to be called. This would cause the device id, scan code and
flags to be incorrect.
Bug: 10966229
Change-Id: Ib84ef88d28c0da517b376c5493a851cf8fe0a9f7
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 8232eb9c19c9d74e9ec605ad0bf436a76a748f33 |
|
27-Sep-2013 |
Alan Viverette <alanv@google.com> |
Preserve but don't draw accessibility focus for unfocused windows
BUG: 6472572
Change-Id: Id3d7d76cc59a3d8141d043d6797f176345fd0cbb
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 77e9a28e2faa36f127231b842476d47f9823a83a |
|
13-Sep-2013 |
Alan Viverette <alanv@google.com> |
Add live region politeness to View, AccessibilityNodeInfo
Alters the content change API to contain a bit mask of types of
changes represented by the event. Live regions send CONTENT_CHANGED
events immediately. Removes unused APIs for EXPANDABLE/EXPANDED.
BUG: 10527284
Change-Id: I21523e85e47df23706976dc0a8bf615f83072c04
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| a86ab640f7bb0bf3cb4eaed80473ca8c5d131903 |
|
30-Aug-2013 |
Igor Murashkin <iam@google.com> |
Surface: Change OutOfResourcesException to be a runtime exception
- 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
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| edaf6af16a5c33557a9c4ed00f9bebdac0dd83aa |
|
07-Sep-2013 |
Michael Wright <michaelwr@google.com> |
Merge "Remove tap to click from touch nav devices" into klp-dev
|
| 7b4f60deb2819496733c0c85c57c6236900fe0c2 |
|
07-Sep-2013 |
Michael Wright <michaelwr@google.com> |
Merge "Special case game controller fallback keys for Japan" into klp-dev
|
| f66645671f9c3d8e621296e11fd65941c22f057f |
|
04-Sep-2013 |
Romain Guy <romainguy@google.com> |
Don't draw with invalid display lists
Bug #10301674
Change-Id: I900322dcb9b53f0eb82741c94d4ab1eaf939259e
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 88d7f7992553dde4d140325b306ac9d8f43b9387 |
|
28-Aug-2013 |
Michael Wright <michaelwr@google.com> |
Remove tap to click from touch nav devices
Bug: 10508608
Change-Id: I842a181e847af41b8401dd9dd7aed3f6af556a39
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 4567e40eb04589d211af82f2dcb16cb3955c605e |
|
17-Aug-2013 |
Michael Wright <michaelwr@google.com> |
Special case game controller fallback keys for Japan
Bug: 10306633
Change-Id: I647fc5286678ddd85599a00e68e2fd70c2c3db49
/frameworks/base/core/java/android/view/ViewRootImpl.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/ViewRootImpl.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/ViewRootImpl.java
|
| 973f3b4ebf79c8ce9233e2320d13c2b92d420f93 |
|
14-Aug-2013 |
Alan Viverette <alanv@google.com> |
Prevent refocus after entering touch mode
BUG: 10210009
Change-Id: I9a5d7016728cc7d1fb1c759708b6df41c81865bb
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 30f420fd6a74ffa28b351b4aba74d44f5ea48dda |
|
02-Aug-2013 |
keunyoung <keunyoung@google.com> |
add local focus mode and input event injection API to Window
- This enables keyboard navigation for window without focus.
- FLAG_LOCAL_FOCUS_MODE puts window into local focus mode.
- Application needs to put window in local focus mode, control focus, and
inject events to make dpad navigation work.
- Window in local focus mode does not interact with window manager or ime
regarding focus related events.
- Also renamed ViewRootImpl.dispatchKey to dispatchInputEvent to allow both key and touch events injection.
Change-Id: I8e8561f29e0dade3797fb7ae3ee7690e6b7f8895
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| ed7821a60ca80197384b2a4678b6c4ea307457e6 |
|
25-Jul-2013 |
Alan Viverette <alanv@google.com> |
Use clearFocus() when entering touch mode
Calling unFocus() leaves the view hierarchy in an inconsistent
state. This is okay in ViewGroup, where the state is manually
updated, but causes issues in ViewRootImpl.
BUG: 9983358
Change-Id: Id63e62962d895e6bd4f816f202dcf77254ceab4e
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 25b0c3096131e532e57f5aac48769430dca42c75 |
|
10-Jul-2013 |
Michael Wright <michaelwr@google.com> |
Debounce touch navigation taps and button presses
Bug: 8990644
Change-Id: Ib4ef2e2ab699a109c12614c1d64e4b7e63b514b0
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 8d820ecffdc853aab88cc85bb45bfe72dd2ad893 |
|
16-Jul-2013 |
Svetoslav <svetoslavganov@google.com> |
Fixing bugs discovered by the CTS tests.
1. Delayed accessibility events sent when a view subtree changes may be
be delivered after accessibility is disabled leading to a crash. It is
possible that accessibility was disabled while we were waiting for
the timeout before sending the event. Added a check before dispatching.
2. When refreshing a cached node the accessibility node info cache was
not using the correct bypass cache argument value and as result was
not getting the latest node but its cached value. We really want to
get the latest state to update the cache.
3. The debugging cache integrity verification logic was incorrectly
removing nodes from the cache while doing its work.
4. Removed the comments for some debug logging.
bug:9857067
Change-Id: I20ee1a6ffa65ad35457b51d3f2dc0bc5d8d784e6
/frameworks/base/core/java/android/view/ViewRootImpl.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/ViewRootImpl.java
|
| f1f5054f7aed6c06657955e43a680ed54c463986 |
|
28-Jun-2013 |
Craig Mautner <cmautner@google.com> |
More debug for 9404689.
Changing focus to PhoneWindow.
Change-Id: I75c2ce6b1a20729daf8d2b7f83b2a871e1a7e642
/frameworks/base/core/java/android/view/ViewRootImpl.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/ViewRootImpl.java
|
| 07f36c738e65b8cc2484107b4f8e3386d45d065d |
|
24-Jun-2013 |
Craig Mautner <cmautner@google.com> |
Merge "Add activity token to display system."
|
| 48d0d1886731ff19ed3fb47a5997be5df0d1bba8 |
|
11-Jun-2013 |
Craig Mautner <cmautner@google.com> |
Add activity token to display system.
First step in adding activity specific information to displays.
Replace CompatibilityInfoHolder with DisplayAdjustmentsHolder that
holds an activity token in addition to the CompatibilityInfo.
Change-Id: Ie113cd8dd9c62e0b5311204e039a4829096bea68
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 27e0bf627883e7042384d34cf37fbedf276ff553 |
|
21-Jun-2013 |
Romain Guy <romainguy@google.com> |
Safely dispose of the resize buffer
We just ensure there is a valid EGL context before
we destroy the associated layer.
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 9dafebb8172d767d640c526d717eaef6a52167f3 |
|
19-Jun-2013 |
Svetoslav <svetoslavganov@google.com> |
Correctly update the source of recurring subtree change accessibility events.
Change-Id: I0b0fd9224a5208b274e5c889a27417ef13579849
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| e89f48bfb1ed3a2e9241052b665a41fd2a8898cb |
|
18-Jun-2013 |
Svetoslav <svetoslavganov@google.com> |
Crash in ViewRootImpl when accessibility is on.
We fire view subtree mutation events every X amount of time.
It was possible that the runnable that fires an event to be
scheduled more than once while this should not happen. As
a result there was a crash since we did not expect to have
a second run and nullified a reference.
bug:9422804
Change-Id: I914e163b026cd217e1536ab0ed3a6b11113c2c73
/frameworks/base/core/java/android/view/ViewRootImpl.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/ViewRootImpl.java
|
| 4969fecf074c3e38dc560aaa283868ea728be946 |
|
14-Jun-2013 |
Romain Guy <romainguy@google.com> |
Merge "Fix possible NPE when a ViewRoot doesn't have a view"
|
| 70d4c5a0fe7f3411254df99b8e84b8e633d1fd05 |
|
14-Jun-2013 |
Romain Guy <romainguy@google.com> |
Fix possible NPE when a ViewRoot doesn't have a view
Change-Id: I8f76a657fa44fc5c7e0bec3e609eaf49e269910f
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| f76c17f0cb97bfe0b8751012ba70027b6edc07fd |
|
13-Jun-2013 |
Craig Mautner <cmautner@google.com> |
Merge "Add debug for specific bug."
|
| 9e105e0a9a2fa5ca38073ed4fba0ec7fae2d5c39 |
|
13-Jun-2013 |
Craig Mautner <cmautner@google.com> |
Add debug for specific bug.
To be removed once the bug is fixed.
Change-Id: I83bd5b9fd722826c59b1178303fc4e7feb8eefd2
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 405436021da156fbe3c5d4de48bdefa564cf7fc0 |
|
13-Jun-2013 |
Romain Guy <romainguy@google.com> |
Restore buildLayer()'s old behavior; it's synchronous again
Bug #9193833
Change-Id: I4ee07e65c0a8967f0b55da030ecaad6dfc46136f
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 6b1d5a4ff220378407e19b7733e727be88b41376 |
|
10-Jun-2013 |
Svetoslav <svetoslavganov@google.com> |
Merge "Notification for changed subtree in accessibility mode not fired properly."
|
| 00dbe81fea7be57ee2ff8a97844faf1bc15a427f |
|
10-Jun-2013 |
Svetoslav <svetoslavganov@google.com> |
Notification for changed subtree in accessibility mode not fired properly.
We fire notifications that the a view subtree changed for accessibility.
In some cases the notifications were fired if accessibility is not
enabled. This is now fixed. Also the runnable for making the recurring
subtree change was not dequeued if it was pending but we received a
request which we decided to run immediately.
bug:9337912
Change-Id: I27401b3d11f81c653e8761a704ee530263b08c3a
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| f38fd8784487c72983b061fb41b2aef656ccf265 |
|
10-Jun-2013 |
Romain Guy <romainguy@google.com> |
am 7a6e1297: am 8d8fc469: Merge "Don\'t orphan footers with transient state Bug #8725945" into jb-mr2-dev
* commit '7a6e129759672f0c1b0ce462d389c0f469e7348f':
Don't orphan footers with transient state Bug #8725945
|
| b7e0f7942b97c1f88f4aa2338cbf3623fdfdad97 |
|
08-Jun-2013 |
Romain Guy <romainguy@google.com> |
Don't orphan footers with transient state
Bug #8725945
Selecting text in an EditText causes the View to have transient
state. This would in turn cause the View to be removed from its
ListView parent. When removed, the EditText would lose its
AttachInfo, causing all sorts of problems. Headers and footers
must not be removed, only detached. This is the part of the fix
in AbsListView.
Fixing AbsListView triggered a second bug: when a View is removed
from the Window manager, it would keep its parent assigned, thus
making it impossible to add it again to the window manager. When
a ViewRootImpl goes through doDie(), it must set its content view's
parent to null to properly cleanup.
Change-Id: I0489daa74f8f7fcf85526f0928f8925ec30d4f42
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 494cb689d09a82025b9d892241e62aa149ce3239 |
|
07-Jun-2013 |
Svetoslav <svetoslavganov@google.com> |
Merge "Optimizing AccessibilityNodeInfo caching."
|
| 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/ViewRootImpl.java
|
| 6254f4806dd3db53b7380e77fbb183065685573e |
|
05-Jun-2013 |
Svetoslav <svetoslavganov@google.com> |
Optimizing AccessibilityNodeInfo caching.
1. Before we were firing an accessibility event from the common
predecessor of views with accessibility related state changes
every X amount of time. These events designate that the tree
rooted at the source is invalid and should not be cached.
However, some of the state changes do not affect the view tree
structure and we can just refresh the node instead of evicting
and recaching nodes infos for views that did not change. Hence,
we need a way to distinguish between a subtree changed over a
node changed.
Adding a new event type will not work since if say two siblings
have local changes and their predecessor fires a window state
change event, the client will drop the subtree rooted at the
parent including the two views with changes. Subsequent, more
specialized events emitted from the two changed siblings will
be useless since the parent which did not changed is already
evicted from the cache. Conversely, if the specialized events
are fired from the two siblings with local changes and they
are refreshed in the cache the subsequent window state change
event from the common predecessor will force the refreshed
nodes to be evicted.
Hence, to enable distinction between node being changed and
a subtree baing changed while not changing existing behavior,
we will fire only window content change event with an additional
argument specifying what changed - node or a subtree for now.
Also if the changes are local to a view we fire the window
content changed event from the view. So, the two siblings will
fire such an event independently and the client will know that
these are local changes and can just refresh the node. If the
changes are structural, then we fire the window state change
event from the common predecessor.
2. Added the input type of a text view as one of the properties
reported by an AccessibilityNodeInfo. It is nice to prompt the
user what input is expected.
3. Added a bundle for optional information to AccessiiblityNodeInfo.
For example, it will be used for putting web specific properties
that do not map cleanly to Android specific ones in WebView.
4. AccessibilityInteractionController was not taking into account
whether the current accessibility focused node is shown before
returing it. Hence, a disconnected node would be returned and
caching it puts our cahche in an inconsistent state.
Change-Id: I8ed19cfb4a70bdd7597c3f105487f1651cffd9e0
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 608094041177193dcce7a91e8dc96a2556d29bfd |
|
23-May-2013 |
Romain Guy <romainguy@google.com> |
Merge "Add PerfHUD ES profiling capabilities"
|
| e9bc11f7121dbe373b0cbe5779ee6a12d824492c |
|
23-May-2013 |
Romain Guy <romainguy@google.com> |
Add PerfHUD ES profiling capabilities
The eglGetSystemTimeNV extension can be used to enable profiling
in PerfHUD ES. When the delta of two calls to eglGetSystemTimeNV
equals 0, we now cancels display lists updates. This allows the
tool to redraw the same frame several times in a row to run its
analysis.
For better results profiling should only be attempted after
setting viewroot.profile_rendering to true using adb shell
setprop.
Change-Id: I02e3c237418004cff8d6cb0b9a37126efae44c90
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 0c63d7c239b9288065a11543a0f2cdeb8a0c293f |
|
22-May-2013 |
Romain Guy <romainguy@google.com> |
am 469cc57c: am 2f35d244: Merge "Avoid extraneous EGL surface allocations Bug #8667873" into jb-mr2-dev
* commit '469cc57ca77687420246dd679e94eb242fcec41d':
Avoid extraneous EGL surface allocations Bug #8667873
|
| 370ab062a0a18723531258896b352d5f5dd55ae7 |
|
21-May-2013 |
Romain Guy <romainguy@google.com> |
Avoid extraneous EGL surface allocations
Bug #8667873
windowShouldResize means we need to layout the window, it doesn't mean
the dimensions of the surface have changed. We should only check the
width and the height. With this fix we can avoid a surface allocation
every time the window shade is opened or closed.
Change-Id: I8afe97b820a865723f2aab7a5aa4ddc8eaaec6e1
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 82f92ee5bddbb03f4efe348288150d133ab52e87 |
|
09-May-2013 |
Michael Jurka <mikejurka@google.com> |
am 7741b63c: am 6dee0a0f: Merge "Fix bug where thumbnails flashed more often in Recents" into jb-mr2-dev
* commit '7741b63c5a8e14b5123c4b735dc768cf55fa2ed5':
Fix bug where thumbnails flashed more often in Recents
|
| 5e6fbf269425ea182b8a46e6a33848e1645197f6 |
|
09-May-2013 |
Alan Viverette <alanv@google.com> |
am fa4c935e: am 239a0c0e: Ensure ViewRootImpl.setAccessibilityFocus() doesn\'t crash when reentrant.
* commit 'fa4c935edcfa09bb53a3aac411a285842a00ddee':
Ensure ViewRootImpl.setAccessibilityFocus() doesn't crash when reentrant.
|
| f42d9010f1c7b47ca9d5e395c767eecf4d284daa |
|
08-May-2013 |
Michael Jurka <mikejurka@google.com> |
Fix bug where thumbnails flashed more often in Recents
Bug: 8867698
Change-Id: I2773601d83507dbb55c3a1d0b723e3853e22d352
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 239a0c0e6a6fc36025fdb1c662e1c7acaec144bb |
|
08-May-2013 |
Alan Viverette <alanv@google.com> |
Ensure ViewRootImpl.setAccessibilityFocus() doesn't crash when reentrant.
Internal state must be cleared before calling any methods on the focus
host, since the method may be called again from the host and attempt to
recycle the same AccessibilityNodeInfo twice.
BUG: 8856860
Change-Id: I0410989fd6f3ce3ce29de8edebdfbf3847188843
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 3b748a44c6bd2ea05fe16839caf73dbe50bd7ae9 |
|
18-Apr-2013 |
Romain Guy <romainguy@google.com> |
Pack preloaded framework assets in a texture atlas
When the Android runtime starts, the system preloads a series of assets
in the Zygote process. These assets are shared across all processes.
Unfortunately, each one of these assets is later uploaded in its own
OpenGL texture, once per process. This wastes memory and generates
unnecessary OpenGL state changes.
This CL introduces an asset server that provides an atlas to all processes.
Note: bitmaps used by skia shaders are *not* sampled from the atlas.
It's an uncommon use case and would require extra texture transforms
in the GL shaders.
WHAT IS THE ASSETS ATLAS
The "assets atlas" is a single, shareable graphic buffer that contains
all the system's preloaded bitmap drawables (this includes 9-patches.)
The atlas is made of two distinct objects: the graphic buffer that
contains the actual pixels and the map which indicates where each
preloaded bitmap can be found in the atlas (essentially a pair of
x and y coordinates.)
HOW IS THE ASSETS ATLAS GENERATED
Because we need to support a wide variety of devices and because it
is easy to change the list of preloaded drawables, the atlas is
generated at runtime, during the startup phase of the system process.
There are several steps that lead to the atlas generation:
1. If the device is booting for the first time, or if the device was
updated, we need to find the best atlas configuration. To do so,
the atlas service tries a number of width, height and algorithm
variations that allows us to pack as many assets as possible while
using as little memory as possible. Once a best configuration is found,
it gets written to disk in /data/system/framework_atlas
2. Given a best configuration (algorithm variant, dimensions and
number of bitmaps that can be packed in the atlas), the atlas service
packs all the preloaded bitmaps into a single graphic buffer object.
3. The packing is done using Skia in a temporary native bitmap. The
Skia bitmap is then copied into the graphic buffer using OpenGL ES
to benefit from texture swizzling.
HOW PROCESSES USE THE ATLAS
Whenever a process' hardware renderer initializes its EGL context,
it queries the atlas service for the graphic buffer and the map.
It is important to remember that both the context and the map will
be valid for the lifetime of the hardware renderer (if the system
process goes down, all apps get killed as well.)
Every time the hardware renderer needs to render a bitmap, it first
checks whether the bitmap can be found in the assets atlas. When
the bitmap is part of the atlas, texture coordinates are remapped
appropriately before rendering.
Change-Id: I8eaecf53e7f6a33d90da3d0047c5ceec89ea3af0
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 058feb4e1d18bc1fcedac019d2364ebfd9a4c383 |
|
23-Apr-2013 |
Michael Wright <michaelwr@google.com> |
am 58500051: am 5fe6e4c4: Merge "Rewrite input handling for native applications" into jb-mr2-dev
* commit '585000515faacc02736f920425ae6c323223ee58':
Rewrite input handling for native applications
|
| a44dd26a75e24cc021802288fb81f4761e47be6b |
|
11-Apr-2013 |
Michael Wright <michaelwr@google.com> |
Rewrite input handling for native applications
Bug: 8473020
Change-Id: Ic4353d8924ab877bec21aff8c2dba9fe725bf906
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| cc6dda77501d0e8dd5ea267f51c02fd120476d28 |
|
13-Apr-2013 |
Mathias Agopian <mathias@google.com> |
am 4c87edfe: am 1763d6f9: Merge "always trigger a re-draw when updating the transparent region hint" into jb-mr2-dev
* commit '4c87edfe4d2dce71b7b723f25078cd4bd5d48456':
always trigger a re-draw when updating the transparent region hint
|
| 1763d6f957163faf6d3b629c36f4e8e90e0e31bd |
|
13-Apr-2013 |
Mathias Agopian <mathias@google.com> |
Merge "always trigger a re-draw when updating the transparent region hint" into jb-mr2-dev
|
| 54e3d38490b60cd776ad3b988d923241498816e2 |
|
13-Apr-2013 |
Mathias Agopian <mathias@google.com> |
always trigger a re-draw when updating the transparent region hint
since SF now relies on receiving a frame for latching the
transparent region hint, we make sure we will indeed redraw
something.
Bug: 8581533
Change-Id: Ia12ddf5654a7deeac7628b799bfde4b8c16c992b
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| ffe0c56c29fb3e981f954cc822dddd84d9e3bbb8 |
|
12-Apr-2013 |
Craig Mautner <cmautner@google.com> |
am 429664a5: am d5e7b8bf: Merge "Clear test rectangle if previous focus is null." into jb-mr2-dev
* commit '429664a52ab0d024757650a246297ae8224e60dc':
Clear test rectangle if previous focus is null.
|
| d5e7b8bfb4381baa36feb241bc65d4681f664592 |
|
12-Apr-2013 |
Craig Mautner <cmautner@google.com> |
Merge "Clear test rectangle if previous focus is null." into jb-mr2-dev
|
| 26a84dfdd09011d6a93a3758f794e4585bf10c3d |
|
12-Apr-2013 |
Craig Mautner <cmautner@google.com> |
Clear test rectangle if previous focus is null.
A bug in FolderEditText or DynamicLayout (b/8600683) was causing
the 'rectangle' parameter passed to scrollToRectOrFocus() to be
roughly 1000 feet to the right of the screen.
This bug is normally masked because the focus found in
mLastScrolledFocus never matches the new focus and consequently
the misleading 'rectangle' is nulled. However, on the first
time in to scrollToRectOrFocus when returning to Launcher
from another app, mLastScrolledFocus is null and the code
skips over the place where 'rectangle' is nulled. Without this
clearing it was determined that 'rectangle' was outside the viewable
area and scrolling not required. This is bug 8547155.
This change causes even null values of mLastScrollFocus to be
compared to the new focus thus masking the bug in all situations.
Bug 8600683 will be fixed in a separate CL.
Fixes bug 8547155.
Change-Id: Ic6cb22c42b0e93a9793dd2babc25727c2ba29155
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 0f3e023b637fb6cd60ff6b3add527cee29463a27 |
|
11-Apr-2013 |
Michael Wright <michaelwr@google.com> |
am af543eb0: am 8881455a: Merge "Send joystick key repeat messages to correct handler" into jb-mr2-dev
* commit 'af543eb050546e2197bd54db7cf257e053add4c2':
Send joystick key repeat messages to correct handler
|
| b9618523add13ca3835bbdaf83b8c2313ae277a2 |
|
11-Apr-2013 |
Michael Wright <michaelwr@google.com> |
Send joystick key repeat messages to correct handler
Change-Id: I7f8dbe21c9088553ad2c5efe70585f516ab78141
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 54977db25a46edb0fb0467a41498e6aad8380acc |
|
10-Apr-2013 |
Jeff Brown <jeffbrown@google.com> |
am 55198db2: am 4dac901f: Rewrite touch navigation dpad synthesis.
* commit '55198db2dbb55d4f9ac18db81cc05c553b6c6d23':
Rewrite touch navigation dpad synthesis.
|
| 4dac901f011e7c15882e260441225633a6435e49 |
|
10-Apr-2013 |
Jeff Brown <jeffbrown@google.com> |
Rewrite touch navigation dpad synthesis.
The new implementation more accurately tracks the velocity
of flings and takes care to avoid obvious discontinuities.
The main goal is for a fling to appear to be a linear
extension of the movement already in progress. The minimum
fling velocity is set to ensure that flings appear to be
fairly smooth despite being discretized.
Use sequences of repeated key events instead of individual
down/up events to represent continuous motions in one
direction which can be helpful for stopping flings at boundaries
such as when flinging the cursor position within a text view.
Compute the movement thresholds based on the physical
size of the touch pad, if known. If not known, we assume a
nominal size.
Support stopping flings with a tap just like we do for
normal touch events elsewhere in the framework.
Moved the detection of ASSIST swipes into the InputReader
where it belongs. These swipes must be detected globally
to ensure consistent behavior across the all applications.
Added a custom protocol in EventHub to enable input device
drivers to override the timestamp of the following events
in a packet. This change enables input device drivers
that have a better idea of when an input event was actually
generated to pass this information to the input system.
Particularly useful with uinput.
Bug: 8583760
Change-Id: I8ef4e827804786d549cfaa00793a2b9dd0fda465
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 82c0edaad3ff9da2e28cd17520168e603fe394d5 |
|
10-Apr-2013 |
Jeff Brown <jeffbrown@google.com> |
am f1cee03b: am 678a1252: Split up the event synthesis code by source.
* commit 'f1cee03bf0e5d3144947609a23665d950e385635':
Split up the event synthesis code by source.
|
| 678a1252b4f3cdc18d20b411c05a4320d1d9b719 |
|
10-Apr-2013 |
Jeff Brown <jeffbrown@google.com> |
Split up the event synthesis code by source.
The goal is to better encapsulate this code to make it easier
to maintain and to facilitate some upcoming changes.
Some of the variables have been renamed but the logic is unchanged.
Bug: 8583760
Change-Id: I45501f7dabebcb938e42c386291d615d088a4c8c
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 8140b05f1e4dfce773ce340b157fccda769b41d2 |
|
09-Apr-2013 |
Jeff Brown <jeffbrown@google.com> |
am 9acc8c9c: am 97b968b6: Merge "Fix trackball interpretation of precision." into jb-mr2-dev
* commit '9acc8c9c53a4d3adcf3e3f220ea5e4529c3e60a4':
Fix trackball interpretation of precision.
|
| b437a79b050e8928ce7187899b7754f049008085 |
|
09-Apr-2013 |
Jeff Brown <jeffbrown@google.com> |
resolved conflicts for merge of 21dffd5d to master
Change-Id: I37c48dee471c9d43f19c1fe4a01f70db53e2441f
|
| 97b968b6b3baf40e8cfd5ff147f81cd81398638a |
|
09-Apr-2013 |
Jeff Brown <jeffbrown@google.com> |
Merge "Fix trackball interpretation of precision." into jb-mr2-dev
|
| 3a2854bcee08e3af3ca1b042c1fef6ca68f8c70a |
|
09-Apr-2013 |
Jeff Brown <jeffbrown@google.com> |
Merge "Queues, queues, queues and input." into jb-mr2-dev
|
| c574b68cbb3d6cf20ef7e73fef9c145de93df3de |
|
09-Apr-2013 |
Jeff Brown <jeffbrown@google.com> |
Fix trackball interpretation of precision.
The trackball to dpad synthesis was using the MotionEvent's precision
field to determine a threshold for movement but the calculations
involved did not actually make sense for any value of precision
less than 2.0. This worked fine before since the InputReader
hardcodes the trackball's precision to 6.
Injected trackball events may have a different precision which can
result in the thresholds being set inappropriately. For example,
it was not possible to move focus by one unit at a time when
the precision was set to 1.0.
The old code was probably using precision as a way to set a
threshold based on the trackball moving by some minimum number
of physical ticks, in this case 2. But the code will work just
as well if we set an absolute threshold based on distance
traveled given that the input system is already expected to
normalize the trackball movements before delivering them to the
application.
So stop using precision.
Bug: 8473020
Change-Id: I3c6f7fb1b507f8cf5608b47550e7345fea3352fa
/frameworks/base/core/java/android/view/ViewRootImpl.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/ViewRootImpl.java
|
| 49084108f20e3f3737cb6fa1c1635a6ba348f159 |
|
05-Apr-2013 |
Romain Guy <romainguy@google.com> |
am 9ff408c1: am faec826b: Merge "Reduce the size of dirty invalidates" into jb-mr2-dev
* commit '9ff408c17be8cccc9820d46b207673be22bfbe84':
Reduce the size of dirty invalidates
|
| faec826bd6051e41e1299cd14d580a4f50f6fe97 |
|
05-Apr-2013 |
Romain Guy <romainguy@google.com> |
Merge "Reduce the size of dirty invalidates" into jb-mr2-dev
|
| e55945e219dbf4664683a757c5a9d462c98f2e19 |
|
05-Apr-2013 |
Romain Guy <romainguy@google.com> |
Reduce the size of dirty invalidates
Remove remnants from times long gone. We don't need to redraw the
union of the previous frame's dirty region and the new dirty
region.
Change-Id: I9fb96f99a6a72c2233f9ca563cf6432a42b2b65b
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| e4d9a01bfc7451afff1ed399a5801c7aa2af2831 |
|
29-Mar-2013 |
Dan Morrill <morrildl@google.com> |
Phase 1 of refactoring SystemServer.
SystemServer is currently a monolithic class that brings up key system
services. This change is the first phase of refactoring it to be more
configurable. Specifically, it adds a set of on/off switches used to control
startup of individual services. Future plans include finer grained controls
and a more explicit and consistent startup sequence for these services.
Change-Id: I7299f5ce7d7b74a34eb56dffb788366fbc058532
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| c99d3c1fd618c1f64103b4f39dd95330309be5a3 |
|
30-Mar-2013 |
Chet Haase <chet@google.com> |
Stop jank from window animations overlapping activity animations
Relaunching a running activity will sometimes cause animations in that
activity to run, causing jank due to too much happening (window animations
on that same window running at the same time).
An earlier fix pauses application rendering while window animations are running,
but only the first time the activity comes up. If the window is animated
after that (such as is the case with re-launching it while it is running
in the background), rendering, and therefore animations, happen as usual,
causing the jank.
The fix is to simply broaden the scope of when application rendering is
paused to include anytime the window is animating.
Issue #8472972 Make app animations play nice with window animations
Change-Id: I1dd8da039fcb4d1faf6c0811bae97ef2847deb84
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| bf02096088ffff97738e9f9f01054a730d2f219f |
|
29-Mar-2013 |
Michael Wright <michaelwr@google.com> |
Finish any event in the current input queue
When the pipelining optimization was added we never updated
handleImeFinishedEvent to look through the whole queue of items, so it was only
looking at the head.
Bug: 8498214
Change-Id: I79c62392a93b47e3e1eab3f4fe54a5c999dfb566
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| ca3d655d20c13c71972a4475cec3b98efa7dbdd0 |
|
27-Mar-2013 |
Jeff Brown <jeffbrown@google.com> |
Merge "Use input transport for communications between app and IME." into jb-mr2-dev
|
| c28867a1d67121ce5963de135e3ae2b1dbd9a33d |
|
26-Mar-2013 |
Jeff Brown <jeffbrown@google.com> |
Use input transport for communications between app and IME.
The input method manager service now supplies an input channel for
communication while creating an IME session on behalf of the
application.
This change significanly reduces the overhead of IME event dispatch
by using a standard input channel to send input events rather than
using binder. This results in fewer thread context switches
and fewer object allocations.
What's more, the IME may perform additional batching of the motion
events that it receives which may help it catch up if it is
getting behind while processing them.
Bug: 7984576
Bug: 8473020
Change-Id: Ibe26311edd0060cdcae80194f1753482e635786f
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 40f8f0d1366e8ba47a17376e51c9fc7291ffdc16 |
|
26-Mar-2013 |
Michael Wright <michaelwr@google.com> |
Deliver key repeats for artificial dpad events
Bug: 8425219
Change-Id: Ib41b06ed40d43f2e30ce2a647871a76cea80177b
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 53d13667e39f12644d03278c33298351ac68ec26 |
|
21-Mar-2013 |
Michael Wright <michaelwr@google.com> |
Fix log tags in trackball debugging
Change-Id: I02a623c96aff8b6ffbe11161feea39ad26ba0e83
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 1a89c5324badd10dac142a5a0c40a203503db65f |
|
23-Mar-2013 |
Dianne Hackborn <hackbod@google.com> |
Merge "New media button API." into jb-mr2-dev
|
| 961cae92540763226648813d111c5b5c3b0f1597 |
|
20-Mar-2013 |
Dianne Hackborn <hackbod@google.com> |
New media button API.
This allows sending media buttons to any PendingIntent,
so they can be captured with a registered receiver.
Also add some new ViewTreeObserver APIs; this is all for
a new support library API to watch media buttons while an
app has input focus.
Change-Id: I3c51cef59460662b008c9a2cc87d6a6383c21855
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| c8a7e54fefbb70341427fe5b384447f30e1816f2 |
|
21-Mar-2013 |
Michael Wright <michaelwr@google.com> |
Add pipelining optimization to IME dispatching
Rather than wait for the IME to return before sending it the next input event,
send all available input events as soon as we receive them.
Bug: 7984576
Change-Id: Ie0b1086efc4f9e1ececac22afd997829304bf180
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 95ae9429ee3555f4a1f396da423413ba496bdf33 |
|
14-Mar-2013 |
Michael Wright <michaelwr@google.com> |
Add tracing for pending queue size
Change-Id: Ib31c2245feca31d0276ef1ebf6e6d237d0297671
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| b38258f357a7857ce5d53caad0af9c38053ab071 |
|
15-Mar-2013 |
Chet Haase <chet@google.com> |
Merge "Fix erroneous requestLayout-during-layout issues" into jb-mr2-dev
|
| 107a48236ad73cf4627069edbeaa45a189e0d8ac |
|
13-Mar-2013 |
Chet Haase <chet@google.com> |
Fix erroneous requestLayout-during-layout issues
In general, calling requestLayout() during layout is a Bad Idea.
However, ListView does this during the normal course of its layout, as it
removes and adds views during layout. However, it handles this properly,
ensuring that the views in its hierarchy are all measured and laid out
properly by the time its layout process is done.
A previous fix to the request-during-layout issue attempted to distinguish
the correct from incorrect behavior by checking whether views had been properly
laid out since the requestLayout() call, and making sure the views were
visible in the hierarchy (parented, attached, and !GONE), since otherwise
the views would not be laid out, the flags wouldn't be cleared, and requests
are superfluous anyway. However, this logic only checked whether the
requesting views were GONE, whereas the check should include the entire
parent hierarchy of the views (since a view with a GONE parent is still not
visible to the user).
This fix adds that additional check and cleans up other parts of the previous
code, such as not bothering to post() requests that occur during the second
layout pass unless those requests are also valid (coming from visible views).
Issue #8370042 Path seems to be in an infinite layout loop
Change-Id: I7aaf701229adfeee349a9a7c9ec14585735ba9f6
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| e7a9ae8ba0fb7fc61960e3facd0c5534e9ffce1e |
|
09-Mar-2013 |
Michael Wright <michaelwr@google.com> |
Add touch navigation input source
Bug: 8276741
Change-Id: I674b9804bf9ae76d694ae7073b54a7d43474a43c
/frameworks/base/core/java/android/view/ViewRootImpl.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/core/java/android/view/ViewRootImpl.java
|
| 52036b19a5f82bc4d75cfcbff99c65df8d25a99b |
|
15-Feb-2013 |
Romain Guy <romainguy@google.com> |
Expose display list APIs
The exposed APIs are slightly simpler than the full APIs used internally.
Only APIs useful to applications are exposed.
Change-Id: Ie03014628d40ad5ef63dedbc52ce3def84429d54
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 9dd4c5c6867f8b6de19096d2d68365dccb744c19 |
|
09-Feb-2013 |
Fabrice Di Meglio <fdimeglio@google.com> |
Fix bug #7381967 Add RTL APIs to ViewParent
- add RTL apis to ViewParent
- remove awful and performance bottleneck casts in View during LayoutDirection,
TextDirection and TextAlignment resolutions.
Change-Id: I92a56b16382e13c28c1dad35f6f205620eb01bfe
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 39938752b368ae282b821a43efbc568c925ecc34 |
|
09-Feb-2013 |
Jeff Brown <jeffbrown@google.com> |
Fix build break due to merge.
Change-Id: I08c39690ee9de825ff51afc7d102ee622af6ba13
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| e624e0c70409773df6c3eb274852f9dd7961f025 |
|
09-Feb-2013 |
Jeff Brown <jeffbrown@android.com> |
am 110fe9b3: am fe1f3a1b: Merge "Fix ViewRootImpl to find missing focus using D-pad."
# By Ki-Hwan Lee
# Via Android Git Automerger (1) and others
* commit '110fe9b303be527c30a8af95b6fb7afac12968b5':
Fix ViewRootImpl to find missing focus using D-pad.
|
| 110fe9b303be527c30a8af95b6fb7afac12968b5 |
|
09-Feb-2013 |
Jeff Brown <jeffbrown@android.com> |
am fe1f3a1b: Merge "Fix ViewRootImpl to find missing focus using D-pad."
# By Ki-Hwan Lee
# Via Gerrit Code Review (1) and Ki-Hwan Lee (1)
* commit 'fe1f3a1beff9f73f6a04bcc35239038a21bc38ff':
Fix ViewRootImpl to find missing focus using D-pad.
|
| ccac8c95577aeb2c327c090678011733fa24fba4 |
|
07-Feb-2013 |
Chris Craik <ccraik@google.com> |
Merge "Correctly resume profileRendering"
|
| ae4f3204ec2c9251e0e408816e74502079cd1a6c |
|
07-Feb-2013 |
Chris Craik <ccraik@google.com> |
Correctly resume profileRendering
Ensure profileRendering reschedules a previously created profiler callback if
disabled and reenabled
Change-Id: I181ac5043966b99bb8d21e69ce4fdd7494102acb
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| c2293025a25e04b26bf53713d71f85fd9ca5e8e9 |
|
07-Feb-2013 |
Dianne Hackborn <hackbod@google.com> |
App ops: track system windows, monitoring changes.
Change-Id: I273e82bdad66ada3bf0f7ec9176bc304b9ee1ee8
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 4ef158baa3382909c436cbc31e123ef981387e4e |
|
08-Jan-2013 |
Ki-Hwan Lee <kihwanl@google.com> |
Fix ViewRootImpl to find missing focus using D-pad.
By using D-pad, no-focus in non touch mode is rare but legal in a case like below.
1. The first request to get focus for a new activity is handled in the first
performTraversals() call when activity is not ready for a complete view hierarchy.
So there might be no focusable yet.
2. If the activity has some menus, ActionMenuView can be attached to the view hierarchy
in the PhoneWindow.preparePanel() soon.
So there can be focusables but still not focused.
Fixed ViewRootImpl.deliverKeyEventPostIme() to handle this case to resurrect a focus
if there are focusables.
How to reproduce:
(1) Open "API Demos" application -> Views -> Search View
(2) Select "Action Bar" item using the D-pad
(3) Try to focus the Search View, using the D-pad.
Change-Id: Ic379774f0307f168f0ed775d0f6a9078ac5c9713
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| ef35927abcd089652f87a985dd6dde7afde58b92 |
|
01-Feb-2013 |
Romain Guy <romainguy@google.com> |
Tag HardwareRenderers with a name to help debugging
The name of the renderer is the same as the window it belongs to.
Change-Id: Ie9adc0a1978afa026923ea41f5540eda6ba65a92
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| d0fd54648ca6249f56cf469c57181b5a7bbb71d0 |
|
29-Jan-2013 |
Svetoslav Ganov <svetoslavganov@google.com> |
Merge "Adding UI test automation APIs."
|
| 3696779bca4e5bc1b60c056db6f892e72e51a20f |
|
28-Jan-2013 |
Romain Guy <romainguy@google.com> |
Reinitialize hardware renderer after eglTerminate()
Bug #8066455
ViewRootImpl was properly detecting that the renderer was not
ready to draw but would simply schedule another frame, thus sending
the systemui into an inifite redraw loop. This change reinitializes
the renderer if needed (if the renderer is requested but not enabled.)
This CL also fixes an issue caused by the default wallpaper. Since it
never calls eglTerminate(), managed contexts are never reclaimed.
Change-Id: Idb8caa672be8ee35f6e6a7e942d9abd8aa100967
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 80943d8daa6ab31ab5c486d57aea406aa0730d58 |
|
02-Jan-2013 |
Svetoslav Ganov <svetoslavganov@google.com> |
Adding UI test automation APIs.
This change adds APIs support for implementing UI tests. Such tests do
not rely on internal application structure and can span across application
boundaries. UI automation APIs are encapsulated in the UiAutomation object
that is provided by an Instrumentation object. It is initialized by the
system and can be used for both introspecting the screen and performing
interactions simulating a user. UI test are normal instrumentation tests
and are executed on the device.
UiAutomation uses the accessibility APIs to introspect the screen and
a special delegate object to perform privileged operations such as
injecting input events. Since instrumentation tests are invoked by a shell
command, the shell program launching the tests creates a delegate object and
passes it as an argument to started instrumentation. This delegate
allows the APK that runs the tests to access some privileged operations
protected by a signature level permissions which are explicitly granted
to the shell user.
The UiAutomation object also supports running tests in the legacy way
where the tests are run as a Java shell program. This enables existing
UiAutomator tests to keep working while the new ones should be implemented
using the new APIs. The UiAutomation object exposes lower level APIs which
allow simulation of arbitrary user interactions and writing complete UI test
cases. Clients, such as UiAutomator, are encouraged to implement higher-
level APIs which minimize development effort and can be used as a helper
library by the test developer.
The benefit of this change is decoupling UiAutomator from the system
since the former was calling hidden APIs which required that it is
bundled in the system image. This prevented UiAutomator from being
evolved separately from the system. Also UiAutomator was creating
additional API surface in the system image. Another benefit of the new
design is that now test cases have access to a context and can use
public platform APIs in addition to the UiAutomator ones. Further,
third-parties can develop their own higher level test APIs on top
of the lower level ones exposes by UiAutomation.
bug:8028258
Also this change adds the fully qualified resource name of the view's
id in the emitted AccessibilityNodeInfo if a special flag is set while
configuring the accessibility service. Also added is API for looking
up node infos by this id. The id resource name is relatively more stable
compared to the generaed id number which may change from one build to
another. This API facilitate reuing the already defined ids for UI
automation.
bug:7678973
Change-Id: I589ad14790320dec8a33095953926c2a2dd0228b
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| ebf7c74361baefb826591bd90cdacd9244a2eb59 |
|
18-Jan-2013 |
Dake Gu <dake@google.com> |
am 85a06152: am fe88f1be: Merge "Fix bug of SimulatedTrackball" into jb-mr1-aah-dev
* commit '85a06152ce9b7d3a198639eb1918a9c2a3fd34d4':
Fix bug of SimulatedTrackball
|
| f8739b992f53fdd2e4be73ee10716df32434100a |
|
17-Jan-2013 |
Dake Gu <dake@google.com> |
Fix bug of SimulatedTrackball
Simulated trackball should not generate KeyEvent if dispatchGenericMotionEvent
returns true
b/8022205
Change-Id: I1857e25407c508c98ef4db85fe146b1e25a0803e
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 9afb2e1a95b92d5dfb0612bbb606a09aa528ee5d |
|
14-Jan-2013 |
Jeff Brown <jeffbrown@google.com> |
Optimize focused input event dispatch in view root. DO NOT MERGE
The efficiency of key, trackball and generic motion event
dispatch is greatly influenced by the IME dispatch cycle.
This change simplifies the dispatch of focused input events
and avoids causing event processing to be requeued on the
handler and delayed unnecessarily.
Bug: 7984576
Change-Id: Id82624a3f32c05efe6ee5c322bd55bf2ab21525d
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 22a94cb03ad39c5256608e4954fe4e85179d9ed6 |
|
15-Jan-2013 |
Jeff Brown <jeffbrown@google.com> |
Merge "Optimize focused input event dispatch in view root."
|
| 29c0ed2c130521ce1b648dd517a0d25457004de3 |
|
14-Jan-2013 |
Jeff Brown <jeffbrown@google.com> |
Optimize focused input event dispatch in view root.
The efficiency of key, trackball and generic motion event
dispatch is greatly influenced by the IME dispatch cycle.
This change simplifies the dispatch of focused input events
and avoids causing event processing to be requeued on the
handler and delayed unnecessarily.
Bug: 7984576
Change-Id: Id82624a3f32c05efe6ee5c322bd55bf2ab21525d
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 149567f9d59a07a9d7793ea455ff4c2586c3ae53 |
|
09-Jan-2013 |
Svetoslav Ganov <svetoslavganov@google.com> |
Fixing a memory leak in ViewRootImpl and a focus change callback issue.
1. ViewRootImpl was keeping reference to the old focused view so it can
call back the global on focus change listener when another view gets
focus. The stashed reference, however was not cleared which caused a
memory leak if the last focused view was removed from the view tree.
In general keeping additional state for the last focus in ViewRootImpl
is not a good idea since this add complexity due to additional book
keeping work that is required. The view tree already keeps track of
where the focus is and it should be the only place that holds this
data. Since focus does not change that frequently it is fine to look
up the focus since this operation is O(m) where m is the depth of the
view tree. This change removes the duplicate book keeping from
ViewRootImpl and the focus is looked up as needed.
2. ViewRootImpl was calling the global focus change callbacks when focus
is gained, lost, or transferred to another view. This was done in
*ChildFocus methods. In the case of a child losing focus, i.e. in
clearChildFocus, there was a check whether focus searh yields a view
to take focus and if so it did not call back the global focus listener
assuming the the found view will take focus (the view tree gives focus
to the first focusable when a view looses focus). This is not a correct
assumption since some views override methods called as a result of
View.requestFocus that determine what the next focused view should
be. For example, HorizontalScrollView overrides onRequestFocusInDescendants
and changes the direction of the search. In fact focus search does not
take into accound ViewGroup descendant focusability. Hence, the view found
by calling the focus search from the root is not necessarily the one
that will get focus after calling requestFocus. Actually, it is
possible that the focus search will find a view but no view will
take focus. Now the View class is responsible for calling the
global focus listeners which avoids the above problem. Also this
saves book keeping in ViewRootImpl.
bug:7962363
Change-Id: Ic95a18b364e997021f3f6bb46943559aac07d95a
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| e422737fda48f73cdd74800c9a9b9d15d0186b6d |
|
19-Dec-2012 |
Justin Koh <justinkoh@google.com> |
am a90c92a1: am 86903699: Merge "Start RecognitionActivity with an upswipe gesture." into jb-mr1-aah-dev
* commit 'a90c92a1c97830de5e1766bb64ff421a2a50ed56':
Start RecognitionActivity with an upswipe gesture.
|
| cc699b4fe396b3f93d45211d0df6f02baa325b2f |
|
13-Dec-2012 |
Chet Haase <chet@google.com> |
Fix for requestLayout-during-layout inefficiencies
An earlier fix made it possible to call requestLayout() during layout
(which is not recommended in most cases outside of a ListView) without
ending up with blank content and internal layout flags in a confused state.
However, that fix incorrectly detected a problem in some cases (such as
ListView practices of adding views during layout) which were actually okay;
as long as you make sure to measure and layout your children properly
before returning from layout(), then it's not a problem. We were improperly
spamming the log with supposed problems, and causing more overhead in correct
cases by running a full request/measure/layout pass after the first layout
pass, all of which is unnecessary in cases where the containers know what
they're doing.
This new fix changes the logic to only cause the second layout pass (and third,
posted to the next frame, if things are really done incorrectly) if the layout-request
flags are still set on the requesting views after the full layout pass is complete.
This situation causes the blank screens we've seen in buggy apps, and is exactly
what we should avoid. However, correct cases (e.g., ListView) will not have these
problems because they run measure/layout correctly after the request calls, which
clears these flags. The upshot is that buggy cases will be detected and compensated for
(by clearing the flags and then running a second request/measure/layout pass, as in the
original fix) and non-buggy cases will be noop'd, going back to their previous, working
logic flow.
The bug below is one of the buggy apps to demonstrate this problem. I noticed that the
original problem (blank screen) is no longer reproducible. I suspect that logic was
added to the app to force a refresh after it is attached. You can still detect the problem
(and the fix) by seeing that prior to the fix (say, on mr1.1) there is a delay of about
a second between the end of the progress bar updates and the showing of content on a
screen that used to just remain blank. With the fix (both the previous version and this
one), the content is updated immediately, because we now handle the buggy request-
during-layout situation in the same frame as it occurs.
Issue #6914123 News and Weather app sometimes loads to a blank screen
Change-Id: I4c34817cc3dd44ba422ff50de4321624c0824d83
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 05cb363bf3e714d0a5fb1bc97dfed639c9c9f950 |
|
12-Dec-2012 |
Ben Pietrzak <bpietrzak@google.com> |
Start RecognitionActivity with an upswipe gesture.
Change-Id: I7dd91bef3eb551bb7617307cc9a4777226b5ded7
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| ee0ff18c36ff27977a868c4a6ea695a21723f52b |
|
04-Dec-2012 |
Romain Guy <romainguy@google.com> |
Merge "Optimize onAttachedTo/onDetachedFromWindow"
|
| fbb93fa2f3abf8b50ea945a319c0a190f2aae213 |
|
04-Dec-2012 |
Romain Guy <romainguy@google.com> |
Optimize onAttachedTo/onDetachedFromWindow
Apps detaching/attaching large subtrees would waste a few milliseconds
dealing with dirty display lists. This change removes the need to do
ArrayList.remove() on every detachedFromWindow().
Change-Id: Icee72516c40d48ff0fd9d6f3128589f99bf61428
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 2c5f782094c5668a9615e2f9f41063386ae52b28 |
|
04-Dec-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Merge "Refactoring of the screen magnification feature."
|
| 152e9bb81aa5b2ab4637f4b2dae04b3ce89fa891 |
|
13-Oct-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Refactoring of the screen magnification feature.
1. The screen magnification feature was implemented entirely as a part of the accessibility
manager. To achieve that the window manager had to implement a bunch of hooks for an
external client to observe its internal state. This was problematic since it dilutes
the window manager interface and allows code that is deeply coupled with the window
manager to reside outside of it. Also the observer callbacks were IPCs which cannot
be called with the window manager's lock held. To avoid that the window manager had
to post messages requesting notification of interested parties which makes the code
consuming the callbacks to run asynchronously of the window manager. This causes timing
issues and adds unnecessary complexity.
Now the magnification logic is split in two halves. The first half that is responsible
to track the magnified portion of the screen and serve as a policy which windows can be
magnified and it is a part of the window manager. This part exposes higher level APIs
allowing interested parties with the right permissions to control the magnification
of a given display. The APIs also allow a client to be registered for callbacks on
interesting changes such as resize of the magnified region, etc. This part servers
as a mediator between magnification controllers and the window manager.
The second half is a controller that is responsible to drive the magnification
state based on touch interactions. It also presents a highlight when magnified to
suggest the magnified potion of the screen. The controller is responsible for auto
zooming out in case the user context changes - rotation, new actitivity. The controller
also auto pans if a dialog appears and it does not interesect the magnified frame.
bug:7410464
2. By design screen magnification and touch exploration work separately and together. If
magnification is enabled the user sees a larger version of the widgets and a sub section
of the screen content. Accessibility services use the introspection APIs to "see" what
is on the screen so they can speak it, navigate to the next item in response to a
gesture, etc. Hence, the information returned to accessibility services has to reflect
what a sighted user would see on the screen. Therefore, if the screen is magnified
we need to adjust the bounds and position of the infos describing views in a magnified
window such that the info bounds are equivalent to what the user sees.
To improve performance we keep accessibility node info caches in the client process.
However, when magnification state changes we have to clear these caches since the
bounds of the cached infos no longer reflect the screen content which just got smaller
or larger.
This patch propagates not only the window scale as before but also the X/Y pan and the
bounds of the magnified portion of the screen to the introspected app. This information
is used to adjust the bounds of the node infos coming from this window such that the
reported bounds are the same as the user sees not as the app thinks they are. Note that
if magnification is enabled we zoom the content and pan it along the X and Y axis. Also
recomputed is the isVisibleToUser property of the reported info since in a magnified
state the user sees a subset of the window content and the views not in the magnified
viewport should be reported as not visible to the user.
bug:7344059
Change-Id: I6f7832c7a6a65c5368b390eb1f1518d0c7afd7d2
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 3efa7b597c9d95d47c6d31b73da05117d6d5d244 |
|
03-Dec-2012 |
Chet Haase <chet@google.com> |
Fix requestLayout-during-layout problems
An earlier fix to allow requestLayout() to be called during layout
didn't handle some of the requests properly, leaving some nodes
stranded with layout requests that didn't propagate all the way
up the hierarchy. The fix is to do, on the second layout pass, exactly
what we do in a normal layout pass: run measure, then layout.
Issue #7657033 Checkboxes not being updated immediately in Settings
Change-Id: I90be3992d3441e8f43629d26c8386c81a7c31482
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 5bb3c730f5ebd2a0db1b02a8981c6fdbea6c1a2e |
|
30-Nov-2012 |
Romain Guy <romainguy@google.com> |
Apply dev. settings at runtime
Bug #7434649
Change-Id: I16f00eaa8a5eefd9f9849e196cf2cb1659215390
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| d075031944171139c1235bbc96c9533eaeeceb08 |
|
29-Nov-2012 |
Romain Guy <romainguy@google.com> |
Improve profiling by using Choreographer
This will avoid jank and lead to better measurements.
Change-Id: Id18587a0a0b7d45adb3a65dfc427800565cc5d0b
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| abae2a1b891772d36d8f781adfcc8969e551691f |
|
28-Nov-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Simplification of the poolable management utils.
Before to implement a pool of objects, the pooled class had to implement an
interface which was leaking the pool management APIs. This requires
hiding APIs - inconvenient at best. Further, each client had to
implement the chaining of pooled instances which means adding a couple
of member variables which are manipulated by the implemented interface
methods. As a consequence the client is aware of how pooling is
implemented which is error prone and breaks encapsulation. Now the
pool objects are responsible for managing pooling state via reusable
wrapper objects and the clients are oblivious of how pooling is done.
Creating a thin cached wrapper for each pooled object has minimal
performance impact while making the code more maintainable. Actually
implementing of the old version of the APIs was taking as much code
as implementing the pooling yourself.
Also clients had to implement a poolable manager whose responsibility
was to create new instances and provide callbacks when an instance
is added to or removed from the pool. Now, the clinet class should
create a static member for the pool and expose obtain/aquire and
release/recycle methods in which it should create a new instance if
the pool did not return one and clear the state of the host when
it is returned to the pool. Updated the JavaDoc with a best practice.
The pooling was composed of several interfaces and classes scattered
over a few files, now all this is in a single small file.
Update all usages of the pooling APIs in the framework.
Also one had to write a poolable
manager which
Change-Id: Ib8dc286040eb3d7cb7d9668ba76fead05cb97647
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| d5a835259d1dd79893f043ce4813e3d24b6e54d5 |
|
22-Nov-2012 |
Chet Haase <chet@google.com> |
Fix layout-in-layout logic
Fix to allow requestLayout() during layout needs to disable
the "currently doing layout" flag while it processes the requests
that came in during layout to allow these initial requests to go
through unhindered.
Change-Id: Ied5ff1589224792f153cc10f65e004f14724523d
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| b104b202bdf7998018b21dcad96059eded9f7ef9 |
|
02-Nov-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
am cb5c66b9: am 5e27e55a: am 28e8f76c: Merge "Cannot click on partially visible views in touch exploration." into jb-mr1-dev
* commit 'cb5c66b9c1602b750bb481641253604ba3d59ac6':
Cannot click on partially visible views in touch exploration.
|
| 5e27e55aecea63c6cf0477ab75f4c39b7b68c9cd |
|
02-Nov-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
am 28e8f76c: Merge "Cannot click on partially visible views in touch exploration." into jb-mr1-dev
* commit '28e8f76c50b26efd657bc0740fee25ac18520f9e':
Cannot click on partially visible views in touch exploration.
|
| a94c3194ffa896632f025b983ca57095cd4ba277 |
|
01-Nov-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Cannot click on partially visible views in touch exploration.
1. In touch exploration mode the system clicks in the center of the
accessibility focus rectangle. However, if this rectangle is only
partially shown on the window or on the screen the system may not
be able to perform the click, if the accessibility focus center
is not on the screen, or click on the wrong window, if the access
focus center is outside of the window.
This change clips the rectangle to the window bounds which and the
display bounds. This will ensure no clicks are sent to the wrong
window and no clicks are sent outside of the screen.
bug:7453839
Change-Id: I79f98971e7ebcbb391c37284467dc76076172c5f
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 990c1b7f3e8f3f63f3362c8eae263ddbb7050f95 |
|
24-Oct-2012 |
Craig Mautner <cmautner@google.com> |
am a170dcb7: am 9e96c69e: am 6757572b: Merge "Add throwing InvalidDisplayException from addView." into jb-mr1-dev
* commit 'a170dcb7b6908d0ea4dd7c2717d2d2b1da59262c':
Add throwing InvalidDisplayException from addView.
|
| 9e96c69e3e9ebdb820acd347b4691c32a5d76be4 |
|
24-Oct-2012 |
Craig Mautner <cmautner@google.com> |
am 6757572b: Merge "Add throwing InvalidDisplayException from addView." into jb-mr1-dev
* commit '6757572b39d3802c4d7b69467b5ebf69a96c208b':
Add throwing InvalidDisplayException from addView.
|
| 6757572b39d3802c4d7b69467b5ebf69a96c208b |
|
24-Oct-2012 |
Craig Mautner <cmautner@google.com> |
Merge "Add throwing InvalidDisplayException from addView." into jb-mr1-dev
|
| 16a5ad8345f2518947bbd47f072a02fd97dd1c67 |
|
24-Oct-2012 |
Chet Haase <chet@google.com> |
am 4a82a0fc: am f5fa64f2: am fbba753f: Merge "Handle offscreen animations correctly" into jb-mr1-dev
* commit '4a82a0fc09f4743b59b5de483329fb76e60aab07':
Handle offscreen animations correctly
|
| 5d7cc93625b0cbad545082dab39a391e96047832 |
|
24-Oct-2012 |
Romain Guy <romainguy@google.com> |
am be815669: am 9389d447: am b75ade9c: Merge "Use existing display list to render the resize buffer Bug #7400903" into jb-mr1-dev
* commit 'be815669d1c41a95f79222aaa7caa4462bddfb2d':
Use existing display list to render the resize buffer Bug #7400903
|
| f5fa64f24b0ee6aa53ac2803590e8729122c445b |
|
24-Oct-2012 |
Chet Haase <chet@google.com> |
am fbba753f: Merge "Handle offscreen animations correctly" into jb-mr1-dev
* commit 'fbba753f62f13a12d9287c67921d1ea60e92768d':
Handle offscreen animations correctly
|
| fbba753f62f13a12d9287c67921d1ea60e92768d |
|
24-Oct-2012 |
Chet Haase <chet@google.com> |
Merge "Handle offscreen animations correctly" into jb-mr1-dev
|
| 9389d447c175b4ef9fb85cd296f53cf24be4fd7d |
|
24-Oct-2012 |
Romain Guy <romainguy@google.com> |
am b75ade9c: Merge "Use existing display list to render the resize buffer Bug #7400903" into jb-mr1-dev
* commit 'b75ade9cce02dffb967ff4719381254585074c58':
Use existing display list to render the resize buffer Bug #7400903
|
| 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/ViewRootImpl.java
|
| 3561d062ff01f3455c984e4cfcd101a64a2e902f |
|
23-Oct-2012 |
Chet Haase <chet@google.com> |
Handle offscreen animations correctly
A bug in software rendering caused animations on views that are offscreen
to not get drawn, therefore the animation doesn't continue (since old-style
animations depend on the logic in the drawing code to keep running). Fix is
to special case the isAnimating case in ViewRoot to go ahead and schedule
a traversal even if the dirty rect does not intersect with the visible region.
Issue #7396035 Animations starting offscreen don't draw run/end/draw properly (sw rendering only)
Change-Id: Iae25b3a424ddc5a16ba431ecd68cf42d5500db3f
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 3a2d6aaf8e71a89f82517369acc03d46ffe9bb22 |
|
23-Oct-2012 |
Romain Guy <romainguy@google.com> |
Use existing display list to render the resize buffer
Bug #7400903
Change-Id: Ia2e534e47b4f67c280e2de7ce99cae0202751c42
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 573f1429a028e8fea8b7339b28e139b501a79d4d |
|
23-Oct-2012 |
Romain Guy <romainguy@google.com> |
am 2635e743: am d04fe3c1: am 04c8d402: Merge "Properly draw the window background on window resize Bug #7385090" into jb-mr1-dev
* commit '2635e7431a74b89c338ea9d56715f94b9c328cc1':
Properly draw the window background on window resize Bug #7385090
|
| d04fe3c1aeaf4ce63f6a6f3def61a8cc5faff705 |
|
23-Oct-2012 |
Romain Guy <romainguy@google.com> |
am 04c8d402: Merge "Properly draw the window background on window resize Bug #7385090" into jb-mr1-dev
* commit '04c8d402fa824c548dc5de82c56e63eb5df02371':
Properly draw the window background on window resize Bug #7385090
|
| 41308e2936c768103d0e9c82500e97938d6797f1 |
|
23-Oct-2012 |
Romain Guy <romainguy@google.com> |
Properly draw the window background on window resize
Bug #7385090
This change gets rid of two silly asumptions:
- That a layer needs to be cleared with opaque black (it shouldn't,
it's already cleared to transparent and the view will cover it up
with its own background)
- The the clip should be dirty at the beginning of a frame only
when the render target is opaque
Change-Id: I415b6d3cab196057fb0281419a53fef601a44e28
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| da391700c964077306ff43fd4296f31536942e9d |
|
19-Oct-2012 |
Fabrice Di Meglio <fdimeglio@google.com> |
resolved conflicts for merge of e549a602 to master
Change-Id: I37dc0e48321d4baea49d77b6ef22bca19dcb0d9b
|
| af26ac3130c0e956e28443d6e42212b02d4da611 |
|
19-Oct-2012 |
Fabrice Di Meglio <fdimeglio@google.com> |
am 398a6713: Merge "Fix bug #7367429 Popup window should get its direction from it Anchor View if it can" into jb-mr1-dev
* commit '398a6713c355cf59af071e944268aec7c0096b5a':
Fix bug #7367429 Popup window should get its direction from it Anchor View if it can
|
| 398a6713c355cf59af071e944268aec7c0096b5a |
|
19-Oct-2012 |
Fabrice Di Meglio <fdimeglio@google.com> |
Merge "Fix bug #7367429 Popup window should get its direction from it Anchor View if it can" into jb-mr1-dev
|
| b003e28c1d65d06fcb5690ff2955d007d8f7a626 |
|
18-Oct-2012 |
Fabrice Di Meglio <fdimeglio@google.com> |
Fix bug #7367429 Popup window should get its direction from it Anchor View if it can
- set the popup layout direction depending on the anchor view's layout direction
(if not defined before)
- make first pass of ViewRootImpl.performTraversals() and configuration update
not override any layout direction that could have been set before
Change-Id: I8e86ca805f0caf52c058d06aa7861df56fb862e6
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 8ebb55429496887590aad0bf99d35f745ed5577d |
|
18-Oct-2012 |
Chet Haase <chet@google.com> |
am b7379d3e: am 68716710: am 6f3e7bbf: Merge "Fix for previous commit on non-interesecting invalidations" into jb-mr1-dev
* commit 'b7379d3e4808fc1b4af4f4a6286e4432aa2b7036':
Fix for previous commit on non-interesecting invalidations
|
| 6871671063262759c906e6a24829d37a91d3b278 |
|
17-Oct-2012 |
Chet Haase <chet@google.com> |
am 6f3e7bbf: Merge "Fix for previous commit on non-interesecting invalidations" into jb-mr1-dev
* commit '6f3e7bbf14d43553dfca6a59bbbb1c6ee19a70fc':
Fix for previous commit on non-interesecting invalidations
|
| 9911d18f0ebc9a68e41838471de507a04ea8fd9d |
|
17-Oct-2012 |
Chet Haase <chet@google.com> |
Fix for previous commit on non-interesecting invalidations
An error in the logic meant that some valid invalidations weren't getting through,
causing Launcher (for one) to get stuck sometimes.
Change-Id: I180622623b19770cd61034a5bd7991a5e2fd0a64
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 6d166b7c5f86581cbccd52bc55bd45d724968a1e |
|
17-Oct-2012 |
Chet Haase <chet@google.com> |
am a1954051: am e31cc171: am d95316e2: Merge "Skip drawing offscreen objects" into jb-mr1-dev
* commit 'a195405199f8d70ffce3de015bfe49316992faa4':
Skip drawing offscreen objects
|
| e31cc17159f5a6eada40ffda20cb0b0560a0bc5c |
|
17-Oct-2012 |
Chet Haase <chet@google.com> |
am d95316e2: Merge "Skip drawing offscreen objects" into jb-mr1-dev
* commit 'd95316e2c78c7e6cfacac9cced66f7ace36d6497':
Skip drawing offscreen objects
|
| d95316e2c78c7e6cfacac9cced66f7ace36d6497 |
|
17-Oct-2012 |
Chet Haase <chet@google.com> |
Merge "Skip drawing offscreen objects" into jb-mr1-dev
|
| b78ee0ef60e5323b15b4ffdc97be4d889e272b79 |
|
17-Oct-2012 |
Chet Haase <chet@google.com> |
Skip drawing offscreen objects
Previous logic in ViewRoot would schedule and perform a draw
when it was requested by offscreen objects. The problem was that the
logic checking for an interesection between the offscreen invalidation rectangle
and the onscreen display rectangle was flawed. The fix was to use the return value
from Rect.intersect() to do the right thing and skip drawing.
Issue #7366568 Offscreen invalidates can cause useless work for framework
Change-Id: Ie4e277c695dacee39848a8a223f0c4ee34d9bb4d
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 7cfd0a2809ee39d4a6c484384615f873a133979d |
|
17-Oct-2012 |
Fabrice Di Meglio <fdimeglio@google.com> |
am 86a8b251: am d8989364: am e9a33c60: Merge "Fix bug #7363252 Popup and Dialog UI widgets should be RTL aware" into jb-mr1-dev
* commit '86a8b25114fbc033c474a214699ad77a9140af5e':
Fix bug #7363252 Popup and Dialog UI widgets should be RTL aware
|
| d89893642f81f854455da601e4735d226cf95214 |
|
17-Oct-2012 |
Fabrice Di Meglio <fdimeglio@google.com> |
am e9a33c60: Merge "Fix bug #7363252 Popup and Dialog UI widgets should be RTL aware" into jb-mr1-dev
* commit 'e9a33c6098f51c687665adbed799860df2569ad0':
Fix bug #7363252 Popup and Dialog UI widgets should be RTL aware
|
| e9a33c6098f51c687665adbed799860df2569ad0 |
|
17-Oct-2012 |
Fabrice Di Meglio <fdimeglio@google.com> |
Merge "Fix bug #7363252 Popup and Dialog UI widgets should be RTL aware" into jb-mr1-dev
|
| cf12897cf553bfd07734dad3de071915fd21d4eb |
|
17-Oct-2012 |
Fabrice Di Meglio <fdimeglio@google.com> |
Fix bug #7363252 Popup and Dialog UI widgets should be RTL aware
- set the Configuration's layout direction in ViewRootImpl instead of PhoneWindow$DecorView
- then remove unecessary API on ListPopupWindow for passing the layout direction
Change-Id: Ia2c6e4aa8cb82aed9b088bc3b8004ea0a1ded1f3
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 1c80844464fbe977c5303cd56af9abb81a2bc218 |
|
16-Oct-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
am 7d5de594: am d46503d5: am 40b7ea44: Merge "Accessibility focus drawing does not take into account view\'s transformation matrix." into jb-mr1-dev
* commit '7d5de5941d24aadf57d883198f79cf39da324635':
Accessibility focus drawing does not take into account view's transformation matrix.
|
| d46503d5088b46f3e45a94b81efa406856559ca8 |
|
16-Oct-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
am 40b7ea44: Merge "Accessibility focus drawing does not take into account view\'s transformation matrix." into jb-mr1-dev
* commit '40b7ea443612213e9c973393658f07c176c3269e':
Accessibility focus drawing does not take into account view's transformation matrix.
|
| 78bd9835eb99fd829026a05dc543c6708367ca5b |
|
16-Oct-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Accessibility focus drawing does not take into account view's transformation matrix.
1. We are using the view drawing bounds but did not take into account the transformation
matrix. This leads to showing ugly artifacts on the launcher's hotseat which is
pretty much the first thing we see.
2. Updated the documentation of View.getDrawingRect to be more explicit that the
results does not have the transformation matrix applied.
bug:7354033
Change-Id: Ief2e0ea8da05471d71e215ce4497d94ff6e92d1a
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 9c377bd2d6c8315c6917ed58b2b7a5f6fb8b8a4c |
|
06-Oct-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
am 481a0aac: am 88ae2e2a: am d9c99124: Merge "Incorrect temporary detach of accessibility focused view may lead to a crash." into jb-mr1-dev
* commit '481a0aac1f28233854ead339f0c9697eb1286653':
Incorrect temporary detach of accessibility focused view may lead to a crash.
|
| 88ae2e2abeda94f3ec1d87ffad35e7e5d716a94f |
|
06-Oct-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
am d9c99124: Merge "Incorrect temporary detach of accessibility focused view may lead to a crash." into jb-mr1-dev
* commit 'd9c99124d4870361c7c1e28fb78adf245eb1305a':
Incorrect temporary detach of accessibility focused view may lead to a crash.
|
| c8860602726d771c69a3fefedfa03419d1c03b1c |
|
06-Oct-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Incorrect temporary detach of accessibility focused view may lead to a crash.
1. If an app naither reattaches nor removes detached view that has
accessibility focus, an exception in the drawing of accessibility
focus occurs since we are trying to compute the focused rect by
offseting the bounds of the focused view in coords of the root
but the focused one is not attached.
bug:7297191
Change-Id: Ib69d52e474b8ea365754f5311f5e809bd757dd1a
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 82fa5ffbbc4a0b9842c809d0d4fdbec622819f38 |
|
04-Oct-2012 |
Romain Guy <romainguy@google.com> |
am bf8d8e73: am 5971d03f: am f7ee2a03: Merge "Fix rendering artifacts on tiled renderers Bug #7275145" into jb-mr1-dev
* commit 'bf8d8e73e4123f529845e88de6d74b62853b9786':
Fix rendering artifacts on tiled renderers Bug #7275145
|
| 5971d03f233c52d697e55ee83d8e514adac21527 |
|
04-Oct-2012 |
Romain Guy <romainguy@google.com> |
am f7ee2a03: Merge "Fix rendering artifacts on tiled renderers Bug #7275145" into jb-mr1-dev
* commit 'f7ee2a03c1f930db4b20c04225f496ada97e646b':
Fix rendering artifacts on tiled renderers Bug #7275145
|
| dfab363807b3b44be4032e410f016e0a0d018426 |
|
03-Oct-2012 |
Romain Guy <romainguy@google.com> |
Fix rendering artifacts on tiled renderers
Bug #7275145
This change fixes ViewRoot and adds extra debug information. It does
not solve the problem entirely. Another CL will.
Change-Id: I7e604ba38aad7f421769783dcbd998d6905ab2d9
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| e3eb2c7754b2eea24e9c1f6551cf15fc533b3262 |
|
29-Sep-2012 |
Jean-Baptiste Queru <jbq@google.com> |
am 3c45765a: Merge from jb-mr1-aah-dev
* commit '3c45765a2a15c685aa28b74f626c6c10c909c133': (21 commits)
Import translations. DO NOT MERGE
Import translations. DO NOT MERGE
Import translations. DO NOT MERGE
Send Trackball clicks instead of Enter Key for taps
Import translations. DO NOT MERGE
Import translations. DO NOT MERGE
Import translations. DO NOT MERGE
Import translations. DO NOT MERGE
Import translations. DO NOT MERGE
Import translations. DO NOT MERGE
Import translations. DO NOT MERGE
Import translations. DO NOT MERGE
Fix auto-merger error in I74c0644c6938d28c20c42d88d995ffb56a71d703
Import translations. DO NOT MERGE
Import translations. DO NOT MERGE
Import translations. DO NOT MERGE
Import translations. DO NOT MERGE
Converts hover touch events to trackball events
Import translations. DO NOT MERGE
Import translations. DO NOT MERGE
...
|
| 06e7a030c029294a4c03c87652cfc161f8f29b3a |
|
28-Sep-2012 |
Chet Haase <chet@google.com> |
am d3451ae8: am 4af11461: Merge "Force redraw of new/resized windows" into jb-mr1-dev
* commit 'd3451ae8e07fefad529d6abf4f48ca83e177b4fb':
Force redraw of new/resized windows
|
| 22904334a0866c15dde8287d3f103e39cb76df5a |
|
28-Sep-2012 |
Chet Haase <chet@google.com> |
am 4af11461: Merge "Force redraw of new/resized windows" into jb-mr1-dev
* commit '4af1146145550dee904bcaa744abfa582c8756b7':
Force redraw of new/resized windows
|
| 391fef0f5d99c13df3d86a5798614c0695046732 |
|
28-Sep-2012 |
Chet Haase <chet@google.com> |
Force redraw of new/resized windows
Our use of the GL flag EGL_SWAP_BEHAVIOR_PRESERVED_BIT caused a problem
with windows that are resized, where some of the contents were not being
updated when the window was first placed/resized. The fix is to force the
window to redraw completely when it is first resized.
Issue #7246918 Label selection view disappears
Change-Id: I3562141569502af581a3d63b1290c598abb57ade
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 2c9141206ceaee137ef02dd1a145ae7ca1a48283 |
|
26-Sep-2012 |
Ben Pietrzak <bpietrzak@google.com> |
Send Trackball clicks instead of Enter Key for taps
Change-Id: Ib1e77a1bdad81db18f84bb33402e9144517a0f4c
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 749bbe97ee775fb997df0270f0f9fc7470efb4f6 |
|
24-Sep-2012 |
Dianne Hackborn <hackbod@google.com> |
am 55fd212f: am c0e1f268: Merge "Fix issue #7184877: Calendar Locksceen Widget crashes and forces phone to reboot" into jb-mr1-dev
* commit '55fd212f914a28d0a64202a09f0127fa0a1b4175':
Fix issue #7184877: Calendar Locksceen Widget crashes and forces phone to reboot
|
| a611a53292049e070f39f5d98092a06415f4e6ec |
|
24-Sep-2012 |
Dianne Hackborn <hackbod@google.com> |
am c0e1f268: Merge "Fix issue #7184877: Calendar Locksceen Widget crashes and forces phone to reboot" into jb-mr1-dev
* commit 'c0e1f268451550368d1d3d3558f8ce2459ed5713':
Fix issue #7184877: Calendar Locksceen Widget crashes and forces phone to reboot
|
| 3b84206bba19ae2bc9decef6a88f97951c2a205c |
|
23-Sep-2012 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #7184877: Calendar Locksceen Widget crashes and forces phone to reboot
Don't kill the system uid if we are running out of RAM.
Change-Id: Ie1818a3241fc80d4dfa19f8e8bdad22d164d7baa
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 18c166bcd68a141d932717b8d3abd863093d7c50 |
|
22-Sep-2012 |
Romain Guy <romainguy@google.com> |
am 3f7c246f: Merge "Update layers in a single batch at the beginning of a frame Bug #7186819" into jb-mr1-dev
* commit '3f7c246f3ea85af9fb98cba37387bb55658d4614':
Update layers in a single batch at the beginning of a frame Bug #7186819
|
| 7fdf367d7ad63c90c13ddf553d05f58030454191 |
|
21-Sep-2012 |
Romain Guy <romainguy@google.com> |
am 0b697061: am 3f7c246f: Merge "Update layers in a single batch at the beginning of a frame Bug #7186819" into jb-mr1-dev
* commit '0b69706103dc6ddf765fa2e86265a6428f6728bb':
Update layers in a single batch at the beginning of a frame Bug #7186819
|
| 11cb642756093a4af901b1525375b1eb2b5c3e2b |
|
21-Sep-2012 |
Romain Guy <romainguy@google.com> |
Update layers in a single batch at the beginning of a frame
Bug #7186819
Change-Id: Ice5926dfedfb3be3a3064e65008dafa2852407da
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| b4641b5cd45331102c831635dd1856c35e1ba6e0 |
|
21-Sep-2012 |
Justin Koh <justinkoh@google.com> |
Merge "Converts hover touch events to trackball events" into jb-mr1-aah-dev
|
| 971405797f1131d69cb77ac449e66ac4a6276100 |
|
13-Sep-2012 |
Chet Haase <chet@google.com> |
Handle requestLayout() calls during layout
Calling requestLayout() during a layout pass is inadvisable, but
happens often enough in applications (especially when it occurs in
very indirect means that the application may not easily be able to
control) that we need to handle the situation without breaking. In particular,
applications that have run across this problem have had artifacts which are
difficult to debug (like things just not showing up on the screen) and
also difficult to fix. One of the side-effects of the problem is that it
leaves the view hiearchy in an unpredictable state where some views have
requested layout and are waiting to be layed out while the root view has
not received those requests, so it is never calling layout on those views.
The fix is to try to do the 'right' thing, while avoiding getting into
an inifinite loop (which could result from calling layout, which calls requestLayout(),
which causes another layout, which ...). The solution is two-tier: we handle
all requests that happen during layout by delaying them until after the current
layout is done. We then process those requests and call layout again.
If we receive more requests during that second layout, we post them to the
next frame, to allow us to finish the current one.
Issue #7155974 handle requestLayout() during layout more robustly
Change-Id: I9d13c405be28a19c86add22210e69817ddddaf8b
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| dc4b5037a33956b3b04a45a24ef272e81eeb5438 |
|
10-Sep-2012 |
Ben Pietrzak <bpietrzak@google.com> |
Converts hover touch events to trackball events
Change-Id: Ibb843fcc0c525250a775d3b3567f8ca964f525c0
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 603f6de35f21d74ae242d52d501f4f5c25ff4f4c |
|
15-Sep-2012 |
Chet Haase <chet@google.com> |
Fix occasional crash bug with layers
Launcher occasionally crashes with a stack trace indicating that the memory
of a Layer object is corrupt. It is possible for us to delete a Layer
structure and then, briefly, use it to draw a DisplayList again before
that DisplayList gets recreated (without the layer that got deleted).
When this happens, if the memory got corrupted, it's possible to crash.
The fix is to add Layer to the other objects which we currently refcount
(bitmaps, shaders, etc.). Then instead of deleting a Layer, we decrement the
refcount. We increment when creating it, then increment it again when it's
referenced from a DisplayList. Then we decrement the refcount instead of
deleting it, and decrement when we clear a DisplayList that refers to it.
Then when the refcount reaches 0, we delete it.
Issue #6994632 Native crash in launcher when trying to launch all apps screen
Change-Id: I0627be8d49bb2f9ba8d158a84b764bb4e7df934c
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| f84208faf8e9ab7bbf81224006662fc3219c6ad4 |
|
14-Sep-2012 |
Romain Guy <romainguy@google.com> |
Prevent crash when invalidating all Views
Bug #7165793
A ViewRootImpl's root view can be null. Check for this condition to
prevent an NPE invalidateWorld(). Other messages perform a similar
check to properly handle the case where mView == null.
Change-Id: I5bcfc41c48a469d38b21be74df2f6c715b0f9352
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| dcd8c81bf4beb719888b6be1b9418303c9075938 |
|
13-Sep-2012 |
Craig Mautner <cmautner@google.com> |
Merge "Propagate systemUiVisibility changes to window manager" into jb-mr1-dev
|
| 7eac0f557cd87486d0f10b7c72e25aeb195a4351 |
|
13-Sep-2012 |
Craig Mautner <cmautner@google.com> |
Propagate systemUiVisibility changes to window manager
The mAttachInfo.mSystemUiVisibility value was changing in
View.dispatchAttachedToWindow but
mAttachInfo.mRecomputeGlobalAttributes was not being set.
Consequently ViewRootImpl.collectViewAttributes was returning
without updating the subtreeSystemUiVisibility. This is fixed
by calling needGlobalAttributesUpdate in dispatchAttachedToWindow.
WIthin ViewRootImpl.collectViewAttributes the assignment to
subtreeSystemUiVisibility was only being made if
mAttachInfo.mSystemUiVisibility was changed within
collectViewAttributes. But mAttachInfo.mSystemUiVisibility
was changing outside of collectViewAttributes in
dispatchAttachedToWindow. Consequently subtreeSystemUiVisibility
was never updated. By looking for a mismatch between
subtreeSystemUiVisibility and mSystemUiVisibility
subtreeSystemUiVisibility gets assigned whenever it is out of
sync.
Fixes bug 7091817.
Change-Id: I1e97a7dec14dc9594876175ae26370fb9030a8a6
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 8d5e6f8d4a2bd39c6656cbac4f963d2527d707bf |
|
11-Sep-2012 |
Dianne Hackborn <hackbod@google.com> |
Maybe fix issue #7146119: exception in FragmentManager
Seems like we should never be dispatching input events to windows
that currently don't have focus.
Change-Id: I524796df69f3fdda4147cb37e7b85b79bad88762
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| b38070caa5143ab9fd1883e0c7c879533a480bc7 |
|
24-Aug-2012 |
Victoria Lease <violets@google.com> |
IME support for trackball and generic motion events
Trackball and generic motion events now pass through the IME in case
it would like to handle them before passing them on to the view
hierarchy.
While I was at it, I also...
...fixed the documentation on InputMethodService.onKeyUp()
...added documentation to InputMethodService.onTrackballEvent()
...added trackball and generic motion events to the "input" command
...fixed input consistency verification involving ACTION_OUTSIDE
Bug: 7050005
Change-Id: I40ab68df4a9542af6df25de6ec2ec500e4c02902
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 1cf70bbf96930662cab0e699d70b62865766ff52 |
|
06-Aug-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Screen magnification - feature - framework.
This change is the initial check in of the screen magnification
feature. This feature enables magnification of the screen via
global gestures (assuming it has been enabled from settings)
to allow a low vision user to efficiently use an Android device.
Interaction model:
1. Triple tap toggles permanent screen magnification which is magnifying
the area around the location of the triple tap. One can think of the
location of the triple tap as the center of the magnified viewport.
For example, a triple tap when not magnified would magnify the screen
and leave it in a magnified state. A triple tapping when magnified would
clear magnification and leave the screen in a not magnified state.
2. Triple tap and hold would magnify the screen if not magnified and enable
viewport dragging mode until the finger goes up. One can think of this
mode as a way to move the magnified viewport since the area around the
moving finger will be magnified to fit the screen. For example, if the
screen was not magnified and the user triple taps and holds the screen
would magnify and the viewport will follow the user's finger. When the
finger goes up the screen will clear zoom out. If the same user interaction
is performed when the screen is magnified, the viewport movement will
be the same but when the finger goes up the screen will stay magnified.
In other words, the initial magnified state is sticky.
3. Pinching with any number of additional fingers when viewport dragging
is enabled, i.e. the user triple tapped and holds, would adjust the
magnification scale which will become the current default magnification
scale. The next time the user magnifies the same magnification scale
would be used.
4. When in a permanent magnified state the user can use two or more fingers
to pan the viewport. Note that in this mode the content is panned as
opposed to the viewport dragging mode in which the viewport is moved.
5. When in a permanent magnified state the user can use three or more
fingers to change the magnification scale which will become the current
default magnification scale. The next time the user magnifies the same
magnification scale would be used.
6. The magnification scale will be persisted in settings and in the cloud.
Note: Since two fingers are used to pan the content in a permanently magnified
state no other two finger gestures in touch exploration or applications
will work unless the uses zooms out to normal state where all gestures
works as expected. This is an intentional tradeoff to allow efficient
panning since in a permanently magnified state this would be the dominant
action to be performed.
Design:
1. The window manager exposes APIs for setting accessibility transformation
which is a scale and offsets for X and Y axis. The window manager queries
the window policy for which windows will not be magnified. For example,
the IME windows and the navigation bar are not magnified including windows
that are attached to them.
2. The accessibility features such a screen magnification and touch
exploration are now impemented as a sequence of transformations on the
event stream. The accessibility manager service may request each
of these features or both. The behavior of the features is not changed
based on the fact that another one is enabled.
3. The screen magnifier keeps a viewport of the content that is magnified
which is surrounded by a glow in a magnified state. Interactions outside
of the viewport are delegated directly to the application without
interpretation. For example, a triple tap on the letter 'a' of the IME
would type three letters instead of toggling magnified state. The viewport
is updated on screen rotation and on window transitions. For example,
when the IME pops up the viewport shrinks.
4. The glow around the viewport is implemented as a special type of window
that does not take input focus, cannot be touched, is laid out in the
screen coordiates with width and height matching these of the screen.
When the magnified region changes the root view of the window draws the
hightlight but the size of the window does not change - unless a rotation
happens. All changes in the viewport size or showing or hiding it are
animated.
5. The viewport is encapsulated in a class that knows how to show,
hide, and resize the viewport - potentially animating that.
This class uses the new animation framework for animations.
6. The magnification is handled by a magnification controller that
keeps track of the current trnasformation to be applied to the screen
content and the desired such. If these two are not the same it is
responsibility of the magnification controller to reconcile them by
potentially animating the transition from one to the other.
7. A dipslay content observer wathces for winodw transitions, screen
rotations, and when a rectange on the screen has been reqeusted. This
class is responsible for handling interesting state changes such
as changing the viewport bounds on IME pop up or screen rotation,
panning the content to make a requested rectangle visible on the
screen, etc.
8. To implement viewport updates the window manger was updated with APIs
to watch for window transitions and when a rectangle has been requested
on the screen. These APIs are protected by a signature level permission.
Also a parcelable and poolable window info class has been added with
APIs for getting the window info given the window token. This enables
getting some useful information about a window. There APIs are also
signature protected.
bug:6795382
Change-Id: Iec93da8bf6376beebbd4f5167ab7723dc7d9bd00
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| df2390adc3879b7040425e75e4acc64729612b9c |
|
30-Aug-2012 |
Craig Mautner <cmautner@google.com> |
Don't die(immediate) if from performTraversals.
The Drive application was calling PopupWindow.dismiss from within
onMeasure. This caused dispatchDetachedFromWindow to be called
from within performTraversals. Since dispatchDetachedFromWindow
destroys much of what performTraversals uses this was a disaster
waiting to happen.
This fix adds a check for seeing if die(immediate=true) is being
called from within performTraversals. If it is then die doesn't
execute doDie immediately, but instead treats it as a call to
die(immediate=false).
Fixes bug 6836841.
Change-Id: I833289e12c19fd33c17a715b2ed2adcf8388573a
/frameworks/base/core/java/android/view/ViewRootImpl.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/ViewRootImpl.java
|
| 4702a856973a553deb82f71b1d3b6c3db5dbf4ba |
|
18-Aug-2012 |
Dianne Hackborn <hackbod@google.com> |
More view hierarchy, fragment debugging.
Add a View.toString() method.
Rename all of the View private flags to have a PFLAG prefix to
avoid going insane trying to figure out which constant goes with
which flag.
Activity.dump() now includes a summary of the activity's view
hierarchy, using the View.toString() method.
All exceptions thrown by FragmentManager now perform a dump of
the owning activity state, where appropriate.
Change-Id: I6482e397e10cb5a0612ab02ce6ed5131823437a6
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| c89b14bba0f6cc2c91629080617f7ed215f697f3 |
|
08-Aug-2012 |
Romain Guy <romainguy@google.com> |
It seems that apparently useless public APIs are actually useful
Bug #6953651
Change-Id: Ic47ce504e63262711f5d3edc76f7d2b9c12471ad
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 17112ad8a21a77620eb1ff14dcf8bdd6b7859712 |
|
07-Aug-2012 |
Romain Guy <romainguy@google.com> |
Cleanup of libhwui
Change-Id: Ib7f5771548462c00027a8ad57badfb68c50644f9
/frameworks/base/core/java/android/view/ViewRootImpl.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/core/java/android/view/ViewRootImpl.java
|
| 908aecc3a63c5520d5b11da14a9383f885b7d126 |
|
01-Aug-2012 |
Dianne Hackborn <hackbod@google.com> |
Start moving away from DisplayMetrics.DENSITY_DEVICE.
This puts in most of the infrastructure needed to allow us to
switch between different densities at run time. The main remaining
uses of the global are to initialize the Bitmap object (not sure
what to do about that since it doesn't have anything passed in
the constructor to get this information from), and being able to
load drawables if we need a different density than what was preloaded
by zygote.
Change-Id: Ifdbfd6b7a5c59e6aa22e63b95b78d96af3d96848
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 6881a10557acf3b0270de54799d6f19437acf584 |
|
27-Jul-2012 |
Craig Mautner <cmautner@google.com> |
Small step towards supporting multiple displays
Change-Id: I353449c2b464394988c7e0203656b5851a0c9127
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| a8b9defade5b937d4ad64f9aff4bca792298f43c |
|
23-Jul-2012 |
Jeff Brown <jeffbrown@google.com> |
Stop using raw display size except in window manager.
We don't actually need the raw size in these places.
The logical size is good enough.
Starting to move dependencies on surface flinger
and window manager out of the Display class.
Change-Id: I2065bee8e5bf7f42c5a452dd1e8479e40ebb0d37
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 63cf0752226383cfc8fa35a3233413301b49fab7 |
|
25-Jul-2012 |
Romain Guy <romainguy@google.com> |
Merge "Make HardwareRenderer able to target generic Surface objects"
|
| 786fc93d71b833ab6b02b0c7ea5e30f25cceeedf |
|
25-Jul-2012 |
Romain Guy <romainguy@google.com> |
Make HardwareRenderer able to target generic Surface objects
Change-Id: I4b7199a1eb30e0df354ae12c4819adc69db5df40
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 23e7c35ab5d43242d35b1019ce1a50bfb495cd27 |
|
20-Jul-2012 |
Jeff Brown <jeffbrown@google.com> |
Remove dead code in window manager.
The 'nest' parameter is always false so we can get rid of support
for redundantly added views.
Change-Id: I30c6a856797bdc72c4e1aa4cb26b930a33ce9a16
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| c9c9a48e7bafae63cb35a9aa69255e80aba83988 |
|
16-Jul-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Removing a workaround for incorrect window position on window move.
1. The window manager was not notifying a window when the latter
has been moved. This was causing incorrect coordinates of the
nodes reported to accessibility services. To workaround that
we have carried the correct window location when making a
call from the accessibility layer into a window. Now the
window manager notifies the window when it is moved and the
workaround is no longer needed. This change takes it out.
2. The left and right in the attach info were not updated properly
after a report that the window has moved.
3. The accessibility manager service was calling directly methods
on the window manager service without going through the interface
of the latter. This leads to unnecessary coupling and in the
long rung increases system complexity and reduces maintability.
bug:6623031
Change-Id: Iacb734b1bf337a47fad02c827ece45bb2f53a79d
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| fbf885b652272013f44da71e9f77923333bf62eb |
|
10-Jul-2012 |
Craig Mautner <cmautner@google.com> |
Merge "Notify client side of window movement."
|
| 05e91ed5a7ea17f021e1811166942a7d758e1cce |
|
03-Jul-2012 |
Chet Haase <chet@google.com> |
Force invalidates on non-visible views to traverse the hierarchy
An optimization prunes invalidates on views which are not inside their
parent's bounds. This works in most cases, but it is possible to run
a situation where a view has been invalidated (and is thus waiting to
be redrawn), but the pruning logic ensures that that draw call
will not happen. Further, when/if the view comes into the bounds
of its parent again, it may still not be redrawn, because now future
invalidates on the view are noop'd because it is already in an invalidated
state (and thus will not propagate invalidates up the hierarchy).
The fix is to remove the optitmization. This will cause some overhead
sending the invalidation request up to the view root, but this
overhead is minimal (and only extra for cases of out-of-bounds views),
and the more expensive part of rendering these views will still not be done
since the view root will avoid re-drawing the hierarchy when the dirty
rectangle is empty.
Issue #6773607 Layered views animating from offscreen sometimes remain invisible
Change-Id: Ia2c1a2b9d3e7f267253cb325ccceff1e7fdbe8bd
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 27e2da7c171afa39358bbead18fbe3e6b8ea6637 |
|
03-Jul-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Remove the accessibility focus search code.
1. In JellyBean we have added some APIs to search for next accessibility
focus in various directions and set accessibility focus from hover.
However, we have decided that there is not clean answer for how this
should behave and the APIs were hidden. Now the accessibility service
is responsible for that. The unused code is now taken out.
2. This patch also takes out the hidden attribute accessibiligyFocusable
since we moved the responsibility for implementing focus search strategy
to accessibility services and we did not need that for Jellybean which
is a good sign that this is not needed. I general this is one less thing
for an app developer to worry about. We can add this if needed later.
bug:6773816
Change-Id: I0c858d72c93a2b7ff1f8f35a08d33ec4b9eb85fd
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 5702d4dfb5b81491f873a3617f8d8fc8dc5279e6 |
|
30-Jun-2012 |
Craig Mautner <cmautner@google.com> |
Notify client side of window movement.
Add a one way method to notify Views that the window has moved
on the screen. Fixes issues arising from the IME popping up and
translating the window that uses it. Accessibility was left unaware
of these movements and was drawing the box around the wrong widgets.
Similarly PopupWindow used getLocationOnScreen to determine how
much screen real estate was above and below the anchor point to
determine where to put an anchored window.
Fixes bug 6623031.
Change-Id: I4731a94d5424c1ec77bf1729fba8fc9ea34cae46
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| c32b2091d6441e7709342ca62f0976fc4a0367e4 |
|
18-Jun-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
am 45c4a8df: am ec7c7ebf: Merge "API for finding accessibility focus in virtual tree not needed." into jb-dev
* commit '45c4a8df9487f53af37ded1f5a1ebe500e89b493':
API for finding accessibility focus in virtual tree not needed.
|
| 45a02e0809c14a52aa24658666df0d41ce661857 |
|
18-Jun-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
API for finding accessibility focus in virtual tree not needed.
1. The function for finding where the accessibility focus in a virtual
node tree presented by an AccessibilityNodeProvider is not needed
API since the framework already keeps track of the accessibility
focused virtual node in order to draw the focus rectangle. This API
adds unnecessary complexity to developers of AccessibilityNodeProviders.
bug:6675330
Change-Id: I84774686b06a995073a39e45b8ef22f2cd04b773
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 04ddf3c0508f3d50e6ab82cecc0adc92f52b7803 |
|
14-Jun-2012 |
Jeff Brown <jeffbrown@google.com> |
Allow applications to recover from IME related ANRs.
Timeout after 2.5 seconds.
Because communication with an IME occurs asynchronously
using oneway binder calls, it's possible for an input event
that was delegated to the IME to be dropped on the floor.
When this happens, the app (not the IME!) will get blamed
for the problem and will ANR forever.
Even if an event is not dropped on the floor, we should
eventually time out event dispatch to the IME if it's
being too slow.
This patch implements a timeout on all events delegated
to the IME. When the timeout expires, the event is marked
as having not been handled by the IME and the application
gets a crack at it. We also write a message to the log when
this occurs.
Ensure that we do not invoke the event finished callback
while holding the InputMethodManager's lock to avoid
potential deadlocks.
Fixed a minor bug where the InputMethodManager would not
remember the id of the current input method. This caused
the log messages and dumpsys state to print "null" as the
current input method id.
Bug: 6662465
Change-Id: Ibb3ddeb087ee6998996b0b845134e16a18aa3057
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 54ab347fdde0e4d14d923cca80e5bcc7b879fc52 |
|
14-Jun-2012 |
Romain Guy <romainguy@google.com> |
Don't create a giant layer for all notifications
Bug #6642475
When expanding the status bar, create one layer per notification instead of
a single giant layer for the pile of notifications. This prevents layer
creation failure when the total height of the notifications is larger
than the maximum allowed texture size in OpenGL ES 2.0.
This change only enables layers on notifications that will be visible
once the notification area is fully expanded.
Change-Id: I3c791a66cf5ac0973f3a65cfcd84b95209d580f3
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 9d0908919a65a4f3158a8fc50aaf320dfed36278 |
|
12-Jun-2012 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #6634325: View.setKeepScreenOn and...
...MediaPlayer.setScreenOnWhilePlaying seem broken
We need to correctly clear the keep screen on flag when the view
hierarchy request is gone... and to do that, we need to keep the
actual state of the flag requested by the app. Also when the app
changes its state, we need to compute the proper value based on
both the app request and any requests in the view hierarchy.
Bug: 6634325
Change-Id: I060e9a34a10faffbaa77c06098cf21298bb4969f
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 527ee91b60426b5a344e9905c7f9a14d6d26219e |
|
11-Jun-2012 |
Romain Guy <romainguy@google.com> |
Prevent crash in WebView when disabling the hw renderer
Bug #6596807
A crash would occur in the following situation:
- WebView registers a functor with the hardware renderer
- The hardware renderer gets disabled
- WebView attemps to unregister its functor
Unregistering the functor fails because the hardware renderer is now disabled.
When the renderer becomes enabled again, the functor is invoked, which leads
to a native crash.
This change simply allows functors to always be unregistered, even when the
renderer is disabled. A disabled renderer only means that it will not be used
for rendering; as such, unregistering a functor is a valid operation and
should be allowed.
Change-Id: I0ff897a0cca7e048c609033215cd0f7f5c940bcc
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 86783474fdec98a22bc22e224462767eab13e273 |
|
07-Jun-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Cannot interact with dialogs when IME is up and on not touch explored popups.
1. If the last touch explored location is within the active window we
used to click on exact location if it is within the accessibility
focus otherwise in the accessibility focus center. If the last touch
explored location is not within the active window we used to just
click there. This breaks in the case were one has touch explored
at a given place in the current window and now a dialog opens *not*
covering the touch explored location. If one uses swipes to move
accessibility focus i.e. to traverse the dialog without touching
it one cannot activate anything because the touch explorer is using
the last touch explored location that is outside of the active
window e.g the dialog.
The solution is to clear the last touch explored location when a
window opens or accessibility focus moves. If the last touch
explored location is null we are clicking in the accessibility
focus location.
bug:6620911
2. There is a bug in the window manager that does not notify a
window that its location has changed (bug:6623031). This breaks
accessibility interaction with dialogs that have input because
when the IME is up the dialog is moved but not notified. Now
the accessibility layer gets incorrect location for the
accessibility focus and the window bounds.
The soluion is when the accessibility manager service calls
into the remove thress to obtain some accessibility node infos
it passes the window left and top which it gets from the
window manager. These values are used to update the attach info
window left and top so all accessibility node infos emitted
from that window had correct bounds in screen coordinates.
bug:6620796
Change-Id: I18914f2095c55cfc826acf5277bd94b776bda0c8
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 932b7f6765968bd526c03512f3805fbc3924dc29 |
|
06-Jun-2012 |
Chris Craik <ccraik@google.com> |
Revert "Add more temporary logging for investigating detachFunctor"
bug:6608646
This reverts commit 8857b2f76abad1e4ec742dfd85d0c997880be376
Change-Id: I1563b5974c52b84201ae448298f804eb0dcc235d
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 8857b2f76abad1e4ec742dfd85d0c997880be376 |
|
05-Jun-2012 |
Chris Craik <ccraik@google.com> |
Add more temporary logging for investigating detachFunctor
bug:6596807
Change-Id: Ic9e34e323b12a887f2e8df0773a6155627b6a64f
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 41ee465734d0006797a8fd36e88976c1e85d161c |
|
01-Jun-2012 |
Chris Craik <ccraik@google.com> |
Force webview invalidates on unsuccessful functor attach
Functor attach should always be successful, but adding a fallback just in
case. Also invalidates the WebView on initial content arriving.
bug:6511995
Change-Id: Ibca16505afec9f693ea4a7cc4966cd6d7353725c
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 38c2ece5ce4c59f30e5832779bf1d86d68b1c442 |
|
24-May-2012 |
Romain Guy <romainguy@google.com> |
Clear bitmap references from display lists as early as possible
Bug #6555840
Apps like Google+ with large bitmaps displayed in listivews could
run into memory issues because of these references.
Change-Id: I39486bda13ce00c5a3b6481139ad54547506a8b4
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| f40628645df750991ced8dde803dd57225fca04f |
|
22-May-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Merge "Accessibility focus and input focus do not sync - part 2" into jb-dev
|
| 525ae2075cf96d3a2ac67cd3a662069fd579f42d |
|
22-May-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Accessibility focus and input focus do not sync - part 2
1. This patch has somecode that syncs input and accessibility
focus or tries to put accessibility focus on the top most
container that was missed by the previous patch.
Change-Id: I08f21670b1c6e9f363d5714b1976fb52d84baae4
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| e2d7f182ff2db26723089206c7d01f6695bd3dfc |
|
21-May-2012 |
Romain Guy <romainguy@google.com> |
Remove DEBUG_LATENCY flag
This flag was replaced with the more versatile and powerful systrace.
Change-Id: I2267698f86fe9ba9e1102856795ca641001fecd5
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 13b907353f18215b52b5ceda24bbf520d91d72a1 |
|
21-May-2012 |
Romain Guy <romainguy@google.com> |
Remove unused, obsolete debug code
All these features have either been abandonned and left un-maintained
for years or can be replaced by systrace.
Change-Id: I42e4579a8078744047e5fe08a7a15254970b09bc
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| dddcd22b7ea56b1d3e31f2bbc35c80cb047de879 |
|
19-May-2012 |
Romain Guy <romainguy@google.com> |
Don't crash on Surface.unlockAndPost() but log & try again
Bug #6482593
Change-Id: Ib477b58e2b7a6cb19a87d05f2aa0448e04d82f7c
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 648337b3a8024b22a77977024cdf171f83999d56 |
|
17-May-2012 |
Adam Powell <adamp@google.com> |
Merge "Fix a bug where late-invalidating views with animations would be held for too long by ViewRootImpl" into jb-dev
|
| 3e3c4ee0475ad7096201a5f00f2e9be22fb891dd |
|
17-May-2012 |
Adam Powell <adamp@google.com> |
Fix a bug where late-invalidating views with animations would be held
for too long by ViewRootImpl
Change-Id: I1e32bf2683b50f8834f215a753f881b5d4b8dbc9
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| c8d2668bc4506aa9e771931534c6379cf687d41e |
|
17-May-2012 |
Jeff Brown <jeffbrown@google.com> |
Add systrace method tags for measure and layout.
Change-Id: I739f6384b390d1b34b09b622ca0f752de1dd7304
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 413baf8a03db180607efaca0bb60c15a153c4322 |
|
16-May-2012 |
Romain Guy <romainguy@google.com> |
Don't draw onto a hw surface using the software renderer
Bug #6485955
If an invalidate gets scheduled right before the EGL surface is destroyed,
the next draw pass is done in software. This causes the software renderer
to connect to the surface forever which prevents the hardware renderer
from coming back when the screen is turned back on.
The fix here is to ignore the draw request when hw acceleration is requested
but not yet available. Proper software fallback will still happen when an
error is encountered with hardware rendering (in which case hw acceleration
will not be marked as requested anymore.)
Change-Id: I1edc4a51c8dd38240aa2345092a18a081a756fc1
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 78cb7cf7d1d82834c4405650a17e387370004570 |
|
15-May-2012 |
Chris Wren <cwren@android.com> |
Allow animations to run past cancelled draws, if the view is visible.
Bug: 6475482
Change-Id: Iecb3a04744282135efa0049f1b70a46dc4a6bb23
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 791fd31a68c59395952005886ba799169f80a29a |
|
15-May-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Accessibility focus traversal in virtual nodes.
1. Finished the implementation of support for maintaining
accessibility focus in view with virtual descendants.
2. Finished the NumberPicker implementation of virtual
subtree such that all requred attributes are reported
and ensuring that it support accessibility focus in
its virtual descentants.
3. Fixed a bug where if a predecessor of the view that is
accessiiblity focused is removed the accessibliity focus
host in ViewRootImpl is not cleared leading to a crash
when trying to draw the accessibility focus highlight.:
bug:6472646
bug:6433864
Change-Id: I3645642b87b4a26025c0b2ba9dfaad92d11a48f1
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 8ce2d78aa89e89e9a5607d8809bf6d248508a531 |
|
15-May-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Merge "Improving accessibility focus traversal." into jb-dev
|
| e5dfa47d84668376b84074c04570fb961870adeb |
|
09-May-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Improving accessibility focus traversal.
1. Now the views considered during the accessibility focus search
are the ones that would get accessibility focus when thovered
over. This way the user will get the same items i.e. feedback
if he touch explores the screen and uses focus traversal. This
is imperative for a good user experience.
2. Updated which focusables are considered when searching for access
focus in ViewGroup. Generally accessibility focus ignores focus
before/after descendants.
3. Implemented focus search strategy in AbsListView that will traverse
the items of the current list (and the stuff withing one item
before moving to the next) before continuing the search if
forward and backward accessibility focus direction.
4. View focus search stops at root namespace. This is not the right
way to prevent some stuff that is not supposed to get a focus in
a container for a specific state. Actually the addFocusables
for that container has to be overriden. Further this approach
leads to focus getting stuck. The accessibility focus ignores
root names space since we want to traverse the entire screen.
5. Fixed an bug in AccessibilityInteractionController which was not
starting to search from the root of a virtual node tree.
6. Fixed a couple of bugs in FocusFinder where it was possible to
get index out of bounds exception if the focusables list is empty.
bug:5932640
Change-Id: Ic3bdd11767a7d40fbb21f35dcd79a4746af784d4
/frameworks/base/core/java/android/view/ViewRootImpl.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/core/java/android/view/ViewRootImpl.java
|
| 78b8ef3f3ad8ab935f677d8d672db0d97bff8119 |
|
07-May-2012 |
Jamie Gennis <jgennis@google.com> |
Surface: replace active rect with window crop
This change replaces the setActiveRectCrop method on Surface, which was called
from app processes, with the setWindowCrop method that is to be called from the
window manager.
Bug: 6299171
Change-Id: Ica51efcd8c488a526e7013b83d80df4856694519
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| cf67578c7f99492273a8f8446dd18ddc5af2ae76 |
|
11-May-2012 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #6475693: OnSystemUiVisibilityChangeListener reporting...
...incorrect visibility when the ActionBar overflow menu is opened
Don't report layout flags in system UI visibility callback. Update
docs to reflect this.
Change-Id: Icfa411b5537de037cafbcac04991101e8b9138c4
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| a482d36635cbfbbfb4aee9fc79d55514bf6b7464 |
|
10-May-2012 |
Dianne Hackborn <hackbod@google.com> |
Merge "Fixed typo in findAccessibilityFocus API." into jb-dev
|
| 57aab755441a28c2e5c78c35a57b940afc2799e0 |
|
10-May-2012 |
alanv <alanv@google.com> |
Fixed typo in findAccessibilityFocus API.
Change-Id: I3ca1448792a1b712f781c1bfa73823ca08ea3d39
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 571d4cbeec4adad050b8e188770e7e7dedc558f1 |
|
10-May-2012 |
Jeff Brown <jeffbrown@google.com> |
Merge "Fix bugs in fallback key handling." into jb-dev
|
| a53de0629f3b94472c0f160f5bbe1090b020feab |
|
09-May-2012 |
Dianne Hackborn <hackbod@google.com> |
Add callback hack to find out when to load system properties.
Use this to reload the trace and layout bounds properties.
This is ONLY for debugging.
Change-Id: I1c4bdb52c823520c352c5bac45fa9ee31160793c
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| fd23e3ed976b22b9a92ddb2cb3a46f9d2a0ce23f |
|
09-May-2012 |
Jeff Brown <jeffbrown@google.com> |
Fix bugs in fallback key handling.
If a fallback key is generated using a key plus a modifier,
then it's possible we might get a different fallback key
generated if the modifier has changed. PhoneWindowManager
needs to remember which fallback is last generated for a
given key code so that it can apply the same fallback action.
When generating cancellation events, it's important to have
preserved the policyFlags of the original event. Otherwise
we may not dispatch the cancellation properly. For example,
some actions are not performed if the POLICY_FLAG_TRUSTED
is not specified.
Remember the metaState associated with a key event so we can
include it when canceled.
Tell the policy when a fallback is being cancelled so that it
can clean up its state.
After a SEARCH shortcut is invoked, clear the flag indicating
that a shortcut is pending. This is to prevent SEARCH from
getting stuck down in the case where we might forget to send
the up. (Shouldn't happen anymore after the prior fixes.)
Bug: 5616255
Change-Id: I68f0a9679c7af464eaf31c099f2aa50b53fecf1f
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 2a0f228a30c85a124f92a5a7c1b10a81cf69af6d |
|
08-May-2012 |
Romain Guy <romainguy@google.com> |
Invalidate display lists immediately when views are removed/added quickly
The deferred invalidation of display list could cause problems with
view like TextureView who destroy resources when detached from the
window but only recreate them later at draw time. This would cause
temporary flashes or other visual glitches on screen.
Change-Id: I018488ba09743df21c6434ea610813014fb80a85
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| ec4d9040f603b57b1706299f51838b6cc68b8f99 |
|
06-May-2012 |
Romain Guy <romainguy@google.com> |
Merge "Attempt to recover from apps destroying their window at draw time Bug #6436642" into jb-dev
|
| 1f59e5c19bf72f88eed6f8de08b0a879d999f61c |
|
06-May-2012 |
Romain Guy <romainguy@google.com> |
Attempt to recover from apps destroying their window at draw time
Bug #6436642
Change-Id: I906b9c68225683f97b9c97c153a1132cf9ac6509
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 139e5aa1da51b27231ab36344cf2d0dafab23f1e |
|
06-May-2012 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #6404215: New ActionBar auto-hide can conflict with application
The action bar now maintains separate states for the things that can
impact its visibility (calls from the app, action mode, system UI) so
that the changes in these won't incorrectly mix together.
Also added a hack to force the status bar to be shown when showing
the action bar for an action mode, when the UI is in a state where
the action bar would be shown with a gap above where the status bar
is.
Change-Id: Ib0950a7f585c5d2c9e77d11b237ba6e150f15ebd
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 3556c9a8068497d0de8964fd3be719c68eae1f00 |
|
05-May-2012 |
Dianne Hackborn <hackbod@google.com> |
Implement cropping of windows based on system UI elements.
Start calling Surface.setActiveRect().
Change-Id: I94197059c971c6ab7820e615ea8f285482b86c75
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 3fe38c0e73e520c6c38454a41a4cffa16faaf67d |
|
04-May-2012 |
Craig Mautner <cmautner@google.com> |
Retain current visibility when copying layoutparam
The LayoutParams members, systemUiVisibility and
subtreeSystemUiVisibility are derived values rather than app-generated
values. When copying LayoutParams members make sure these values are
not overwritten.
Overwriting them was causing the STATUS_BAR_DISABLE_XXX flags to be
overwritten exposing elements that should have remained hidden.
Fixes bug b6374541.
Change-Id: Iaae4b4167e1b148bbdba4d05f473844f7fa3bf8d
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| fb68fdb9c6e915e38ec5c7f4b0d526b613e4ea8b |
|
01-May-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Merge "Accessibility should not change input focus behavior." into jb-dev
|
| cf8a3b82241a320f568f8448184df6da5bbcf152 |
|
01-May-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Accessibility should not change input focus behavior.
1. Removed a change in the input focus behavior I forgot
to take out when submitted the main accessibility focus
patch. Ugh..
bug:6320098
Change-Id: Id7942e8aac64ba4bf6df7e19f733fa70b368d1bb
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 1e945c4fda0242e8ae02ccb7a2262556f41b42cc |
|
30-Apr-2012 |
Dianne Hackborn <hackbod@google.com> |
Merge "Add system insets to windows." into jb-dev
|
| 2f87014ea2f177e715032b07004d05e2549a63a8 |
|
30-Apr-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Merge "Enabling accessibility focus only if explore by touch is on." into jb-dev
|
| 18dcf2f1cd3f84cbdffd8394e16475a13d6243df |
|
30-Apr-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Merge "Fixing crash when drawing accessibility focus indicator." into jb-dev
|
| 07b726c86b1d0b22e51b08cb4234f8212864d9f9 |
|
30-Apr-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Enabling accessibility focus only if explore by touch is on.
1. Now we will enable the accessibility focus only if Explore by
Touch is enabled. Enabling this feature allows a blind user to
touch the screen and set the accessibility focus at this
location as well as get spoken feedback. Also an accessibility
service can move the accessibility as a result of user gestures
detected only if Explore by Touch is enabled. Since we will
handle some gestures by default if not accessibility service
does so to provide reasonable built-in navigation of the UI
by "objects" we need the accessibility focus functionality.
bug:6383361
Change-Id: I13ce6072a90f5838c7656379788144c99a772bf0
/frameworks/base/core/java/android/view/ViewRootImpl.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/core/java/android/view/ViewRootImpl.java
|
| 1d74df226619101d905d872c8e609d315409695e |
|
29-Apr-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Fixing crash when drawing accessibility focus indicator.
1. Added a lacking null check for the accessibility node
info returned by an accessibility node provider. If
the provider implementation is not correct this may
happen.
2. Added clearing of the current accessibility focused
node when the window focus changes. Now it is cleared
in every case and if it happens that accessibility is
enabled when the window gets focus, the accessibility
focus will be properly set.
bug:6381296
Change-Id: Ieea1b07762745e6d932fc4ed4febfe77760b25b7
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 79c6346100b555a8a3d51b3b1c34dbbe99305b9a |
|
28-Apr-2012 |
Dianne Hackborn <hackbod@google.com> |
Merge "When a window is first shown only draw once while animating." into jb-dev
|
| 771526c88f5cc4b56a41cb12aa06a28d377a07d5 |
|
28-Apr-2012 |
Jeff Brown <jeffbrown@google.com> |
Resample touch events on frame boundaries.
Bug: 6375101
Change-Id: I8774e366306bb2b6b4e42b913525bf25b0380ec3
/frameworks/base/core/java/android/view/ViewRootImpl.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/core/java/android/view/ViewRootImpl.java
|
| 330314c6fb7c178c0f0da65d6aa8c9e7d3004568 |
|
27-Apr-2012 |
Jeff Brown <jeffbrown@google.com> |
Simplify the consume before traversal heuristic.
Calling doConsumeBatchedInput() from doTraversals() can result
in redundant attempts to consume batched input. Instead of making
this call directly, just schedule consume batched input at the
same time as traversals are scheduled. This should have the same
overall effect.
Bug: 6375101
Change-Id: Ie5799e6a68fedbd1978cca6d03852d9a7f1b1f64
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 97d5c418730946a0332f601cd140ed0b12ea19c1 |
|
27-Apr-2012 |
Jeff Brown <jeffbrown@google.com> |
Remove unused pipelining optimization.
Bug: 6375101
Change-Id: I5fcbbabfafae9e1661adac7b2becc748e42c4b66
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| ba6be8a62dcdb3ffd210cd36b9af4e3a658eac47 |
|
24-Apr-2012 |
Romain Guy <romainguy@google.com> |
Prevent WebView from crashing when detached from the window
Bug #6365056
WebView enqueues a functor in the hardware renderer to handle
animations and this functor is called at a later time by the
hardware renderer. However, the functor was not removed from
the queue when WebView was removed from the window. This could
cause the hardware renderer to attempt to execute an invalid
functor and lead to a crash.
Change-Id: I9d38e80f3fdc5e29d4d0cdfa1e893c251a954508
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 72de2062485f711c9a2291c204fd2c0fb6c4e20f |
|
21-Apr-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Merge "Adding support for traversing the content of a node info at granularity."
|
| aa780c110922148a6a4ba06734bb2b0bb8c98f93 |
|
20-Apr-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Adding support for traversing the content of a node info at granularity.
1. A view that creates an accessibility node info may add to the info
a list of granularity labels. These are granularities by which the
source view can iterate over its content. For example a text view
may support character, word link while a web view may additionally
support buttons, tables, etc. There are actions on accessibility
node info to go to the next/previous at a given granularity which
is passesed as an argument.
2. Added Bundle argument to the APIs for performing accessibility
actions. This is generic and extensible.
bug:5932640
Change-Id: I328cbbb4cddfdee082ab2a8b7ff1bd7477d8d6f9
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| d6b1098e1f46530528dfea415655468ec994bbb6 |
|
20-Apr-2012 |
John Reck <jreck@google.com> |
Support fallback action if unhandled key event
Bug: 6023055
Change-Id: Ib802c4b9d1b606f9ea7a5081e30c50b5bd78e30c
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| b78c284bd535f48207750e5a406474ea22381edd |
|
19-Apr-2012 |
Chet Haase <chet@google.com> |
Always execute actions on the runQueue
A View that is not attached will place posted actions on the
ViewRoot's runQueue. Previously, this runQueue was only ever executed
during a layout (during performTraversals()). This works in most situations
(a View that is added to or removed from the hierarchy will force a layout
in general), but not in all cases. For example, a new View being added to
a ListView will not cause a layout, so any actions posted to that View
prior to its being attached will not be run until some indeterminate time
later when a layout happens to run.
The fix is to execute the (typically empty) runQueue on every traversal.
Issue #6366678 View.post() ignored when called on an unattached ListView item
Change-Id: I94e6fdd9da6bb57fd83b547f8d742cd0ddfecbd6
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| f01d3dd710e8b86b3e2846af62835158fd4e0db1 |
|
18-Apr-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Merge "Adding some more gestures and actions for accessibility."
|
| 005b83b0c62d3d0538f0d566b08bd457015ec661 |
|
17-Apr-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Adding some more gestures and actions for accessibility.
1. Added more gesture for accessibility. After a meeting
with the access-eng team we have decided that the current
set of gestures may be smaller than needed considering
that we will use four gestures for home, back, recents,
and notifications.
2. Adding actions for going back, home, opening the recents,
and opening the notifications.
3. Added preliminary mapping from some of the new gestures
to the new actions.
4. Fixed a bug in the accessibility interaction controller
which was trying to create a handled on the main looper
thread which may be null if the queried UI is in the
system process. Now the context looper of the root view
is used.
5. Fixed a bug of using an incorrect constant.
6. Added a missing locking in a couple of places.
7. Fixed view comparison for accessibilityt since it was
not anisymmetric.
bug:5932640
bug:5605641
Change-Id: Icc983bf4eafefa42b65920b3782ed8a25518e94f
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 09dd116cd39613a3736dbbf028544e1655002430 |
|
17-Apr-2012 |
John Reck <jreck@google.com> |
Fix a bug with enterTouchMode removing focus
Bug: 6347083
Fix an issue where enterTouchMode would remove focus from the
view that already has focus and is focusableInTouchMode. This
causes issues with WebView, as it updates internal state when
losing and gaining focus.
Change-Id: I5c1f72cc08baf3445e2be9e0496606a53fb9929e
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 4213804541a8b05cd0587b138a2fd9a3b7fd9350 |
|
20-Mar-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Accessibility focus - framework
Usefulness: Keep track of the current user location in the screen when
traversing the it. Enabling structural and directional
navigation over all elements on the screen. This enables
blind users that know the application layout to efficiently
locate desired elements as opposed to try touch exploring the
region where the the element should be - very tedious.
Rationale: There are two ways to implement accessibility focus One is
to let accessibility services keep track of it since they
have access to the screen content, and another to let the view
hierarchy keep track of it. While the first approach would
require almost no work on our part it poses several challenges
which make it a sub-optimal choice. Having the accessibility focus
in the accessibility service would require that service to scrape
the window content every time it changes to sync the view tree
state and the accessibility focus location. Pretty much the service
will have to keep an off screen model of the screen content. This
could be quite challenging to get right and would incur performance
cost for the multiple IPCs to repeatedly fetch the screen content.
Further, keeping virtual accessibility focus (i.e. in the service)
would require sync of the input and accessibility focus. This could
be challenging to implement right as well. Also, having an unlimited
number of accessibility services we cannot guarantee that they will
have a proper implementation, if any, to allow users to perform structural
navigation of the screen content. Assuming two accessibility
services implement structural navigation via accessibility focus,
there is not guarantee that they will behave similarly by default,
i.e. provide some standard way to navigate the screen content.
Also feedback from experienced accessibility researchers, specifically
T.V Raman, provides evidence that having virtual accessibility focus
creates many issues and it is very hard to get right.
Therefore, keeping accessibility focus in the system will avoid
keeping an off-screen model in accessibility services, it will always
be in sync with the state of the view hierarchy and the input focus.
Also this will allow having a default behavior for traversing the
screen via this accessibility focus that is consistent in all
accessibility services. We provide accessibility services with APIs to
override this behavior but all of them will perform screen traversal
in a consistent way by default.
Behavior: If accessibility is enabled the accessibility focus is the leading one
and the input follows it. Putting accessibility focus on a view moves
the input focus there. Clearing the accessibility focus of a view, clears
the input focus of this view. If accessibility focus is on a view that
cannot take input focus, then no other view should have input focus.
In accessibility mode we initially give accessibility focus to the topmost
view and no view has input focus. This ensures consistent behavior accross
all apps. Note that accessibility focus can move hierarchically in the
view tree and having it at the root is better than putting it where the
input focus would be - at the first input focusable which could be at
an arbitrary depth in the view tree. By default not all views are reported
for accessibility, only the important ones. A view may be explicitly labeled
as important or not for accessibility, or the system determines which one
is such - default. Important views for accessibility are all views that are
not dumb layout managers used only to arrange their chidren. Since the same
content arrangement can be obtained via different combintation of layout
managers, such managers cannot be used to reliably determine the application
structure. For example, a user should see a list as a list view with several
list items and each list item as a text view and a button as opposed to seeing
all the layout managers used to arrange the list item's content.
By default only important for accessibility views are regared for accessibility
purposes. View not regarded for accessibility neither fire accessibility events,
nor are reported being on the screen. An accessibility service may request the
system to regard all views. If the target SDK of an accessibility services is
less than JellyBean, then all views are regarded for accessibility.
Note that an accessibility service that requires all view to be ragarded for
accessibility may put accessibility focus on any view. Hence, it may implement
any navigational paradigm if desired. Especially considering the fact that
the system is detecting some standard gestures and delegates their processing
to an accessibility service. The default implementation of an accessibility
services performs the defualt navigation.
bug:5932640
bug:5605641
Change-Id: Ieac461d480579d706a847b9325720cb254736ebe
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 067b091d46c3c2d11a33d25e81c8348fb609b7ab |
|
13-Apr-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Accessibility query APIs report invisible views.
1. The accessibility querying APIs failed to check whether
all predecessors of a view are visible before reporting it.
bug:6291855
Change-Id: I364a6f08e8d02c7105c00c9fdff0fec033829554
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| aa6f3de253db6c0702de0cc40028750c1fcfb22c |
|
10-Apr-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Some view not shown on the screen are reported for accessibility.
1. Some applications are keeping around visible views off screen
to improve responsiveness by drawing them in layers, etc. While
such a view is not visible on the screen the accessibility layer
was reporting it since it was visible. Now the check is improved
to verify whether the view is attached, is in visible window,
is visible, and has a rectangle that is not clipped by its
predecessors.
2. AccessibilityNodeInfo bounds in screen were not properly set
since only the top left point was offset appropriately to
take into account any predecessor's transformation matrix
and the not transformed width and height were used. Now
the bounds are properly offset.
bug:6291855
Change-Id: I244d1d9af81391676c1c9e0fe86cf4574ff37225
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| edbca1285e4757900e43d31087451d1953555d7d |
|
05-Apr-2012 |
Romain Guy <romainguy@google.com> |
Make sure we clean up after ourselves
Because of the mAdded=false statement a few lines above, a large section
of doDie() was not executed. Things would eventually get cleaned up
but it seems better to do it at the right time.
Change-Id: I1a2f3a8e05057dd7cd7205b6d3f9c145d6c0241d
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 25eba5c5029bd91ff7e396b2cca0e4ce024124ed |
|
05-Apr-2012 |
Romain Guy <romainguy@google.com> |
Add a new OnDrawListener to ViewRoot
This can be used by app to efficiently listen for draw passes. This listener
is guaranteed to not generate any garbage unlike OnPreDrawListener.
Change-Id: Ida40d11a3f8a5d2617bafe722906ee5c9af48602
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 3a3a6cfd8ec12208ca75c0d0d871d19d76c34194 |
|
26-Mar-2012 |
Dianne Hackborn <hackbod@google.com> |
Add new feature to let apps layout over status bar / system bar.
The main change is a few new flags you can supply to
View.setSystemUiVisibility(). One is a new visibility mode,
SYSTEM_UI_FLAG_FULLSCREEN, which is basically the same as
the global FLAG_FULLSCREEN option for windows, but driven as
part of the system UI state.
There are also three new flags for telling the framework that you
would like to have your application's UI ignore screen
decorations -- SYSTEM_UI_FLAG_LAYOUT_NO_NAVIGATION for going
behind the navigation bar and SYSTEM_UI_FLAG_LAYOUT_FULLSCREEN
for ignoring full screen decorations (that is the status bar).
In combination with this you can use SYSTEM_UI_FLAG_LAYOUT_STABLE
to have the framework report consistent insets to your application.
When using NO_NAVIGATION, when the user taps the screen we now
also automatically clear ONLY_CONTENT, so that we atomically show
both UI elements. This should make it easy for apps like video
players that want to move between fully full-screen and regular
modes.
The ActionBar has also been extended when in overlay mode so
that it will adjust the system window insets to also account
for its space, and allow it to be hidden using the new
SYSTEM_UI_FLAG_FULLSCREEN.
Change-Id: Ic8db1adec49a0f420bfe40c1d92eb21307856d0b
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| fa8b27c858438554fd94c014de959d8ec6b208bb |
|
30-Mar-2012 |
Jeff Brown <jeffbrown@google.com> |
Improve responsiveness by always consuming batched events.
Change-Id: I2eb88f8fde97ce0cd820f39da4ebe8698a7db95c
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| a08f3e866a46c990e786defa95013ee0313b0887 |
|
30-Mar-2012 |
Jeff Brown <jeffbrown@google.com> |
Merge "Enable vsync traversals by default."
|
| ebb2d8d708c5c58c79ae88ac2bd10450a856f702 |
|
24-Mar-2012 |
Jeff Brown <jeffbrown@google.com> |
Enable vsync traversals by default.
Improved how the various callbacks are managed and sequenced
to reduce code duplication.
Added a heuristic to avoid postponing traversals until
the next vsync frame if we did not actually do any drawing during
the previous frame. This helps in the very common case where
drawing occurs in response to input.
Change-Id: I277d9eeaf50408f8745a3cfd181db1d140770658
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| a998dff5d49a423aaf7097aa8f96bf5bdc681d25 |
|
24-Mar-2012 |
Romain Guy <romainguy@google.com> |
Destroy the hardware renderer when ViewRootImpl's die is post-poned
Bug #6109035
ViewRootImpl.die() can be invoked in such a way that doDie() will be
executed later. On memory limited device, an eglTerminate() may happen
before doDie() is executed which leads to unstable behaviors. This
change makes sure the renderer is destroyed as soon as possible.
Change-Id: I3322410cdd744b464951e2055aeade6069d1d673
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 006f0e41abca961bade88908d7ef56ae63c429fb |
|
21-Mar-2012 |
Craig Mautner <cmautner@google.com> |
Override not drawing to screen when screen is off.
A new test had been added to performDraw to provide an early return if
the screen was off. Drawing should have proceeded however if
mReportNextDraw is set. Otherwise views that turn on the screen (such
as the alarm) are not shown.
Fixes bug 6168158.
Change-Id: If9013d9dbd39d60ee1de8aeb3e0c1facbc5a7db5
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 7b2f8b8fb7064a1d3b6d942b978c30c24c9d7299 |
|
20-Mar-2012 |
Romain Guy <romainguy@google.com> |
Pre-scale bitmaps on the native heap
Change-Id: I9819b532b89a997ab775b31ffee46445f1d16e20
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 51e4d4db296c252641161b39e98f49acebc46062 |
|
16-Mar-2012 |
Romain Guy <romainguy@google.com> |
Better implementation to clear display lists
Change-Id: I58f9af4bae70a8117db1455a50c0c5daf19b2f4a
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 481c1570dc5cdf58265b53f657801709dd05d1df |
|
09-Mar-2012 |
Jeff Brown <jeffbrown@google.com> |
Add Java wrappers for new atrace functionality.
Instrument a few parts of the input dispatcher and the
view hierarchy.
Change-Id: I49285c9fb3502253baa1ffed60f521b8c24fccaf
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| df813c03b16ed32c25a8c8fee82a7a98088ac940 |
|
09-Mar-2012 |
Jeff Brown <jeffbrown@google.com> |
Merge "Use the Choreographer for Drawable animations."
|
| 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/core/java/android/view/ViewRootImpl.java
|
| 250069bf6bf3d7e2ef85c49e0cd100e80c3c8b7d |
|
08-Mar-2012 |
Romain Guy <romainguy@google.com> |
Merge "Ignore draw requests when the display is off"
|
| 7ae9d5faad5816f7e567ec1ec77e78d746cf7e5c |
|
06-Mar-2012 |
Jeff Brown <jeffbrown@google.com> |
Use the Choreographer for Drawable animations.
Change-Id: Ifcbf33434bf3c32d1900fd0b3f5bde004604ce8a
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 5bebea436e631aa77aeb0f39a34c9e830c9638f5 |
|
06-Mar-2012 |
Jeff Brown <jeffbrown@google.com> |
Rename remove callback methods.
Change-Id: Ib9ef32fedbe0db2ea5efd250693915d626d7d8ae
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 6cb7b46c56449e84434b11eb12f9b8977fcd0398 |
|
05-Mar-2012 |
Jeff Brown <jeffbrown@google.com> |
Change widgets to post invalidate to the animation timer.
Change-Id: I8377e924529fb9d8afd8a834003a17de616e8e87
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 7e4e561bc717a6eea4e0d06ec4173ad27420425f |
|
05-Mar-2012 |
Romain Guy <romainguy@google.com> |
Ignore draw requests when the display is off
When WindowManagerService's events are enabled/disabled, the state of the
display is dispatched to the known windows. This allows ViewRootImpl to
ignore draw requests until the screen is turned back on. This can potentially
lead to significant battery savings. For instance, a launcher widget showing
a repeating animation will cause the CPU and the GPU to wake up regularly
without this change.
(Change submitted by Intel and merged manually)
Change-Id: I7f93b0e60c3e6de1705f619e80860c36b1cdb978
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 00d0c14a0fe8e6dff8dd3e230ee4b61dd275f860 |
|
24-Feb-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Regression: Cannot query the content of certain windows.
1. A bad merge on my part caused ViewRootImpl not to register
for accessibility state change.
bug:6064348
Change-Id: Idf7b8b444e9021e9d9ec3749164cfe448c8268ab
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 42d840b91d161fe98ebe3305f011b3b0f6d4561c |
|
24-Feb-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Merge "Fixing issues with the AccessibilityNodeInfo cache."
|
| 57c7fd5a43237afc5e8ef31a076e862c0c16c328 |
|
24-Feb-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Fixing issues with the AccessibilityNodeInfo cache.
1. Before there were two caches one in the app process that
kept track only the ids of infos that were given to a
querying client and one in the querying client that
holds the infos. This design requires precise sync
between the caches. Doing that is somehow complicated
since the app has cache for each window and it has
to intercept all accessibility events from that window
to manage the cache. Each app has to have a cache for
each querying client. This approach would guarantee that
no infos are fetched twice but due to its stateful nature
and the two caches is tricky to implement and adds
unnecessary complexity. Now there is only one cache in
the client and the apps are stateless. The client is
passing flags to the app that are a clue what nodes to
prefetch. This approach may occasionally fetch a node
twice but it is considerably simpler and stateless
from the app perspective - there is only one cache.
Fetching a node more than once does not cause much
overhead compared to the IPC.
Change-Id: Ia02f6fe4f82cff9a9c2e21f4a36747de0f414c6f
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| cfef12374c15b11b3c2a1041582be9728152e15d |
|
23-Feb-2012 |
Romain Guy <romainguy@google.com> |
Perform early intersect to avoid unnecessary draws
Change-Id: I48d61c4488e622f93733d8e53a50c93e6a20166d
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 0d04e245534cf777dfaf16dce3c51553837c14ff |
|
21-Feb-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Improving accessibility APIs used for UI automation.
1. UiTestAutomationBridge was accessing the root node in the
active window by tracking the accessibility event stream
and keeping the last active window changing event. Now
the bridge is stateless and the root node is fetched by
passing special window and view id with the request to
the system.
2. AccessibilityNodeInfos that are cached were not finished,
i.e. not sealed, causing exception when trying to access
their children or rpedecessors.
3. AccessibilityManagerService was not properly restoring its
state after the UI automation bridge disconnects from it.
I particular the devices was still in explore by touch mode
event if no services are enabled and the sutomation bridge
is disconnected.
4. ViewRootImpl for the focused window now fires accessibility
events when accessibility is enabled to allow accessibility
services to determine the current user location.
5. Several missing null checks in ViewRootImpl are fixed since
there were scenraios in which a NPE can occur.
6. Update the internal window content querying tests.
7. ViewRootImpl was firing one extra focus event.
bug:6009813
bug:6026952
Change-Id: Ib2e058d64538ecc268f9ef7a8f36ead047868a05
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 539ee8716b4f81260bab2e9f3dc5d88d81c99985 |
|
04-Feb-2012 |
Adam Powell <adamp@google.com> |
Add transient state tracking to Views
Transient state is temporary bookkeeping that Views need to perform
that the app should not need to be aware of. Examples include text
selection regions and animation state.
Transient state is a problem for AdapterViews like ListView that do
view recycling. Unless the app takes responsibility for tracking and
restoring transient state as if it were a part of the adapter's data
set, it cannot correctly recycle views. Selections disappear when an
EditText is scrolled out of sight and animations seem to play on the
wrong views.
Views can now flag themselves as having transient state. (As the name
implies, this should be a temporary condition.) If a ViewGroup
contains a child with transient state, that ViewGroup also has
transient state.
AbsListView's recycler now tracks views with transient state
separately. Views with transient state will be retained, and until a
data set change occurs the same view will be reused for that position
instead of calling the adapter's getView() method.
The API to set and check transient state is currently hidden.
Change-Id: Idfd8eaac2c548337686d8d9f98fda4c64be5b8a0
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| e0dbd002750856e55d637e883b629e09adfc8a4e |
|
16-Feb-2012 |
Jeff Brown <jeffbrown@google.com> |
Mark input and sensor messages as asynchronous.
Set a barrier on traversals.
Vsync is still not enabled by default in this patch so there
should be no observable effect from these changes.
Change-Id: Ie12081b95a8f1e81ed686edf747cc62f2e044b7e
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| a175a5b7ea3682cb58cca7f9726d0b8171cd549d |
|
16-Feb-2012 |
Jeff Brown <jeffbrown@google.com> |
Encapsulate the ViewRootImpl's handler.
This change makes it much easier to make sense of the messages that
get posted to the ViewRootImpl's handler by encapsulating their point
of dispatch within the ViewRootImpl itself.
As part of this change, the View.AttachInfo now carries a reference
to the ViewRootImpl itself, which simplifies some code that used
to try to find the ViewRootImpl by getting the root view's parent.
In principle, it might have been nice to hide the ViewRootImpl from
the View hierarchy but in practice the two were coupled in many ways.
Change-Id: I51ebccdf5f8c8c505cd6f17cdf594174d041dc54
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 4a06c8008b2edd6677f9a411af79b0a4971b87fe |
|
16-Feb-2012 |
Jeff Brown <jeffbrown@google.com> |
Simplify Choreographer API.
Removed the listeners and schedule animation / draw methods.
Instead all requests are posted as one-shot callbacks, which is a
better match for how clients actually use the Choreographer.
Bug: 5721047
Change-Id: I113180b2713a300e4444d0d987f52b8157b7ac15
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| b36a0ac9709e9e1c7098559c0435cfbdc09e6c46 |
|
15-Feb-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Incorrect behavior of View clear focus v2.0.
The framework tries to have a focused view all the time. For
that purpose when a view's focus is cleared the focus is given
to the first focusable found from the top. The implementation
of this behavior was causing the following issues:
1. If the fist focusable View tries to clear its focus it
was getting focus but the onFocusChange callbacks were not
properly invoked. Specifically, the onFocusChange for
gaining focus was called first and then the same
callback for clearing focus. Note that the callback
for clearing focus is called when the View is already
focused.
2. If not the first focusable View tries to clear focus,
the focus is given to another one but the callback
for getting focus was called before the one for clearing,
so client code may be mislead that there is more than
one focused view at a time.
3. (Nit) The implementaion of clearFocus and unFocus in ViewGroup
was calling the super implementaion when there is a
focused child. Since there could be only one focused View,
having a focused child means that the group is not focused
and the call to the super implementation is not needed.
4. Added unit tests that verify the correct behavior, i.e.
the focus of the first focused view cannot be cleared
which means that no focus change callbacks are invoked.
The callbacks should be called in expected order.
Now the view focus clear precedes the view focus gain
callback. However, in between is invoked the global
focus change callback with the correct values. We may
want to call that one after the View callbacks. If
needed we can revisit this.
Change-Id: I8cfb141c948141703093cf6fa2037be60861cee0
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| dd29f8c4e3db3338bc055302145c3bc51a27566f |
|
15-Feb-2012 |
Amith Yamasani <yamasani@google.com> |
Merge "Revert "Incorrect behavior of View clear focus.""
|
| 73eb97f628b298c7bd032aa9db11dadf05f5b539 |
|
15-Feb-2012 |
Amith Yamasani <yamasani@google.com> |
Revert "Incorrect behavior of View clear focus."
This reverts commit c6fd88e213703a581fe4680259981f09ae0444f2
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 072ec96a4900d4616574733646ee46311cb5d2cb |
|
07-Feb-2012 |
Jeff Brown <jeffbrown@google.com> |
Implement batching of input events on the consumer side.
To support this feature, the input dispatcher now allows input
events to be acknowledged out-of-order. As a result, the
consumer can choose to defer handling an input event from one
device (because it is building a big batch) while continuing
to handle input events from other devices.
The InputEventReceiver now sends a notification when a batch
is pending. The ViewRoot handles this notification by scheduling
a draw on the next sync. When the draw happens, the InputEventReceiver
is instructed to consume all pending batched input events, the
input event queue is fully processed (as much as possible),
and then the ViewRoot performs traversals as usual.
With these changes in place, the input dispatch latency is
consistently less than one frame as long as the application itself
isn't stalled. Input events are delivered to the application
as soon as possible and are handled as soon as possible. In practice,
it is no longer possible for an application to build up a huge
backlog of touch events.
This is part of a series of changes to improve input system pipelining.
Bug: 5963420
Change-Id: I42c01117eca78f12d66d49a736c1c122346ccd1d
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| f9261d20b3773f9785d98f32f62ccfedefba8083 |
|
03-Feb-2012 |
Jeff Brown <jeffbrown@google.com> |
Process input events immediately when received.
Reduce the latency for handling input events by ensuring that they are
handled as soon as they are received from the dispatcher. This also
makes it easier for the input system to intelligently batch motion events.
This is part of a series of changes to improve input system pipelining.
Bug: 5963420
Change-Id: I0b3f6cbb3de5ac3c4eed35dfc774d6bd4a0b07fc
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| c38fa1f63674971f9ac6ced1a449fb81026b62f7 |
|
02-Feb-2012 |
Chet Haase <chet@google.com> |
Add Developer Option setting for Animator scaling.
This new setting allows users to set a scale factor for the
duration and startDelay of all Animator-based animations. This
setting is very similar to the Transition animation scale and
Window animation scale settings, except this one applies specifically
to Animator animations. The property is only accessible by users
through the Settings UI, not programmatically. The value applies
system-wide and is picked up per-process at the time of the first
ValueAnimator construction.
This is an update to a previous CL; this approach uses the WindowManager
to store the animator scale settings, instead of SystemProperties.
Change-Id: I8295fab060aa6d597ae507ded8f9c9d6077be966
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| bbf1bc8b6c3348265930ce08506efbbd3c5ab61f |
|
02-Feb-2012 |
Romain Guy <romainguy@google.com> |
Merge "Add optional metadata to initiliaze the render threat."
|
| 211370fd943cf26905001b38b8b1791851b26adc |
|
02-Feb-2012 |
Romain Guy <romainguy@google.com> |
Add optional metadata to initiliaze the render threat.
The render threat is likely to break your application if you initiate it.
As such it must be explicitely requested using the following meta-data
tag in your manifest's application tag:
<meta-data android:name="android.graphics.renderThread" android:value="true" />
Change-Id: Ibf0a48af2a0d091562bf6907eac970e3d1d601c4
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 2eecea3b48ece6f45b30fef9b41dc20075ccc94f |
|
01-Feb-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Merge "Speedup the accessibility window querying APIs and clean up."
|
| c6fd88e213703a581fe4680259981f09ae0444f2 |
|
26-Jan-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Incorrect behavior of View clear focus.
The framework tries to have a focused view all the time. For
that purpose when a view's focus is cleared the focus is given
to the first focusable found from the top. The implementation
of this behavior was causing the following issues:
1. If the fist focusable View tries to clear its focus it
was getting focus but the onFocusChange callbacks were not
properly invoked. Specifically, the onFocusChange for
gaining focus was called first and then the same
callback for clearing focus. Note that the callback
for clearing focus is called when the View is already
focused. Also note that at the end the View did not
clear its focus, hence no focus change callbacks
should be invoked.
2. If not the first focusable View tries to clear focus,
the focus is given to another one but the callback
for getting focus was called before the one for clearing,
so client code may be mislead that there is more than
one focused view at a time.
3. (Nit) The implementaion of clearFocus and unFocus in ViewGroup
was calling the super implementaion when there is a
focused child. Since there could be only one focused View,
having a focused child means that the group is not focused
and the call to the super implementation is not needed.
4. Added unit tests that verify the correct behavior, i.e.
the focus of the first focused view cannot be cleared
which means that no focus change callbacks are invoked.
The callbacks should be called in expected order.
Now the view focus clear precedes the view focus gain
callback. However, in between is invoked the global
focus change callback with the correct values. We may
want to call that one after the View callbacks. If
needed we can revisit this.
Change-Id: Iee80baf5c75c82d3cda09679e4949483cad475f1
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 79311c4af8b54d3cd47ab37a120c648bfc990511 |
|
18-Jan-2012 |
Svetoslav Ganov <svetoslavganov@google.com> |
Speedup the accessibility window querying APIs and clean up.
1. Now when an interrogating client requires an AccessibilibtyNodeInfo
we aggressively prefetch all the predecessors of that node and its
descendants. The number of fetched nodes in one call is limited to
keep the APIs responsive. The prefetched nodes infos are cached in
the client process. The node info cache is invalidated partially or
completely based on the fired accessibility events. For example,
TYPE_WINDOW_STATE_CHANGED event clears the cache while
TYPE_VIEW_FOCUSED removed the focused node from the cache, etc.
Note that the cache is only for the currently active window.
The ViewRootImple also keeps track of only the ids of the node
infos it has sent to each querying process to avoid duplicating
work. Usually only one process will query the screen content
but we support the general case. Also all the caches are
automatically invalidated so not additional bookkeeping is
required. This simple strategy leads to 10X improving the
speed of the querying APIs.
2. The Monkey and UI test automation framework were registering a
raw event listener for accessibility events and hence perform
connection and cache management in similar way to an AccessibilityService.
This is fragile and requires the implementer to know internal framework
stuff. Now the functionality required by the Monkey and the UI automation
is encapsulated in a new UiTestAutomationBridge class. To enable this
was requited some refactoring of AccessibilityService.
3. Removed the *doSomethiong*InActiveWindow methods from the
AccessibilityInteractionClient and the AccessibilityInteractionConnection.
The function of these methods is implemented by the not *InActiveWindow
version while passing appropriate constants.
4. Updated the internal window Querying tests to use the new
UiTestAutomationBridge.
5. If the ViewRootImple was not initialized the querying APIs of
the IAccessibilityInteractionConnection implementation were
returning immediately without calling the callback with null.
This was causing the client side to wait until it times out. Now
the client is notified as soon as the call fails.
6. Added a check to guarantee that Views with AccessibilityNodeProvider
do not have children.
bug:5879530
Change-Id: I3ee43718748fec6e570992c7073c8f6f1fc269b3
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 44d79747b5e434e8f43928b5548442c65e40e5c3 |
|
13-Jan-2012 |
Romain Guy <romainguy@google.com> |
Remove unused parameter
Change-Id: I0896b2cdb9f1fa9c5e191e4ea425e22ac6f10f29
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| bdc18b28eb04b8c8cc00313096f8bfb142e407e3 |
|
09-Dec-2011 |
Jeff Brown <jeffbrown@google.com> |
am 03e63427: am 8e0ecbfc: Merge "Shortcut keys should be handled on down, not up." into ics-mr1
* commit '03e634270d880407316b51fac2278e604fc82703':
Shortcut keys should be handled on down, not up.
|
| 7bedf2449041a425899448cb672e91b0a5c97c62 |
|
08-Dec-2011 |
Jeff Brown <jeffbrown@google.com> |
Shortcut keys should be handled on down, not up.
Bug: 5720360
Change-Id: I3afc278e576ea992c76f024c8b6bad14b214239c
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 07069a04ef2e52ad6cebd9041b5288bebd811a38 |
|
07-Dec-2011 |
Jeff Brown <jeffbrown@google.com> |
Fix PIN pad.
Some widgets apparently inject keys into the ViewRoot by sending
a DISPATCH_KEY message to its handler. Ugh.
Bug: 5711577
Change-Id: Ibe9aaf705095d152ec866c536f31f5d85e27b97f
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 96e942dabeeaaa9ab6df3a870668c6fe53d930da |
|
01-Dec-2011 |
Jeff Brown <jeffbrown@google.com> |
Use a Choreographer to schedule animation and drawing.
Both animations and drawing need to march to the beat of
the same drum, but the animation system doesn't know
abgout the view system and vice-versa so neither one
can drive the other.
We introduce the Choreographer as a drummer to keep
everyone in time and ensure a magnificent performance.
This patch enabled VSync based animations and drawing by
default. Two system properties are provided for testing
purposes to control the behavior.
"debug.choreographer.vsync": Enables vsync based animation
timing. Defaults to true. When false, animations are
timed by posting delayed messages to a message queue in
the same way they used to be before this patch.
"debug.choreographer.animdraw": Enables the use of the animation
timer to drive drawing such that drawing is synchronized with
animations (in other words, with vsync or the timing loop).
Defaults to true. When false, layout traversals and drawing
are posted to the message queue for execution without any delay or
synchronization in the same way they used to be before this patch.
Stubbed out part of the layoutlib animation code because it
depends on the old timing loop (opened bug 5712395)
Change-Id: I186d9518648e89bc3e809e393e9a9148bbbecc4d
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 92cc2d8dc35f2bdd1bb95ab24787066371064899 |
|
02-Dec-2011 |
Jeff Brown <jeffbrown@google.com> |
Remove type tests when recycling input events.
Change-Id: I1c2d5980a763c457a0546bbf601e686c601a4c03
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 32cbc3855c2a971aa5a801fd339fb6a37db91a1a |
|
01-Dec-2011 |
Jeff Brown <jeffbrown@google.com> |
Refactor InputQueue as InputEventReceiver.
This change simplifies the code associated with receiving input
events from input channels and makes it more robust. It also
does a better job of ensuring that input events are properly
recycled (sometimes we dropped them on the floor).
This change also adds a sequence number to all events, which is
handy for determining whether we are looking at the same event or a
new one, particularly when events are recycled.
Change-Id: I4ebd88f73b5f77f3e150778cd550e7f91956aac2
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 4952dfd16a0f839559ffa78f5016394caf85294f |
|
01-Dec-2011 |
Jeff Brown <jeffbrown@google.com> |
Ensure input events are processed in-order in the application.
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
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 95db2b20d7bc0aaf00b1d4418124f5cf0a755d74 |
|
01-Dec-2011 |
Jeff Brown <jeffbrown@google.com> |
Improve latency instrumentation.
Change-Id: I4edfa0a5659d207f7e46722e48ffa1dc43d2aa13
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| c0b7f65ae0594e19d1272e5caf2d83638041d19c |
|
29-Nov-2011 |
Dianne Hackborn <hackbod@google.com> |
am 496f6e2a: am b54980d1: Merge "Fix issue #5588689: Black camera preview after coming back from gmail" into ics-mr1
* commit '496f6e2ad656c5bb8a277e191554d16abd290b58':
Fix issue #5588689: Black camera preview after coming back from gmail
|
| b54980d1d4d903f68cdfa952256afff01902cd94 |
|
29-Nov-2011 |
Dianne Hackborn <hackbod@google.com> |
Merge "Fix issue #5588689: Black camera preview after coming back from gmail" into ics-mr1
|
| d3ea6b40bb8f0fbc2a877963db1ab4fa0fc02b2f |
|
29-Nov-2011 |
Chet Haase <chet@google.com> |
am 38928899: am 8990cb57: Merge "Fix flashing wifi dialog after rotating back from landscape." into ics-mr1
* commit '3892889952b0ad3fa0b095c96d8ae2ae110585e2':
Fix flashing wifi dialog after rotating back from landscape.
|
| 08837c246c9c27902c59b41c8661c2f27a4aa2bc |
|
28-Nov-2011 |
Chet Haase <chet@google.com> |
Fix flashing wifi dialog after rotating back from landscape.
There was an error in some of the OpenGL layer logic such that we would
occasionally set up a layer for rendering and then not clean up when it was
done. This caused future OpenGL rendering to go into that layer instead of
to the buffers being displayed on the screen, resulting in artifacts including
flashes and displaying of stale content. This happened specifically when
using the wifi settings dialog with the InputMethod keyboard displayed,
but it was probably visible in other situations as well.
Issue #5628248: Flickering/flashing after entering password for WiFi
Change-Id: I38139f620b310f4309570fa7224552d2ee633999
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 6d05fd3c795088ac60f86382df5a66d631e8a0cb |
|
19-Nov-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #5588689: Black camera preview after coming back from gmail
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
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 3526b00a53a2582a51ff8b98ac1400a48f351107 |
|
22-Nov-2011 |
Romain Guy <romainguy@google.com> |
am c26e4d18: am 8cd39e3a: Merge "Notify views when EGL resources are about to be destroyed Bug #5639899" into ics-mr1
* commit 'c26e4d18a20ab0b3e769fb3e547994f1c27d6713':
Notify views when EGL resources are about to be destroyed Bug #5639899
|
| 31f2c2e94656530fbf6282803e62edb47e9a894d |
|
21-Nov-2011 |
Romain Guy <romainguy@google.com> |
Notify views when EGL resources are about to be destroyed
Bug #5639899
Change-Id: I7c5d8bebf02294426f5b3ab1358a31c38a4fd064
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 1333742bedc9b462024302f302e3a7f27053df66 |
|
11-Nov-2011 |
Akwasi Boateng <akwasi.boateng@ti.com> |
am cb0db030: Merge branch \'ics-mr1-plus-aosp\' of ssh://android-git:29418/platform/frameworks/base into ics-mr1-plus-aosp
* commit 'cb0db0306b5849a35d3d99eea1b34ce019c6f0d8':
Make the overridden ImageView#setVisibility remotable
Clamp non-monotonic stats instead of dropping.
DO NOT MERGE. Fix leak in LayoutTransition
Fix lastVisible/global rects
Fix Wimax-less build.
Fix leak in LayoutTransition
Deferring wallpaper update to improve workspace scrolling (issue 5506959)
Terminate EGL when an app goes in the background
boot animation is dithered and scaled
Fix NdefRecord byte-stream constructor.
PopupWindow dismiss() can get into a recursive loop.
Fold WiMAX state into the mobile RSSI.
Remove dedicated wimax icon to fix RSSI layout.
|
| 8ff6b9ebeeb24a6161ec6098e6bfdf8790ee5695 |
|
10-Nov-2011 |
Romain Guy <romainguy@google.com> |
Terminate EGL when an app goes in the background
This does not happen on high end gfx devices. This happens
only if only one EGL context is initialized in the current
process.
Change-Id: Ibd1737efdf84eef8a84108b05795440d1ae9964e
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 2a639347aebb56febdef21a78c70fb0433adc1e5 |
|
05-Nov-2011 |
Chet Haase <chet@google.com> |
resolved conflicts for merge of aa4d2f69 to master
Change-Id: Iadb63ecf52d8bd2911276fa3db55a43c9c378620
|
| 1f4786bbe1ed7ae54b94cd52c0e1a4a826fecd68 |
|
02-Nov-2011 |
Chet Haase <chet@google.com> |
Improve Launcher drag performance.
Launcher swiping looks choppy. It's because we deliver the
motion events of the drags asynchronously, and sometimes we
may get an event to redraw before the motion event is posted, so we
end up drawing again without updating to the latest motion
information.
This fix makes input event processing more proactive. Every time
we run ViewRootImpl.performTraversals() (which is what
happens whenever we need to layout, measure, and/or draw), we
first process all pending input events, ensuring that we are
completely up-to-date with posted events prior to drawing, so that the
drawing we do is synchronous with the events we've received.
This eliminates the choppiness and means that we can now get the full
refresh rate on the screen with drag events.
The fix was done for Launcher, but it is pervasive in the system,
so this may fix other laggy drag behavior as well.
Change-Id: I8dbed6acadc2662f317f736e769f536f555701aa
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| f31aba7346c6991ac8848f3b3992651a68781a10 |
|
29-Oct-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Fixing the build breakage due to bad merge.
Change-Id: I2804bccc44e061229c3f7b2ad9e00b9e0a0ba916
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| f79f476fd1e25d3d7bf77e890d064a503537e939 |
|
29-Oct-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
resolved conflicts for merge of c00d2ddc to master
Change-Id: I075cc5b5df2909152ee463f8a0c7534344b47c62
|
| af5b4f471df108ffbe1c3861d18b2141710d7bf8 |
|
28-Oct-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Fixing a memory leak in accessibility enteraction APIs.
1. AccessibilityInteractionConnection was non-static inner
class, hence keeping a handle to the enclosing ViewRootImpl
resulting in leaking activities.
bug:5525412
Change-Id: Ie438861663d623d503995844125d9e15d677fc32
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 021078554b902179442a345a9d080a165c3b5139 |
|
04-Oct-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Adding APIs to enable reporting virtual view hierarchies to accessibility serivces.
Added an interface that is the contract for a client to expose a virtual
view hierarchy to accessibility services. Clients impement this interface
and set it in the View that is the root of the virtual sub-tree. Adding
this finctionality via compostion as opposed to inheritance enables apps
to maintain backwards compatibility by setting the accessibility virtual
hierarchy provider on the View only if the API version is high enough.
bug:5382859
Change-Id: I7e3927b71a5517943c6cb071be2e87fba23132bf
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 972b7d2c3bbb54a61a505d9d78927a158356ffb6 |
|
21-Oct-2011 |
Gilles Debunne <debunne@google.com> |
Merge "Typo in ViewRootImpl"
|
| 5ac84423a28fea4924eb1c389d647defe1c1b93c |
|
19-Oct-2011 |
Gilles Debunne <debunne@google.com> |
Typo in ViewRootImpl
Change-Id: I4a5acfb091ce05f56cdbaa0a56809f377cbf9b39
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 841d79497d9eff2d4df6948380b79db316d24dc3 |
|
18-Oct-2011 |
Chet Haase <chet@google.com> |
am 87bc53de: Merge "Make notification panel delete-all animation smoother" into ics-mr0
* commit '87bc53de2adf479ad5a5e226bf3d8fd31af6dc21':
Make notification panel delete-all animation smoother
|
| 2f2022afa1eb85018368398bd150e9575fc099c9 |
|
11-Oct-2011 |
Chet Haase <chet@google.com> |
Make notification panel delete-all animation smoother
Making the notfication delete-all animation smoother by carefully
choreographing the various parts of it. The problem with the previous
animation was that there was simply too much going on at the
same time, causing things like layout and recreating display-lists
in the middle of animations that became choppy as a result. This
approach swipes all items off quickly, then scrolls the shade up to the
top, making both sets of animations smoother as a result.
Fixes #5431207: Notification delete-all should be smoother
Change-Id: Iefe8ab5d661e05adcd10379dab85227d17904450
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 856d4e1a872b5aed6792b33e0360554cb3d19eed |
|
15-Oct-2011 |
Romain Guy <romainguy@google.com> |
Disable hardware acceleration for apps in compatibility mode
Change-Id: I2d1c01a30c6fe6fff85c2a9bd6ee6de98e1ed422
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 85b9edf2da0534bc53d139bb88cda8866d265afe |
|
07-Oct-2011 |
Dianne Hackborn <hackbod@google.com> |
Merge "Fix issue #5371530: SYSTEMUI_FLAG_HIDE_NAVIGATION reasserts itself immediately"
|
| 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/core/java/android/view/ViewRootImpl.java
|
| 40e0383dce630ed9b2b1aa0e497709b89dfab6ef |
|
06-Oct-2011 |
Chet Haase <chet@google.com> |
Fix issue #5384631: hw windows not resizing correctly
When the SystemUi becomes visible, the activity window resizes.
The hardware renderer was not begin resized to suit, so it was drawing
to a surface larger than that of the activity window, and some of the
rendering (like the action bar) appeared off the screen.
The fix is to keep track of the surface size in HardwareRenderer and to
recreate the surface when the size changes.
This change also removes the BUFFER_CHANGE flag from WindowManager.LayoutParams.
The only reason the flag existed was to trigger a hardware surface recreation,
but checking the old/new size is a more direct way of handling this.
Change-Id: I9d6bf6385794886d1d93c60609c170864cdcdfab
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 2588a07730ff511329c87b5f61b20419b2443d48 |
|
04-Oct-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Merge "The logic for not populating text to some accessibility events is scattered."
|
| 2cdedffcfa5594f9d516fa235d5edf4d4f92c21d |
|
03-Oct-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Accessibility services cannot obtain the source of an event coming from a root namespace descendant.
1. The user can touch the screen at an arbitrary location potentially crossing the root namespace
bounday which will send an accessibility event to accessibility services and they should be able
to obtain the event source. Also accessibility ids are guaranteed to be unique in the window.
Added a package scoped findViewByAccessibilityId method that dives into nested root namespaces.
2. Added accessibility support to the AnalogClock.
bug:5405934
Change-Id: I84edcb554bae41aafcbbc2723c5e62c1ef8a6ddf
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 82e236d72ac197d6673d0b4d484fe5f0b9436731 |
|
30-Sep-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
The logic for not populating text to some accessibility events is scattered.
1. Some accessibility evenents should not and were not dispatched for
text population but there was no centralized location for enforcing
this - rather the system was firing them in a specific way or there
were conditions in a few places enforcing that. Now this is centralized
and clean.
2. Updated the documentation with some new event types the were lacking.
3. Explicitly stated in the documentaition which events are dispatched to
the sub-tree of the source for text populatation.
bug:5394527
Change-Id: I86e383807d777019ac98b970c7d9d02a2f7afac6
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 4f59f8be0e177435a9a493668a74c793971b3bb5 |
|
16-Sep-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #5300880: setSystemUiVisibility() always triggers a surface reallocation
Change-Id: Ia0a9d8acba6b62ef095e4c615099466c52eec8e4
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| ea515aeafa01de6f50c854ee381b972ef2478284 |
|
15-Sep-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Update the public APIs for finding views by text to optionally use content description.
1. Added flags to the search method to specify whether to match text or
content description or both.
2. Added test case for the seach by content description.
3. Updated the code in AccessibilityManager service to reflect the latest
changes there so test automation service works - this is the fake
service used for UI automation.
Change-Id: I14a6779a920ff0430e78947ea5aaf876c2e66076
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 180c48489f07ebd748700a5a312070583fefdb45 |
|
13-Sep-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #5309443: Ninjump crashes on boot with...
...java.lang.IllegalArgumentException: Window type can not be
changed after the window is added
Change-Id: I4e34622c99d721fa214fd534a9bbfc8006184770
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| aacbf9111b58f10f7474fbd3a8debb02713f8b18 |
|
08-Sep-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Merge "Not visible view should not be announced or interacted with."
|
| 0b0a41d8e26eaf0f1d9d922621494daf40964a9a |
|
08-Sep-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Not visible view should not be announced or interacted with.
1. Some invisible views' text was reported by accessibility events.
2. Accessibility actions could have been perfromed on invisible views.
bug:5264355
Change-Id: I68184fb436a3e10e947ec6f1eae02aa3d0d1cb7f
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| d56c6951755a902a354e13e5fa05fb0984132cc6 |
|
07-Sep-2011 |
Chet Haase <chet@google.com> |
Add end functionality to LayoutTransition
This new hidden API is called by ViewRootImpl when there is a pending
transition but the parent window is not visible.
Change-Id: Idd6a0959b391fae542e675e8740b6a16f8963678
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 3791dc9b1c849bfacbff6de7fb53b77f414d1e4b |
|
07-Sep-2011 |
Chet Haase <chet@google.com> |
Merge "Fix issue with LayoutTransition on non-visible windows."
|
| 61158c621d0834d6d4e1e0310596d9b7a1071178 |
|
07-Sep-2011 |
Chet Haase <chet@google.com> |
Fix issue with LayoutTransition on non-visible windows.
There's a problem with how LayoutTransition cleans up after itself
when the target view is in a Window that is not on the screen.
The quick fix is to always start (and therefore properly end and clear)
transitions, regardless of whether the window is in the tree.
Change-Id: I23f4f4f04176f3943e5c6e1d78acba0190a96930
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| f21c9b0f52d5a1de5050f90f0818467fad014eaa |
|
07-Sep-2011 |
Romain Guy <romainguy@google.com> |
Don't destroy a window's buffers when moving it
Change-Id: Ib08608373ae4299639c1b157421ba633e4293446
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 6b0c11da5a7a7ea236fd9dc409d1ce7a33bff9c2 |
|
03-Sep-2011 |
Dianne Hackborn <hackbod@google.com> |
Merge "Fix issue #5150899: Call activity takes 15MB we never get back."
|
| 3c4ce72c4d66d9ee041924259f20381b658c1529 |
|
03-Sep-2011 |
Chet Haase <chet@google.com> |
Fix artifact with LayoutTransitions on disappearing window.
Logic in performTraversals() starts a transition running at the
proper time. But when a view's parent window goes away, this transition
may not start at that time because drawing gets canceled. But the
transition still hung off of the ViewRoot, waiting until some later
drawing operation to kick it off. This resulted in some weird animations
like the Recents panel appearing and having a single item animate off of it.
The fix is to delete pending transitions when drawing is skipped.
Change-Id: I3ab7702c16e069644a163424f977350743e2cecc
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 5d927c2d8e832fcfcb0154c8741f896001141ef4 |
|
02-Sep-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #5150899: Call activity takes 15MB we never get back.
Persistent process can no longer use hardware acclerated drawing
when running on a low-memory device.
Change-Id: I3110335617af1c98fcede9bf41f4a1d0c20d0e87
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 08a1c04b9668e51ca3043a4e531b7649b018b245 |
|
01-Sep-2011 |
Romain Guy <romainguy@google.com> |
Merge "Dispatch onDetachedFromWindow before destroying everything Bug #5245686"
|
| 16260e73f6c1c9dc94acf0d328a3c564426b8711 |
|
01-Sep-2011 |
Romain Guy <romainguy@google.com> |
Dispatch onDetachedFromWindow before destroying everything
Bug #5245686
Change-Id: I637178ee0bb47fbec9b59198b388bb8de22c1786
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| cc4f7db698f88b633a286d8ab1105b28a474cd09 |
|
31-Aug-2011 |
Jeff Brown <jeffbrown@google.com> |
Fix input channel leak.
Bug: 5156144
Input channels could leak or simply live longer than they should
in some cases.
1. Monitor channels (used by the pointer location overlay) are never
unregistered, so they would leak.
Added code to handle failures in the receive callback by closing
the input channel.
2. The DragState held onto its input window and application handles
even after the input channel was disposed.
Added code to null these handles out when they are no longer needed.
3. Input channels previously used as input event targets would stick
around until the targets were cleared (usually on the next
event).
Added code to detect when the input dispatcher is in
an idle state and to proactively clear the targets then
to ensure that resources are released promptly.
4. Native input window handles held onto the input channel even
after the input window was removed from the input dispatcher.
Consequently, the input channel would not be disposed until
the input window handle itself was freed. Since the input
window handle is held from managed code, this meant that the
window's input channel could stick around until the next GC.
Refactored the input window handle to separate the properties
(info) and identify (handle) state into different objects.
Then modified the dispatcher to release the properties (info)
when no longer needed, including the input channel.
7. The pointer location overlay does not actually use its
standard input channel, only the monitor input channel.
Added INPUT_FEATURE_NO_INPUT_CHANNEL to allow windows to
request that they not be provided with an input channel
at all.
Improved some of the error handling logic to emit the status
code as part of the exception message.
Change-Id: I01988d4391a70c6678c8b0e936ca051af680b1a5
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| eca9b1f53c2c291cbfb89b5f3cc45db7bdca6c7d |
|
26-Aug-2011 |
Romain Guy <romainguy@google.com> |
Prevent crash in VPN settings
Bug #5217245
Change-Id: Ibacf4cbd40537cd417f1518b5ac4367a3f3d7d03
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 12bde60b39affbfdcb7ef6317e0a5f99c3f41b10 |
|
25-Aug-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Merge "Intra-process view hierarchy interrogation does not work."
|
| 6ff0037792619c4441d9d3caa4f9ab4f45c11236 |
|
25-Aug-2011 |
Dianne Hackborn <hackbod@google.com> |
Merge "Fix to show the correct HW accel background in the preview window."
|
| 07213e6d8895af10951851435adf96a779863f6c |
|
25-Aug-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix to show the correct HW accel background in the preview window.
Also tweak wallpaper service to do a cleaner transition to a
static wallpaper.
Change-Id: I876a32091f92dd5a529d7fd809d3b8e730bb7d2a
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| fa6b35be126ffcc3b5818393c26aff724ac65daf |
|
25-Aug-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #5050039: Launcher is sometimes rendering underneath the system/status bar
It looks like this is caused by the change in HC to stop activities when
the screen is off. ViewRootImpl (a.k.a. ViewRoot) has special code to
avoid doing work when it is stopped, and it is now stopped when the screen
is off. The problem here is if the window's activity is stopped when the
window is first displayed, then it would never do the initial fitSystemWindows()
with the status bar offsets given by the window manager, and never do this
again until the status bar changes.
Also included here is some re-arranging of the code dealing with the offsets
changing, because it was dealt with in two places and only one had a bunch of
code dealing with HW accelerated drawing and performing the fade transition
between states. Now all of that is unified into one place.
Change-Id: I9828f02664cc622dbf186effb1f685a8aa4456a1
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 8bd69610aafc6995126965d1d23b771fe02a9084 |
|
23-Aug-2011 |
Svetoslav Ganov <svetoslavganov@google.com> |
Intra-process view hierarchy interrogation does not work.
The content retrieval APIs are synchronous from a client's
perspective but internally they are asynchronous. The client thread
calls into the system requesting an action and providing a callback
to receive the result after which it waits up to a timeout for that
result. The system enforces security and then delegates the request
to a given view hierarchy where a message is posted (from a binder
thread) describing what to be performed by the main UI thread the
result of which it delivered via the mentioned callback. However,
the blocked client thread and the main UI thread of the target view
hierarchy can be the same one, for example an accessibility service
and an activity run in the same process, thus they are executed on the
same main thread. In such a case the retrieval will fail since the UI
thread that has to process the message describing the work to be done
is blocked waiting for a result is has to compute! To avoid this scenario
when making a call the client also passes its process and thread ids so
the accessed view hierarchy can detect if the client making the request
is running in its main UI thread. In such a case the view hierarchy,
specifically the binder thread performing the IPC to it, does not post a
message to be run on the UI thread but passes it to the singleton
interaction client through which all interactions occur and the latter is
responsible to execute the message before starting to wait for the
asynchronous result delivered via the callback. In this case the expected
result is already received so no waiting is performed.
bug:5138933
Change-Id: I382e2d8689f5189110226613c2387f553df98bd3
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 50d133e290468fd149b5c03e46549afca2ee05f8 |
|
13-Aug-2011 |
Romain Guy <romainguy@google.com> |
<blink/> is not an acceptable default behavior.
Bug #5156334
Change-Id: I9f803b090e81f4e490d0cccd6347a0f9f64bd20f
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 70a3f677bf015d8641f41d149b76d362bb2b801c |
|
08-Aug-2011 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #5016544: IME keyboard hides folder rename text field.
Tweak some issues in TextView with the focus rect used to determing
where the scroll position needs to be. The ultimate problem was that
in various situations it would use the right-most selection position
cursor as the scroll location and when it adds 1 to make this a valid
rect we end up with a rectangle that is outside of the view.
Change-Id: Ia200c58e4e014d2a0a1be4761f9a1e5eb702a8e5
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| c3166e15f8898a2ba66fb177efbddb1d0edf6140 |
|
09-Aug-2011 |
Romain Guy <romainguy@google.com> |
Don't draw more than what we need.
Change-Id: Ifeac66d379a48e8a1124188125e029421eb24226
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 1d0c708961f824ac5171238c205a7bf328d5d8a5 |
|
04-Aug-2011 |
Romain Guy <romainguy@google.com> |
Destroy the EGL surface when the ViewRootImpl surface is invalid
Bug #5109839
Change-Id: Icebde9abf43b852397a73ffef519004993b46901
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| cf15efba0792b052dca5baa350d9fb00e6a60667 |
|
02-Aug-2011 |
Romain Guy <romainguy@google.com> |
Properly cancel pending buffers on window size change
Change-Id: Id6108ce61a971673f3ebc8270e9dd00849c91ae5
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| c68c913d357e2955d4bd7ca52829071e531c7825 |
|
29-Jul-2011 |
Dianne Hackborn <hackbod@google.com> |
Various work on out of memory managment.
- Improve how we handle processes that have shown UI, to take care
of more cases where we want to push them into the background LRU
list.
- New trim memory level for when an application that has done UI
is no longer visible to the user.
- Add APIs to get new trim memory callback.
- Add a host of new bind flags to tweak how the system will adjust
the OOM level of the target process.
Change-Id: I23ba354112f411a9f8773a67426b4dff85fa2439
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| ea83503e8683531fac2534047e50bc1e5979b6dd |
|
29-Jul-2011 |
Romain Guy <romainguy@google.com> |
Don't create hw layers when there's no hw context.
Bug #5093805
Change-Id: Ia58b3381c83b9a200e80020e5c1b9c337ad6c35c
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| b6f7a27c59fd170b5d7617e43e21bfd8587f234e |
|
28-Jul-2011 |
Romain Guy <romainguy@google.com> |
Merge "Reclaim more memory, more often."
|
| 65b345fa22b878e141b8fd8ece9c208df00fa40f |
|
28-Jul-2011 |
Romain Guy <romainguy@google.com> |
Reclaim more memory, more often.
Yay.
Change-Id: I04557ad575c307a55088549f48f0e9ad994b7275
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| c8ec222cd8e7d7056b0f01018ac0c38d2c7204c0 |
|
28-Jul-2011 |
Romain Guy <romainguy@google.com> |
Merge "Destroy layers and flush layers cache when a window is destroyed."
|
| 6d7475d666baefaa3ba9f0dcee25238739454241 |
|
28-Jul-2011 |
Romain Guy <romainguy@google.com> |
Destroy layers and flush layers cache when a window is destroyed.
Change-Id: I3fa1bc3ff50fb99e3d2e490925bd6b0a0f809fff
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 3d5a703db83265f7914eed8580de986106abfad2 |
|
28-Jul-2011 |
Jeff Brown <jeffbrown@google.com> |
Merge "Report the external display size to the input reader."
|
| 912a7b32d0c59ba38265c5dd6ff84ce93f909a7f |
|
27-Jul-2011 |
Romain Guy <romainguy@google.com> |
Make sure we have a current EGL context when invoking EGL
Bug #5081795
Change-Id: Iee3382d362a71c1e6c5c498b319bf7f7bcf5a2f0
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| bc68a59c024bdb745dac8e2ec7408a9f30595f1a |
|
25-Jul-2011 |
Jeff Brown <jeffbrown@google.com> |
Report the external display size to the input reader.
The input reader needs this information so that it knows how to
interpolate touches on an external touch screen.
Changed Display so that it asks the WindowManager what the real
display size is (as opposed to the raw display size). This means
it now takes into the forced display size set by
adb shell am display-size.
Replaced all calls to getRealWidth() / getRealHeight() /
getRealMetrics() in the WindowManager and replaced them with direct
usages of the mCurDisplayWidth / mCurDisplayHeight so that the WM
doesn't end up making a reentrant Binder call into itself.
Fixed the table status bar HeightReceiver so that it updates the
height on all configuration changes since it is possible that the
display size changed independently of an external HDMI display
being plugged / unplugged.
Improved the Display class documentation to make the distinctions
betweeen the various sizes clearer.
Change-Id: I3f75de559d3ebffed532ab46c4ae52c5e7f1da2b
/frameworks/base/core/java/android/view/ViewRootImpl.java
|
| 6dd005b48138708762bfade0081d031a2a4a3822 |
|
18-Jul-2011 |
Dianne Hackborn <hackbod@google.com> |
I. Can. Not. Stand. ViewAncestor.
It was done so we would have the name "ViewRoot" available for a
public API. However, the name "ViewAncestor" just makes no sense.
So instead, change it to ViewRootImpl.
Change-Id: If9599ca67896f339f6fefa7d1dde121201171d97
/frameworks/base/core/java/android/view/ViewRootImpl.java
|