| 0e1e72e1338d483c09ab9af1fb3704ae58190d9a |
|
07-Oct-2012 |
Robert Greenwalt <rgreenwalt@google.com> |
Handle exception if nobody handles ACTIVITATION
bug:6900121
Change-Id: I8d01bfb748187dbdabbdeb9ce769536acf37986e
/packages/apps/Phone/src/com/android/phone/OtaUtils.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/OtaUtils.java
|
| 7fa5266a69d52606144302c0a3a92645ab64b095 |
|
08-Sep-2012 |
Dianne Hackborn <hackbod@google.com> |
Explicitly specify current user everywhere home is started.
Change-Id: I2eb9f6b62a7d650e851e37249edefd43c0d5fc80
/packages/apps/Phone/src/com/android/phone/OtaUtils.java
|
| b0f85b4a78abead921c363f9c8e247d5bdd20c74 |
|
14-Jun-2012 |
Wink Saville <wink@google.com> |
Use telephony-common
Change-Id: I1710418850040fc20afff4795ee4a85027203fc9
/packages/apps/Phone/src/com/android/phone/OtaUtils.java
|
| c49d1c9004f3151d1cc5f31d6fc617bfc9603267 |
|
30-Apr-2012 |
Daisuke Miyakawa <dmiyakawa@google.com> |
Suppress debug logs
Because of remaining issues to be fixed, some are still remained.
Bug: 6201805
Change-Id: Ic5d9deb3775c59bbfb63f353fcebb5c24a18c7a3
/packages/apps/Phone/src/com/android/phone/OtaUtils.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/OtaUtils.java
|
| 0d5fc92288847d393d3237503da362c8beb77194 |
|
24-Feb-2012 |
Daisuke Miyakawa <dmiyakawa@google.com> |
Remove unnecessary View objects from in-call screen
- Remove an apparently redundant RelativeLayout.
- Make CallCard itself a LinearLayout, instead of making it
FrameLayout containing one LinearLayout.
- Make similar hack to InCallTocuhUi. This time instead of just
using RelativeLayout it holds, we use FrameLayout because it can
do same functionality with less layouting cost.
TESTED:
- make a phone call
- receive a phone call
- do multiple calls at once (with GSM, CDMA)
- try a conference call
Bug: 1271870
Change-Id: I71b66dbdbcc70be0b4dfbd3d3f0cf6d122c85847
/packages/apps/Phone/src/com/android/phone/OtaUtils.java
|
| 89f361ae8e283592dc84f62af428eef24bb83177 |
|
08-Feb-2012 |
Daisuke Miyakawa <dmiyakawa@google.com> |
Allow PERFORM_CDMA_PROVISIONING without a pending intent
This is all about documentation. The code already accepts null
for the PendintIntent, while comments imply it as an erroneous
situation.
Bug: 5966988
Change-Id: I5f5ab7a8a69eaa13137be25e499a711dadbf2e7b
/packages/apps/Phone/src/com/android/phone/OtaUtils.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/OtaUtils.java
|
| d0c1beb9de9365f386becd7324e4e272152bd010 |
|
18-Nov-2011 |
Meng Hu <meng.hu@sta.samsung.com> |
Make sure isOtaCallCommitted flag is updated
Always update isOtaCallCommitted flag on receiving CDMA_OTA_PROVISION_STATUS_COMMITTED.
Tablet devices don't use onscreen OTASP UI, so not updating the flag when
mApplication.cdmaOtaScreenState.otaScreenState is OTA_STATUS_UNDEFINED causes some issue.
Change-Id: I975d079f080521d8f1d3fd7812fd4ffb2c985a67
/packages/apps/Phone/src/com/android/phone/OtaUtils.java
|
| 9bb1e9b46be44d45367e8c9a99fcb2edb0546c54 |
|
11-Nov-2011 |
David Brown <dab@google.com> |
Fix potential crash when launching OTASP in response to BOOT_COMPLETED
When calling OtaUtils.maybeDoOtaCall() from the BOOT_COMPLETED receiver in
OtaStartupReceiver.java, we're running in the PhoneApp's context, not an
Activity context. So if we do actually need to launch an OTASP call(*), the
FLAG_ACTIVITY_NEW_TASK flag is required.
(*) This issue first came up in the context of bug 5528222, although the
real problem in *that* bug was that we shouldn't have been launching
old-style OTASP at all on LTE devices. But the fix here is still
needed, for CDMA devices that do still use old-style OTASP.
TESTED:
(1) On Prime-C, temporarily hacked OtaUtils.maybeDoOtaCall() to force an
old-style OTASP call upon boot.
==> Before this change: the startActivity() call crashes (as reported in
bug 5528222)
==> After this change: old-style activation UI comes up correctly, and
OTASP call starts when you press "Activate".
(2) Also confirmed that I didn't break the PERFORM_CDMA_PROVISIONING intent,
by running
adb shell am start -a com.android.phone.PERFORM_CDMA_PROVISIONING
(which is the only other way to launch the old-style OTASP sequence.)
That works fine both with and without this change.
Bug: 5528222
Change-Id: I89055c7b40a3e261aff3657a8ec052477462171e
/packages/apps/Phone/src/com/android/phone/OtaUtils.java
|
| a173cc986b1ca7d4dbb18263ed37d85c189d6cb7 |
|
23-Sep-2011 |
Meng Hu <meng.hu@sta.samsung.com> |
Only update OTA progress if OTA call in valid state.
1. Sometimes an OTA status event is received after user clicks BACK
button to end the OTA activation. The "Try Again" screen displays
briefly, then the "Programming In Progress" screen shows up upon
receiving the OTA status event, and it will never go away because
the OTA call has already ended.
To correct this, we only update OTA progress when the OTA call is
in normal state.
2. After activation, if the user goes on to do a different OTA call,
e.g. PRL update, "Phone is activated" screen shows up after PRL update
succeeds. After receiving CDMA_OTA_PROVISION_STATUS_COMMITTED, we
check otaScreenState before showing success screen.
bug:5584633
Change-Id: Ibcaceb958483a8e7a50e9c41442e023974958bbb
/packages/apps/Phone/src/com/android/phone/OtaUtils.java
|
| a57dd655ab3959f0985567393e17f69d138cfeb7 |
|
05-Nov-2011 |
Freeman Ng <tenorslowworm@google.com> |
add check for LTE state to maybeDoOtaCall()
whether a device is LTE affects which activation activity is launched
also renamed the unrelated static variable mIsWizardMode to sIsWizardMode
in order to have it correctly follow variable naming conventions
bug: 5528222 Unable to start receiver com.android.phone.OtaStartupReceiver after shell stop/start
Change-Id: I29e9b3f1cbee6be808259cb8be7f8d904b005a0d
/packages/apps/Phone/src/com/android/phone/OtaUtils.java
|
| eef9637aa8fd5463ca3f29e36953499f9f1468a2 |
|
27-Sep-2011 |
David Brown <dab@google.com> |
OTASP: Fix problems with how we handle the PERFORM_CDMA_PROVISIONING intent
When the SetupWizard notices that the device needs CDMA activation, it
fires off a PERFORM_CDMA_PROVISIONING intent.
Prior to this change, we handled that intent by simply launching a
call to "*228", which had two problems:
(1) We're not supposed to launch the call right away; we're actually
supposed to let the user press the "Activate" button first
(2) Once the call would start, the onscreen OTASP UI would be in the
wrong state: the DTMF dialpad would be hidden, even though the
activation process needs you to press "1" :-(
Now, we handle the PERFORM_CDMA_PROVISIONING intent by simply bringing
up the InCallScreen in the "activation" state. Then, when the user
presses the "Activate" button we'll actually launch the call.
TESTED: by manually firing off a PERFORM_CDMA_PROVISIONING intent:
adb shell am start -a com.android.phone.PERFORM_CDMA_PROVISIONING
Result:
- The "Activate your phone" screen came up correctly
- When I pressed "Activate", it successfully launched the OTASP call
- Once the call started, the DTMF dialpad *was* displayed correctly, and I
was able to press "1" to activate my device.
(The activation ultimately failed, though, since my device was already
activated.)
Bug: 5092031
Change-Id: If3166139ea162dca2ff6d4dae52345bcd4414faa
/packages/apps/Phone/src/com/android/phone/OtaUtils.java
|
| ed6c435b8ce38a269982385071b720cc98819239 |
|
21-Sep-2011 |
David Brown <dab@google.com> |
Fix bogus "End" button visible during the OTASP call
Since the OTASP-specific UI elements are no longer totally opaque,
there were some cases where the *regular* in-call UI elements (like
most of the "End" button") were visible during the activation call.
The fix is to explicitly hide the InCallTouchUi widget during OTASP
calls, just like we already do with the InCallPanel. (The InCallPanel
contains the contact photo and call banner, and the InCallTouchUi
widget contains the End button and dialpad/mute/speaker/etc.)
Also added a TODO with a bit more info about the "DTMF dialpad not
visible" issue, which is a separate problem also covered by bug
5092031.
TESTED:
(1) Boot device
(2) Make a regular call, then hang up
(3) Force an OTASP call by calling "*22899"
==> Before this change: "End" button would be visible behind the OTASP UI
elements.
==> After this change: "End" button is hidden; only the OTASP UI is
visible.
Also tested:
(1) Boot device
(2) Make an OTASP call (which fails since my device is already activated)
(3) Then make a regular outgoing call, or get an incoming call and
answer it.
==> Note that "End" button (and the other in-call touch controls)
*are* correctly displayed.
Bug: 5092031
Change-Id: I24549843f4858b496cb66ffefd975212b741b3c0
/packages/apps/Phone/src/com/android/phone/OtaUtils.java
|
| d23dc59768909d8e18b42c908764c7d340935796 |
|
01-Sep-2011 |
David Brown <dab@google.com> |
Fix Activate / Skip buttons in otaSkipConfirmationDialog
3 changes:
- Right-hand button label: "Skip" is renamed to "OK".
- Left-hand button label: "Activate" is renamed to "Cancel".
- Left-hand button behavior: just dismiss the dialog; don't actually start
an activation call
TESTED:
- "OK" choice
==> exits the OTASP UI completely
- "Cancel" choice
==> just dismisses the dialog, leaving you on the activation screen
- Tap outside the dialog
==> same behavior as "Cancel"
Bug: 5188435
Change-Id: Ifb4131719c062a087f42ac3d5b4e011d82c5adba
/packages/apps/Phone/src/com/android/phone/OtaUtils.java
|
| 7c8cb32060a685b2f20c1e0cf181fc392be840e0 |
|
06-May-2011 |
David Brown <dab@google.com> |
Misc OTASP cleanup
Some minor OTASP-related code and resource cleanup that I did while
tracking down bug 5092031:
- Cleaned up the useless "mDialer" field in OtaUtils.java. The OtaUtils
instance already has its own DTMFTwelveKeyDialer, so the one from the
InCallScreen is totally irrelevant.
- Removed a couple of useless ScrollViews in otacall_card
- Added android:id attributes to a bunch of view elements (for easier
debugging in hierarchyviewer), also renamed a couple of elements to be
more clear
- Fixed flood of updateScreen() calls while the OTASP UI is active.
(The various otaShow*() methods should *not* call requestUpdateScreen(),
since they themselves are part of the updateScreen() sequence!)
- Improved documentation in a bunch of places
TESTED:
- OTASP call on Crespo-S (succeeded)
- Also ran an OTASP call with the OtaShowListeningScreen resource
temporarly enabled, to simulate an OTASP call for the other carrier.
Confirmed that the DTMF keyboard showed up correctly and allowed you to
press "1".
Bug: 5092031
Change-Id: I86b6b80a340606aba6f4a3d4292193c027486913
/packages/apps/Phone/src/com/android/phone/OtaUtils.java
|
| 4ba332e62c4d54b2623ccdc59fafd46ecba08cf0 |
|
20-Jul-2011 |
David Brown <dab@google.com> |
Clean up dead code that originally supported non-prox-sensor devices
In previous Android releases, the in-call UI provided special support for
devices with no proximity sensor. The main differences were:
- The entire in-call UI had to be driven by hard buttons rather than
onscreen touchable UI
- All in-call controls that didn't have dedicated hard buttons were
menu-based rather than touchscreen-based
- The DTMF dialpad was contained in a "SlidingDrawer" widget that you
had to drag up from the bottom of the screen
- A special "touch lock overlay" would come up after 6 seconds and cover
the DTMF dialpad to avoid false touches
The code to implement this behavior has been unused (and untested) since
the froyo release: Google hasn't built software for any non-prox-sensor
devices since the G1 and myTouch, and any OEMs shipping non-prox-sensor
devices are probably using a completely custom in-call UI anyway (or
perhaps a customized version of the Cupcake-era phone app.)
Given that, it's not worth the extra complexity and clutter to keep these
features in the code base. So this change removes all code and resources
in the phone app that were only there to support non-prox-sensor devices.
The gory details:
- Entirely remove all Menu-related code from the in-call UI:
- The classes InCallMenu, InCallMenuView, and InCallMenuItemView
- Menu item handling in InCallScreen.onClick()
- Special handling of the Menu key itself
- Remove all code and resources for the "SlidingDrawer" that was used to
access the DTMF dialpad
- Remove all code / resources / animations for the "touch lock" overlay
- Rename non_drawer_dialpad.xml to dtmf_twelve_key_dialer_view.xml to be
less confusing (since we don't use a "drawer" anywhere any more)
- Remove the onscreen hint that said "Press Menu for call options" in a
couple of states
- Simplify the layout in call_card.xml: we don't need that top-level
RelativeLayout any more since the "menu hint" is gone
- Remove the config resources that allowed you to disable the normal
onscreen touch UI
- Remove a bunch of no-longer-needed string resources and ids
TESTED:
- Basic phone states (incoming / outgoing; 1 or 2 lines in use;
conference calls)
- Onscreen DTMF dialpad
- In-call screen prox sensor behavior
- In-call screen timeout
- Press Menu button (verify nothing happens)
Change-Id: I6ad5fd6df9bdef89e4defc7add7ade52d30d6335
/packages/apps/Phone/src/com/android/phone/OtaUtils.java
|
| 65454c803eb305c4740885ad4995a871b034a58a |
|
22-Jun-2011 |
David Brown <dab@google.com> |
Use constants for URI schemes
Use SCHEME_* constants instead of hardcoding
"tel" / "sip" / "sms" / etc. everywhere.
Change-Id: I1858384909a54ae86a27a5f557a80ee185873927
/packages/apps/Phone/src/com/android/phone/OtaUtils.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/OtaUtils.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/OtaUtils.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/OtaUtils.java
|
| 777b22c936d2bfa8140427402906a140d17180dc |
|
04-Feb-2011 |
Freeman Ng <tenorslowworm@google.com> |
don't launch activation on bootup when running in test harness
bug: 3414485
Change-Id: I9473904ee38d9dedec86cf7208c9ef3c405d2b0b
/packages/apps/Phone/src/com/android/phone/OtaUtils.java
|
| c3098c14cb1c0444d61ba1b6d0b81175e93bbd75 |
|
27-Jan-2011 |
David Brown <dab@google.com> |
Clean up remaining STOPSHIPs in apps/Phone
- InCallScreen now logs a wtf (rather than crashing) if we somehow launch
it on a non-voice-capable device
- Removed STOPSHIP comments in OtaUtils and OtaStartupReceiver, but I'm
still leaving verbose logging enabled at the request of the telephony
team (because we're still seeing OTASP issues in the field and need all
the debugging info we can get.)
Bug: 3396883
Change-Id: I0e2a99d59698c71721fa29d0b8a3bf1cc58bcd6d
/packages/apps/Phone/src/com/android/phone/OtaUtils.java
|
| 0c38cb459cd32bbe1db923fa77fa9f4671f7edfa |
|
18-Jan-2011 |
Freeman Ng <tenorslowworm@google.com> |
turn on option to allow user to ask not to see activation activity any more from bootup
bug: 3354214
Change-Id: I65ef741a7d7153df4a608237f10b49157db6ba06
/packages/apps/Phone/src/com/android/phone/OtaUtils.java
|
| 3e651fd2b8bc3b43ad2af296e6c720363a3af900 |
|
12-Jan-2011 |
Wink Saville <wink@google.com> |
Enable/add debugging to OtaUtils and OtaStartupReceiver.
There have been times when we OTASP is needed but it is not automatically
detected. Enable and add debugging so that if it happens we have more
information available for diagnosing the problem.
Bug: 3339109
Change-Id: Ic9a465735d49405395768df9d38d513b508055ac
/packages/apps/Phone/src/com/android/phone/OtaUtils.java
|
| 62995702f659b906127351596305906ccd0d7cb5 |
|
01-Dec-2010 |
Freeman Ng <tenorslowworm@google.com> |
handle SPC retry failure for tablet by returning new code
bug: 3201638
Change-Id: I84c18af64672a90b7ae4f2a98ad3d682a7f893c1
/packages/apps/Phone/src/com/android/phone/OtaUtils.java
|
| d5251aa62c211ab6f7b66c877d862131d709bccb |
|
23-Nov-2010 |
Freeman Ng <tenorslowworm@google.com> |
Revert "remove autolaunch of activation when booting up non voice capable device"
This reverts commit 18eb57a6255360a9b83cdf0db429bc0afc25a6ee.
/packages/apps/Phone/src/com/android/phone/OtaUtils.java
|
| 18eb57a6255360a9b83cdf0db429bc0afc25a6ee |
|
12-Nov-2010 |
Freeman Ng <tenorslowworm@google.com> |
remove autolaunch of activation when booting up non voice capable device
Change-Id: I338ba7597e1f16d8f80f2284fb4293a5cd02fac9
/packages/apps/Phone/src/com/android/phone/OtaUtils.java
|
| 6c5cf46a2a31f0bffe9df36da8922971f7ee296b |
|
27-Oct-2010 |
David Brown <dab@google.com> |
Handle CALL intent gracefully on non-voice-capable devices
The exact details:
- For tel: URIs, just demote the CALL to a DIAL and relaunch it. That
hands it over to the Contacts app, which will bring up a UI letting you
do something useful with the phone number (like "Add to contacts" if it
isn't a contact yet.) See https://android-git.corp.google.com/g/76050
for the Contacts change.
- For anything other than a tel: URI, since the Contacts app can't do
anything useful with those (yet) we just display a generic "Voice
calling not supported" dialog (using basically the same wording as the
dialog that currently comes up if you try making a SIP call on a device
that doesn't support SIP.)
- The above applies only to the CALL intent. The other call-related
intents (CALL_PRIVILEGED and CALL_EMERGENCY) are only used internally by
built-in apps, so they should never get used in the first place on a
non-voice-capable device. So if we *do* ever see these, we log a
warning and show the generic dialog.
- Removed the "@android:style/Theme.NoDisplay" them from
OutgoingCallBroadcaster so that the new dialog will get the correct
system-wide default theme. This was irrelevant all along since
OutgoingCallBroadcaster never brought up any UI anyway.
- Finally, since there should now be no way to ever reach the InCallScreen
on non-voice-capable devices, throw an exception if that ever happens
(to make sure we notice.) There's a STOPSHIP comment to turn that into
just a warning before we ship.
TESTED on Stingray:
- Confirmed CALL and DIAL behavior using the CallDialTest activity from
change https://android-git.corp.google.com/g/75710 :
(1) tel: intent
==> CALL and DIAL both bring up the dialog from the
Contacts app with the options "Add to contacts" and "Close".
(2) sip: intent:
==> CALL brings up a generic "Voice calling not supported"
dialog from the phone app. DIAL throws an
ActivityNotFoundException just like on regular phones (since
the dialer has never handled sip: URIs.)
(3) blank intent (with no data)
==> CALL throws ActivityNotFoundException. DIAL is absorbed by
the contacts app but does nothing (since "bring up an empty
dialer" is meaningless on a non-voice-capable device.
- Also confirmed correct behavior of the generic "Voice calling not
supported" dialog:
- tap OK button
- tap outside the dialog
- press BACK
- press HOME
All of these successfully dismiss the dialog.
- Also tested a bunch of scenarios on Stingray to confirm that we don't ever
try to create the InCallScreen:
- regular boot
- manually killing and restarting the phone app
- after a CALL intent
- during an OTASP call
Bug: 3116625
Change-Id: I10d490c89e881572efb3e39b50c7b47338a7b5f5
/packages/apps/Phone/src/com/android/phone/OtaUtils.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/OtaUtils.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/OtaUtils.java
|
| d92cf8295af01ac7c72486e95b6c52376df601fa |
|
14-Oct-2010 |
Freeman Ng <tenorslowworm@google.com> |
launch non-voice activation if necessary upon bootup
bug: 3028862
Change-Id: I9b7054076c15b4751f3d5bcae88fd70ac7b6da7f
/packages/apps/Phone/src/com/android/phone/OtaUtils.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/OtaUtils.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/OtaUtils.java
|
| 9afe1de771110096822a2501d78135575101421d |
|
14-Aug-2010 |
John Wang <johnwang@google.com> |
resolved conflicts for merge of 17509be3 to master
Change-Id: Ie52e3bfd5f127788840b11e56ba5fe9dd5b97cf0
|
| 8343169cc89621d46dce86449f5ee1ff5d3a4919 |
|
11-Aug-2010 |
John Wang <johnwang@google.com> |
Enable CallManager to handle SIP call.
Using CallManager to handle SIP call
1. Register SIP phone in SipBroadcastReceiver
2. Answer SIP incoming call
3. Reject SIP incoming call
4. Make SIP outgoing call
5. hangup SIP outgoing call
6. Add SIP call while there is foreground call
7. Answer SIP call while there is foreground call
8. Swap SIP call and background call
Change-Id: I2fc1f88e0fc100da45eb497469d69c784f44d06a
/packages/apps/Phone/src/com/android/phone/OtaUtils.java
|
| f0d315541b1b1f33fab5e7952471da6e886b53ef |
|
26-May-2010 |
Wink Saville <wink@google.com> |
Removed unnecessary code needsActivation and used needsOtaServiceProvisioning.
Change-Id: Icc144dd05fa2e1c389f00f303c8918c2af848cac
/packages/apps/Phone/src/com/android/phone/OtaUtils.java
|
| d3a8a3a138614071a7a8020e1579048c411abd78 |
|
21-May-2010 |
Wink Saville <wink@google.com> |
Cleanup OTASP use in OtaStartupReceiver.
Make isCdmaPhone private in OtaUtils.
Rename TelephonyCapabilities.supportsOTAProvisioning to
supportsOtasp.
Add PhoneApp.getPhone().
Change-Id: I2406864a7c4ce2e3f56d97d6dd678df2c22160cf
/packages/apps/Phone/src/com/android/phone/OtaUtils.java
|
| 9e9d66682248d0d9d0514b906f4c0a5ee7b9f7d3 |
|
11-Mar-2010 |
Jim Miller <jaggies@google.com> |
Fix 2410688: Put OTA listen text into a scrollview just in case the text is too large to fit.
Change-Id: I2efdd7a507cb72ac925b6d3011b65be2d285c98b
/packages/apps/Phone/src/com/android/phone/OtaUtils.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/OtaUtils.java
|
| 2f22a9001166458ef4b04f6142b6d6a480af1c9d |
|
18-Feb-2010 |
David Brown <dab@google.com> |
Fix 2432289: passion#c: no DTMF feedback during activation
Local playback of DTMF tones would work fine during a normal call, but not
during the OTA call. This was because the OtaUtils class was creating its
own "DTMFTwelveKeyDialer" instance, but never properly initializing it.
This bug has always been there, but we never noticed this on Sholes,
because local DTMF tones are played automatically by the Sholes radio.
(So on Sholes that DTMFTwelveKeyDialer instance didn't actually *need* to
make any sound.)
The fix is to correctly initialize the DTMFTwelveKeyDialer instance that
we create: we call startDialerSession() on it from initOtaInCallScreen(),
and call stopDialerSession() from cleanOtaScreen().
It's still pretty confusing how we have two separate DTMFTwelveKeyDialer
instances around, but we're very close to eclair code freeze so I'm
keeping this change as minimally invasive as possibile. (I added a TODO
comment about eventually cleaning this up, though.)
Tested: On PassionC, local tones are now audible during the OTA call.
(They're pretty faint unless you turn the speaker on, but I think that's
normal, or possibly due to bug 2447744.)
Bug: 2432289
DrNo: hiroshi
/packages/apps/Phone/src/com/android/phone/OtaUtils.java
|
| 65336771f727928a14d1d8fe175390ef7a06f71d |
|
31-Jan-2010 |
Wink Saville <wink@google.com> |
Ignore unknown CDMA_OTA_PROVISION_STATUS values.
Some rils are returning unknown values, completely ignore them.
bug: 2389875
Change-Id: I973081a95d2999df8eb189ebd14ae1d0781b11ad
/packages/apps/Phone/src/com/android/phone/OtaUtils.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/OtaUtils.java
|
| 5c0517ae3c17505ffd466be79ab0026b7fe6c959 |
|
12-Oct-2009 |
Wink Saville <wink@google.com> |
Ensure InCallScreen OTASP state is cleaned up when completing.
To reproduce 2165731:
1) Power up Phone A
2) Place *22899 call and activate Phone A
3) Press the power key on Phone A to turn off the display
4) Call Phone A from Phone B answering Phone A
5) The screen will be blank (Should be normal InCallScreen)
6) Hang up the Phone B
7) Phone A displays the activation screen.
Step 3 is the critical step to cause the onResume, onPause
onNewIntent, onResume sequence. If step 3 is skipped the
sequence will be onNewIntent, onResume and all will be well.
I did not find a consistent way to reproduce 2170100 where
but have not seen the bug reproduced with these changes.
Bug: 2165731
Bug: 2170100
Change-Id: Ic70cff8409deff7c38d9040306f2e1b91e04f25a
/packages/apps/Phone/src/com/android/phone/OtaUtils.java
|
| f6eb7893215a875863e1e0200e4aa3174137f76c |
|
26-Sep-2009 |
Wink Saville <wink@google.com> |
Refactor Cdma OTASP InCallScreenState to be saved in PhoneApp via OtaUtils.
State that needs to outlive the life of an activity must reside
in an application. This fixes a bug which the caused the OTASP
to apparently not complete because if the Activity was recreated
then last OTASP state would be lost.
One way to see this occur is when in OTASP mode press the power
key to turn off the display which makes the InCallScreen Activity
a background task. When InCallScreen moves to the foreground it
is recreated and we lose state and there is no Next button displayed.
Bug: 2133182
Change-Id: Ife9753bf7689b48be4c5e78f95be95250d0a55b5
/packages/apps/Phone/src/com/android/phone/OtaUtils.java
|
| 79b9f6e30e8402b103f1ec3ed9dda1fcad2b1cd5 |
|
22-Sep-2009 |
Tammo Spalink <tammo@google.com> |
Replace Phone.getPhoneName() calls with getPhoneType().
The latter is numeric, and hence allows some compiler protection
against typos.
Addresses issue:
http://buganizer/issue?id=1905415
Change-Id: If46c709fd7bfb817a2801d0200eac0ad8cf819e0
/packages/apps/Phone/src/com/android/phone/OtaUtils.java
|
| e31831f42ffa08456ef0d5d1461ddc70b9d1fcfe |
|
23-Sep-2009 |
David Brown <dab@google.com> |
Explain OTA and SPC in the OtaUtils javadoc comment.
/packages/apps/Phone/src/com/android/phone/OtaUtils.java
|
| 325cc2ced6f1ff5fb1708abfcc5e9c73ac0cd962 |
|
22-Sep-2009 |
David Brown <dab@google.com> |
Misc Phone app cleanup:
- Naming: Clean up the various "request UI update from some other thread"
APIs to all be named like "requestSomeKindOfUiUpdate()".
Also got rid of the way-too-generic postNewMessageDelay() method,
replaced it with specific methods for the 2 things that the OtaUtils
code actually needs to do.
- Added comments for one unclear case in OutgoingCallBroadcaster
- Remove no longer used IncomingCallDialWidget, and its assets. (It's now
in the framework as com.android.internal.widget.RotarySelector.)
- Added better javadoc comment for CallNotifier
/packages/apps/Phone/src/com/android/phone/OtaUtils.java
|
| 57a38778e8c9f58b24cea1062e451934cadc4b3d |
|
20-Sep-2009 |
Jim Miller <jaggies@google.com> |
Fix for #2110151: Remove the 'back' key when OTA provisioning is started from the ON_BOOT_COMPLETED receiver.
/packages/apps/Phone/src/com/android/phone/OtaUtils.java
|
| 5aadc2633b13d6676598dc0954be25c108d05fcd |
|
16-Sep-2009 |
David Brown <dab@google.com> |
Update in-call DTMF Dialpad for "full touch" devices.
Here's a UI overhaul of the in-call DTMF dialpad for devices that use the
new-style in-call UI with onscreen touchable buttons.
These devices now have a smaller dialpad that fits above the main cluster
of onscreen buttons, and pops in and out when you press the "Dialpad"
button. There's no SlidingDrawer at all.
(The old-style dialpad and "sliding drawer" are now used *only* on devices
like Dream and Sapphire that don't have onscreen UI controls at all.)
Also, integrated a whole bunch of new assets from Jeff, so *all* the
dialpads (even including the emergency dialer) have the new squared-off
button backgrounds and new one-line-high labels.
Also:
- Removed a few more unused resources
- Added a "dialpadVisible" indication to InCallControlState,
which now controls the label of the "Hide/Show Dialpad" UI element
- Make sure the dialpad goes away when we Hold or Unhold
TESTED: all the possible "dialpads" shown by the Phone app:
- in-call dialpad in the SlidingDrawer, used for Dream/Sapphire
- new-style in-call dialpad for "onscreen touch" devices
- in-call dialpad used during an OTA call
- the dialpad in the EmergencyDialer
/packages/apps/Phone/src/com/android/phone/OtaUtils.java
|
| 8df5c508da2c836b841ee24120fa7c5cc92df387 |
|
16-Sep-2009 |
David Brown <dab@google.com> |
Clean up "dialer drawer" usage in the InCallScreen.
Stop having the InCallScreen and OtaUtils directly manipulate the
SlidingDrawer widget that contains the DTMF dialpad. Instead, have the
DTMFTwelveKeyDialer provide an abstract wrapper around it. Also, the
DTMFTwelveKeyDialer now finds the SlidingDrawer widget itself, rather than
having it passed in to the constructor.
This way the rest of the phone app doesn't have to know the
SlidingDrawer's resource ID, or care whether or not it even exists.
(This is nice, given that I'm about to remove it on some platforms.)
TESTED: Ran the full DTMF Dialpad test suite:
- Type DTMF digits on the onscreen dialpad:
- tones get sent correctly
- digits get appended to the digits display
- Type DTMF digits on the hard keyboard while dialpad is up
- tones get sent correctly
- digits get appended to the digits display
- Type DTMF digits on the hard keyboard while dialpad is hidden
- tones get sent correctly
- digits get appended to the digits display correctly even though
you can't see it. (They're there if you open the keypad.)
- Type DTMF digits on the hard keyboard before *ever* bringing up the
dialpad
- tones get sent correctly
- digits get appended to the digits display correctly even though
you can't see it. (They're there if you open the keypad.)
Ran these on:
- A GSM device
- A CDMA device
- A CDMA device during the OTA call (but note there's no
onscreen "digits" display)
/packages/apps/Phone/src/com/android/phone/OtaUtils.java
|
| dfa83d531cdb88513f09e913424b7a16628b37d3 |
|
04-Sep-2009 |
David Brown <dab@google.com> |
More DTMFTwelveKeyDialer and landscape-mode cleanup.
In this change:
- Nuked landscape versions of both dtmf_dialer_display.xml and
dtmf_twelve_key_dialer.xml. (Note this eliminates any possible way for
the InCallScreen to NOT have a valid "dtmfDialerField" EditText widget.)
- Also nuked the *portrait* version of dtmf_dialer_display.xml since that
was just an empty <merge>.
- Nuke the EditText widget that was used only in landscape mode to display
the DTMF digits you had dialed, and a bunch of animation code that was
used to fade it in and out
- Removed DTMFTwelveKeyDialer's CallerInfoAsyncQuery.OnQueryCompleteListener
implementation, which is totally unnecessary and probably came from a
copy/paste error sometime in 2008
- Make sure the DTMFTwelveKeyDialer can tolerate mDialerContainer being
null (like on devices which don't use a SlidingDrawer), and the
mDialpadDigits EditText widget being null (like in OTA mode where
there's no onscreen "digits" display.)
- Nuked the ConfigurationHelper class, which is no longer needed since the
in-call UI is now Portrait-only.
- No need for DTMFTwelveKeyDialer to set the FLAG_IGNORE_CHEEK_PRESSES
window flag; the InCallScreen already does it.
TESTED:
- Type DTMF digits on the onscreen dialpad:
- tones get sent correctly
- digits get appended to the digits display
- Type DTMF digits on the hard keyboard while dialpad is up
- tones get sent correctly
- digits get appended to the digits display
- Type DTMF digits on the hard keyboard while dialpad is hidden
- tones get sent correctly
- digits get appended to the digits display correctly even though
you can't see it. (They're there if you open the keypad.)
- Type DTMF digits on the hard keyboard before *ever* bringing up the
dialpad
- tones get sent correctly
- digits get appended to the digits display correctly even though
you can't see it. (They're there if you open the keypad.)
Tested this on:
- A GSM device (all tests worked)
- A CDMA device (all tests worked)
- A CDMA device during the OTA call (all tests worked, but note
there's no onscreen "digits" display)
/packages/apps/Phone/src/com/android/phone/OtaUtils.java
|
| a44a437fae34920b0ecbf66400ac50e10e5ae49e |
|
08-Sep-2009 |
Eric Laurent <elaurent@google.com> |
Fix issue 2102351: Speaker indication on UI mismatches with audio routing during OTA process.
Update speaker button state according to actual speaker state when made visible.
Reset speaker state and update screen when end call button is pressed while the OTA call is not connected. This is necessary because only the call disconnect handler would do it.
/packages/apps/Phone/src/com/android/phone/OtaUtils.java
|
| 9bd141ba20a6cf6dcb745aca6c5c05a9c88f3a98 |
|
03-Sep-2009 |
Jim Miller <jaggies@google.com> |
Add 'speaker' button to programming screen
so it can still be accessed while waiting for the phone to be programmed.
/packages/apps/Phone/src/com/android/phone/OtaUtils.java
|
| 986d2f46bd9572b563b89627fa60a9ea0853a91f |
|
01-Sep-2009 |
Jim Miller <jaggies@google.com> |
Re-skin OTA provisioning to match SetupWizard. Wrap phone activation screen in a ScrollView since space is tight (not currently used but may be a problem with some translations). Fix 'Try Again' button to return to ActivatePhone state.
/packages/apps/Phone/src/com/android/phone/OtaUtils.java
|
| 425b8e3c9846d5e0e76466604b35cad8856d79de |
|
02-Sep-2009 |
Eric Laurent <elaurent@google.com> |
Fix issue 2094757: Wired headset connection while in call disables speaker button but leaves speaker on.
The fix consists for one part in never disabling the speaker button: the user has the possibility to enable/disable the speaker even if a headset is connected.
When a headset is connected while the speaker is on, the speaker is automatically turned of but its current state is remembered so that it can be reapplied if the headset is disconnected.
/packages/apps/Phone/src/com/android/phone/OtaUtils.java
|
| 839b14d460986608fe577f89f789de854dc85b58 |
|
26-Aug-2009 |
Jim Miller <jaggies@google.com> |
Integrate CDMA provisioning into SetupWizard. Fixed trailing whitespace.
/packages/apps/Phone/src/com/android/phone/OtaUtils.java
|
| e4a6da04f5ed72f8be2e578b91d041493277e248 |
|
05-Aug-2009 |
Paul Berman <paul.berman@motorola.com> |
Fix dialpad visibility issue on OTA calls; OTA widget background coloring
Fix 2 OTA issues:
- Issue where if the dialpad was opened during an OTA call and the screen
decided to timeout, once it woke up the dialpad would no longer be visible.
- Nit: fixed coloring of OTA controls from OTA screens where background
screen color didn't match widget's LayoutGroup color. Blends in now :)
/packages/apps/Phone/src/com/android/phone/OtaUtils.java
|
| 17c36a10d09fac3e2312c0bcb839e0a704f42105 |
|
31-Jul-2009 |
w00278 <w00278@motorola.com> |
Phone shutdown after CDMA SPC error dialog is shown
One minute after the CDMA SPC (Service Programming Code) error
dialog is shown during OTA, the phone needs to shut down.
/packages/apps/Phone/src/com/android/phone/OtaUtils.java
|
| af684393e2c6d0c051b9d5a189c2cd1de2506831 |
|
16-Jul-2009 |
Wink Saville <wink@google.com> |
Rebase against latest changes.
/packages/apps/Phone/src/com/android/phone/OtaUtils.java
|