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
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
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
