| 64513fe4ba55ed888bbd38b88e11511a276128a1 |
|
18-Mar-2013 |
Santos Cordon <santoscordon@google.com> |
Update callLog on a failed outgoing call.
Did some calllog code consolidation into new CallLogger class.
Used new class to provide functionality into CallController which is
responsible for placing the call and reacting to failed outgoing calls.
It's worth noting that the consolidation wasn't necessary for the bug
fix, but it's a good change nonetheless.
The merging of the two codepaths in CallNotifier is hard to trace, but
looking through the execution path, both inevitably did the same thing
except for one case: We didn't previously call stripSeparators for the
CdmaCallWaitingReject calls. It isn't necessary since we
would never find those separators coming from direct cdma calls. Having
that extra call now doesn't hurt since it is a no-op in that case. It
should be the only difference between the two (thus merging made sense).
bug:7614900
Change-Id: Iac50cba53f4312715c803c2f375baed697c678a4
/packages/apps/Phone/src/com/android/phone/CallController.java
|
| a1a9601840e50e18ff8ca4be9b888e592287577b |
|
11-Sep-2012 |
Dianne Hackborn <hackbod@google.com> |
Don't crash phone app when running as non-primary user.
Rename PhoneApp to PhoneGlobals. Add new PhoneApp that only
instantiates PhoneGlobals when running as the primary user. Add
check in PhoneGlobals.getInstance() to immediately throw if called
when there are no globals for that process. Add new
PhoneGlobals.getInstanceIfPrimary() that doesn't throw;
OtaStartupReceiver uses to abort early if receiving a BOOT_COMPLETED
for a non-primary user.
All of the other files here are just due to the rename of PhoneApp
to PhoneGlobals.
Change-Id: Ic3999d956198ac836cb6a07fa3c77f36c1754ea3
/packages/apps/Phone/src/com/android/phone/CallController.java
|
| 98e53a1f30285cfe855a5955107a24e78ac831ea |
|
07-Sep-2012 |
Santos Cordon <santoscordon@google.com> |
resolved conflicts for merge of 08336552 to jb-dev-plus-aosp
Change-Id: Iaca8c127b07e4c29ad93f05c7b17ee07b477e457
|
| 083365527c51806a5cc4d1966e46f3f32325deee |
|
05-Sep-2012 |
Santos Cordon <santoscordon@google.com> |
Adding contextual "Voice Mail" text to in-call dialpad.
Adds contextual "Voice Mail" text as the hint in the DMTF dialpad
editText.
bug: b/7110391
Change-Id: I85241dc7fa6768f68867fdb1237540233b8be01b
/packages/apps/Phone/src/com/android/phone/CallController.java
|
| b0f85b4a78abead921c363f9c8e247d5bdd20c74 |
|
14-Jun-2012 |
Wink Saville <wink@google.com> |
Use telephony-common
Change-Id: I1710418850040fc20afff4795ee4a85027203fc9
/packages/apps/Phone/src/com/android/phone/CallController.java
|
| f8a9fbe31969b4f97ea03d233684efc117888879 |
|
29-Mar-2012 |
Daisuke Miyakawa <dmiyakawa@google.com> |
Move TelephonyCapabilities from Phone to telephony
Must be after I0d4ca2f8e4d775004d146fe6f9c60165a94366a9 (framework)
- Use the class in framework and remove the original class.
- Add useShortDtmfTones() to PhoneUtils. It was originally in (old)
TelephonyCapabilities but it is more suitable to have it in the other
place.
- Remove now unused strings.
Bug: 6252254
Change-Id: Iee8964cd13f9a2fa9212b1655de0f49b04153ee5
/packages/apps/Phone/src/com/android/phone/CallController.java
|
| 71039bbfc875e579fd7f9aeb53784e89bedbcfc1 |
|
20-Mar-2012 |
Daisuke Miyakawa <dmiyakawa@google.com> |
Show dialpad when we're sure it is voicemail request
When the user requests to access voicemail service, most likely
she/he wants to open dialer immediately. This change forces
in-call screen to show dialer when voicemail Uri is specified.
Bug: 2089202
Change-Id: Ic15180ed4bb4e10faca3b40a968b30b76661ebb7
/packages/apps/Phone/src/com/android/phone/CallController.java
|
| b8e01d75f21087d55ba70e70f2b8ff1422b2406b |
|
31-Jan-2012 |
Daisuke Miyakawa <dmiyakawa@google.com> |
Integrate gateway provider info with call card
- Show provider information as part of CallCard, removing badge
layout.
- Use animation when displaying/hiding provider/call-state.
- Stop using the term "overlay" since it isn't an overlay anymore.
- Remove unnecessary resources. Modify comments.
TESTED:
- phone call without 3rd party provider (GSM, CDMA)
-- try twice with one device, checking animation *won't* during
DIALING.
- phone call with 3rd party provider (GSM, CDMA)
-- try twice with one device.
- try outgoing/incoming calls with BT headset
Bug: 5045539
Change-Id: Ic1677e256fd764a8dfafda1606fe50772117db84
/packages/apps/Phone/src/com/android/phone/CallController.java
|
| 8ba06a2f88a2fabdbcc7d8090b79837e2ed9b63b |
|
17-Jan-2012 |
Daisuke Miyakawa <dmiyakawa@google.com> |
Move getInitialNumber() to PhoneUtils
Tiny clean up which removes an old TODO
Change-Id: I444d8a8a2ef0e65ebf0be47a8ed261753bb7e4a7
/packages/apps/Phone/src/com/android/phone/CallController.java
|
| b1545c869ff7fa76ce3c3256b23e1b2b4411f483 |
|
30-Nov-2011 |
Daisuke Miyakawa <dmiyakawa@google.com> |
Resume previous call origin if it looks a second call
3rd party app can intercept outgoing call and replace it with
another call initiated by the app, which makes the Phone app
forget call origin. We keep the call origin for very short term
and restore the previous info assuming the second call has
a same origin for users' perspective.
TESTED (with and without 3rd party app bypassing calls):
incoming calls
-> go back to calllog
outgoing calls
- make a phone call from dialpad -> go back to dialpad
- make a phone call from favorite -> go back to favorite
- make a phone call from calllog -> go to calllog
- make a phone call from call detail -> go to calllog
- make a phone call from People UI -> go to calllog
- make a phone call from dialpad and launch Phone UI
again during the phone call -> go to dialpad
- make a phone call from contact card (reached via
phone favorite) -> go to calllog
- make a phone call from dialpad or favorite, bail out the
in-call UI. Have the recipient hang up the call.
Then have an incoming call again. Hang up the second
phone call.
-> go to calllog
- make a phone call from search UI launched from dialpad
-> go to dialpad
- make a phone call from search UI launched from favorite
-> go to favorite
- make a phone call from dialpad and finish the call. Immediately
call again via People UI (to check the cache won't be used)
-> go to calllog
Bug: 5528034
Change-Id: Ia872c1fe9f5d00300377899271e8872bc9d8b90f
/packages/apps/Phone/src/com/android/phone/CallController.java
|
| df2c68ff479d499b1b60a0f6ed24ab22f764cb9c |
|
09-Nov-2011 |
David Brown <dab@google.com> |
am a42348fc: Use isPotentialLocalEmergencyNumber() to enforce ACTION_CALL restriction
* commit 'a42348fcc3a76ab0db9b710ee40042a73a0b9dac':
Use isPotentialLocalEmergencyNumber() to enforce ACTION_CALL restriction
|
| a42348fcc3a76ab0db9b710ee40042a73a0b9dac |
|
07-Nov-2011 |
David Brown <dab@google.com> |
Use isPotentialLocalEmergencyNumber() to enforce ACTION_CALL restriction
The framework PhoneNumberUtils class now provides a way to distinguish
between (a) numbers that are definitely emergency numbers, and (b) numbers
that *might* result in an emergency call being dialed, but aren't
specifically emergency numbers themselves.
Given that, we now use the new isPotentialLocalEmergencyNumber() API when
enforcing the restriction that 3rd party apps should not be allowed to
make emergency calls using the ACTION_CALL intent. (This ensures that 3rd
party apps can't make emergency calls by passing in an "invalid" number
like "9111234" that isn't technically an emergency number but might still
result in an emergency call with some networks.)
Everywhere else in the app, though, we still use the original
isLocalEmergencyNumber() API, which now returns true only if the specified
number *exactly* matches a known emergency number. This ensures that the
in-call UI will only display the "emergency call" state for numbers that are
*definitely* emergency numbers. (See bug 5493790 for the full details.)
TESTED (on Prime-C):
- Call regular non-emergency numbers from the built-in dialer
==> calls succeed with no emergency-call specific behavior
- Call "911" from the built-in dialer
==> Call to 911 succeeds
==> In-call UI shows the "emergency call" state
==> We correctly disable "mute"
==> We correctly enter ECM
- Call "9111234567" from the built-in dialer
==> We allow the call to be placed
==> The call does not actually go through; you just hear a recorded
message from Verizon saying "the call could not be completed"
(although this behavior might be different on other networks)
==> The in-call UI does NOT show the "emergency call" state
==> We do not disable "mute"
==> We do not enter ECM
- use CallDialTest activity to fire off various ACTION_CALL intents
(as if launched from a 3rd party app):
"911" ==> doesn't allow the call to be placed (brings up dialer instead)
"9111234" ==> doesn't allow the call to be placed (brings up dialer instead)
"6502530000" ==> call succeeds
Note: This change depends on
Change-Id: Ic528cfcc555734cdaf4ca8a18a50199771ba49b1
in frameworks/base (which must be submitted first.)
Bug: 5493790
Change-Id: Ib949fea3c0ce6b341a90e617a03ba3f22c69018b
/packages/apps/Phone/src/com/android/phone/CallController.java
|
| 91c4c7ee183e3c65278465064c2b307aab93aa34 |
|
20-Oct-2011 |
David Brown <dab@google.com> |
Fix the "Exiting Emergency Callback Mode" dialog
If you make an outgoing non-emergency call while in ECM, we're supposed to
(a) cancel ECM, and (b) display a simple dialog saying "Exiting Emergency
Callback Mode" when the in-call UI comes up.
This change fixes part (b), which was broken. The problem was a bug in
the CallController: there's a "pending call status code" that tells the
InCallScreen to display the "Exiting ECM" dialog, we were setting it
correctly at the point we noticed we were in ECM, but we would then clear
it immediately as soon as the call succeeded :-(
This fix is for placeCallInternal() to explicitly return EXITED_ECM in
this case, rather than just plain SUCCESS.
TESTED:
- Regular phone calls => No change
- Exiting ECM => Dialog comes up correctly
- Other types of call failures => No change (we still display the
appropriate error dialogs).
Bug: 5487455
Change-Id: Ic5d521e5c95e8137067ca53b5876b35788768abc
/packages/apps/Phone/src/com/android/phone/CallController.java
|
| 57bb26f8da77cbdc13995f472a40df566599326c |
|
14-Oct-2011 |
David Brown <dab@google.com> |
Force in-call notification to be shown if "voice privacy" is active
Normally we suppress the in-call status bar notification if the
InCallScreen is the foreground activity. (The goal is to reduce clutter
in the status bar; that icon isn't needed since it's already obvious that
you're on a call.)
But we shouldn't do that if "Voice Privacy" mode is active, since the
status bar icon is the only indication we have for "voice privacy" mode.
So if voice privacy is in effect, force the status bar icon to be visible
regardless of whether the InCallScreen is active.
TESTED:
- NOTE I couldn't do a real end-to-end test because the "voice privacy"
feature isn't available at all on my device for some reason. So
instead, I tested this change by simply hacking getVoicePrivacyState()
to return true.
(1) Made a call with Voice Privacy "enabled":
==> Status bar icon showing phone with tiny lock symbol is visible
when I'm on the InCallScreen *and* when I bail out to some other app
(2) Made a call with Voice Privacy disabled:
==> Status bar icon is visible *only* after I bail out of the
InCallScreen. Also, the icon is just a plain phone, with no lock
symbol.
Bug: 5371658
Change-Id: I230bed89eae137d4cd106f3e44d7ad0105d6998c
/packages/apps/Phone/src/com/android/phone/CallController.java
|
| aa7a5e8ffbceca40991631e72fd94a0d9db357ea |
|
19-Sep-2011 |
David Brown <dab@google.com> |
Merge "Update code to use location aware isEmergencyNumber."
|
| 4158ed3e7bdff5212a5542e662240ea0063664b2 |
|
16-Sep-2011 |
David Brown <dab@google.com> |
Enable logging in the phone app for a few important telephony actions
Slightly turn up logging verbosity to help debug a few strange
telephony-related problems that have started happening recently, for
example bugs 5313580, 5313015, and 5331988.
TESTED: Verified the new log messages, made sure no PII is leaked.
Bug: 5313580 (and others)
Change-Id: I0a2957f7ea167e079cbb7bf231af11908c6803c6
/packages/apps/Phone/src/com/android/phone/CallController.java
|
| 1ca2b2b333a7c22b728d648d3592ee064762dd00 |
|
14-Sep-2011 |
Shaopeng Jia <shaopengjia@google.com> |
Update code to use location aware isEmergencyNumber.
Bug: 5247602
Change-Id: Ibce4b29f7062117c89071f23f39019deb3969b13
/packages/apps/Phone/src/com/android/phone/CallController.java
|
| a841177ae2676d3ad92f82f8d378bc4915f238c9 |
|
30-Aug-2011 |
David Brown <dab@google.com> |
Fix a bunch of STOPSHIP comments, mostly about PII logging.
TESTED:
- normal outgoing call sequence: confirmed no PII in logs
- normal incoming call sequence: no PII there either
- verified the ITelephony call() and dial() APIs still work, and don't
log any PII either. (Added new tests to the CallDialTest activity for
these.)
- confirmed no remaining STOPSHIPs anywhere under apps/Phone
Bug: 5231962
Change-Id: I995bc58791f553f1a4ad51276b4b31603b196635
/packages/apps/Phone/src/com/android/phone/CallController.java
|
| 3426afaf85d33d454fad8d341a1a895fd7e21c10 |
|
30-Jul-2011 |
David Brown <dab@google.com> |
Fix "emergency call from airplane mode" sequence
If you dial an emergency number while the device is in airplane mode, the
device needs to first take you *out* of airplane mode, and then (once the
radio is powered up) actually make the call.
In gingerbread we did this using an invisible activity called
EmergencyCallHandler, but that's a bad design for a few reasons:
- Visible display glitches during the activity transitions
- Potential bugs if you interfere with the activity lifecycle (e.g. by
pausing the EmergencyCallHandler by pressing Power at just the right
point.)
- The code is overly complicated.
Instead, it's cleaner to implement this sequence without using activities
at all. Here's the new design:
- The whole sequence is run by a helper class called EmergencyCallHelper
- If you try to dial 911 while in airplane mode, the CallController
notices this, lazily creates an EmergencyCallHelper instance, and
starts the sequence
- Then, the EmergencyCallHelper runs the next steps:
- power on the radio
- listen for the service state change when the radio comes up
- then launch the emergency call
- Retry if the call fails with an OUT_OF_SERVICE error
- Retry if we've gone 5 seconds without any response from the radio
- Finally, clean up when the emergency call disconnects successfully
There's also a corresponding update to the in-call UI: the InCallScreen
now knows how to put up a progress dialog (i.e. a "spinner") while we're
waiting for the radio to come on. That's controlled by a new
"progressIndication" field of the InCallUiState.
TESTED (with hacked telephony layer that doesn't actually dial 911):
- Call 911 in normal mode
- Call 911 in airplane mode
- After 911-from-airplane-mode sequence, double-check no wake locks still held
- Confirm no cosmetic glitches
Also tested some corner cases:
- Tested retry logic by using a temporary hack to deliberately ignore
the "service state changed" event
- Tested the "too many retries" case (using a temporary hack to make
all calls fail); confirmed that we give up after 6 tries and display
an error message
- Do the whole "911 from airplane mode" sequence twice in a row (to make
sure it works even if the EmergencyCallHelper object has already been
instantiated)
- Manually turn screen off in the middle of the sequence, confirm that
doesn't disrupt the call
Bug: 4195290
Bug: 4194458
Change-Id: I209768ffdc6b3d2bd4efd04474eed630284ec551
/packages/apps/Phone/src/com/android/phone/CallController.java
|
| 8ffe7a03a21441fa6d1f3c96a82c68f4ee8900dd |
|
27-Jul-2011 |
David Brown <dab@google.com> |
Fix outgoing calls for phone numbers with "keypad letters"
During the OutgoingCallBroadcaster sequence, we convert the phone number
from the CALL intent into an "actual number to dial" by stripping out
separators and converting keypad letters to digits.
Unfortunately, in change https://android-git.corp.google.com/g/112767 I
accidentally removed the code in CallController that *used* that string,
so we would just end up dialing the unsanitized number from the original
intent :-(
The fix is to have CallController.getInitialNumber() pay attention to that
value again. (It's passed as an extra, which I renamed to be
EXTRA_ACTUAL_NUMBER_TO_DIAL to be more clear. I also improved some
javadoc while I was in there, particularly startSipCallOptionHandler().)
TESTED: All the different kinds of outgoing calls:
- Raw number typed into the dialpad
- Normal PSTN number from contacts
- 1-800-FLOWERS from contacts
- SIP address
And also confirmed that 1-800-FLOWERS shows up correctly in the call log.
Bug: 5021243
Change-Id: I0b67f39e09b857e97f89852411a820ab049affb7
/packages/apps/Phone/src/com/android/phone/CallController.java
|
| 211ff4c5c95f63f845b953f0020dfb516c01fcad |
|
02-Jun-2011 |
David Brown <dab@google.com> |
Get interactive OTASP working again
Here's the next step of the CallController / InCallScreen redesign
(http://wiki/Main/InCallScreenRedesign). This change gets
"interactive OTASP" (i.e. CDMA activation on voice-capable devices)
working again.
The main change here is to initiate the outgoing OTASP call via the
CallController, *not* from the InCallScreen activity.
Background: In gingerbread and earlier releases, the InCallScreen
used to directly handle certain intent actions that could initiate
phone calls, mainly ACTION_CALL and ACTION_CALL_EMERGENCY, but also
OtaUtils.ACTION_PERFORM_CDMA_PROVISIONING.
But it was a bad design to tie those actions to the activity lifecycle
of the InCallScreen, and in change
https://android-git.corp.google.com/g/106821 I moved the phone app's
"call control" functionality out to a new class called CallController.
This change makes OTASP calls work the same way. Interactive OTASP
calls are now launched using the CallController, from the new
OtaUtils.startInteractiveOtasp() method. And the InCallScreen itself
is now purely a "view" class in MVC terms: we only ever launch it
using the ACTION_MAIN action, and (upon launch) it performs no
functionality other than displaying the UI in a state that matches the
current telephony state.
Other cleanup in this change:
- Got rid of the confusing use of the EXTRA_PHONE_NUMBER extra with
the ACTION_CALL intent (see CallController.getInitialNumber()).
Now, when we place a call from the OtaUtils code we simply load the
OTASP number into the *data* of the ACTION_CALL intent, which is
where it should have been all along.
- Cleaned up naming and/or doc comments in a bunch of places
- Have CdmaOtaStatusChange messages go only to the PhoneApp instance,
not to the InCallScreen some of the time. (Either way, they would
still ultimately get forwarded to the OtaUtils instance.)
Note there's still more cleanup to do:
- It's really ugly for the OtaUtils object to reach into the
InCallScreen and directly manipulate its widgets.
Instead, the model/view separation should be more clear: OtaUtils should
only know about a higher-level abstraction of the OTASP-specific UI
state (just like how the CallController uses the InCallUiState object),
and the InCallScreen itself should translate that higher-level
abstraction into actual onscreen views and widgets.
- The current state of the OTASP call is confusingly spread out among four
separate classes:
OtaUtils.CdmaOtaProvisionData
OtaUtils.CdmaOtaConfigData
OtaUtils.CdmaOtaScreenState
OtaUtils.CdmaOtaInCallScreenUiState
with at least some redundancy, especially between CdmaOtaScreenState and
CdmaOtaInCallScreenUiState (not to mention the "InCallScreenMode"
maintainted by the InCallUiState object.)
Instead, we should combine these into a single object (or container)
with zero redundancy and clear documentation, and possibly make it a
com.android.internal.util.StateMachine to make the state transitions
more clear too.
- When handling the ACTION_PERFORM_CDMA_PROVISIONING intent, we're
supposed to come up in the "activate" state where we display the
message "A special call needs to be made to activate your phone
service" and wait for the user to press the "Activate" button. But
right now we skip that state and launch the OTASP call immediately.
These open issues are all flagged with "TODO(OTASP)" comments.
TESTED on crespo-S:
- manually dial *228
==> interactive OTASP succeeds
- manually launch ACTION_PERFORM_CDMA_PROVISIONING intent
==> interactive OTASP succeeds
- regular incoming and outgoing calls
==> these work as before
Bug: 4194458
Change-Id: I40911c7774bd0f2e9c904f7e15defb753dbd5fab
/packages/apps/Phone/src/com/android/phone/CallController.java
|
| 75e3711d82d0c98444f6c438437cad41d862fca6 |
|
20-Apr-2011 |
David Brown <dab@google.com> |
Introduce CallController (Step 1 of InCallScreen redesign)
This is the first step toward pulling "call control" out of the
InCallScreen, and leaving the InCallScreen responsible for only the
onscreen in-call UI.
Design doc: http://wiki/Main/InCallScreenRedesign
The CallController is a singleton object which acts as the interface to
the telephony layer for all user-initiated telephony functionality, like
making outgoing calls.
In particular, any functionality which needs to happen whether or not
the InCallScreen is currently visible belongs in the CallController,
*not* the InCallScreen.
This change introduces the CallController class, and moves the entire
outgoing call sequence (basically placeCall() and its helper methods)
from the InCallScreen to the CallController.
Also, this change adds a helper class called InCallUiState, which keeps
track of some high-level state of the in-call UI that needs to persist
beyond a single pause/resume cycle of the InCallScreen.
This enables us to handle failed calls much more cleanly than before:
If there's a failure in the placeCall() sequence, the CallController
stashes away a failure code value in the "pending call status code"
field of the InCallUiState structure. Then, when the InCallScreen comes
up, if that field contains an error code we do some UI-specific action
(like displaying a dialog) depending on the code. See the "Error /
diagnostic indications" section of InCallUiState.java for the full
details.
Other details:
- Added a new class called "Constants", which currently contains the
CallStatusCode enum, but which I'll eventually use for other app-wide
constants too (for example the various EXTRA_* and intent action
constants that are currently all over the place.)
- Removed references to Intent.ACTION_ANSWER (which has never actually
been used for anything)
- Cleaned up confusing use of EXTRA_NEW_CALL_INTENT in
OutgoingCallBroadcaster (bug 3325827)
- Finally bit the bullet and added an mApp field to InCallScreen (so we
no longer need PhoneApp.getInstance() calls all over the place)
This change is just the first step of the InCallScreen/CallController
overhaul. Basic calling works fine with this change, but some other
stuff still needs to be fixed:
- OTASP-related behavior: (1) Handle the PERFORM_CDMA_PROVISIONING
intent in the CallController, not the InCallScreen; (2) move the
functions of InCallScreen.checkIsOtaCall() over to the CallController.
- Implement the "emergency call from airplane mode" sequence inside the
CallController (and get rid of the EmergencyCallHandler activity)
- plus various other loose ends covered by TODO comments.
TESTED: "Basic telephony functionality" on Crespo:
- outgoing calls
- incoming calls
- failed outgoing calls (airplane mode, no service, etc.)
- bail out and return to InCallScreen while in-call
- basic telephony states (two lines in use, hold/unhold, etc.)
Bug: 4194458
Bug: 3325827
Change-Id: I0523ef182a53fc7f252940d0b0e2804661dc9247
/packages/apps/Phone/src/com/android/phone/CallController.java
|