summaryrefslogtreecommitdiff
path: root/tools/aapt2/java/JavaClassGenerator_test.cpp
diff options
context:
space:
mode:
authorTyler Gunn <tgunn@google.com>2016-10-17 15:48:19 -0700
committerTyler Gunn <tgunn@google.com>2016-10-17 15:48:19 -0700
commit2282bb97e78ea87ff322ecf12563ab0120af2b28 (patch)
treec9cd052b13f6a7bda0f8db82d778305dd744db38 /tools/aapt2/java/JavaClassGenerator_test.cpp
parent73c46f060908d58e1adcade3ee4ee121dc4a8f39 (diff)
Framework fixes to support VoLTE conf calls via RemoteConnectionServices.
Fixing some issues with the addExistingConnection and addConference APIs on ConnectionService. When a connection manager relays the addition of an existing connection or a conference to Telecom, it will assign a new ID to the new connection/conference. Due to how RemoteCSes work, the Connection/Conf will be added directly via TelephonyConnectionService and also via the connection manager's connection service. Because the ID changes, we ended up adding these twice. Conferences weren't a problem in the GSM conference case because the TElephonyConnectionService's ConnectionServiceWrapper didn't know of the IDs for the children of the conference. However, due to how the existing connections work its not the case for VoLTE conferences. To mitigate this, I'm passing the original connection/conference ID to the connection manager via extras (ugh) and using this to ensure that when the new existing connection/conference is added to telecom that the same ID is used. This ensures that we can properly de-dupe the requests from TelephonyConnectionService and the connection manager. Also, there was some missing code in RemoteConnectionService which would cause it to not properly track existing connections. Bug: 31464792 Change-Id: I436f4438fd000ea48ebea7ceb75105bd3f456e46
Diffstat (limited to 'tools/aapt2/java/JavaClassGenerator_test.cpp')
0 files changed, 0 insertions, 0 deletions