when areas of the FB are undefined (transparent windows on top of
nothing), we clear those areas before composition.
however, it makes no sense to do this when the FB is not in use
(case where hwc handles all layers)
Bug: 5360529
Change-Id: If51bb669307e8419bbe1f3a89d1c88e0ec1f216c
Theme.Holo.Light.DarkActionBar gets black text
Make sure that menus generated for use in action bars get themed correctly.
Change-Id: I14ba676d296c785514425d40d89e62dc4ff1da1a
If the default target button is hidden all activities are shown in the list from
which to choose. In this case due to off by one error the list was not showing the
option to expand it if the activities are one more than the initially shown.
bug:5358475
Change-Id: I8c3db37dab008637d78330f8de830cec92720264
Be more explicit about initialization -- power manager never sends
screen update when first initializing, phone window manager retreives
current screen state and applies that itself when initializing.
Change-Id: I8294ed36d700e186c1637754df8c8183721c15dd
The original change said that if the RAT were X or Y we would only
accept APN's that explicitly called out X or Y. This meant that
any device using X or Y would stop working until their APN db were
adjusted.
This change changes it to be if a particular APN calls out X or Y
it will only be considered if the current RAT matches. If the APN
doesn't specify, it matches all RAT.
This allows just as tight a restriction, but the default is looser.
Change-Id: Ia5e92f13c5052e890bf169e0db9584302afb36f5
Bug: 4981385
Simplify the orientation changing code path in the
WindowManager. Instead of the policy calling setRotation()
when the sensor determined orientation changes, it calls
updateRotation(), which figures everything out. For the most
part, the rotation actually passed to setRotation() was
more or less ignored and just added confusion, particularly
when handling deferred orientation changes.
Ensure that 180 degree rotations are disallowed even when
the application specifies SCREEN_ORIENTATION_SENSOR_*.
These rotations are only enabled when docked upside-down for
some reason or when the application specifies
SCREEN_ORIENTATION_FULL_SENSOR.
Ensure that special modes like HDMI connected, lid switch,
dock and rotation lock all cause the sensor to be ignored
even when the application asks for sensor-based orientation
changes. The sensor is not relevant in these modes because
some external factor (or the user) is determining the
preferred rotation.
Currently, applications can still override the preferred
rotation even when there are special modes in play that
might say otherwise. We could tweak this so that some
special modes trump application choices completely
(resulting in a letter-boxed application, perhaps).
I tested this sort of tweak (not included in the patch)
and it seems to work fine, including transitions between
applications with varying orientation.
Delete dead code related to animFlags.
Handle pausing/resuming orientation changes more precisely.
Ensure that a deferred orientation change is performed when
a drag completes, even if endDragLw() is not called because the
drag was aborted before the drop happened. We pause
the orientation change in register() and resume in unregister()
because those methods appear to always be called as needed.
Change-Id: If0a31de3d057251e581fdee64819f2b19e676e9a
