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
Updated with annotation LargeTest
Copyright changed to 2011
Review reworked and with new test contents
Video Editor CTS Test code
Change-Id: Ia37956ef39fafcc5d969996c1791fce8663aa0fe
Applications that create an icon for launcher to use couldn't determine
which size or density the icon should be created.
Bug: 3224340
Change-Id: Iee96113a4092696a9bd18eecbd2593b38f952a16
When invoking a registered shortcut for which the activity was not
found, the startActivity throws ActivityNotFoundException. If this
exception is not caught and handled, then the shortcut key is
dispatched to the application instead of being suppressed as it
should have been.
Found while fixing Bug: 3396233
Change-Id: I0e8e9e3ba09dd403a901d5eae12839734be467ed
