Java API version
Update frameworks to enable support for CAST
V2 Authentication in the DRM Plugin.
Change-Id: I23cfbbbc89c1226b7a3968ce8bc1e2d4bd41014a
related-to-bug: 12702350
setAvrcpAbsoluteVolume is passed wrong unit parameter from AudioManager.
It cause maximize volume in Bluetooth speaker/device.
The volume expected by Bluetooth Avrcp should be from 0 to 15.
But the current volume parameter passed to Bluetooth Avrcp is from 0 to 150.
It is scaled by 10 times than the correct volume.
index = rescaleIndex(index * 10, streamType, streamTypeAlias);
Should divide the volume by 10 before pass to Bluetooth Avrcp.
bug:12495379
Change-Id: I4160588e92ee384e21a75d63036d8bd6ccb30621
For storing pointers, long is used in media classes,
as native pointers can be 64-bit.
In addition, some minor changes have been done
to conform with standard JNI practice (e.g. use
of jint instead of int in JNI function prototypes)
Change-Id: Idc4ca0124d03df7f9cef412488abafd020e5e774
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Marcus Oakland <marcus.oakland@arm.com>
Signed-off-by: Kévin PETIT <kevin.petit@arm.com>
For storing pointers, long is used in MTP classes,
as native pointers can be 64-bit.
In addition, some minor changes have been done
to conform with standard JNI practice (e.g. use
of jint instead of int in JNI function prototypes)
Change-Id: I67805547251722e7b77611d47d0bb632a64d3e6d
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Marcus Oakland <marcus.oakland@arm.com>
Signed-off-by: Kévin PETIT <kevin.petit@arm.com>
For storing pointers, long is used in VideoEditor
classes, as native pointers can be 64-bit.
In addition, some minor changes have been done
to conform with standard JNI practice (e.g. use
of jint instead of int in JNI function prototypes)
Change-Id: Ifff3a28f2ab6774ee89d31770ad63451c8726431
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Marcus Oakland <marcus.oakland@arm.com>
Signed-off-by: Kévin PETIT <kevin.petit@arm.com>
For storing pointers, long is used in AudioEffect
and Visualizer classes, as native pointers can be 64-bit.
In addition, some minor changes have been done
to conform with standard JNI practice (e.g. use
of jint instead of int in JNI function prototypes)
Change-Id: Ief49bbe5baef663e268c7f6d70ac33a4df45621c
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Marcus Oakland <marcus.oakland@arm.com>
Signed-off-by: Kévin PETIT <kevin.petit@arm.com>
For storing pointers, long is used in AmrInputStream
class, as native pointers can be 64-bit.
Change-Id: I78fff3eb54fc7101746b0d693cbc4e923c2bad08
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Marcus Oakland <marcus.oakland@arm.com>
Signed-off-by: Kévin PETIT <kevin.petit@arm.com>
For storing pointers, long is used in MediaDrm and
MediaMuxer classes, as native pointers can be 64-bit.
Change-Id: I77f26cde627baf0dce70b6aa3a4dbd974051d9a6
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Keep track of how many clients are requesting scans and scan
continuously until all of them are gone then explicitly terminate the
scan instead of letting it time out as before.
Suspend wifi display scans while connecting or connected to a remote
display. This is handled by both the display manager and media router
since neither has complete information about what is happening.
Much of this code will no longer be needed once wifi display support
is integrated directly into the media router service.
Ensure that we don't attempt to scan or connect to wifi displays
while the wifi display feature is off.
Infer when a connection attempt fails and unselect the wifi display
route automatically so it doesn't appear to be connecting forever.
Fix issues around correctly canceling and retrying connection attempts.
Often we would cancel but not retry.
Improved connection reliability somewhat. It seems that discovery must
already be in progress in order for a connection attempt to succeed.
Ensure QuickSettings uses exactly the same logic as the MediaRouteButton
to determine when the remote display tile should be made visible.
Bug: 11717053
Change-Id: I18afc977b0e8c26204b8c96adaa79f05225f7b6e
Only allow the system ui and settings to connect to a remote display.
To do this, we essentially hide the remote displays from applications
by using the ROUTE_TYPE_REMOTE_DISPLAY then add permission checks
around the operations that connect to them.
As a bonus, this may actually save power on devices since applications
that use MediaRouter will not longer be performing discover on
remote display routes at all.
Bug: 11257292
Change-Id: I9ea8c568df4df5a0f0cf3d0f11b39c87e2110795
A regression was introduced when trying to limit the number of
internal synchronization generation IDs that caused RCC
information to be shown only for applications that requested
audio focus after media button receiver and RCC registration,
(such as Play Music), not for applications that requested focus
first (such as Play Movies).
The correct behavior is to always check and update the
RemoteControllers (seen by MediaFocusControl as RCD interfaces)
whenever a RemoteControlClient is registered (even if it's a
re-registration) when it is associated when an entry at the top
of the remote control stack.
Bug 11657655
Change-Id: I30716e2028f7f718a31e13401b191178735229ff
Hide disabled routes from the chooser.
Fix layout of chooser dialog when the settings button is visible and
the list is very long to prevent truncation of the settings button.
Fix an issue when we fake the route connecting status when a route
is selected. The route changed notification needs to be propagated
to apps. Fake it better.
Immediately disconnect from a route when the connection is lost or
a connection attempt fails. Added a few new test displays for this
case.
Bug: 11257292
Change-Id: I360ab5dc937ad60d97592eab54b19f034519645e
Fixed the Preference ordering code to consider the case where
two preferences might have the same order. In that case, it
falls back on the title to disambiguate. Previous behavior was
undefined (and technically not stable).
Expose the wifi display device address.
Perform wifi display scans every 10 seconds instead of every 15
to improve reponsiveness.
Make sure to define routes for wifi displays that we are connecting
to even if they are not yet paired. Simplified the logic for
adding and removing these routes to avoid possibly getting out
of sync and leaving stale routes behind.
Fix wifi display notification icon.
Bug: 11257292
Change-Id: I8ac15fb17d83758c0bdce80399e12723c367b83c
Port the new style UI back into the framework from the support library.
There are now two dialogs: a chooser and a controller. We use the
same dialogs for selecting routes within app and within quick settings.
Note that the new UI does not support any grouping features since they
are deprecated and unused.
Bug: 11257292
Change-Id: I64e936a18d25ab75f0c470cbc1e7085f67004863
This change adds a new media router service whose purpose is to track
global state information associated with media routes. This service
publishes routes to the media router instance in application processes
and handles requested state changes such as selecting or unselecting
global routes. The service also binds to remote display provider
services which can offer new remote display routes to the system.
Includes a test application for manually verifying certain aspects
of the operation of the media router service.
The remote display provider interface is essentially a stripped down
media route provider interface as defined in the support library
media router implementation. For now, it is designed to be used only
by first parties to publish remote display routes to the system so
it is not exposed as public API in the SDK. In the future, the remote
display provider interface will most likely be deprecated and replaced
with a more featureful media route provider interface for third
party integration, similar to what is in the support library today.
Further patch sets integrate these new capabilities into the System UI
and Settings for connecting remote displays.
Bug: 11257292
Change-Id: I31109f23f17b474d17534d0f5f4503e388b081c2
This interface allows applications to register services that offer
remote displays to the system. The system will then provide UI
to allow user to connect to these displays and enable mirroring.
Bug: 11257292
Change-Id: I34da5b9dfdaf71267bd3450c505bc1b7368d1b40
When A2DP absolute volume is enabled, the music stream
software volume is maxed out because the headset applies
the volume.
We must also max out other streams playing over A2DP otherwise
they are attenuated twice and are barely audible.
Bug: 11316102.
Change-Id: I7e58c74cb683ad1d6f3b68abb0ef967c817fbf4f
State only depends on events from the MediaPlayer (this includes
the pseudo-event from MTP recovery mechanism.)
Change-Id: Idd62a773d2386ad6bfbfe417412c2e2ff09b3600
Signed-off-by: Lajos Molnar <lajos@google.com>
Bug: 11412881
At the beginning of each song, the Music app re-registers its
media button event and requests audio focus, which causes
the reevaluation of each corresponding stack of clients. Each
reevaluation is accompanied by the incrementation of the
RemoteControlClient generation ID, which causes RemoteController
to issue a notification that the client has changed. The lockscreen
correctly interprets this as a reason to dump the current
RemoteControlClient data (including the artwork) because it will
receive the new data if new one is available. This is what causes
the "flashing" of the wallpaper on the lockscreen: for an instant,
no client data is available.
The fix consists in not causing the client generation ID to be
incremented when registrations don't cause any change in the
RemoteControlClient stack. Even though Music re-registers everything,
nothing has changed: it still is the current media button receiver,
and it still has the same RemoteControlClient.
Bug 11307382
Change-Id: I4d2404b571e88aeedb0eca6bd19d39f7ec4fc8b1
