* changes:
Expose the window flags for lights out mode.
Make TabletStatusBar call into StatusBarManagerService when it goes out of lights out mode on its own.
Make FLAG_FULLSCREEN not go into lights out mode anymore.
I hadn't wanted to do this, but it makes porting the FLAG_FULLSCREEN
stuff over to this simpler because you don't have to go find a view
to proxy through.
This change also clears the flag everywhere when the window manager
notifies the views that the change has come back.
Change-Id: I48392c7550925bcca50c5bb9e1f263e99de6c7bc
It was previously the case that a view marked ~DRAWN must be
invalidated correctly already, so we would not mark any flags.
Display lists added new logic such that an undrawn node must still
be checked to see if its cache has been marked invalid. If not,
we must mark it invalid to make sure that a future rendering call
will cause the view to refresh its display list, thus refreshing its
child node tree's display lists, since that's where the invalidate
call must have originated.
Change-Id: I0f73c85459174c0e3f16d703f7eb914a706c808a
The SurfaceHolder provided by the wallpaper service was not reporting
the correct size in getSurfaceFrame(). This broke an optimization in
the ImageWallpaper. The old code happened to work because calling
lockCanvas on the SurfaceHolder with a null dirty rectangle happened
to have the side-effect of updating the SurfaceHolder's surface frame
size field because it passed mSurfaceFrame as the dirty rect, causing
mSurfaceFrame to be set to the size of the region to be drawn.
However, relying on this side-effect is wrong. Among other things,
the dirty region could actually be smaller than the surface frame.
This patch fixes WallpaperService, SurfaceView and ViewRoot to ensure
that the surface frame size is always set explicitly and is not modified
by calls to lockCanvas.
Change-Id: I10948f5ec269409ceaf0f7d32b3f6731e9499ebc
Bug #3385247
- The layer's alpha was interpreted in the wrong range 0..255 instead of 0..1
- 9-patches would not correctly dirty the layer region, the generated mesh
was incorrect
Change-Id: I4916249bedcdb0794929f3796bd17854971efc88
requestLayout() and forceLayout() should force the INVALIDATED
flag to be set, which causes a view's display list to be regenerated
on the next drawing operation. This is necessary when containers change
due to layout requests.
Change-Id: I5b18b5936b59f0605f93c8f45baf83a76dab4e5e
The objective in this listener is to be more careful about the
signal processing to prevent spurious orientation changes
and to make all of the tweakable factors physically meaningful.
The calibration is defined in terms of time constants and
does not assume a particular discrete sampling rate. This is
useful because it allows us to change the accelerometer sampling
interval if desired without having to change the calibration.
Moreover, the accelerometer sampling interval can vary +/- 20ms
from one sample to the next even in normal circumstances.
Proposed orientation changes are weighted by confidence factors
that vary exponentially in relation to how close the device
is to the ideal orientation change posture (screen is vertical,
angle is exactly at the midpoint of the orientation quadrant,
and no external acceleration beside gravity). When not in an ideal
posture, the device takes proportionally longer to settle into a
new orientation state.
Added a little tool to plot the log output of the
WindowOrientationListener. Check the README for more information
about how to use it.
Change-Id: I787f02d03582ff26367df65eda8d9ce85c5cb343
Bug 3381317
Changes made in https://android-git.corp.google.com/g/#change,91880
displayed the IME onFocus. However, the test was not consistent to what
is done in touch event. textIsEditable is now checked too.
Change-Id: If11382c1c90a557839b87d62494253470c42b621
1. Remove mDeferMultiTouch in WebView, it was for testing only but
we don't need it now since we always pass MultiTouch to WebKit.
2. Remove the use of mDeferMultiTouch in DRT tests.
3. Correct the index of getX(Y) for the second touch point in the
debug string of MotionEvent.
Change-Id: Ib63cfc5935af1a169ed26b2b138f74908492bc18
Previously, display lists were used only if hardware acceleration
was enabled for an application (hardwareAccelerated=true) *and* if
setDrawingCacheEnabled(true) was called. This change makes the framework
use display lists for all views in an application if hardware acceleration
is enabled.
In addition, display list renderering has been optimized so that
any view's recreation of its own display list (which is necessary whenever
the visuals of that view change) will not cause any other display list
in its parent hierarchy to change. Instead, when there are any visual
changes in the hierarchy, only those views which need to have new
display list content will recreate their display lists.
This optimization works by caching display list references in each
parent display list (so the container of some child will refer to its
child's display list by a reference to the child's display list). Then when
a view needs to recreate its display list, it will do so inside the same
display list object. This will cause the content to get refreshed, but not
the reference to that content. Then when the view hierarchy is redrawn,
it will automatically pick up the new content from the old reference.
This optimization will not necessarily improve performance when applications
need to update the entire view hierarchy or redraw the entire screen, but it does
show significant improvements when redrawing only a portion of the screen,
especially when the regions that are not refreshed are complex and time-
consuming to redraw.
Change-Id: I68d21cac6a224a05703070ec85253220cb001eb4
1. Views may setSystemUiVisibility() to recommend that
the system chrome (status bar or other UI) show or hide
itself. (This functionality was previously available only
via the FLAG_FULLSCREEN window flag for some SystemUI
implementations.)
2. Views may register a OnSystemUiVisibilityChangedListener
on a view, and find out when the system UI actually
appears or disappears, allowing apps to coordinate the
appearance of their own UI if desired.
Bug: 3241144
Change-Id: Ia1758d94099182d49a1e3688ea2738ae4995b829
The activity manager was not performing the layout pass on the new window,
because its app token was still hidden, because the activity manager / window
manager were still waiting for it to be ready to show.
Just ignore whether the app token is hidden for this case.
Also fixes some problems with animations, and tweaks the ViewConfiguration
values for xlarge screens.
Change-Id: Icbe9c77ba8127d1e02df2d6f27b8e86ec842e50a
On touch up, View would move itself to the pressed state if it
hadn't already shown as pressed. However, it did this *after*
scheduling the message to deliver the onClick(). Thus if the
app took a little too long to execute inside of onClick(), the
invalidate to draw the highlight state would be executed right
before the following message to remove the highlight state,
causing it to basically not be shown.
This change just does the invalidate before scheduling the
onClick, so we can be sure it gets done first.
Change-Id: I6a4d1742a3aab60969c38b44bb3e163f48de62d4
Fixes bug 3362502
The underlying cause was that the DragEvent.obtain() variant which
clones an existing event was failing to copy the local state field.
This change also moves the logic for inserting the local state object
into DragEvents about to be dispatched from the Binder incall thread
into the main-thread code sequence. This is to eliminate any potential
SMP memory coherency issues around drag start vs incoming events
needing to refer to the local state object.
Change-Id: I368e8936dbf8a00b7d5cc19c2ef0101bd75b6b2d
