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
When launching an assist, we have a new API allowing the
current foreground activity/application to provide additional
arbitrary contextual information that is stuffed in the
assist intent before it is launched.
Change-Id: I0b2a6f5a266dc42cc0175327fa76774f814af3b4
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
This CL adds support for invoking any view method with
primtive arguments, and setting layout parameters from
the debugger (hierarchy viewer).
requestLayout() and invalidate() are now just implemented
using the more generic invokeMethod() command.
Change-Id: Icffda251728a4963b35266786b0b6143bae7fe8e
bug:8037003
Changes the DisplayList from using stream read/write commands to use an array of
objects manually allocated on a linear buffer.
Depends on frameworks/native change https://googleplex-android-review.googlesource.com/#/c/257695/ which adds LinearAllocator
Also changes drawRects to use float count instead of rect count, to be more like drawLines/drawPoints
Change-Id: Ia2e4a11acd8f0a757042a05cbc9e7563cb73ee47
Simulated trackball should not generate KeyEvent if dispatchGenericMotionEvent
returns true
b/8022205
Change-Id: I1857e25407c508c98ef4db85fe146b1e25a0803e
Bug #7146141
When non-rectangular clipping occurs in a layer the render buffer
used as the stencil buffer is not cached. If this happens on a
View's hardware layer the render buffer will live for as long
as the layer is bound to the view. When a stencil buffer is
required because of a call to Canvas.saveLayer() it will be allocated
on every frame. A future change will address this problem.
If "show GPU overdraw" is enabled, non-rectangular clips are not
supported anymore and we fall back to rectangular clips instead.
This is a limitation imposed by OpenGL ES that cannot be worked
around at this time.
This change also improves the Matrix4 implementation to easily
detect when a rect remains a rect after transform.
Change-Id: I0e69fb901792d38bc0c4ca1bf9fdb02d7db415b9
Hierarchy Viewer currently interfaces to the host via a socket
opened by ViewServer which resides in the WindowManagerService.
Since this has access to all windows, it is enabled only on
debug builds.
This CL adds necessary support to DDM to handle all the commands
required for Hierarchy Viewer. It only misses two commands that
are sent to the Window Manager (which we don't have access to
from the applications).
A future CL will remove the ViewServer functionality.
Change-Id: I1dae316a00737b0cae4e640ccc97bf9bb1d05973
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
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
Region clipping, using Canvas.clipPath or Canvas.clipRegion, requires
a stencil buffer to be always present. In addition, extra wiring is
required in JNI and display lists.
This change only adds the necessary JNI/C++ APIs and some extra
plumbing to start the real work on properly supporting region
clipping.
A new debug define called DEBUG_CLIP_REGIONS can be used to draw
the current clip region. It is off by default, as is region
clipping.
The default implementation of clipPath() and clipRegion(), now
in native, mimics the previous Dalvik implementation to prevent
regressions.
Change-Id: I7903e7cfd7412b9b9b622566d4dbfce7bdcec00c
- add mirrored version of the icons
- make VolumePanel respond to layout direction changes
- make AudioService propagate layout direction changes to the VolumePanel
Change-Id: Ibb884ab81641c319a9b7bea1381066f3f19581f0
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
This change merges debug.hwui.profiling and profiling_visualize.
Now only the first property exists and accepts the values true, false
and visual. This enables setting the property from Settings.
Change-Id: I16a11fe23ac1a6bb907a1a826e418d6b3994b56c
When profiling is enabled with debug.hwui.profile set to true,
setting debug.hwui.profile_visualizer to true will display the
profiling data directly on screen.
Change-Id: I3d5fe3f0347090815087b1cbfce66b8e76d9347b
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
