This is an initial API that will allow the plugin to request to
keep the screen on.
companion change is in external/webkit
bug: 3331493
Change-Id: Ic18787e7ecd705a5b2e31a34ea884fd39ad9d11a
Bug 3381317
Also generalized and uniformized the use of peekInstance. Added null
tests, and isActive tests before hiding.
Change-Id: Ifd1a053fd920841333e0ebab3e2a8d26b469a0f6
There was logic in ViewGroup that assumed that an accelerated
view must always be able to get a display list for any child
that it was drawing. One situation occurred, however, that
caused a problem with this - a contacts activity was started
and not yet attached, but was being asked to render into an
accelerated canvas. We assumed that the child would have a display
list and simply called getDisplayList(). But since that call
returned null, we later deref'd the null object.
The fix is to check whether a child can have a display list
instead of assuming that it can just because the container view
is accelerated.
Change-Id: I7de62fd597ad50720c9585d621bec02e77c171df
Bug 3266751
The boot time is 43 compared to 44 seconds, which is within the precision of the measure.
Starting 15 activities in a sequence takes 20-24 seconds with the old version and 17-18
seconds with the new pre-load (12/13 when ran a second time, all apps being loaded).
The standard deviation is high, but it seems consistently better.
Change-Id: Ieac3cb93be03e8186979b894adda29f0549b9734
Display lists could not handle custom views that did their
own draw dispatching, as is the case with gmail. This fix makes that
possible and display lists handle this case robustly. Now the
crossfade works because the display lists contain the right content.
Change-Id: Iea7d6e99239b24f833701d546fe083aa00e2b31b
while selectiong the last day of the week.
The NumberPicker widget was getting into an inconsitent state when
reaching the end of the range (non wrapping selector wheel) and
the user touches the location of the hidden increment/decrement
button.
Change-Id: Id54103295dd2574030e2c29996061faa659a5bb7
Various property setters in View need to invalidate the parent's
cache to get redrawn properly when accelerated with display lists.
Also, fix logic around display lists and old-style Animations in
ViewGroup.
Change-Id: I70e1c2fa49e62228ee4a1301a006ce50bda4c305
This fixes a bug in StatusView believed to be caused by
seeing "invalid charger" update from BatteryService.
The code normally relies on "interesting events", as determined
by KeyguardUpdateMonitor. I believe something else is
triggering an update (perhaps a SimStateChanged event) that updates
the status without also updating StatusView.mShowingBatteryInfo
and mPluggedIn.
The safer way to do this is to explicitly check the battery
level before telling the user the device needs to be charged.
Change-Id: Ic39ed86c78a157dc9fbdef4d76a9c3db39ccafca
