An odd little bit of logic (attempting to defend against
the status bar getting stuck on orientation change) was
ironically causing it to get stuck if the bar was closed
twice in very rapid succession (which can happen if you
manage to click the settings button as the panel is about to
close).
Other tweaks to help defend against this sort of problem in
the future:
- When the screen goes off, immediately collapse the
notification panel (without animation)
- When completing panel collapse, force the height of the
expanded view to 0 (in case it ended up some other way by
this point).
- Reduce a weird little glitch when you start
animateCollapse() in the middle of a reveal animation.
(The panel would jump to full height.)
Bug: 6765842
Change-Id: I233467c73e130f64401333319943289cbf3daa56
Bug #6836448
External bug: http://code.google.com/p/android/issues/detail?id=34946
DO NOT MERGE
DisplayListRenderer::drawPath was not invoking quickReject() properly,
passing x,y,width,height instead of left,top,right,bottom. A path
could thus get rejected when it should be drawn instead.
While working on this change I found a similar issue with another
drawing command, drawBitmapData().
Change-Id: I8306faf72db14d71b54ecb7de295c9a6957d9494
Between ICS and JB we changed it to use TelephonyManager's network type
enumeration. This changes it back to represent the RIL's radio
technology. The only diff between the two is 13 and 14 are swapped,
so the change was causing problems with LTE and eHRPD.
bug:6830908
Change-Id: I85a7c8037f370f368e5cbf6dc2c9395c6889b541
DO NOT MERGE
External bug: http://code.google.com/p/android/issues/detail?id=34879
This is a regression from ICS.
This CL also fixes a bug where a View's alpha would be applied twice.
Change-Id: I13a1546228f44d4c169259414b6fa103a6e4a0fa
The system gives priority to physically connected
headphones/speakers/docks/etc. Reflect this in MediaRouter and
associated UI.
Bug 6777592
Change-Id: Ibabf3d7512207117e892c99f004443490c3d0612
An optimization prunes invalidates on views which are not inside their
parent's bounds. This works in most cases, but it is possible to run
a situation where a view has been invalidated (and is thus waiting to
be redrawn), but the pruning logic ensures that that draw call
will not happen. Further, when/if the view comes into the bounds
of its parent again, it may still not be redrawn, because now future
invalidates on the view are noop'd because it is already in an invalidated
state (and thus will not propagate invalidates up the hierarchy).
The fix is to remove the optitmization. This will cause some overhead
sending the invalidation request up to the view root, but this
overhead is minimal (and only extra for cases of out-of-bounds views),
and the more expensive part of rendering these views will still not be done
since the view root will avoid re-drawing the hierarchy when the dirty
rectangle is empty.
Issue #6813661 offscreen views don't get invalidated properly (may remain invisible when returning onscreen)
Change-Id: Ic4b439540084a7163be9afc585bea6560d073280
Previous to this change the forceHiding variable was a boolean. This
change recognizes the different configurations of the keyguard by
defining separate states for forceHiding and testing for window
visibility differently in each state.
Fixes bug 6786114.
Change-Id: I3460c45ea6da772a4ff76bb016de7aa4b051a673
