In particular, even though the mobile data network isn't
routing packets (and therefore is not an internet
connection), we want to show the PLMN anyway:
[MOBILE RSSI] Carrier [WIFI RSSI] WiFi SSID
This change also improves the following cases:
- Combines "No internet connection" from wifi and mobile
into one single string in airplane mode:
[AIRPLANE] No internet connection.
- Removes "No internet connection" from the mobile string
when wifi is on in airplane mode, making a nice compact
display in this case:
[AIRPLANE] [WIFI RSSI] WiFi SSID
Bug: 5903914
Change-Id: I477821d2c5e9922252dd6bcb3ed494c8c57d99b0
This is between the two previous attempts. I returned the part from the
original that was breaking gallery, but have some new code to detect when
something about the window params has changed that would require a
layout pass to make sure we still do a layout then, even if the window is
not currently visible.
Change-Id: I07745e1f66022583e3076b84cc8bbe8bd2acd48f
When an AudioTrack is in underrun state, the AudioFlinger mixer will
sleep for a short period of time to give the app a chance to fill the
AudioTrack buffer. If the AudioTrack is still not ready during next mixing round,
the mixer will proceed with other tracks.
If an application keeps a steady underrun condition, the AudioFlinger mixer will
alternate between ready and not ready states. In the longer term this will cause the
audio HAL to underrun.
There is a mechanism to reduce the sleep period if the mixer is not ready several times in a
row but this mechanism is defeated by the alternating ready/not ready conditions.
The fix consists in only increasing sleep time if the mixer is ready for at least two
consecutive times.
Issue 5904527.
Change-Id: Id0139bca9be8c4e425ec6d428515c4d8f718e8c9
It seems that something (probably layout transitions)
occasionally leaves the navigation bar layout in a weird
state such that most of the buttons are offscreen. For
example, the portrait nav bar might have buttons with widths
matching the nav bar's old width from landscape; the
clickable regions will therefore be far off the right edge
of the display.
The navigation bar now looks for this situation when the
size of the view changes and corrects for it.
Bug: 5549288
Change-Id: I8464ac9fd64cb64ec18baf51478dd0f6564a2284
This was a bug only when the status bar was hidden, the screen space for
the nav bar would not be correctly removed for all frames used in layout
computation.
This code really $*#&^!! needs to be cleaned up, the whole "status bar
is the system bar when on a tablet so it should take space from apps,
but status bar doesn't do that on phones but on phones there is a nav
bar that does the same thing" thing is whacked.
Proof that evolution DOESN'T WORK!!!!!!!!!!
Change-Id: I24e4994328480820cb638e7a40aa0b65b7ae2003
This fixes a complaint from carriers (that we used 8.8.8.8), but also
fixes the case where there is only room for one live radio
connection: the secondary connection (tethering) doesn't have a
default route to prevent on-device traffic from slipping out on the
tethering connection, but tethered dns is proxied through dnsmasq, so
it is appearing as on-device traffic and is unroutable. By switching
to the carrier-indicated dns servers we can use the host-routes
already set for those and kill two bugs with one fix.
bug:5898904
Change-Id: Ida8777687994f353b2d4f2c7db5d6ea4b6ac3882
This increases lock screen's thread priority from THREAD_PRIORITY_FOREGROUND
to THREAD_PRIORITY_DISPLAY to ensure it runs before other activities that
might stall lock screen when the screen turns on.
Change-Id: I14cf9f3f5c092817bc6cf2d0a254001a5d34f744
This increases lock screen's thread priority from THREAD_PRIORITY_FOREGROUND
to THREAD_PRIORITY_DISPLAY to ensure it runs before other activities that
might stall lock screen when the screen turns on.
Change-Id: I14cf9f3f5c092817bc6cf2d0a254001a5d34f744
Also fixes some minor layout glitches along that row of
icons (Bluetooth vertical alignment & spacing, battery text
width, inter-icon padding).
Bug: 5895226
Change-Id: I303c2899bf21ddb7e28914d8fb36efd7090ac5e2
This creates (well, restores, since we had this until
Honeycomb) a user-visible state for "no service" that is
distinguishable from "very very weak service" (less than one
bar).
Bug: 5775939
Change-Id: Idd08b1a9411d5d94e4d7a97fa7f3ffd92b8113a6
