Fix areBundleEqual in Call.

Currently the sentence in areBundleEqual arranged in a wrong order.
Fixed this by moving the check sentence before the actual query
sentence.

Bug: b/312604549
Test: cts call tests
Change-Id: Id8caa5719b4df724cbe03edd75b99a2b2e3882b5

Clarify in the docs that only the system/default dialer can
directly place call forwarding MMI codes. For other applications,
placing a call using these mmi codes will cause the dialer to
pop up with the MMI code populated so that the user can manually
confirm  before the call is placed.

Bug: 306380262
Test: docs only change
Flag: DOCS_ONLY
Change-Id: Id486304020b12e01785c5d98a1496d3bd9cfac43

Test: Owners only change.
Bug: 296459098
Change-Id: Ib97b6c3c155e0eee0529089f08ac87ebdd27e95a

Use Map.computeIfAbsent or the result of get() calls to interact with
the map via a single access, avoiding duplicate lookups.

Test: atest cts/tests/tests/telecom/src/android/telecom/cts/RemoteConnectionTest.java
Bug: 274764512
Change-Id: I1e6b10381f0c9b408c4a734384e550dfaefc1f40

bug: 282997779
Test: build
Change-Id: I9c1a3d0ca6e24a5cc6090d7e659329bf19391d1b

Because of the INTERACT_ACROSS_USERS permission, an app that implements
a ConnectionService can upload an image icon belonging to another user
by setting it in the StatusHints. Validating the construction of the
StatusHints on the calling user would prevent a malicious app from
registering a connection service with the embedded image icon from a
different user.

From additional feedback, this CL also addresses potential
vulnerabilities in an app being able to directly invoke the binder for a
means to manipulate the contents of the bundle that are passed with it.
The targeted points of entry are in ConnectionServiceWrapper for the
following APIs: handleCreateConnectionComplete, setStatusHints,
addConferenceCall, and addExistingConnection.

Fixes: 280797684
Test: Manual (verified that original exploit is no longer an issue).
Test: Unit test for validating image in StatusHints constructor.
Test: Unit tests to address vulnerabilities via the binder.
Change-Id: I6e70e238b3a5ace1cab41ec5796a6bb4d79769f2
Merged-In: I6e70e238b3a5ace1cab41ec5796a6bb4d79769f2

Because of the INTERACT_ACROSS_USERS permission, an app that implements
a ConnectionService can upload an image icon belonging to another user
by setting it in the StatusHints. Validating the construction of the
StatusHints on the calling user would prevent a malicious app from
registering a connection service with the embedded image icon from a
different user.

From additional feedback, this CL also addresses potential
vulnerabilities in an app being able to directly invoke the binder for a
means to manipulate the contents of the bundle that are passed with it.
The targeted points of entry are in ConnectionServiceWrapper for the
following APIs: handleCreateConnectionComplete, setStatusHints,
addConferenceCall, and addExistingConnection.

Fixes: 280797684
Test: Manual (verified that original exploit is no longer an issue).
Test: Unit test for validating image in StatusHints constructor.
Test: Unit tests to address vulnerabilities via the binder.
Change-Id: I6e70e238b3a5ace1cab41ec5796a6bb4d79769f2
Merged-In: I6e70e238b3a5ace1cab41ec5796a6bb4d79769f2

Because of the INTERACT_ACROSS_USERS permission, an app that implements
a ConnectionService can upload an image icon belonging to another user
by setting it in the StatusHints. Validating the construction of the
StatusHints on the calling user would prevent a malicious app from
registering a connection service with the embedded image icon from a
different user.

From additional feedback, this CL also addresses potential
vulnerabilities in an app being able to directly invoke the binder for a
means to manipulate the contents of the bundle that are passed with it.
The targeted points of entry are in ConnectionServiceWrapper for the
following APIs: handleCreateConnectionComplete, setStatusHints,
addConferenceCall, and addExistingConnection.

Fixes: 280797684
Test: Manual (verified that original exploit is no longer an issue).
Test: Unit test for validating image in StatusHints constructor.
Test: Unit tests to address vulnerabilities via the binder.
Change-Id: I6e70e238b3a5ace1cab41ec5796a6bb4d79769f2
Merged-In: I6e70e238b3a5ace1cab41ec5796a6bb4d79769f2

Because of the INTERACT_ACROSS_USERS permission, an app that implements
a ConnectionService can upload an image icon belonging to another user
by setting it in the StatusHints. Validating the construction of the
StatusHints on the calling user would prevent a malicious app from
registering a connection service with the embedded image icon from a
different user.

From additional feedback, this CL also addresses potential
vulnerabilities in an app being able to directly invoke the binder for a
means to manipulate the contents of the bundle that are passed with it.
The targeted points of entry are in ConnectionServiceWrapper for the
following APIs: handleCreateConnectionComplete, setStatusHints,
addConferenceCall, and addExistingConnection.

Fixes: 280797684
Test: Manual (verified that original exploit is no longer an issue).
Test: Unit test for validating image in StatusHints constructor.
Test: Unit tests to address vulnerabilities via the binder.
Change-Id: I6e70e238b3a5ace1cab41ec5796a6bb4d79769f2
Merged-In: I6e70e238b3a5ace1cab41ec5796a6bb4d79769f2

Add an extra key used internally with call attributes when setting up a
call.

Test: Manual testing.
Bug: 277232336
Merged-In: Ic8b5d57df88cf9c1d8a82a11ad4934ed4ef5fd78
Change-Id: Ic8b5d57df88cf9c1d8a82a11ad4934ed4ef5fd78

TL;DR:
- docs update for CallControlCallback rejection cases
- CTS coverage for onAnswer#(wasCompleted(false)) case
- CTS coverage for onSetActive#(wasCompleted(false)) case
- TSW fix

In most of the Transactional tests, it's expected that the client
always completed the CallControlCallback. In adding these tests I
noticed that the current logic will answer or set the call active if the
client rejects the onAnswer or onSetActive. In order to prevent this two
active call scenario, I've adjusted the appropriate code.

Fixes: 279034589
Test: CTS coverage for changes
Change-Id: I97f6371d845e00e7708b8b65abd57591d7a01cb7

Update API docs for REMOTE to make it clear that this disconnect cause is
used both for user-initiated disconnection on behalf of the remote party,
and for cases where the remote party never answered the call.

Test: Docs only change
Fixes: 280505750
Change-Id: Id718c75e2b748d2b5d5778f89d3dd7a420845418

Also fix bug where CallStreamingService would never init the streaming
adapter.  This caused the CallStreamingService to NEVER get notified of
onCallStreamingstarted since the handleMessage method was checking to see
if the adapter was set.

Test: Added CTS test for this case.
Bug: 279650527
Change-Id: I389efacd7547439985caabc068be5413897cf128

Also update javadoc to remove outdated information about self-managed
calls.

Bug: 279209119
Test: n/a
Change-Id: I6dba56f7afb8b383904a28042ad6e2a10e0a84b8

The D2DI team hit an NPE while testing out the call transfer/streaming
stuff. The NPE arises in StreamingCall whenever a call streaming changed
msg comes in and the StreamingCallAdapter is null.

Ideally, we should be wrapping any adapter request with an NPE check and
ignoring messages if the adapter is destroyed or not set.

bug: 277119309
Test: manual
Change-Id: I90a5c1dc16dfda9f3c92316b2f4f1655166a59b9

API council had originally created a bug to add details on disconnecting
a call and not needing to create a foreground service. I decided to
completely redo the docs to improve the adpotion of the API surface.

bug: 274957450
Test: none
Change-Id: I47dd84f8673ee7b81f1bd99ee6f42743d1d54b37

While investigating how the VoipCallMonitor class treats transactional
calls, I noticed a security exception was being thrown whenever
startForegroundServiceDelegate was being called. Upon some further
digging, an incorrect UID was being given to the activity manager class.

The fix is to fetch the UID in TelecomServiceImpl#addCall and store it
in the extras. Then, when the call is created in CallsManager, those
values are stored in the Call object. VoipCallMonitor can then query the
value and there is no longer a security exception.

Fixes: 276802273
Test: manual (start T-call and grep VoipCallMonitor)
      + unit test (ensure the CallingPackageIdentity is being set)
Change-Id: I10a22df721d1c9c6f467a24fed2d1204e0db843f

Bug: 261877110
Test: Telecom unit test
Change-Id: I05258c0ce17de38fb220f97ddbdda75a6bab1a1f
Merged-In: I05258c0ce17de38fb220f97ddbdda75a6bab1a1f

- include disable accounts when looking up accounts for a package to
  check if the limit is reached (10)
- put a new limit of 10 supported schemes
- put a new limit of 256 characters per scheme
- put a new limit of 256 characters per address
- ensure the Icon can write to memory w/o throwing an exception

bug: 259064622
bug: 256819769
Test: cts + unit
(cherry picked from https://googleplex-android-review.googlesource.com/q/commit:b07326f1fb3d0e42a6bab902c271974c42d93c06)
Merged-In: Ia7d8d00d9de0fb6694ded6a80c40bd55d7fdf7a7
Change-Id: Ia7d8d00d9de0fb6694ded6a80c40bd55d7fdf7a7

We've seen some bugs lately which root cause to an operation taking
place OUTSIDE of the Telecom sync lock when it should happen inside.
To help diagnose these types of problem, this change adds an icon to
the end of Telecom log messages which indicates if the log message was
triggered from within the Telecom lock or not.
 indicates the message came from outside the Telecom lock; this is NOT
always a problem as some logs purposely take place outside a lock.
 indicates the message came from inside the Telecom lock.
This is only enabled in userdebug builds to ensure no extra overhead
is incurred to check locks when logging takes place (Thread.holdsLock
does appear to be a very efficient API, but still).

Test: Build; verify logging indicates whether calls are from in Telecom lock.
Bug: 273759792
Change-Id: I3bdf7d444ff81af2df55ff76ec72d8862f72c0f4

Test: N/A
Change-Id: I6aebd39eba3077e4435873a3db1de32d54622c15

bug: 271324001
Test: none
Change-Id: Ifbb246d5469a93ec1da8b706edf3a05e87790999

This intent was never exposed as a proper API and the developer should
use a TelecomManager API instead.

Test: Make/run cts/unit tests
Fixes: 148361587
Change-Id: I058490ceed809d3e4c0d32b300463fffed1a2dac

- include disable accounts when looking up accounts for a package to
  check if the limit is reached (10)
- put a new limit of 10 supported schemes
- put a new limit of 256 characters per scheme
- put a new limit of 256 characters per address
- ensure the Icon can write to memory w/o throwing an exception

bug: 259064622
bug: 256819769
Test: cts + unit
Change-Id: Ia7d8d00d9de0fb6694ded6a80c40bd55d7fdf7a7
Merged-In: Ia7d8d00d9de0fb6694ded6a80c40bd55d7fdf7a7

- include disable accounts when looking up accounts for a package to
  check if the limit is reached (10)
- put a new limit of 10 supported schemes
- put a new limit of 256 characters per scheme
- put a new limit of 256 characters per address
- ensure the Icon can write to memory w/o throwing an exception

bug: 259064622
bug: 256819769
Test: cts + unit
Change-Id: Ia7d8d00d9de0fb6694ded6a80c40bd55d7fdf7a7
Merged-In: Ia7d8d00d9de0fb6694ded6a80c40bd55d7fdf7a7

- include disable accounts when looking up accounts for a package to
  check if the limit is reached (10)
- put a new limit of 10 supported schemes
- put a new limit of 256 characters per scheme
- put a new limit of 256 characters per address
- ensure the Icon can write to memory w/o throwing an exception

bug: 259064622
bug: 256819769
Test: cts + unit
Change-Id: Ia7d8d00d9de0fb6694ded6a80c40bd55d7fdf7a7
Merged-In: Ia7d8d00d9de0fb6694ded6a80c40bd55d7fdf7a7

- include disable accounts when looking up accounts for a package to
  check if the limit is reached (10)
- put a new limit of 10 supported schemes
- put a new limit of 256 characters per scheme
- put a new limit of 256 characters per address
- ensure the Icon can write to memory w/o throwing an exception

bug: 259064622
bug: 256819769
Test: cts + unit
Change-Id: Ia7d8d00d9de0fb6694ded6a80c40bd55d7fdf7a7
Merged-In: Ia7d8d00d9de0fb6694ded6a80c40bd55d7fdf7a7

After reviewing the API as a team more, we have decided to
add CallControl#answerCall to make CallControl more symmetric
to CallEventCallback.

bug: 268259965
Test: CTS
Change-Id: Ib48cd09002e1ee4522fe0439bf0c79a00ffa43da

CAPABILITY_SUPPORTS_TRANSACTIONAL_OPERATIONS and
CAPABILITY_SUPPORTS_CALL_STREAMING were added in android U.
Currently, if you register these capabilities, they fail to print
in dumpsys. This will make debugging harder. Adding to logs to
make the debugging easier.

bug: 270620095
Test: manual
Change-Id: Ia11907c983404b06c400fb9b8757a3ea26b08772

bug: 268107048
Test: CTS
Change-Id: I16e51ab8e9c3cd7f3ad7d17ebf7ab1cdff019253

bug: 269512817
Test: CTS
Change-Id: I5f4561192b7c8ab978754e3a7da6549d35c61b1d

Bug: 268542899
Test: Build

Change-Id: I4a5193200bfe959e405e0a67e653d3b4534f2efc

Make it more clear how to specify an anonymous call and its associated
presentation.

Test: docs only change.
Bug: 257534258
Change-Id: Ieb44fe8c9de954eabfda0d959fe529d63b53f72d

After some discussion amongst Telecom and an API council member, the
better design decision is to break up previous CallEventCallback into
two seperate callbacks.

The reason being, there is one set of callbacks that require the
client to complete a Consumer and another set of callbacks that only
provide event updates.

By making this change, the API surface becomes cleaner and should
eliminate some confusion.

bug: 268098087
Test: CTS
Change-Id: If5c46af9618be3720be203402bad9b583b3b2d06

Some of the docs used {@link} to refer to an intdef, which won't resolve
in the javadoc.

Fixing these.

Test: Docs only change.
Bug: 249779561
Change-Id: I3581a93c5630b35e6d850e252e6496b4314e0b2a

1. Make CallStreamingService and StreamingCall SystemApi and hide
2. Add android.permission.BIND_STREAMING_SERVICE
3. Change StreamingCall#DisplayName to CharSequence
4. Hide StreamingCall constructor
5. Fix CallControl#startCallStreaming doc

Bug: 265304561
Test: build; add cts
API-Coverage-Bug: 268061643
Change-Id: I29771cfbf60553eb8325e40b2cd11c5828a445e4

The API docs are not clear; they insinuate that a caller can issue any
number of "play" DTMF requests followed by a single "stop" request and
that the framework will interpret this as two digits in succession.
In reality, the documentation is referring to the fact that the local tone
will correctly stop if another tone is already playing.  The API
requests are sent directly to the modem as the InCallService sends them,
and it is possible that some ConnectionService implementations (more
specifically some vendor IMS implementations) will get confused if
they receiver multiple starts and then a single stop.

Test: Docs only change
Bug: 262699364
Change-Id: I770008cc3b000f739d930ea899df5e98d1b17129

Bug: 258629881
Test: NA
Change-Id: I503767a4752a55207ece61255f7b547226129091

API council reviewed CallControl and suggested that reject should be
merged into disconnect.  After talking it over with the team, we decided
this was a good suggestion.

changes:
- CallControl#Reject API removed
- CallControl#Disconnect API only allows 3 disconnect codes
- Throw an IllegalArgumentException if the client passes an invalid code
- EndCallTransaction adjustments

bug: 265809508
Test: CTS

Change-Id: I2b11ad507a7c280e8447f069c1865f765991468c

changes:
- remove CallException(String)
- TSW will propogate the CallException
- All VoIP transactions do not use RESULT_FAILED
- CTS coverage for some CallExceptions

bug: 264468805
Test: CTS
Change-Id: I11140ad39b610ec24ed3894cccbdc6b17bfec626