When the display state is DOZE or DOZE_SUSPEND, assume this means
that the AP may go to sleep at any time so hold a wake lock for
a little while starting when traversals are scheduled to ensure
that the AP remains awake long enough to draw and post the frame
to the display hardware.
This patch is somewhat approximate but should be good enough for
most devices today.
Note that the implementation uses the window manager to ensure that
the window which wants to draw is actually visible before acquiring
the wake lock. There is a cost to this test (a round-trip) which
should not be significant today since we do not expect apps to draw
more than one frame or two while dozing. However, if we wanted to
support animations in general, we might want to optimize it or
eliminate the check altogether (since we can already account for
the app's use of the wake lock).
Another way to implement this functionality might be for the view
hierarchy to listen for the power manager to report that it has entered
a non-interactive power state before deciding to poke draw locks.
This would be somewhat more accurate than watching the display state.
Also, the draw lock timeout logic could be implemented more directly
instead of using an ordinary timed wake lock.
Bug: 18284212
Change-Id: I84b341c678303e8b7481bd1620e634fe82cc4350
This change refactors ScreenMagnifier to use resources for its triple-tap
adjustment and scale threshold values. New values more appropriate for
wearable form factors are supplied. This also fixes a bug in the triple-
tap detection logic where the incorrect ViewConfiguration value for the
tap threshold was used, prematurely disqualifying some touch events as
potential taps.
Change-Id: If47e556aadb5beb1bad24644122560c6fbe33bad
The magnification viewport expects its boundary to be a rectangular region,
and always draws it as such. This change causes the indicator to draw as a
circle on devices with circular displays. This also refactors the width of
the indicator's frame to use a proper dimension resource and updates the
width to 4dip.
Bug:18242438
Change-Id: I1d86647b6d1ef84f5dd506f4141223ec050a79b5
Mostly copy/paste of the Holo with some padding fiddling to make the
EditText, which has baked-in padding, and TextView line up.
Bug: 19280124
Change-Id: I4a8ad7dcc1f1bd519f4d1c506984871a25a1db31
There is a bug in <scale>, but this works around it for now. Removes
the previous fix, which broke the initial state due to the level not
propagating when the current drawable was swapped out.
Bug: 19269656
Change-Id: Ibe586ef4ea326a7ce7516ca42a369c5386c24359
Reverts to Holo-style layout where the View divider masks the bug.
Uses a 0-height divider to avoid visual changes.
Bug: 19201079
Change-Id: Ib9e701815c57b23d5ba7173f8de553e90e27ed11
All supported locales use only U+2025 and U+2026 to represent
ellipses, and it will unlikely change in future. Given translated
resources are inconsistent and often use three dots it is safer
to use constants instead of resources.
(cherry-pick of ed0daa93e48d38e54a7ad1c99c461510a4c07599.)
Bug: 18542179
Change-Id: I51a6cb903f62f739fbadd6b78e5765c0028d641a
- Added a config entry in velues-television to disable the options panel
feature for TVs.
- Fixed parts of the code in PhoneWindow that assumed this feature is supposed
to always be available, which was causing exceptions when it was turned off.
Bug: 18780696
Change-Id: I923bd4b5019d634e5352a6e893005133edb475f6
In cases where networks are not properly configured, WiFi might tries to repeatdly switch from one network to a bad network, or might try to roam and renew DHCP which can fail. In KK, WiFi autojoin would try other networks (by cycling to network it sees) and end up associated to a "good" network. In L release even thought WiFi might pick a good network it will still repeatedly try to switch to what it thinks is a better network and fail, thus annoying the user whose connection becomes unstable. This CL tries to remember networks that have seen multiple DHCP or auth failure in the past and for those networks it disable roaming temporarily. That is, if wifi is not associated to any network, it will tries to join a network aggressively, however if wifi is currently associated to a network, it will not try to switch to a new network if that new network has seen multiple failure in the past. The maximum blacklist time is set to 2 days for now.
An example of such situation is:
- user has multiple SSID at home, one of which is incorrectly configured with a wrong password
- broken DHCP situation (potentially: multiple servers on home network, broken implementation incorrecting NAK'ing DHCP requests but properly serving DHCP offer...)
Bug:18792931
Change-Id: I332a9cebdc19be2e00b455205d386fcffcb70b29
+ Remove entries from config_tether_apndata when primary carrier requires
DUN apn and the mvno does not.
Bug: 19006861
Change-Id: Idf93fe2302662ce2b25e72277080bbc9d410b2de
The version of the warning with a named installer should be shown in
the case of a managed profile, not only a managed device.
Bug: 18224038
Change-Id: I27865f77e963b9b15416f2e4a4ffc38fed8f5532
This reverts commit e1d8dcd9e170c1ed8a13b6e1256ea1fb22c26c49.
Something funny happened in the process of submitting this,
swathes of strings.xml became mis-encoded.
Bug: 18224038
Change-Id: I0276ff3f880fe749546e8cc7e3e2f41c22c27705
