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
This CL exposes a new meta-data, IN_CALL_SERVICE_RINGING. If this is set
to true then ringing is played by the dialer instead of Telecom.
This CL also adds a new silenceRinger() API to InCallService. This is
needed to implement ringer silence on volume key down.
BUG: 22857261
Change-Id: I498538282eddbb727104f5b879f25adbef4e6cf6
This CL makes the missed call notification action public. This will be
used by the dialer app to show it's own missed call UI.
See ag/850080 for more info.
BUG: 22857261
Change-Id: Ifae82d3036a278e5619edc8c766a1d0781296e72
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
Add dumpAnalytics in TelecomManager to allow the connectivity stats
service to access Telecom analytics for uploading.
Change-Id: I197d6af340fac7f38b28bb44a476b5e694db4dba
- New carrier config option is used to determine if presence is used
to determine whether a contact is capable of video calling.
- Also, improve logging for PhoneAccount capabilities.
Bug: 20257833
Change-Id: Ifcc7df95677eb4399f08eb8849c4004892957e90
Admittedly this isn't going to cause a build breakage for anyone misusing
the values, but it should help make issues more aware at code authoring
time.
See http://goo.gl/zaH4RE for more information.
Change-Id: I3f20dc4bff364dec290d4b647e31f8032d4a13ec
Many places across the platform query package details without
gracefully handling packages or components that go missing for
various reasons. This can cause annoying user data loss, such as
resetting back to built-in apps or dropping of accounts, etc.
This change verifies that system callers have thought about these
edge cases by logging if they use default matching behaviors without
explicitly marking themselves as being "triaged." (The logging is
currently disabled by default.)
Also creates explicit definitions of supported flags for various
incoming PackageManager calls, and defines a clear distinction
between flag types:
-- GET-style flags are used to request additional data that may have
been elided to save wire space.
-- MATCH-style flags are used to include components or packages that
would have otherwise been omitted from a result set by current system
state.
There are a handful of existing GET flags that better fit under the
MATCH definition, so this change clones them to new constants and
marks the old ones as deprecated.
Fixes bug in JobSchedulerService to consider jobs from apps on
external storage. Revert some dialer behavior back to being
untriaged.
Change-Id: I9b6ab0968241e3479bddbd78de0c51e3b9917318
Create distinct flags for encryption aware, unaware, and both, and
name them like the other MATCH_ flags.
Start adding logic to help triage all system internal callers to
verify that they've done their homework and thought about how to
handle apps while locked. Call sites in the system should either
ask for explicit matching behavior, or explicitly use the DEFAULT
match flag to indicate that they've been triaged to use the
default state-based matching.
Bug: 26250295
Change-Id: I86214e5c4f71a6dc72f06930800388713aecd107
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
Added new PhoneAccount capability used to indicate whether the dialer
should use the presence bit in the contacts provider to determine when
the video call icon is shown or not.
Bug: 20257833
Change-Id: Ifb3cc5b7ff1090d539dfb925dce9f6327de15c46
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 body of {@code} must not be HTML escaped. This is one of
several changes that fix the source in conjunction with a
doclava fix.
Bug: 25757239
Change-Id: Ib38a0fa2dd2a3d68e467f78a812071e763d7e881
- Added acceptRingingCall API which accepts a videostate to complement the
existing API.
Bug: 20159300
Change-Id: I2a9d53fd4dbbb0be49d95416f7e26d3ec61774cd
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
