| 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/InCallScreenShowActivation.java
|
| 58e4707b6cc021a663deae3e614364545ec9ee6a |
|
17-May-2011 |
David Brown <dab@google.com> |
Fix ACTION_CALL_EMERGENCY code path through OutgoingCallBroadcaster
InCallScreen/CallController overhaul: One place in OutgoingCallBroadcaster
was still launching the InCallScreen with a CALL intent, which would crash
the phone app if you tried to dial 911 :-(
The fix is to use CallController.placeCall() instead.
TESTED (crespo):
- regular outgoing calls
- directly dial 911
- dial 911 via voice dialer
Also double-checked that nobody else is manually creating intents pointing
to InCallScreen.class, except for places that are already flagged with a
"TODO(InCallScreen redesign)" comment.
Bug: 4444071
Bug: 4194458
Change-Id: I518fbf71302564bfb31d1c821464961823f1ed8b
/packages/apps/Phone/src/com/android/phone/InCallScreenShowActivation.java
|
| 2e97fab35871f41a9a8d8099ccb664b17d92554c |
|
26-Oct-2010 |
David Brown <dab@google.com> |
Disable "ongoing call" notification on non-voice-capable devices
The "ongoing call" notification allows you to reach the in-call UI, so
totally disable it on non-voice-capable devices (even when the phone is
technically "in use" like during the OTASP call.)
Also some other related cleanup:
- Cache the config_voice_capable resource as a static PhoneApp field to
save a bunch of resource lookups. (This also minimizes the number of
places that know about that resource, in case we ever switch to using a
system feature instead of a resource.)
- Tracked down all other possible ways of bringing up the in-call screen:
- the ITelephony showCallScreen() API
- the internal displayCallScreen() method
and disabled those too on non-voice-capable devices.
Bug: 3121559
Change-Id: I13343233e8af7aef0846e3cacb429c6736902fd0
/packages/apps/Phone/src/com/android/phone/InCallScreenShowActivation.java
|
| 7d38129b67491544c5969dc784db478b13918b08 |
|
26-Oct-2010 |
David Brown <dab@google.com> |
Last bits of STOPSHIP cleanup
- Don't turn on speaker during non-interactive OTASP (which had no effect
on Stingray devices anyway)
- Disable the EXTRA_OVERRIDE_INTERACTIVE_MODE extra in user builds, also
reduce logging from InCallScreenShowActivation
- Confirmed no other STOPSHIP comments remaining in the phone app (either
in code or resources)
Bug: 3040809
Change-Id: I94b4ff78071b47ddf12fe153652693a3e2475c4b
/packages/apps/Phone/src/com/android/phone/InCallScreenShowActivation.java
|
| b5d698eb0a399d6f8c5c1b82f9b39903408e3cb8 |
|
18-Aug-2010 |
David Brown <dab@google.com> |
Update phone app to use new location of "config_voice_capable".
As of change https://android-git.corp.google.com/g/61765 , the "voice
capable" resource now comes from the framework. So update the phone code
to use the new location, and remove the (now unused) flag from our own
config.xml file.
Change-Id: I29dff61944f3761b8940047f456d1fc314cdb15c
/packages/apps/Phone/src/com/android/phone/InCallScreenShowActivation.java
|
| b154630235935e1aab2a41eff9ed794d40084a02 |
|
28-Jul-2010 |
David Brown <dab@google.com> |
Add "non-interactive" mode for the OTASP (CDMA provisioning) call.
Non-voice-capable devices (like Stingray) have no built-in phone UI, but
do still need to make a special phone call when first "activating" the
device.
Till now, the code handling the OTASP call (OtaUtils.java) was very
tightly coupled to the InCallScreen, using special modes of the in-call UI
to display the "skip" and "activate" choices, and display a DTMF dialpad
and Speaker button and progress info during the call.
This change decouples the OtaUtils and InCallScreen code, and allows the
OTASP call to run in "non-interactive" mode. Now, on data-only devices we
launch the OTASP call without involving the InCallScreen at all.
This change also cleans up the way we send results back to the
SetupWizard:
- First of all, in non-interactive mode, we now return an activity result
right away after kicking off the OTASP call. This lets our caller know
either that the OTASP call started (and is running in the background),
or that that we couldn't start the OTASP call at all.
- And as before, when the OTASP call ultimately finishes, we send back a
PendingIntent that was originally provided by our caller. But now, we
explicitly add an extra called EXTRA_OTASP_RESULT_CODE to that
PendingIntent. That extra's value is an integer code, which allows
the caller to distinguish among several possible outcomes, namely
"success", "failure", and "user skipped".
Finally, this change includes a test activity called OtaspTestActivity which
exercises the whole "non-interactive" OTASP sequence (which basically
mimics the PERFORM_CDMA_PROVISIONING behavior of SetupWizard.)
More details:
- When we handle the PERFORM_CDMA_PROVISIONING intent (see
InCallScreenShowActivation.java) we check a config resource called
R.bool.voice_capable to decide whether to use the in-call UI. (That
resource is true by default, but overridden to false on Stingray.)
- The singleton OtaUtils instance is now owned by the PhoneApp, not the
InCallScreen, since we can now have an OtaUtils instance *without* an
InCallScreen.
- I renamed the "com.android.phone.InCallScreen.SHOW_ACTIVATION" intent
action to be "com.android.phone.PERFORM_CDMA_PROVISIONING", to be more
precise, and especially to make it clear that it's not tied to the
InCallScreen.
- Moved all OTASP-releated string constants into OtaUtils (rather than
having them sprinkled around in 3 or 4 places.)
Bug: 2837917
Change-Id: Ifa82591478ccb2ec9501163963944d0d0659b9ea
/packages/apps/Phone/src/com/android/phone/InCallScreenShowActivation.java
|
| 13660626500d047d4a3a097e832bb175e1c4f894 |
|
10-Mar-2010 |
Freeman Ng <tenorslowworm@google.com> |
Change "Back" button on first OTA provisioning screen to "Skip", and pop up confirmation dialog on Skip offering choice to go ahead and skip, or activate after all.
patch set 5: receive, stow away, and send back a pending intent when the user skips provisioning
patch set 7: changed where pending intent is stored; readability changes
Bug: 2086893
Change-Id: I4d4d00fca98ef44d36afaee0b8536eb4dad83431
/packages/apps/Phone/src/com/android/phone/InCallScreenShowActivation.java
|
| 4a5a966f0d43e04d336be1b94182346399a931f6 |
|
22-Oct-2009 |
Wink Saville <wink@google.com> |
Fix bug 2189519.
The speaker mode is disabled sometimes after OTASP.
Sometimes if an OTASP has occurred speaker mode will be set
to false when InCallScreen.onResume is called. This can happen
when the screen is turned off by the screen timeout or pressing
the power button. The bug is that initOtaState calls cleanOtaScreen
which calls setSpeaker(false) disabling speaker mode.
To reproduce:
1) Complete the OTASP sequence using *228
2) Make a call using Phone application
3) Press Speaker to enable speaker mode
4) Press power button to turn off screen
5) Press power button to turn on screen
6) Speaker mode will be disabled
Two fixes were tired, one was to remove the call to
cleanOtaScreen in initOtaState thus speaker mode will
not be reset. This was recently added as some defensive
programming in case there was a code path that cleanOtaScreen
was not called when completing an OTASP call and is
not strictly necessary.
In normal operation where an OTASP has not been done
or onCreate has been called otaUtils member variable
will be null and thus this change has no effect under
most useage cases.
The second solution was to change cleanOtaScreen to have
a disableSpeaker parameter. It was decided to use this
solution as it was a less risky change.
Return to activation when VKEY back is pressed.
The routine finish() is called when the VKEY back is
and it was a mistake to call setInCallScreenMode(UNDEFINED)
here as the Activity is not really finished. So a new
new routine, endInCallScreenSession has been created which is
called from internal routines and finished just moveTaskToBack
as it was before change Ic70cff84.
To reproduce:
1) Begin an OTASP call via *228
2) While the call is offhook and not complete press VKEY Back
3) Pull down the notification screen and select "Current call (xx:yy)"
Instead of going back to the activation InCallScreen you see a
regular in call screen, with this fix you are returned back
to the Activation screen
Removed activity-alias InCallScreenOtaActivation and added
InCallScreenShowActivation as a separate activity instead
of an alias.
An alias causes multiple instances of InCallScreen to be created.
To reproduce:
1) Factory Data Reset via Settings > Privacy
2) After booting
3) Press the Android
4) Press the Activate button <<< InCallScreen.onCreate is called
5) Press the VKEY back (not back button)
6) Press the Android
7) Press the Activate button <<< InCallScreen.onCreate is called
8) Press "1" on dial pad and complete setup wizard
9) Run Phone application from home screen
10) Dial *22899 <<< InCallScreen.onCreate is called
11) Press Next when complete
The solution was to use a new Activity InCallScreenShowActivation
and not an alias. This new trivial activity, with just an onCreate,
validates that the Intent is SHOW_ACTIVATION and then forwards
that Intent to InCallScreen. A second option was also tried which
was to export InCallScreen directly by adding the permission and
and the intent filter from the alias to InCallScreen. This worked
but it was felt the first option was better as it more clearly
shows that only the SHOW_ACTIVATION intent is exported.
Bug: 2189519
Change-Id: Ib20d326d7433c7baf951bd26f6f36fdb649d172e
/packages/apps/Phone/src/com/android/phone/InCallScreenShowActivation.java
|