Floating toolbar is now rendered as TYPE_APPLICATION_ABOVE_SUB_PANEL.
This causes the FloatingToolbar to be rendered in a layer above
the text selection handles (at layer TYPE_APPLICATION_SUB_PANEL.)
Bug: 20135562
Change-Id: I1484b3493bf4cd98c679eb222270c53daa46cdf4
This fixes several issues that were causing missing events in
enrollment and authentication.
Bug 20271180
Change-Id: Ic1c8ab35145de4d29d60238ef8ee71443a882348
Also removed some legacy bluetooth energy collection
that was never invoked.
Also fixed an issue with Wifi scan power estimation.
Bluetooth energy recording is still disabled as strange results
are still reported.
Change-Id: Iafa37eba285fd933ff221116b14af260e904fa4f
History now records when wifi data activity starts and "ends"
based on the triggers we get from the kernel used to determine
when to collect data. (Basically the same as the current cell
data, but of course when it ends is just an arbitrary x seconds
after the last data traffic.)
Re-arranged the state bits to make room for this data in the
right place and move some other things that make more sense to
have in states2.
Try to improve overflow handling, so when it happens we allow
the various bit states to drop to 0 instead of being stuck
active for an indeterminant amount of time.
Added recording of the points where we decide we want to
retrieve new power stats, giving the reason for doing so.
These are only recorded when full logging is turned on.
Change-Id: Ic5d216960a07e0eb658731cdfba7f49ad3acf67e
This change allows clients to add temporary (transient) views to a
list of such views in any layout container. These views will be drawn at
the specified index when the container is being rendered, but will otherwise
not participate in the normal events of child views, such as focus,
input, and accessibility. The purpose of this functionality is to
enable better animations when views have been removed, such that clients
can add them back into containers temporarily while an animation runs,
then remove them when the animation finishes. This functionality is similar,
albeit a subset, of the what ViewGroupOverlay provides, but this API
allows clients to interleave these views with the other children in
the container, which allows correct drawing order. ViewGroupOverlay,
and the older internal mechanism used by the old animation package,
draw all of their views after a container is drawn, which pops
these temporary views on top of the other children in the container.
Issue #18621099 Enable View overlay to respect elevation and shadows
Change-Id: I530df69b406aa27b9f551f5724384f4dd1215a6f
These shouldn't be needed because the video call APIs were never
previously made public.
Bug: 20160491
Change-Id: Ic9c5d0d1e8618bfe61f8905d4afaeaa37f51c915