When the user is in a phone or VoIP call, the volume keys should
control the STREAM_VOICE_CALL volume. Before MODE_IN_COMMUNICATION
was introduced to cover VoIP use cases, having an active VoIP call
was determined by checking whether there was any track used the
output stream STREAM_VOICE_CALL, which can give false positives.
This CL checks instead against the audio mode to see if
MODE_IN_COMMUNICATION is selected to determine if a VoIP call
is in progress.
This implies that applications that play on STREAM_VOICE_CALL
shouldn't rely on that fact alone to expect the volume keys
to control the STREAM_VOICE_CALL volume, and should instead,
rely on the official mechanism for that:
android.app.Activity.setVolumeControlStream(int)
Change-Id: Ia487951ea1684477aa3d522c9031fad484d8a40d
(Previous behavior: the tap would pass through to the clock,
which would open the shade. Only sometimes it wouldn't,
because you'd have hit the left-hand-side of the ticker
where there's no clock underneath. So this fixes that too.)
Additionally, tapping the ticker will now immediately
dismiss the ticker.
Bug: 3365129
Change-Id: Ic641184c518b18d799a560c8da6b4c5844c912de
These trackers have two copies of the network type: newSS and newNetworkType. I think thats wrong,
but this was the smaller change on code that will hopefully be refactored soon.
On radio_off we were making a new, empty newSS but not clearing newNetworkType so it
still thought we were on 3G and when we reconnect and get 3G state changes new==old and we don't
send the update. In this fix I reset newNetworkType every time we apply it to networkType.
bug:3389886
Change-Id: I294f34259dc6c6f8f445bf2cb5466c8be747e25c
Or at least make it better. Now if we get a failure locking the surface,
we mark to do a full relayout pass later to try to get a new good surface.
Also fix some bugs in how activity manager was classifying processes for
their OOM adjustment to make better choices in what to kill.
Change-Id: I8e4aa86744211ba7693f9828291d8bbf2698274f
Also removed android:detachWallpaper="false" from lock_screen_exit
since it's not guaranteed to do something sane when windows aren't
owned by applications.
Change-Id: I28b5fc6b68d1aef93f092538d1318ce2b2a835ef
Bug 3370191
The documented behavior is to hide the error when the text changes.
However, this should not be the case if the error was reset by a text watcher.
Comparing errorBefore and errorAfter as was done before is not sufficient in the
case where the error is reset to the same value. String pool optimization will re-use
the same Object and it will look like the error has not been modified (hence the
blinking behavior reported in the bug).
For this reason, TextView has a mErrorWasChanged flag. The fix is to export methods
that can use this flag as in done inside TextView when a physical keyboard is used.
These methods are hidden.
Change-Id: Ie3ec59a368f3b1588b81242890b971ac48e8ff7e
Also display placeholders for status/title/action bars depending
on if the app is a tablet and its theme.
Change-Id: I651c1a2e5cfde165e004c11b236e6df056853dec
This is an initial API that will allow the plugin to request to
keep the screen on.
companion change is in external/webkit
bug: 3331493
Change-Id: Ic18787e7ecd705a5b2e31a34ea884fd39ad9d11a
Bug 3381317
Also generalized and uniformized the use of peekInstance. Added null
tests, and isActive tests before hiding.
Change-Id: Ifd1a053fd920841333e0ebab3e2a8d26b469a0f6
There was logic in ViewGroup that assumed that an accelerated
view must always be able to get a display list for any child
that it was drawing. One situation occurred, however, that
caused a problem with this - a contacts activity was started
and not yet attached, but was being asked to render into an
accelerated canvas. We assumed that the child would have a display
list and simply called getDisplayList(). But since that call
returned null, we later deref'd the null object.
The fix is to check whether a child can have a display list
instead of assuming that it can just because the container view
is accelerated.
Change-Id: I7de62fd597ad50720c9585d621bec02e77c171df
Bug 3266751
The boot time is 43 compared to 44 seconds, which is within the precision of the measure.
Starting 15 activities in a sequence takes 20-24 seconds with the old version and 17-18
seconds with the new pre-load (12/13 when ran a second time, all apps being loaded).
The standard deviation is high, but it seems consistently better.
Change-Id: Ieac3cb93be03e8186979b894adda29f0549b9734
Display lists could not handle custom views that did their
own draw dispatching, as is the case with gmail. This fix makes that
possible and display lists handle this case robustly. Now the
crossfade works because the display lists contain the right content.
Change-Id: Iea7d6e99239b24f833701d546fe083aa00e2b31b
