- Change onCreateIncomingConnectionFailed/onCreateOutgoingConnectionFailed
to accept the connection mgr phone account as the first parameter.
- For the video APIs, pass the target SDK of the caller into along so
that the Telecom permission check can have fallback behavior for older API
versions.
- Add guidance for how UX should be shown in onShowIncomingCallUi API.
API guidance follows how the Dialer app shows its notification and full
screen UX.
Test: Manual, CTS.
Bug: 35767711
Bug: 35767096
Change-Id: Ib343f0eda1a4d067a38c553f33f140b4efcf3e48
Add methods and callbacks to facilitate local and remote RTT initiation
and termination in the middle of a call. Adds @hide Connection-side APIs
to communicate with the ConnectionService, as well as plumbing for
RemoteConnections.
Test: manual, through telecom testapps
Change-Id: Ia80604b7dff8586ff222dbccdbe55e91aab02178
Add signaling methods and data pipes for handling real-time text during
a call.
Change-Id: I876827c448252c5f786d7a4919c47891acb03877
Test: manual, through telecom testapps
Also added new isInManagedCall TelecomManager API, used to determine if
there are ongoing managed calls only.
Test: Manual, cts
Bug: 34159263
Change-Id: Ib8020617607ccb433c2eee9b9d5a2c929665214b
When a calling InCallService attempts to use the setCamera API on the
VideoCall, Telecom will perform a permission check to ensure that the
caller has the correct camera permission and passes the app-ops camera
check. A failure to set the camera will result in a callback via the
call session event API.
This got a little messy as the app ops package name needs to come from the
InCallService, and handler usage in the VideoProvider API means we had to
pass around the uid/pid of the caller, obtained before we trampoline onto
the handler.
Test: Unit tests added, manual testing performed.
Bug: 32747443
Change-Id: I555a04f9c3fb45e60bb811f64ba855ccf2e3b0e2
This can be used to determine if an incoming call is potentially
an emergency callback.
Bug: 30952524
Test: none
Change-Id: I2d4ca8e6885c0314394b3a2ad389ad8115b79156
The set audio routes are used by Telecom to restrict where the audio may
be routed to. For example, an account can specify that calls may not be
routed over bluetooth headsets, which will prevent a new call from being
routed to this source.
This is a cherry-pick of abandoned ag/1521009.
Bug: 32958838
Change-Id: Idd5e4d38b157f11454f3d991385644f2f384596e
The set audio routes are used by Telecom to restrict where the audio may
be routed to. For example, an account can specify that calls may not be
routed over bluetooth headsets, which will prevent a new call from being
routed to this source.
This is a cherry-pick of abandoned ag/1521009.
Bug: 32958838
Change-Id: Idd5e4d38b157f11454f3d991385644f2f384596e
When a calling InCallService attempts to use the setCamera API on the
VideoCall, Telecom will perform a permission check to ensure that the
caller has the correct camera permission and passes the app-ops camera
check. A failure to set the camera will result in a callback via the
call session event API.
This got a little messy as the app ops package name needs to come from the
InCallService, and handler usage in the VideoProvider API means we had to
pass around the uid/pid of the caller, obtained before we trampoline onto
the handler.
Test: Unit tests added, manual testing performed.
Bug: 32747443
Change-Id: I555a04f9c3fb45e60bb811f64ba855ccf2e3b0e2
1. removing deprecation for setExtras on Connection/Conference as these
have legitimate use-cases going forward.
2. Expanded documentation on Call.Callback class to clarify how it is
expected to be used.
3. Updated Callback#onConnectionEvent callback docs to clarify its usage.
4. Expanded Call#sendCallEvent docs to clarify expected namespacing of
call event keys and extras keys, as well as clarification about backwards
compatibility and expectations of ConnectionServices.
5. Standardized the "invoked" vs "notifies" language in the Conference
docs.
6. Clarified how Connection callbacks from Telecom should be implemented.
7. Added Bundle parameter expectations for pre-defined connection events.
8. Documented capabilities and properties toString methods.
9. Documented expectations for onCallEvent method.
10. Expanded documentation for sendConnectionEvent method to clarify
namespacing, use cases, etc.
Bug: 29759275
Bug: 29759954
Bug: 29759773
Change-Id: Ib8c983af4dbbfee68edb60937b268e2c1a9b5e64
Adds the CDMA Enhanced Voice Privacy Property to a Call when it has been
enabled for the call by the network.
Bug: 26931679
Change-Id: I1f5b4a4fb22fe6aaaf0c424ef11925c6058c6e82
am: 53b5df43b4
* commit '53b5df43b49b191e442c4d2c7b9a9cba3ebdcf92':
Rename PROPERTY_WORK_CALL to PROPERTY_ENTERPRISE_CALL based on API review
Change-Id: I24a866a5947a20127f3b79e2e75ba0cf534b450c
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
This CL adds a new service that the default dialer can implement to
screen incoming calls.
If the service is implemented then Telecom uses it to decide if a call
should be shown to the user or rejected.
Note, I initially tried to simply extend InCallService instead of
creating a whole new service. The problem with this approach is that:
- this breaks some in call services which show UI as soon as they are
bound to
- the in call service lifecycle is tightly coupled to adding and
removing calls. Call screening happens before a call is added which
makes it a bad fit to in call service
- call screening is a function of only the default dialer's in call
service but the existing code also binds to "controller" call
services
For these reasons it seemed simpler to just create a new optional
service.
BUG: 22857261
Change-Id: I53f2ef93360e0af19b6ce45af21026be6cf3a7f3
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
In our current design, in-call ui in parent user is used.
We need a way for Telecom to tell in-call ui that is the call a work
call or not show that we can have some UI changes to reflect it.
Bug: 26022174
Change-Id: I5f54371ddac14ffdb50359c2e792b9f24858bcb8
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
VideoCallImpl had a depedency on android.telecom.Call, which was used
to get the current video state of a call when the user issues a
session modify request (we need to know what the video state was before
the request was sent). This proved problematic for unit tests, as
android.telecom.Call is a final class and cannot be mocked.
These changes assume the VideoCallImpl will instead have a video state
property, which is updated by the Call whenever it changes. This
removes the dependency on the Call, and makes it possible to unit test the
API.
Change-Id: Ie67255d68b23e32aa177b30ac6439632fad5cc27
The the android.telecom.Call.Details class provides its own equals
implementation. Recently added in M is to also check if the mExtras
and mIntentExtras are different. Unfortunately, Bundles do not implement
equals. As a result when Telecom calls are parceled and sent to the
InCallServices, this means that the internalUpdate method will always
assume that the Details of a call have changed, even if they have not.
This was causing a LOT of extra calls to onUpdate in the InCall UI (2x the
amount). Although there is still room for improvement in the number of
callbacks from Telecom, this fix prevents a pretty significant regression
on that front.
Bug: 23218195
Change-Id: I128e996faf60376ed3df1dc848a97c4a7b0482ee
Since the Call API's callbacks are now fired from handlers, they end up
changing the order in which the callbacks from the Phone and Call API's
are fired. To preserve the below ordering, we move the call removal from
Phone's db to after all the onCallDestoryedcallbacks have executed.
1. Call->onStateChanged
2. Call->onDetailsChanged
3. Call->onCallDestroyed
4. Phone->onCallRemoved
BUG: 22127504
Change-Id: Ice17f727decb516baabbe69adae598ebdf370094
1. IMS MWI Feature
- Add new API to update waiting
voice message count, for UI
propagation based on RFC 3842
2. phantom call support
Supplementary services
3. IMS : Incoming Call Barring
- Modified existing API to support
request like registration,activation,
deactivation,erasure,interogation.
4.Unsol supplementary service notification
- send unsol supplementary notification to UI
- add call history info
Miscellaneous
5. Ims: Originate conference call in DIALING state
6. IMS: Addition of Extras to ImsCallProfile
- Add EXTRA string definitions to ImsCallProfile
7. IMS: Definition of error code
- answered elsewhere
- FDN call failure
8.
- Propagate IMS supplementary services to telephony framework
- Introduce call forwarding history info.
Bug: 21725750
Squash of 2 earlier CLs:
Change-Id: I52a64e9a5df3479189f62921a01655a50fb386fc
Change-Id: Idc3a433785e84a3d683cbcfc7fb90f0b89dced12
Change-Id: I428ce3c6a043e43b86dea41622e0a828d8b45e53
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
