Per feature council decision, the multi-endpoint APIs will be @hide for
the N release.
Bug: 28196918
Change-Id: Ia80b089bc754ce87ca208382eb79442b5265844d
- Per suggestion of API council, moving properties of a Connection from
CAPABILITIES_* to PROPERTIES_*.
Bug: 27458894
Change-Id: Icce921b03cda514a991646ed39a26559c7e91230
Currently, connection extras are propagated up to Telecom as an
entire bundle. This is not ideal, as any time a change is made to
the extras, the bundle needs to be fetched, changed, and then re-set on
the connection, where it is parceled to Telecom as a whole.
Using how extras on an Intent as inspiration, this CL adds separate
putExtras, putExtra, and removeExtra methods to allow manipulation of
the extras bundle without operating on it in its entirety.
This Cl also adds support for Calls modifying the extras bundle, with
changes propagated back down to ConnectionServices.
Bug: 27458894
Change-Id: I152340a3bca2dc03f170b06b172a6823410fb961
This CL includes changes required to support multi-endpoint (see the
design doc linked off the bug).
Main changes include:
- support for indicating if a call/connection is "external" to the device.
- support for indicating if an external call can be pulled from the
remote device to the local device.
- API used to initiate a pull of a call external to the current device to
the current device.
- Made the "connection event" API public (was previously @hide); this will
be used to support passing some error events involving pulling calls to
the incall ui.
- Added new InCallService metadata which will be used to determine if an
InCallService wants to be informed of external calls.
- New disconnect causes which will be used to expose the fact that a
multi-endpoint call was answered elsewhere and that a call ended because
it was pulled to another device.
- New call log call types to indicate if calls were answered elsewhere
or pulled to another device.
Bug: 27458894
Change-Id: I423f64ff965b5e50194635a51868c327782db2a1
Connection event used to inform Telecom that it should play or stop
the on hold tone. This is used to play or stop a tone when the peer
puts the current call on hold.
BUG=25357778
Change-Id: I2669f8f5062449784a712b9dd28e576326fcc679
By default we assume downgrade to audio is permitted; this capability
probides a means for a carrier to specifically deny that.
Bug: 22728624
Change-Id: I75e0a5b9e5ad2d970003a4691b6fc0ac0dcfe9e0
Some capabilities, such as CAPABILITY_SUPPORTS_VT_LOCAL_BIDIRECTIONAL
are defined in terms of other capabilities; eg:
CAPABILITY_SUPPORTS_VT_LOCAL_RX | CAPABILITY_SUPPORTS_VT_LOCAL_TX
The current capability logic will return TRUE if checking for
CAPABILITY_SUPPORTS_VT_LOCAL_BIDIRECTIONAL and either of the TX or RX bits
is on; which is incorrect. Yay cts tests for finding this.
Bug: 26272951
Change-Id: I55a5676674ee74e213deb3a07e226b04a37d10ee
Add support for caching telecom call ID in connection and conference
classes.
Enhance connection service call ID generation:
For "existing calls", the connection service will try to use a call ID
of the format ClassName@ID
Where ClassName is the ComponentName of the connection service, and ID
is a unique incrementing ID for the connection service.
Bug: 23357902
Change-Id: I2284b018465e2b330fc8a3b556758e9f34a2daba
When an IMS conference call encounters an SRVCC event requiring a
fallback to GSM/CDMA, we need to maintain the call time for the
conference host across this fallback. So, adding a connectTime attribute
in the underlying conference host's connection object which can be used
to account for the call time from the now inactive conference call into
the new call created.
BUG: 21918593
Change-Id: I13e7ae6e31f004e798776c02ac7a6ac09a10f0bd
Used to mark IMS conference calls so that it is possible to know that we
never expect child calls to be associated with the conference.
Bug: 21085329
Change-Id: I7e5c82622ed382e431d4156878c28b37421e1e35
The problem was that we were calling Connection.getAudioState
in the conferencing code. This led to a null pointer exception.
Fix was to add a null pointer check.
BUG: 21957102
Change-Id: Ibad0f6cc70a5bc4a30023beb857125802bc35cd4
While authoring the CTS tests I discovered a few issues with the
VideoProvider.
1. The VideoProvider's default handler should be on the main Looper,
similar to other Telecom components.
2. When calling IVideoCallbacks, the try/catch for RemoteExceptions was
around the for-loop which iterates over the various VideoCallbacks. If
one was to fail, the other VideoCallbacks would not be called.
3. The mVideoCallbacks hashmap should use a ConcurrentHashMap; in CTS
tests I ran into a few concurrency exceptions related to the various
InCallServices registering callbacks while other methods on the provider
were being called.
Bug: 21802841
Change-Id: Ib0d46daf03554309044e9efaa991a15cb2c4b46b
Added constructor for VideoProviders to allow creating instances where
the Looper is specified. This is required for creating
VideoProviderProxy instances within Telecom.
Bug: 20232310
Change-Id: Ieb31e499caca9d65ff4b52c287e030c0ceeeb6ee
- Cleaned up documentation and added more details where possible.
- Also added cross references from the VideoProvider and VideoCall
APIs to make it more clear what the link is between the two.
Bug: 21520606
Change-Id: I0a79450d69841df5850061311a523b37688efc49
Two major changes:
1) Add the notion of extras to a Connection. These extras will be
parceled through to InCallService as Call.getExtras()
2) The previously existing Call.getExtras() has been renamed to
getIntentExtras(). This name better describes the fact that these
particular extras are from the original CALL or INCOMING_CALL intents.
Change-Id: I08c1baf4f08d54757f98012f0c08b423a707c53d
Deprecate AudioState class and make methods @SystemApi where
necessary to minimize impact to SystemApi
Replace usages of AudioState inside Telecom sub-systems
Fire both onCallAudioStateChanged and onAudioStateChanged callbacks
for backward compatibility
Support both setAudioState and setCallAudioState for all classes
Bug: 21040387
Bug: 21088300
Change-Id: I3ec7b3afdaa344c6d639d1c421f1842d67f7d0f7
Move CameraCapabilities into VideoProfile
Make PhoneAccount and PhoneAccountHandle final
Bug: 21040387
Bug: 21066505
Change-Id: I72453c89ae3765f9b9cf263938fce96d5978d2e0
Including a fromProfile in addition to the requestedProfile.
- Changed VideoCallImpl to generate the fromVideoProfile based on the
call's current videoState. This ensures the InCall UI only needs to
pass in the new video profile; the VideoCall Impl already has enough
knowledge to generate the fromProfile.
- Changed VideoCallImpl to track the current videoQuality, which forms
a part of the fromVideoProfile.
Bug: 20704229
Change-Id: I89f293f03a2b13fc8c1dcfd8a07ab8640d3950e0
The merge failure is not plumbed up through any layer that
can trap the callback and act on it. The first part of this
fix is to create that plumbing. Then we need to reenable the
merge button. At this point in time, we leverage the fact
that forcing the call to reassess its capabilities will poke
the InCallUI to reenable the merge button. In the future, we
should plumb the merge failure all the way to InCallUI and
not only handle the button but display UI to the user. The UI
is currently being displayed by CallNotifier which is the wrong
place. See b/20530631 for more details.
Bug: 20229905
Change-Id: I0355ada46b484c6db4bee656c77386dd61be5e1f
The current code assumes that only a single instance of VideoCall will be
provided to the default system InCall UI. Ideally multiple
InCallService implementations should be able to use the VideoCall APIs.
Note: it only really makes sense for a single InCallService to get/set
the video surfaces.
- Fixed bug in ParcelableCall which would cause a new instance of
VideoCallImpl to be created every time a call is updated from Telecom.
Added a flag to ParcelableCall to indicate whether the parcel includes a
change to the video provider information, which is used when unparceling
to determine whether to set/create the video call impl.
- Renamed "setVideoCallback" to "addVideocallback".
- Modified Connection.VideoProvider code to keep a list of Video callbacks
and fire off all of them when Video Provider changes occur.
Bug: 20092420
Change-Id: Ic16b6afe1b7532cc64d006c133adbae57946d97d
