| a6d8e8b73b03a34db4b012b1ca53ebae168f8daf |
|
15-Jul-2016 |
Brad Ebinger <breadley@google.com> |
Allow for Reconnect from Connection Manager
There are currently two situations where Telecom will redial on another
ConnectionService's PhoneAccount: 1) An Emergency Call has been placed,
Telecom connects successfully to a ConnectionService, and the
ConnectionService returns an ERROR message; and 2) A ConnectionManager
is being used to place a call and the ConnectionManager rejects the
Call with a onCreateConnectionFailure callback.
In case 1), we disconnect to the ConnectionService connect to another
emergency call capable PhoneAccount to place the call.
In case 2), we try to place the call directly on the ConnectionService
that the PhoneAccount is registered to.
This change reverts part of a previous change that broke case 2).
Bug: 29877938
Change-Id: I58badca94bb893f8ec797fc16ecb66f8ca9acabd
/packages/services/Telecomm/src/com/android/server/telecom/CreateConnectionProcessor.java
|
| 3ff5eddd28eeec2fed1c833a493ba7469bfa951f |
|
12-Jul-2016 |
Brad Ebinger <breadley@google.com> |
Only Redial calls in the case of Emergency Calling
Currently, if there are multiple Calling Accounts and a call fails, we
redial the call on another Calling Account. We should only redial if it
is an emergency call being placed and it has failed from Telephony with
an Error.
Bug: 29877938
Change-Id: I2efa9f7f06e9eed03799c1514a027cf73ea5b3ee
/packages/services/Telecomm/src/com/android/server/telecom/CreateConnectionProcessor.java
|
| 6e8f3d70ac7397afb4cb5ab276d1cd385c92dd21 |
|
20-Jun-2016 |
Brad Ebinger <breadley@google.com> |
Rename Telecom Call Ids to include attempt
Telecom Call Ids will now append an attempt id (in the form of an
integer) that will be used by the CreateConnetionProcessor to name the
Telecom Call Ids that are used during the creation of a Connection to
the ConnectionService. This allows us to better identify which
Connection is calling back to Telecom to update status, disconnect,
etc. Previously, all of the attempted Connections in
CreateConnectionProcessor would be given the same name, which could lead
to multiple Connections trying to manage the same Call object in
Telecom.
Also, a supporting tests were added and a few Unit Tests were fixed.
Bug: 28799824
Change-Id: I7e23497ab671712bc8d3cc9542537ae1c4829afc
/packages/services/Telecomm/src/com/android/server/telecom/CreateConnectionProcessor.java
|
| e6c481acfcad381e3973e3250a366e1893259b84 |
|
12-May-2016 |
Brad Ebinger <breadley@google.com> |
Account for User's Voice SIM preference for E911
Currently, we do not take into account a user's Voice SIM preference
when making an emergency call. The CreateConnectionProcessor now first
trys to use the Voice SIM preference of the user and backs up to other
SIM accounts if that account fails.
Bug: 27059146
Change-Id: Ic64ecdd23fe081f9660820e5659d314f2c9b9902
/packages/services/Telecomm/src/com/android/server/telecom/CreateConnectionProcessor.java
|
| 8ff99f3751fcdd662932317ca45f886f6883e196 |
|
13-Feb-2016 |
Santos Cordon <santoscordon@google.com> |
Add call should always be present in CDMA calls.
This is reverting Change I2e4b396f5665b5517275766daa722866cf92d68c
Initially, the idea was that CDMA could not place additional calls while
a conference was happening. This is not always the case. CDMA
conferences exist in two states: merged and unmerged. Also, a call can
disconnect from the conference and the conference will continue as a 1:1
call.
In the case where the conference is "merged" or a party has
disconnected, the "add-call" option will function fine. This is why we
are adding the add-call back.
Bug: 22850789
Change-Id: Ib6bafed528cb84d46b46b11313db902d9aba4292
/packages/services/Telecomm/src/com/android/server/telecom/CreateConnectionProcessor.java
|
| f19000764f6b93dfa15561342cbdd9c1aa1d3e22 |
|
13-Nov-2015 |
Brad Ebinger <breadley@google.com> |
Refactor CreateConnectionProcessor
Currently, if a ConnectionManager refuses a connection from a Call, this
code will set a flag and call process() again. This finds all of
possible PhoneAccounts again (without the addition of the
ConnectionManager). In order to avoid this redundancy, a queue is utilized to
have the CreateConnectionProcessor fall back to another account if the
connection fails.
This change only changes how a ConnectionManager is being found/used.
Also, tests have been added for CreateConnectionProcessor
Change-Id: Id7479e5337a812fdae83411fb2fbc248d8c1a7da
/packages/services/Telecomm/src/com/android/server/telecom/CreateConnectionProcessor.java
|
| 240656f19c078b4f703d0502ce29114de0d45a50 |
|
04-Dec-2015 |
Tony Mak <tonymak@google.com> |
Methods in PhoneAccountRegistrar should ask for userhandle explicitly
1. Get calling user handle before calling clearCallingIdentity
2. Methods in PhoneAccountRegistrar asked for the user handle explicitly
instead of trying both current user and calling user
3. Modify isVisibleForUser in PhoneAccountRegistrar,
- PA with CAPABILITY_MULTI_USER is visible to all users including
managed profile (We are still discussing this, but let's assume it
works in this way and change it later if necessary)
- For other PAs, they are only visible within the user they are
registered to.
- TelecomManager.getPhoneAccount is an exception case. The visibility
checking of getPhoneAccount allowing a PhoneAccountHandle from other
profiles in the same user.
Reason:
Telecom passes PhoneAccountHandle to incall UI and incall UI
retrieves PhoneAccount from the handle.
It is because we never bind to managed profile's incall UI, and bind
to its parent user provided one instead. So phone account handle in
managed profile is passed to it's parent user incall UI. And we need
to allow parent user incall UI to retrieve the PhoneAccount from
the handle.
4. Please notice that the default PA account related APIs does not really
support multi-users. The backend (xml storage) does not include user
as a key and it should be able to store one default only and is shared
among all users. This problem is not fixed in this commit.
Bug: 25936882
Change-Id: Ia371723d68247a208a0c1185f6d02f1b5897946a
/packages/services/Telecomm/src/com/android/server/telecom/CreateConnectionProcessor.java
|
| 6ffe531cc43849b5ca22a23647f5e729fae01c25 |
|
12-Aug-2015 |
Tyler Gunn <tgunn@google.com> |
Minimize the number of calls to PhoneNumberUtils.isLocalEmergencyNumber.
On a standard outgoing call, isLocalEmergencyNumber was being called
from 30-40 times. Each of these calls requires a system service
invocation.
The Telecom Call object already has an isEmergencyCall() property which
is set any time the handle on the call changes.
When ever possible in Telecom, I have used this already calculated value.
These changes reduce the number of calls to isLocalEmergencyNumber
by about 5-10.
Also removed a duplicate call to setHandle() in the Call constructor.
Bug: 22985202
Change-Id: Ic8662d4ab506486858caf4fbff61c32bae2b7c8c
/packages/services/Telecomm/src/com/android/server/telecom/CreateConnectionProcessor.java
|
| 165c1ced107a1c3b9b359757d41438f9ca585e78 |
|
11-Jul-2015 |
Santos Cordon <santoscordon@google.com> |
Add logging in Telecom for conference call & audio tracking.
Bug: 22331056
Change-Id: Ib6147e55cd886d678d924c92bb86743c22ad6366
/packages/services/Telecomm/src/com/android/server/telecom/CreateConnectionProcessor.java
|
| 7bb8ce9b4e7ffa5e603d8bd8780f55a1c2ced071 |
|
14-May-2015 |
Yorke Lee <yorkelee@google.com> |
Add BIND_TELECOM_CONNECTION_SERVICE permission
Bug: 21088342
Change-Id: I465307899d83c4a3ee5e88a28554c4b867c1f4ba
/packages/services/Telecomm/src/com/android/server/telecom/CreateConnectionProcessor.java
|
| 6a2126477ce3f527ecaec807fe4f40cd13ff02b0 |
|
09-May-2015 |
Santos Cordon <santoscordon@google.com> |
Clean up PhoneAccountRegistrar.
Cleanup lots of duplicate code and consolidate all phone account
retrievals into a single method: getPhoneAccounts(...).
Consolidate checks for capabilities, package-name, uri, and
isVisibleForUser(...). This will be very helpful when
implementing enable/disable for phone accounts.
Bug: 20303449
Change-Id: I24d63cd313876f5d9390f2eb31c0ce79d7cb0ab2
/packages/services/Telecomm/src/com/android/server/telecom/CreateConnectionProcessor.java
|
| 92694519535c54f542b4ef3973e9c1934f2feeff |
|
23-Apr-2015 |
Santos Cordon <santoscordon@google.com> |
Move CallState and rename PRE_DIAL_WAIT.
CallState was a public API only being used by Telecom so I've moved it
into to Telecom and removed it from the public API. The translation
from CallState to Call.STATE_* was happening on the public Call object
which wasn't ideal (Call.java shouldn't have to know that other
representations of state exist). So I moved the translation into
InCallController.java and what we pass into ParcelableCall is now
Call.STATE_* constants.
Bug: 20532827
Bug: 20532435
Change-Id: I79ce36c7e971c1a49b857506c9a56cfe316069cf
/packages/services/Telecomm/src/com/android/server/telecom/CreateConnectionProcessor.java
|
| 8de76915ea2772faeb41705aaaeb65f5b3478ac4 |
|
17-Feb-2015 |
Ihab Awad <ihab@google.com> |
Further refactor Telecom and add tests
Complete refactoring Telecom to remove singletons from the core code.
Introduce a unit test that simulates a full outgoing phone call from
start to hangup.
Change-Id: I8b09cac6eb9b6aeeb0aeba5d8ae032b4c303c08d
/packages/services/Telecomm/src/com/android/server/telecom/CreateConnectionProcessor.java
|
| 91fc8099a0690a3367eb206788c9c25ceff31875 |
|
15-Feb-2015 |
Sailesh Nepal <sail@google.com> |
Fix connection manager bugs related to work profiles
When calling TelecomManager.addNewIncomingCall with an account
that's was not registered we would crash. Fix was to check
for a null phone account.
Various TelecomManager APIs would throw security exceptions when
called from a work profile. Fix was to:
- switch to using APIs that allowed the user to be specified.
For example, using queryIntentServicesAsUse instead of
getServiceInfo
- don't look for work profiles if the calling user isn't the
owner.
The default connection manager (set using a config.xml overlay)
didn't work with work profiles. Fix was to allow the default
connection manager to resolve against the calling process's
user handle.
BUG: 19300886, 19301690, 19301359
Change-Id: I49d75b69dcfc829b74a5483d7a011f17d8d06838
/packages/services/Telecomm/src/com/android/server/telecom/CreateConnectionProcessor.java
|
| 646fa3d6eaea71fb4c3270fde1a30eeb7c5e4288 |
|
28-Jan-2015 |
Sailesh Nepal <sail@google.com> |
Add timeout for emergency calls
Currently connection managers are only able to route
emergency calls if the call can't be placed by the
normal phone account first.
Unfortunately this strategy only works for "fake" emergency
calls (for example when you set a fake number using
ril.ecclist).
When actually dialing "911" the call doesn't disconnect
even if there's no service. This means that the connection
manager never gets a chance to handle the call.
To fix this issue we're adding a timeout for emergency calls
if a connection manager is present. If after 25 seconds
the call is not yet active then we'll disconnect the call
and route it through the connection manager. The timeout
length is 60 seconds if the device is in airplane mode.
Both timeout values can be modified using config values.
To limit the impact of this change we've also added the
following extra condition:
- only use a connection manager if we have wifi
connectivity but no cellular connectivity
BUG: 19020123
Change-Id: Id2d740006cbf850db1cffb0d9f2aaca702ef1366
/packages/services/Telecomm/src/com/android/server/telecom/CreateConnectionProcessor.java
|
| 105d977687d1d0de7cd9420fc140b01404261df1 |
|
25-Nov-2014 |
Evan Charlton <evanc@google.com> |
Track (and use) UserHandle to make connections
When binding to services, use the UserHandle which registered the
PhoneAccount in order to ensure that the correct user receives the
Intent.
Also make sure that TelecomManager does not leak PhoneAccounts across
profiles, unless the caller is a system-privileged app. PhoneAccounts
will not leak across users, even for system-privileged apps.
Bug: 17421902
Bug: 17421044
Change-Id: I673904a7ae038c88688bba62642e93174e55c308
/packages/services/Telecomm/src/com/android/server/telecom/CreateConnectionProcessor.java
|
| 752cacbc0b88b9b4cb4ab7bd547e17b5d2690693 |
|
06-Nov-2014 |
Sailesh Nepal <sail@google.com> |
Continue processing calls that don't connect
If a call goes from DIALING to DISCONNECTED and there are
unprocessed phone accounts then we continue processing.
This fixes a problem where we didn't fallback to the
connection manager for emergency calls.
Bug: 16192560
Change-Id: Ic693a810e4a386f7fdb6f36700d95c8bbd325d0b
/packages/services/Telecomm/src/com/android/server/telecom/CreateConnectionProcessor.java
|
| 6f2c1ebb26b3e1837ac69dcc5394b365b32ea430 |
|
07-Nov-2014 |
mike dooley <mdooley@google.com> |
Merge "Checking that the connection service can be resolved when setting new connection manager." into lmp-mr1-dev
|
| 10a5831cf61b3ab3b126329044ea05dc3181fa63 |
|
06-Nov-2014 |
mike dooley <mdooley@google.com> |
Checking that the connection service can be resolved when setting
new connection manager.
This is to fix an edge case where downgrading could cause an invalid
connection manager to be set, resulting in all calls failing.
Also filtering out unresolveable phone accounts (which prevents the UI
from showing invalid choices).
Bug: 18225329
Change-Id: If46dea2937af42b81d3d7062c385f98370015cbe
/packages/services/Telecomm/src/com/android/server/telecom/CreateConnectionProcessor.java
|
| bafadce53332c7e0f7be0482cf04333c72487a70 |
|
06-Nov-2014 |
Sailesh Nepal <sail@google.com> |
Add connection manager fallback
With this CL we fallback to not using a connection manager in
two cases:
- if the connection manager disconnects a call with
CONNECTION_MANAGER_NOT_SUPPORTED
- or if the connection manager crashed while creating the connection
Bug: 16903083
Change-Id: I05822991c5c34ca3533652a10fbcb8845a604925
/packages/services/Telecomm/src/com/android/server/telecom/CreateConnectionProcessor.java
|
| c127211ffd269bffc8a393a3c5ebfe7bdd99896b |
|
16-Oct-2014 |
Yorke Lee <yorkelee@google.com> |
Always return at least the default emergency phone account
If Telephony hasn't registered any phone accounts yet, return a
default emergency phone account so that emergency calls can still be
made.
Bug: 18003823
Change-Id: I090abb170c9c7d718afd370a1d8c620decf4dbc3
/packages/services/Telecomm/src/com/android/server/telecom/CreateConnectionProcessor.java
|
| 9250e5fa9987c3ab80e11e1955657055f5866539 |
|
01-Oct-2014 |
Yorke Lee <yorkelee@google.com> |
Add ability to add sim-initiated MO call to UI (3/4)
Pipe an unknown call through CallsManager via various new APIs like
onSuccessfulUnknownCall, onFailedUnknownCall, etc. These are the unknown call's
equivalent of onSuccessfulOutgoingCall and onFailedOutgoingCall.
Only the TelephonyConnectionService is allowed to call this hidden new API
in Telecom.
Also add the ability for TestConnectionService to test this API (although the
check for TelephonyConnectionService must be disabled at build time first).
Bug: 16852844
Change-Id: I5dfdfc1bd4675f6b300a4a55a3098582f9d715a2
/packages/services/Telecomm/src/com/android/server/telecom/CreateConnectionProcessor.java
|
| f211ce79c1034315d454289ed233c11dd3aa4d0f |
|
27-Sep-2014 |
Jay Shrauner <shrauner@google.com> |
Fix NPE when disconnect cause wasn't set
Ensure DisconnectCause is set when fail to make a call.
Bug:17681453
Change-Id: I31466dd6c7d71cec5ee5c44789fd30bbef80017d
/packages/services/Telecomm/src/com/android/server/telecom/CreateConnectionProcessor.java
|
| 91d43cf9c985cc5a83795f256ef5c46ebb8fbdc1 |
|
17-Sep-2014 |
Tyler Gunn <tgunn@google.com> |
Preparatory work to move Telecom to system service.
- Removed use of TelecomApp.getInstance() as context.
- Refactored singleton logic and initialization to support being
performed from a SystemService.
- Note: You will see some commented out references to
"import com.android.internal.R"; these must uncommented when the code
is moved to a system service.
- You will also notice in PhoneAccountRegistrar.java a comment block with:
"UNCOMMENT_FOR_MOVE_TO_SYSTEM_SERVICE"
The code in that comment block will replace the existing file path
code.
These were added as a convenience so that I can run a simple sed script
to make the required changes to the code in an automated manner once it
is moved to its new location.
Bug: 17364651
Change-Id: I8e80e9cffc481b688c10a2bca0b59f5ccf8e0fb2
/packages/services/Telecomm/src/com/android/server/telecom/CreateConnectionProcessor.java
|
| 701dc006ac11625b55d872f1639107b028933895 |
|
12-Sep-2014 |
Andrew Lee <anwlee@google.com> |
Use telecomm DiconnectCause in services/Telecomm.
+ Some of this is straightforward replacing the old disconnect cause
code/message with the new DisconnectCause object.
+ Replace codes in some instances; most maps straightforwardly to the
newer generic set of disconnect causes.
+ InCallToneMonitor can no longer rely on the specific telephony
DisconnectCauses. Now, instead, they map from a tone (which is
specified on the new telecomm DisconnectCauses) to the type of tone
which should be played in InCall. Most of these are just taking
unique matches from InCallTonePlayer. It is a little redundant, as
the conversion just flips, but it seemed like the easiest way to
accomplish this given current constraints.
+ Behavior is unchanged, but now DisconnectCause.OUT_OF_SERVICE
will invoke InCallTonePlayer.TONE_CDMA_DROP.
+ Now play TONE_PROP_PROMPT regardless of whether there is precisely
one remaining call; this is because we can't distinguish between
telephony DisconnectCause.ERROR_UNSPECIFIED/NORMAL/LOCAL. I figured
this would be a relatively minor change in scenario, and it wouldn't
hurt for a tone to be played even in a disconnect in that scenario.
Bug: 17329632
Change-Id: I85767d424bcfd59b3929819c9c6de46fc4a8629e
/packages/services/Telecomm/src/com/android/server/telecom/CreateConnectionProcessor.java
|
| e3d8245f09c9d5333ebc7e2d82e684ecfeb6040e |
|
15-Sep-2014 |
Santos Cordon <santoscordon@google.com> |
Remove config variable to disable connection service APIs
Bug: 17445268
Change-Id: I152225ffdb81dafb9bd972d7294f05a8e6e0c746
/packages/services/Telecomm/src/com/android/server/telecom/CreateConnectionProcessor.java
|
| 7cc70b4f0ad1064a4a0dce6056ad82b205887160 |
|
13-Sep-2014 |
Tyler Gunn <tgunn@google.com> |
Renaming Telecomm to Telecom.
- Changing package from android.telecomm to android.telecom
- Changing package from com.android.telecomm to
com.android.server.telecomm.
- Renaming TelecommManager to TelecomManager.
Bug: 17364651
Change-Id: Ib7b20ba6348948afb391450b4eef8919261f3272
/packages/services/Telecomm/src/com/android/server/telecom/CreateConnectionProcessor.java
|