| 2058f72e52da7f4a751f78787a693918d3a3ca9a |
|
02-Sep-2011 |
David Brown <dab@google.com> |
"Respond via SMS": disable the feature in cases we know it won't work
In the few cases where we know a priori that the "Respond via SMS" feature
isn't available for an incoming call, we now totally disable the "SMS"
drag target of the incoming call widget.
Those (relatively rare) cases are:
- incoming number is bogus or blank
- incoming "number" is a SIP address
- incoming "call presentation" says that the number is blocked
Implementation note: There's no convenient way to dynamically enable /
disable one specific target of the MultiWaveView widget, so we just use
two sets of resource arrays: one set for the usual 3-way choice, and one
for the 2-way choice when you can't SMS. Each time we bring up the
MultiWaveView widget we update its resources to use the correct arrays.
TESTED:
- Normal incoming calls
==> "Respond via SMS" still available
- Manually hacked allowRespondViaSmsForCall() to return false:
==> Incoming call widget only shows "Answer" and "Decline" choices
==> Dragging upward and letting go has no effect
- I didn't test allowRespondViaSmsForCall() with actual incoming SIP
calls or PRESENTATION_RESTRICTED calls, but I'll ask QA to do that.
Bug: 4998476
Change-Id: I31ec7606bf47cbf4531b56fa925a097c34dad912
/packages/apps/Phone/src/com/android/phone/RespondViaSmsManager.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/RespondViaSmsManager.java
|
| a29c610482c8db105c3c7f562cd72873d3ac4db6 |
|
22-Aug-2011 |
David Brown <dab@google.com> |
"Respond via SMS": Use new SENDTO_NO_CONFIRMATION intent
Use the new
com.android.mms.intent.action.SENDTO_NO_CONFIRMATION
intent instead of the old-school SmsManager.sendTextMessage() API.
Now, any outgoing texts that you send this way will correctly appear in
the "conversation history" in the SMS app.
TESTED:
(1) Receive phone call, "respond via SMS" using one of the canned messages
(2) Confirm the text gets delivered to the calling device
(3) Confirm it appears in the conversation history on the receiving device
Bug: 4998565
Change-Id: I9108c91d797db076fb42fd5a0c56a963ce8595e0
/packages/apps/Phone/src/com/android/phone/RespondViaSmsManager.java
|
| e662446d37d0f8bea51151488af461efe264c315 |
|
09-Aug-2011 |
David Brown <dab@google.com> |
"Respond via SMS": Show a toast after sending a text message
(Note this is only a partial fix; the toast is *not* yet displayed
correctly if the device is locked. See the TODO in
RespondViaSmsItemClickListener.onItemClick() for more info.)
Bug: 4998666
Change-Id: Iff44aa37b42b227753f3091cbcbafccde8175241
/packages/apps/Phone/src/com/android/phone/RespondViaSmsManager.java
|
| 717392cacea72751cbffb57b0424354b19da0868 |
|
10-Aug-2011 |
David Brown <dab@google.com> |
"Respond via SMS": after responding, reject the incoming call immediately.
Once the user responds by SMS, that means they're done dealing with the
incoming call, so there's no reason to keep the call around. (And it's
especially confusing for the "incoming call" icon in the status bar to
still be visible.)
So now we reject the incoming call as soon as the user selects one of the
choices from the popup (either one of the canned responses, or "Custom
message".)
Also fix a crash that could happen if the ringing call goes away at the
exact moment we're bringing up the popup menu.
Bug: 5042540
Change-Id: I4d7ebcf278abe708e86dbeec89a6a0912d7146ae
/packages/apps/Phone/src/com/android/phone/RespondViaSmsManager.java
|
| 2c8c40738e9b8a8e767aa061721ebaa5b5591a4c |
|
20-Jul-2011 |
Daisuke Miyakawa <dmiyakawa@google.com> |
Enable home as up button on ActionBar in Settings
Confirmed both in phone and tablet devices (on tablet
nothing will change as some of those Activities appear as
dialog, which has no ActionBar)
Bug: 5036273
Change-Id: I64a7bcea74026bed90f1841c0913fc21ebb7bfd4
/packages/apps/Phone/src/com/android/phone/RespondViaSmsManager.java
|
| f40c04a87e30bcfb795a5879d932418f0821fdb0 |
|
23-Jun-2011 |
David Brown <dab@google.com> |
Allow user to customize the canned messages for "Respond via SMS"
This change adds a new preference screen ("Call settings" ->
"Quick text response") that lets you customize the 4 predefined
"Respond via SMS" messages.
The implementation is ultra-simple for now: it's just 4 individual
EditTextPreferences, saved via SharedPreferences.
UI mockup: http://go/quick-text-response
TESTED:
- First time visiting the settings screen: the correct 4 defaults
appear.
- Customize some of the strings; they update correctly in the settings UI.
- Get an incoming call, bring up the popup. Customized strings
correctly appear.
- Get an incoming call with a totally clean SharedPreferences directory
(i.e. before ever visiting the settings screen). Bring up the popup,
all 4 default strings correctly appear.
Still-open loose ends:
- All current strings are provisional.
- Fix StrictMode violation where we load the SharedPreferences object from
the UI thread (see TODO near the bottom of RespondViaSmsManager.java)
- Make the settings UI a little less clunky (see TODO in
respond_via_sms_settings.xml): make strings editable in-place, allow
drag-to-reorder.
- The exact location of the settings screen under "Call settings" is still
TBD. For now, I added it as the 2nd item (after Fixed Dialing Numbers).
It's not inside any particular "PreferenceCategory".
- Eventually allow the user to add new strings beyond the initial 4?
Bug: 4598484
Change-Id: Id708d4686387ee06589c8beeeb19b5cdf8b7e3cd
/packages/apps/Phone/src/com/android/phone/RespondViaSmsManager.java
|
| 524486403a387c324dee5aff7fb78ca784d15255 |
|
01-Jul-2011 |
David Brown <dab@google.com> |
Rename RespondViaSms to RespondViaSmsManager, and make it instantiatable
Originally the RespondViaSms class was just a collection of static utility
methods. But it now needs to maintain some persistent state (namely the
user's custom "canned responses") so it makes more sense for it to
actually be a real instance owned by the InCallScreen.
Note this is NOT a singleton; each InCallScreen instance has its own
RespondViaSmsManager instance. (If RespondViaSmsManager were a singleton,
it would still need to point back to the active InCallScreen, and that
could lead to a memory leak if the ActivityManager were to destroy and
recreate the InCallScreen.)
Change-Id: Icb4d6cf4211fc1deed808408f31bd3854e183d1a
/packages/apps/Phone/src/com/android/phone/RespondViaSmsManager.java
|