| 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
|
| 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
|
| 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
|
| 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
|