The difference is not obvious when compared to no hinting, and turning
off hinting has undesirable side effects because of the lack of sub-
pixel positioning when rendering text.
Change-Id: If2162ba079f68f33b33aed444e80036fdbf015bb
A core app is one that has coreApp="true" in its manifest tag.
The system can successfully boot (though a little painfully) with
only framework-res.apk, SettingsProvider.apk, SystemUI.apk,
DefaultContainerService.apk, and Launcher2.apk set as core apps.
Currently this boot mode is always turned off.
Change-Id: Ieaa4a8031c2c391a12996aa8d8b1d65fc2b09d6b
b/5278759 API changes to pass package, options
b/5249018 consistent/customized add account UI
b/5270079 tag who adds the account
Change-Id: I1ee211d751b565c725c89aa1a429ef2f5bebe34a
For wifi, track ECM and shut down and restart when device
goes in ECM and out
For p2p, simply turn off when in ECM mode
Bug: 5185246
Change-Id: I5f5bf75fac3e27db1d7c412135c796f2b137263d
Back is hidden by DISABLE_BACK; Home, Recents, and Menu are
hidden by DISABLE_NAVIGATION.
Bug: 5261576
Bug: 5284740 (confusion about visible inactive icons)
Change-Id: I410c133b737cc11d61bac0318dc24458353ee7b3
FW was checking "Radio Available" instead of "Radio On" when
broadcasting data availability. This was causing an issue in
a certain recovery case (system server restart/phone process
restart) where "Radio (modem) is available" but radio was
turned off.
This patch obsolete the use of mRadioAvailable attribute and
use RadioState from RIL directly to check if Radio is ON.
Bug:5077346
Change-Id: Ie7ac05e3d5e328e3d5303541ca41326754f309c1
(This only works if the keyguard is not secure, but then
again, the user can't access the notification panel in that
case anyway.)
Bug: 5173952
Change-Id: I8a6081d26c52843822b381d8ebe0fae94a03bef9
Also fixes the right margin for single pane preferences on phones, so the
scrollbar is fully visible.
Bug: 5262868
Bug: 5263470
Change-Id: Ifbbe22744bd42ab33578d1f01daecdea4d59f5cc
The DIRTY flag is used to track which elements of the view hierarchy need
to be redrawn on the next drawing operation. This flag is set on the parent
hierarchy of a view when that view is invalidated. There is an optimization for
opaque views that tells the parent that it is dirty, but that it need not
redraw its own content because the view will cover it (since it is opaque).
This dirty-opaque logic breaks down in the current code because we only set
these dirty flags on the parent hierarchy, not on the view itself. In the situation
raised by this bug, we would invalidate the parent container directly (which does
not case the dirty flag to be set), then we would invalidate a child of that view.
Because the child is opaque, the DIRTY_OPAQUE flag would be set on the parent
container. This would cause us, in the later rendering process, to skip the
drawing on that parent container, assuming that it was only asked to be redrawn
because of its opaque child's invalidation.
The fix is to now set the DIRTY flag on an invalidated view, not just on its parent
hierarchy. The DIRTY_OPAQUE logic will avoid setting the opaque flag on views/parents
that are already marked DIRTY, thus an invalidated parent will be correctly drawn
during the drawing process.
Change-Id: Ib5e014a125a4f5168f6a5a3166e941474659aca5
