"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
Import revised translations.

Change-Id: I2a9dc2931716af4b7dc4e1a997683557858a3b10
Emergency Dialer pixel perfect

Also update Phone assets

TESTED:
- launch EmergencyDialer screen from lock screen
- open dialpad from incall screen

Bug: 5150677
Change-Id: Ia5ffc6a99026d516d082231b098af67a65cb32a3
Fix "emergency call from airplane mode" sequence

If you dial an emergency number while the device is in airplane mode, the
device needs to first take you *out* of airplane mode, and then (once the
radio is powered up) actually make the call.

In gingerbread we did this using an invisible activity called
EmergencyCallHandler, but that's a bad design for a few reasons:
  - Visible display glitches during the activity transitions
  - Potential bugs if you interfere with the activity lifecycle (e.g. by
    pausing the EmergencyCallHandler by pressing Power at just the right
    point.)
  - The code is overly complicated.

Instead, it's cleaner to implement this sequence without using activities
at all.  Here's the new design:

  - The whole sequence is run by a helper class called EmergencyCallHelper

  - If you try to dial 911 while in airplane mode, the CallController
    notices this, lazily creates an EmergencyCallHelper instance, and
    starts the sequence

  - Then, the EmergencyCallHelper runs the next steps:
      - power on the radio
      - listen for the service state change when the radio comes up
      - then launch the emergency call
      - Retry if the call fails with an OUT_OF_SERVICE error
      - Retry if we've gone 5 seconds without any response from the radio
      - Finally, clean up when the emergency call disconnects successfully

There's also a corresponding update to the in-call UI: the InCallScreen
now knows how to put up a progress dialog (i.e. a "spinner") while we're
waiting for the radio to come on.  That's controlled by a new
"progressIndication" field of the InCallUiState.

TESTED (with hacked telephony layer that doesn't actually dial 911):

  - Call 911 in normal mode
  - Call 911 in airplane mode
  - After 911-from-airplane-mode sequence, double-check no wake locks still held
  - Confirm no cosmetic glitches

Also tested some corner cases:

  - Tested retry logic by using a temporary hack to deliberately ignore
    the "service state changed" event

  - Tested the "too many retries" case (using a temporary hack to make
    all calls fail); confirmed that we give up after 6 tries and display
    an error message

  - Do the whole "911 from airplane mode" sequence twice in a row (to make
    sure it works even if the EmergencyCallHelper object has already been
    instantiated)

  - Manually turn screen off in the middle of the sequence, confirm that
    doesn't disrupt the call

Bug: 4195290
Bug: 4194458

Change-Id: I209768ffdc6b3d2bd4efd04474eed630284ec551
Merge "Emergency Dialer pixel perfect"
Merge "Fix "emergency call from airplane mode" sequence"
Update assets for in-call screen

Change-Id: I3b6e1b8e75b4b2c09b25ea9600b8d1de1281109d
Update assets

Change-Id: Ia00a8ba0d3eac7cab76d3f5dcddef924de239542
Bluetooth : Modified ATD command

When device is dialed numbers include "p" or "w" using ATD command,
device cannot recognize the numebers correctly.

Change-Id: I0d61436f872877be359ec288c9f31009ee76b324
Signed-off-by: inshik <inshik.shin@samsung.com>
Merge "Bluetooth : Modified ATD command"
Fix repeated (re)launching of InCallScreen for call-waiting calls

Fix a bad side-effect of change I439930, which added code to refresh the
in-call notification when resuming or pausing the in-call UI.  The problem
was that in the call-waiting case, the notification update from
InCallScreen.onResume() would *also* (re)launch the InCallScreen :-(

The fix is to separate updateInCallNotification() into two distinct APIs,
one for use by the CallNotifier's incoming call sequence (which is allowed
to launch the InCallScreen), and one that *only* updates the status bar
icon and is used everywhere else.  (See updateInCallNotification() and
updateNotificationAndLaunchIncomingCallUi() for the exact details.)

TESTED: all 3 incoming-call actions (answer / reject / respond via SMS),
for the following incoming-call scenarios:
  - Regular incoming call with screen off
  - Regular incoming call with device unlocked
  - Call-waiting call with screen off
  - Call-waiting call with device unlocked, showing the in-call UI
  - Call-waiting call with device unlocked, in some other app

Bug: 5167337

Change-Id: Ifa76e28c27517b0b85df5ba4dccda403073a2efe
Merge "Fix repeated (re)launching of InCallScreen for call-waiting calls"
Clean up "allow_back_key_to_reject_incoming_call" resource

Back in 1.0 and cupcake, on only some devices, we allowed the Back button
to reject incoming calls (i.e. act like the hard "End Call" button.)  This
was controlled by a config resource called
"allow_back_key_to_reject_incoming_call" which was intended to be true on
devices with mechanical hard buttons, and false for capacitive soft
buttons.

But this feature has been useless for a long time because (a) hardly any
phones have mechanical hard buttons any more, and (b) even with hard
buttons, it doesn't really make sense for Back to mean "reject" in the
first place since you presumably have a hard End button too.

So this change gets rid of the "allow_back_key_to_reject_incoming_call"
resource, and updates the incoming call UI to *always* ignore the Back
button.

(Also, in a separate change, I'll remove that resource from the one
product-specific resource overlay that overrides it.)

TESTED: Incoming call; Back button is ignored.

Bug: 5161286
Change-Id: I4729891e7ef4a62c69bc597d9a5329b58288a2c8
Enable some extra logging to help track down unexpected telephony tones

(Telephony tone events are still very rare, so this isn't actually very
much extra logging.)

Bug: 5159921
Change-Id: I911eb3b138c9a8d3dcf2b756b7edc0d8093bed1c
Reposition "Calling via ..." provider badge to not overlap the call banner

Currently, the badge that shows "provider info" (like "Calling via Google
Voice", for example) is drawn at the very top of the screen, and covers up
the info about the actual person / number you're calling :-(

In the short term, at least, the fix is to simply reposition the badge to
not collide with the call banner.  Post-ICS, though, we hope to integrate
the badge more smoothly into the call banner rather than using an overlay
at all (bug 5045539).

TESTED: Using google voice, verified that the badge is repositioned
  vertically more toward the middle of the screen, and doesn't obscure
  either the "call banner" area or any onscreen buttons.

Bug: 5045539
Change-Id: I4ec9f27b2edaa468d4c39515a94310169ffbf351
Emergency dialer: hide Search button

Currently the emergency dialer has the same "additional buttons" row as
the regular dialer (Search / Dial / Backspace).  The emergency dialer
doesn't actually have a search function, though, and the "disabled" state
of the search button is too subtle.  So just hide the button totally.

Bug: 5041949
Change-Id: I1bf0efbffcc4fe852793e5e8cffd3e0f6c7dc468
Merge "Emergency dialer: hide Search button"
Merge "Clean up "allow_back_key_to_reject_incoming_call" resource"
Move handling of intents from broadcast receiver to handler.

Move the handling of battery changed and signal strengh changed intents from
broadcast receiver to message handler. The functions calls sendURC that makes
socket call into kernel and could take some time to send out the URC codes.
This could block the main thread, causing ANR. Now handle them in the message
handler looper thread.
bug 5162882

Change-Id: I156207b30fe2b33b2cb1d47114b779305f623ee8
Merge "Move handling of intents from broadcast receiver to handler."