- add generic icon for search providers that don't supply one
- change alpha weighting factor for glow
- don't show ring background
Change-Id: I86c86dc2d623c25ec7b91e206fac8ad9cd60faac
...in Developer options is on
Don't respect stay awake while on as long as a time to lock limit
is being enforced. When we start enforcing one, make sure the
setting is off (since we won't be respecting it anyway).
Bug: 6664140
Change-Id: Id07cb528afa0c64c7766341841c51771f507121d
Bug 6598784
The algorithm uses three imbricated loops:
- paragraphs
- span regions (called "blocks" in that description) in these
- characters in these
We can ignore the paragraphs and assume paraStart==0.
The span region loop cuts the text into blocks of text which share
the same set of MetricAffectingSpan spans applied to them. Note that
spanStart and spanEnd represent such a range, and not necessarily an
actual span range.
The third loop then iterates over the characters of these blocks, and creates
a new line (calling out() as soon as the width has been reached.
The core of the problem comes from the 'nextSpanStart' variable.
It is used to restart the block loop from a previous position in case
a line has been created that does not intersect with the current block.
However, in case the current block is larger than the width of the text,
the character loop is going to create other lines of text before we exit the
j-loop. Going back to the block loop, we reset spanStart to the nextSpanStart,
which may be too far back in the text. As a result, the same range of characters
is measured again.
The (spanStart == spanEnd) test was used to handle the case where
nextSpanStart was indeed assigned to a value different than spanEnd.
This fix simplifies this logic and removes the nextSpanStart variable:
When the created line ends before the current block (here < spanStart), we
immediately exit the character loop, re-starting the block loop from the
current position.
Patch 4: added a fix in measured to handle overlapping character ranges.
Change-Id: Ie71b3cf4018b332e335ea916fef08acb43a6679e
Weren't cleaning out any ActivityOptions that are still attached
to a finishing activity.
Bug: 6636731
Change-Id: If0520bbcbf1d4ce19d46ff769918893cefda9c87
The AudioService now has an API to call to get the currently
connected devices, and later reports of changes in connection
state. The information includes the name of the bluetooth
device if one is connected for display to the user, and states
for all of the pluggable devices. No longer requires a Bluetooth
permission to keep the routes updated.
Change-Id: I81ca421c60592fbc1592477d59bf1c9d1b64954a
Weren't cleaning out any ActivityOptions that are still attached
to a finishing activity.
Bug: 6636731
Change-Id: If0520bbcbf1d4ce19d46ff769918893cefda9c87
Come back to old versions of setBluetoothA2dpOn() and isBluetoothA2dpOn().
MediaRouter will call methods on IAudioService directly.
Change-Id: I18f0a3106bad78715ed11a6b7b4ec1d656cdae41
When video start in inline mode, and then transition into full screen mode, the
video is still playing, so we need to notify the player, such that the controller
can get the state correctly.
bug:6675847
Change-Id: Ib5f712ca91fe1c374dcc20de996dac6ff7b9e983
1. Currently we are providing accessibility focus search algorithm in the
framework and we are also setting accessibility focus from hover. It
appears that implementing a focus search strategy that works for all
accessibility services is non trivial task if feasible. Based on
feedback from the developers of two such services at Google - TalkBack
and BarilleBack - the built in focus search does not quite match what
they need and they would like to implement a custom strategy.
Hence, having APIs for accessibility focus search in the framework does
not make. Therefore, we are hiding this APIs and later will take out the focus
search logic and allow the accessibility service to implement search.
Also putting accessibility focus from hover is tightly integrated with
the focus search since the set of views that get accessibility focus
from hover should be the same as the set of views returned by the
focus search routine. Therefore, we are letting the accessibility service
decide where to put accessibility focus when it gets an accessibility
hover event.
bug:6675330
Change-Id: Ie152230990a6602f3fd1d82de2177d0b1444d654
We now track whether the device is connected at all, and use
this to suppress the disconnected message in the mobile
status string (we previously just looked at wifi
connectivity).
So, if a device is attached via ethernet:
- On wifi-only devices, the combined label is shown in the
notification panel, so you'll see "ETHERNET" (this comes
straight from EthernetDataTracker; at some point we need
localized strings and icons).
- On mobile-data devices (phones), the notification panel
only shows the mobile data label, which will be
suppressed, so you'll see nothing at all.
Bug: 6648292
Change-Id: I9841eaeffe50a4f046afbdc09d80c5bd4d78a839
This reverts commit 858491ba13ab5d45a5ec462d002b5856703b1b2b
It turns out that Surface Flinger is supposed to generate fake vsyncs while the screen is off, but sometimes it wasn't working due to a bug. That bug has now been fixed by the following change: I7c6abc23bb021d1dfc94f101bd3ce18e3a81a73e
This fixes a bug where the user uses the MMI sequence (**05*PUK*PIN1*PIN1#)
from the EmergencyDialer to unlock their phone instead of the provided interface.
The code now recognizes when UnlockMode becomes invalid because it was previously
locked because of SIM state. It then dismisses the PUK unlock screen and advances
to the home screen.
Change-Id: I8902350e6f640cd2fa0af3460c3ea1a39d926c8a
Prior change 199020 fixes it for instances of CarrierLabel;
this fixes it for customers of NetworkController.
Bug: 6639047
Change-Id: I69dada2298f4a3caf453f43d847cdb32fe7eaa9f
When the screen is off, we might not receive real vsync pulses from
the hardware which would cause posted Choreographer callbacks to not run.
This is bad because messages in the Looper might be blocked behind a barrier
that is scheduled to be removed by one of those Choreographer callback
(see ViewRootImpl.doTraversals). Until the barrier is removed, those messages
will not run. To prevent starvation of the Looper, we synthesize fake vsync
pulses at a reduced rate whenever the display hardware stops generating them.
This change should fix a variety of rare non-deterministic bugs where
the system might appear to be unresponsive while the screen is off,
and spurious ANRs reported shortly after the screen is turned back on.
Bug: 6574842
Bug: 6636995
Bug: 6643559
Change-Id: I263f2fdf979afd79e5ac47a0cc5d34a93b860c21
