| 9a6457362b55d5a98442f004d1d3b733c86188c6 |
|
04-Feb-2013 |
Santos Cordon <santoscordon@google.com> |
Merge "Allow 3rd party apps for instant text back"
|
| f24af3b91bd1bafc8063ad93ecc42917d6ed42d6 |
|
05-Dec-2012 |
Santos Cordon <santoscordon@google.com> |
Changing "custom message" quick response resource string.
Changing to "Write your own" to match similar string changes in other
apps.
bug: 7668698
Change-Id: I861fa9f69193a6867c3d2d36c5693bff6e743791
/packages/apps/Phone/src/com/android/phone/RespondViaSmsManager.java
|
| 4d7d3fab65e210e50f551046bc2a94b06888954b |
|
26-Mar-2012 |
Daisuke Miyakawa <dmiyakawa@google.com> |
Allow 3rd party apps for instant text back
This must be after Ib611368d488de2f8e1e853f550eb2c654305eda4 (framework), and
along with Idda4130f7f20b7cf0fba66900209d36f12dc093f (Mms)
Bug: 5108429
Change-Id: I1b719a5798d1e40d56437d51c3280c4f562b11f7
/packages/apps/Phone/src/com/android/phone/RespondViaSmsManager.java
|
| 3861ae3fdaf2dd79602262460914122c5e8210e5 |
|
25-Sep-2012 |
Santos Cordon <santoscordon@google.com> |
build break fix
Change-Id: I819423cdf199184aba7a9b3c9efb4d76872db7e8
/packages/apps/Phone/src/com/android/phone/RespondViaSmsManager.java
|
| cc01c5efd47627e1adfc8fe606957529ac84411f |
|
22-Sep-2012 |
Santos Cordon <santoscordon@google.com> |
Glowview showing above incall screen.
Quick clicks (or delayed processing of clicks) can cause the
respond-via-sms code to trigger in quick succession. This code
indirectly causes the glowview to animate and then hide. Additionally, the
"hide" code wont run if a hide animation is already running, causing the
second glowview (from the second click) to stay in view indefinitely.
Why this issue didn't happen before:
The answer/reject options have code in place that prevents
click-handling from executing in quick succession but it's a
side-effect of radio-lag management and thus is not suitable for reuse in
respond-via-sms. Moreover a "cancel" within respond-via-sms SHOULD
allow the code to reexecute; another reason the "radio-lag" code cannot
be reused.
The fix:
This change stops the animation of a new glowview control if we are
currently in the state of selecting a quick response. Nips the problem
in the bud by not drawing a glowview unnecessarily. This change means
the double-hiding problem never even comes into play.
Added TODOs to fix the state machine without this patchwork.
bug: 6765896
Change-Id: I473f2f1aea292bb8787ee5ad2203d4e7209e07d6
/packages/apps/Phone/src/com/android/phone/RespondViaSmsManager.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/RespondViaSmsManager.java
|
| b0f85b4a78abead921c363f9c8e247d5bdd20c74 |
|
14-Jun-2012 |
Wink Saville <wink@google.com> |
Use telephony-common
Change-Id: I1710418850040fc20afff4795ee4a85027203fc9
/packages/apps/Phone/src/com/android/phone/RespondViaSmsManager.java
|
| 73edd2d4268a1e42dfc02113b0cf87093f03293b |
|
12-Jun-2012 |
Jim Miller <jaggies@google.com> |
Fix 6613962: Update phone to use new GlowPadView UX design.
Change-Id: I14141f43dff67152e481c7f2fa3721b6a2692c1e
/packages/apps/Phone/src/com/android/phone/RespondViaSmsManager.java
|
| fcfd76719875e86742b16f5cc901689bff5bf43a |
|
21-May-2012 |
Daisuke Miyakawa <dmiyakawa@google.com> |
Hide instant-text-response when there's no destination
Phone app in showing "instant-text-response" (or respond-via-SMS)
choice during incoming call even when MMS/SMS is disabled.
This change will hide the choice when the app cannot find the
correct destination.
Bug: 6522049
Change-Id: I22f83d1973c5c7df33e590d5903ea30d664d5be3
/packages/apps/Phone/src/com/android/phone/RespondViaSmsManager.java
|
| 565a7e471b8f2f27d3061406f0f3981843d892df |
|
27-Mar-2012 |
Daisuke Miyakawa <dmiyakawa@google.com> |
Avoid possible NPE during InCallScreen#onDestroy()
Bug: 6232282
Change-Id: I7c901722f9c753f307e4759ebf9259082aced45f
/packages/apps/Phone/src/com/android/phone/RespondViaSmsManager.java
|
| f4ef613d8e6f203248d459cd77a3a7074c8f817c |
|
22-Mar-2012 |
Daisuke Miyakawa <dmiyakawa@google.com> |
Tiny cleanup around respond-via-sms
- Removes several non-null check for RespondViaSmsManager.
It must not be null and thus the check won't be necessary.
- Tweak misc comments
- Force RespondViaSmsManager to call getSharedPreferences() once,
which will force the Activity to prefetch the shared preferences.
- Remove TODO around bug 4998562. We'll live with it.
Bug: 4998562
Change-Id: I30f5c6e41af2a356ce26eae9065a825b7a8c9340
/packages/apps/Phone/src/com/android/phone/RespondViaSmsManager.java
|
| 41e4c430d08ecbd8dfee7d72bfe3880640caf3ba |
|
20-Mar-2012 |
Tom Taylor <tomtaylor@google.com> |
"Respond via SMS": Non-secure keyguard bogusly appears when using "Custom message"
Bug 4998569
Send custom sms message via the special sms service. The sms service will
start the compose activity with the appropriate window flags to dismiss the
keyguard/lockscreen. Going through the service perserves the permissions.
Change-Id: Iff6ab3eafd72e746998b0115bad448117e94402e
/packages/apps/Phone/src/com/android/phone/RespondViaSmsManager.java
|
| 552eaf42c27575b408ed3087f3dbc7a33680bd56 |
|
06-Mar-2012 |
Daisuke Miyakawa <dmiyakawa@google.com> |
Keep quick-response popup even after incoming call disconnects
The dialog dismisses itself when the incoming call disconnects, while the
user may want to keep the dialog open regardless of the current phone
status.
This change allows users to keep seeing the dialog and exits the whole
in-call screen afterward. This means the in-call screen is being shown
even during IDLE state.
- Stop exiting the in-call screen when:
1. incoming call disconnects, *and*
2. the user is still seeing "Respond via SMS" dialog.
- Exit the in-call screen after sending sms message when the phone state
is already IDLE.
- If the phone isn't IDLE at that moment, it may mean the other phone
calls are available.
- Dismiss popup immediately after sending/canceling the sms reply.
- Previously onResume() has done the job, which is not intuitive and
cause possible troubles with this change.
- dismiss() request on onResume() is still there, because it is
originally for preventing buggy states.
TESTED:
- show the dialog and send actual sms response
- show the dialog and cancel it, then answer or reject it
- show the dialog and keep the dialog until the caller hang up the call
-- send the sms -> send sms and close in-call UI
-- close the dialog -> close in-call UI
-- turn off the screen and re-open -> in-call UI should be closed
- show the dialog and turn off the screen before the phone hangs up
- receive a phone call during the other phone call and try sms-response
Bug: 4998653
Change-Id: Ic5136c309ed141d3aa0cac26d46ee755a962775a
/packages/apps/Phone/src/com/android/phone/RespondViaSmsManager.java
|
| 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
|