This means pre-N apps launched on secondary displays might not work
properly after a density change, but multiwindow (let alone
multidisplay) isn't something truly supported by those apps.
Test: manual
Change-Id: I80e18c6db19faa716ec1d653caef410c67327546
For the key events with the code KEYCODE_HEADSETHOOK, the
MediaSessionService always starts the voice input for long-presses
regardless of the media key listener, and only short-presses can be sent
to the media key listener.
This CL sends all media key events to the media key listener first
if the listener is set. If the key event isn't consumed, short-presses
will be sent to the media session and long-presses will start the voice
input.
Bug: 35348856
Test: Manual test (Install the OnMediaKeyListener test app and confirm
that the app can consume the media key long-press)
Change-Id: I82f8e5f355efe16867e6f4345c46470c690e1f80
Test: verify that fingerprint clients still work and that
null client no longer crashes systemui.
Fixes bug 35806157
Change-Id: Icda7fb538caf50ba44297fe8e47c35aed1275280
The current submenu positioning logic is based on the assumption
that the parent menu was displayed at the exact offset which was
passed to the framework. The actual parent menu position
could have been adjusted to fit the screen.
Bug: 35767083
Test: manual
Change-Id: Ib72eb7808ebf894c526d2c44c6116ee72542fd03
...does not remove all references to callback
Keep the callbacks in a set, so each callback can only appear once.
Test: none currently, not sure how to do a CTS test for this.
(But verifying the system boots and runs.)
Change-Id: I01c8ea2a662e09ad0a0cdf713f0ea7f175182e82
Wrap all options of an audio focus request into a new
class, AudioFocus request, and the corresponding
methods in AudioManager to request and abandon focus
with an AudioFocusRequest instance.
New options include handler for focus change listener,
delayed focus, and option for specifying pause behavior
on duckable transient loss of focus.
Test: cts-tradefed run cts -m CtsMediaTestCases -t android.media.cts.AudioFocusTest
Bug: 30258418
Change-Id: I99151270d0d9c59595db3f5c91480c7af2d1fd71
Telephony stack is relying on non-existant ContentProviders for
sending Uri change notifications; it'll eventually need to move over
to using real ContentProviders, but apply this band-aid for now.
Test: builds, boots, SMS send/receive works
Bug: 35792675
Change-Id: Ice66278f876f1c754852300da7eb045a7c778d14
They're still valid providers, even when they're disabled.
Test: builds, boots, disabled authorities considered
Bug: 35791633
Change-Id: Ie1c40ae92a72b5b9f6869ea3dca19f2b74f80bae
Bug: 34050596
Test: cts-tradefed run cts -m CtsNativeHardwareTestCases
New test cases cover the new functionality.
Change-Id: I9285e53b8e608778ec2f080cb5eda4596215224f
