Age | Commit message (Collapse) | Author |
|
"exported" property was missing "android:" prefix and as a result was
not being respected.
bug:11367588
Change-Id: I2ec5b39bfb68e652d19d4b619889db9414f01109
|
|
This prevents third party apps from handling these intents, which they
were never meant to.
bug:8950263
Change-Id: Ic3c8bfd5a7d3b4676f5eca1bce9b4d02560a0e9a
|
|
Change-Id: Ifa4bc6fe73f9586d105092a9afacf79a51f45598
Auto-generated-cl: translation import
|
|
Adds contextual "Voice Mail" text as the hint in the DMTF dialpad
editText.
bug: b/7110391
Change-Id: I85241dc7fa6768f68867fdb1237540233b8be01b
|
|
|
|
In ICS, Phone app was creating separate Vibrator instances in
Ringer.java and CallNotifier.java, while in Jellybean they started
relying on one single Vibrator Service.
See also Id928ffef9a87e2563198240e91184cf59ecebbb1.
It means vibrate()/cancel() calls from two files interfere with each
other. When "Emergency tone" is set to "Vibrate" in Sound Setting
(which is only available with CDMA devices), this causes unexpected
trouble; the "Emergency tone" vibration is canceled immediately by
Ringer's Vibrator#cancel() call. onPhoneStateChanged() is indirectly
calling the method.
This change stops using the Vibrator Service in the emergency vibration
case, so that two Vibrator objects won't interfere with each other.
TESTED (use CDMA phone):
- Set "Emergency tone" to "Vibrate", and make a phone call to "911"
-> The device should vibrate for hundreds of mills (even without a
fix, it may vibrate for an instant, so need to check how long)
Bug: 6794250
Change-Id: I69e6c3d99b14b3c50c57ff5d59ca42f4ea18024f
|
|
bug:6764322
Change-Id: Ieca5fc35ca57cd71bc07b5beb2319a67450f9a59
|
|
Change-Id: Ia9f1bdf127c1758a6be49f455e557a5399e743e9
|
|
Change-Id: I66425e6921d946c9d2f59058664b1b40dffe778a
|
|
Change-Id: I14141f43dff67152e481c7f2fa3721b6a2692c1e
|
|
.. during other calls.
This change slightly reverts what we've done in
I6c66901c4731299494dcb1340803c25fee42ca31. Before the change,
INCOMING_REJECTED was actually using CALL_ENDED_LONG_DELAY.
Bug: 6616432
Change-Id: I3a1f05616608a52a6013108725887df031a9822f
|
|
|
|
Bug: 6603655
Change-Id: I2446692ba7f782af68fc985bb064d7a9724df730
|
|
- Introduce the functionality
- Have appropriate drawable for it
- Make its target smaller than usual, to avoid mistouch (same behavior
of end-call button)
TESTED:
GSM
- click the secondary photo during having two phone calls.
-> "click" effect and the actual "swap" action should happen
- click the secondary photo during making a second phone call which is
not answered yet
-> "click" effect nor the "swap" action should not happen.
CDMA
- try 3 way calls and click the secondary photo.
-> It should not initiate the "swap" action
Bug: 6598462
Change-Id: I20986ec3e33ee5f7d4015fd5d2ba961207203f02
|
|
This change introduces animation tweaks for entering/exiting
InCallScreen. It looks like a "task-to-task" transition right now,
which is unexpceted.
Here are three parts of this change:
- Have styles for entering animations.
- Have optional args for the Intent exiting InCallScreen.
- Fix a visual glitch around "elapsedTime" TextView, which has existed
but becomes more prominent with the correct animation.
A fundamental fix would be to stop using "singleInstance" launchMode for
InCallScreen, and remove a bunch of implementations relying on it, which
is very risky at this moment.
Bug: 6556973
Change-Id: Id2708ab1b1de650d45946c16a7f062bb2d3ba0ab
|
|
|
|
This will make the notification on top of others with normal
priority, with which users can use "hang-up" action during the call
even when other notifications appear.
TESTED:
- receive a phone call and get a SMS message after answering it.
Without the flag, SMS message will be above the ongoing call, which
makes the "hang-up" button collapsed.
With the flag, the ongoing call notification is still on top of the
list and because fo that the action is clickable by the user.
Bug: 6580973
Change-Id: I2ad1c66ad7b394b603c8ec0bc04a50e730ae338c
|
|
Bug: 6570480
Change-Id: I72e7e50edd61c0dc41c9877976a1e4a63e7a514c
|
|
|
|
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
|
|
Change-Id: I725c5dfcb8c81c8f5c563a1b20d772d04d375c05
|
|
Change-Id: I10c5ffb4eba58d55faa1bcae795243c58343c9ff
|
|
This change add a feature to reveal the swipe to search interface
when the home key is pressed for longer than 50ms. It progressively
reveals the interface. It still requires a bit of tuning, but all
the basic parameters are in this CL.
Change-Id: I6ab14a5adfaab1e46908391381f746c4580fef27
|
|
Make PhoneApp register its media button event receiver so it
sees media button key events first when the phone is ringing
or when in call.
Bug 6484717
Change-Id: I415e4b2b7a1e34922eabb06bb7f0e39b82e40faf
|
|
|
|
Bug 6184359
The EditText was customized with a PasswordTransformationMethod,
which is not propagated to the ExtractedEditText.
Using the equivalent inputType instead.
This is the equivalent change of 191223 in Settings.
Change-Id: I42fbbf7b9f38fc68f8f1bc607984bff38dd6be03
|
|
Change-Id: I9abe893f96c99aacda710d93423b24e170572c0d
|
|
Bug: 6498978
Change-Id: Ic92e6fbbf055d3438638a1415621cf4307404135
|
|
|
|
|
|
Fixing the issue 6476275 Call back notification should not appear for
unknown numbers.
It happens when a caller party hides its phone number and thus the
device cannot obtain a valid number, at which the "number" given to
notifyMissedCall() may become a non-empty but not-callable String.
The fundemental fix would be to stop using the wrong String, but for
a quick workaround, this change just have two checks for the problem.
TESTED:
- Miss an incoming call and check if the current behavior is preserved
- Tweak GsmConnection/CdmaConnection in telephony layer to return
"ABSENT NUMBER" to fake the behavior. Then miss an incoming call.
Check if the missed call notification does not have any actions.
Bug: 6476275
Change-Id: I0e194a7d6e2e51af1e902061f8d09582f1cc4b3d
|
|
Adjust update puk2 change state so that users are able to enter
new pin and confirm it after entering puk2 code.
bug:5671070
Change-Id: Ib0a2b0212b517acbefcb411caac00845ca3df58c
|
|
|
|
Bug: 6491970
Change-Id: I27bc1f7d33d256ad7d87e8028b25bc6544f62bed
|
|
Change-Id: I5d80a7f263a5a0732056fd60c6773e180f0bfa0f
|
|
|
|
Change-Id: I90d7f15dc44f4625f04baebfb00aa9f718df58ac
|
|
Bug: 6120279
Change-Id: Ied58228cb92a37a712a701b572148bf0239e1c17
|
|
bug:5546919
Change-Id: I6be738efb136ea9ff768f905af8c05436ce9a941
|
|
This happens when the user drag up the incoming call widget and
cancel the instant-text-response very quickly.
There are two possibilities causing this problem.
1. The app is setting up Animator, resetting Animation.
We are mixing two kinds of animation APIs, which is not appropriate.
2. Workaround for answer/reject sequences badly affects text-response
Just after answering/rejecting calls, telephony may still return
RINGING state. We want to ignore the state when deciding if we should
show the incoming call widget or not. Right now we remember when the
incoming call widget is dragged, and check if the previous action is
taken in 500ms. (See how mLastIncomingCallActionTime is used for more
detail)
For instant-text-response, however, we *do* want to accept the render
request every time, regardless of when the widget is used last time.
The hack should never be applied.
TESTED:
- Select instant text response and cancel it multiple times. Quickly
--> User should see either incoming-call-widget or
instant-text-response dialog.
- Try answer/reject/instant-text-response as usual.
--> No problem as before
Bug: 6476625
Change-Id: I4d0ddb235a5514e7b740c60ffd698a502f7a6a7e
|
|
This change fixes UI glitch introduced by
I8c0fdfa029357a48b703f7782d2ba069c7f4c76f, with which the previous
choice is visible when canceling the instant-text-response. This only
happens with the 3rd choice, not 1st and 2nd.
MultiWaveView#reset() should be called when the widget is once hidden
and shown again, like before the change above, while we don't want to
call the method in other cases.
Bug: 6472465
Change-Id: I90e4b38c2bb11ac77b85bab4a44c2106d38fbae8
|
|
.. and rename some of assets along with it.
Bug: 6253616
Change-Id: I745b21e41dca7c7930babc225c396c1e23bc5095
|
|
|
|
|
|
Fixing a bug 6472465 incoming call widget (MultiWaveView) loses
surrounding icons during incoming call.
This happens because the app updates the MultiWaveView multiple times
during each incoming call. If we are sure the assets used there are
same as previously used ones, we don't need to update them at all.
TESTED:
- Have an incoming call and check if the original issue is gone
- Have multiple incoming calls and check there's no problem with them.
- Have an incoming call from PSTN number and get another call
from SIP address. The widget should be updated correctly.
Bug: 6472465
Change-Id: I8c0fdfa029357a48b703f7782d2ba069c7f4c76f
|
|
to reduce memory usage further, without hurting its look-and feel.
- The original assets have too big empty space, while the new assets
just have actual content should be shown.
- From Bitmap perspective, empty space still eats memory
- This will reduce 500KB~1MB of memory usage for incoming call
situation.
Bug: 6120279
Change-Id: I5d0cee44237c9d5fa49369e672a1f7841d1766ec
|
|
NOTE: the original issue for which this logging is prepared is not fixed
yet, so we may need this again in the future.
Bug: 6201805
Change-Id: If02138176e47653f5bbf20a2e3a80379bc74013f
|
|
Depends on I850d27629a75615647883fdaa2933f337c4824d1
See also Idb0453e187f8025565d6744cd774613531e7cb8b for Setting app
side change.
Bug: 6036529
Bug: 6393739
Change-Id: I3a4ed2bd5e4bde05dfb97c7bb20b9284d1c6f13f
|
|
Do not rely anymore on deprecated method AudioManager.shouldVibrate().
TODO: remove dependency from AudioManager.setVibrateSetting() and
AudioManager.getVibrateSetting() when Phone app settings for vibration
policy are ready.
Issue 6036529.
Issue 6393739.
Change-Id: I0903cd4972a5ad77f02634b91e2302f44b7cb73a
|
|
|