It's always possible after services have been registered, so it's just early
in the process that's a problem. Lie correctly in those early cases and fix this
in MR1.
bug:3415254
Change-Id: I95811d1efd676fde01f66b742393d3aa4623482f
Default Android MNC value has a 2 digit but it should be supported a 3 digit
MNC in India. (should be supported both 2 and 3 digits MNC)
Change-Id: I69373d196b29bccd06653841f24cbfe3886834fb
Signed-off-by: Sang-Jun Park <sj2202.park@samsung.com>
The new method getCurrentPhoneType has the old behavior of getPhoneType
and does not check for voice capable. This allows code to assume
the old behavior.
bug: 3198435
Change-Id: I0542838ceca2f757cceb6cd7f795e95fe886523e
TTY mode should not be restricted to CDMA phones as some GSM carriers
support it.
TTY support is enabled by overlaying the tty_enabled boolean property
in packages/apps/Phones/res/values/config.xml
Also corrected wrong comments on TTY methods.
Change-Id: I48dbc2be51c3dcdaedc1838b85134edc7012be3c
1. According to TS 23.040, TP-Status values is changed properly.
2. When processing Status Report, it should be checked whether tpStatus is PENDING or FAILED.
Change-Id: I91c315cfb363f3e4b936c6b6b1a01083687a580f
If the RIL_REQUEST_OPERATOR response[2], the numeric for the operator,
is bad use the system property ro.cdma.home.operator.numeric.
bug: 3383515
Change-Id: I9abddc477d57c350a4c9a445242eaa7627cd5f69
We need some additional debugging to help diagnose the cause
of this bug. There is no logic changes just additional debugging.
Change-Id: Ifc5d1c82904042fa87fd3b5b1066f58b62e7359c
Adding them hidden so that if OEM's are rolling their own at least they can
use the same values. Will mark them unhidden in a future sdk release.
bug:3395729
Change-Id: I90eabe036a96e1aa7c8cac49ca51efd9b1776a0c
These trackers have two copies of the network type: newSS and newNetworkType. I think thats wrong,
but this was the smaller change on code that will hopefully be refactored soon.
On radio_off we were making a new, empty newSS but not clearing newNetworkType so it
still thought we were on 3G and when we reconnect and get 3G state changes new==old and we don't
send the update. In this fix I reset newNetworkType every time we apply it to networkType.
bug:3389886
Change-Id: I294f34259dc6c6f8f445bf2cb5466c8be747e25c
This is a cherry-pick Change 91968 from GB branch.
Wakelock will get released while
1) no request pending to be sent out, in which mRequestMessagesPending increases
before calling EVENT_SEND and decreases while handling EVENT_SEND.
and
2) no waiting requests sent to RIL but no replied, in which mRequestMessagesWaiting
increases while sending request and decreases while handling response.
Both will be cleared while WAKE_LOCK_TIMEOUT occurs to recovery from out of sync situation.
bug: 3369427, 3370827
Change-Id: Ibbcc95d67a292ffe20339ea9bdb0f2e4a4988da0
Cherripick from master CL 79833, 79417, 78864, 80332, 87500
Add new audio mode and recording source for audio communications
other than telelphony.
The audio mode MODE_IN_CALL signals the system the device a phone
call is currently underway. There was no way for audio video
chat or VoIP applications to signal a call is underway, but not
using the telephony resources. This change introduces a new mode
to address this. Changes in other parts of the system (java
and native) are required to take this new mode into account.
The generic AudioPolicyManager is updated to not use its phone
state variable directly, but to use two new convenience methods,
isInCall() and isStateInCall(int) instead.
Add a recording source used to designate a recording stream for
voice communications such as VoIP.
Update the platform-independent audio policy manager to pass the
nature of the audio recording source to the audio policy client
interface through the AudioPolicyClientInterface::setParameters()
method.
SIP calls should set the audio mode to MODE_IN_COMMUNICATION,
Audio mode MODE_IN_CALL is reserved for telephony.
SIP: Enable built-in echo canceler if available.
1. Always initialize AudioRecord with VOICE_COMMUNICATION.
2. If echo canceler is available, disable our echo suppressor.
Note that this CL is intentionally not correcting the
getAudioSourceMax() return value in MediaRecorder.java as the
new source is hidden here.
Change-Id: Ie68cd03c50553101aa2ad838fe9459b2cf151bc8
The DEFAULT_WAKE_LOCK_TIMEOUT should be longer than the timeouts
of the vendor ril, aka. rild. We are seeing timeouts which are
30secs and possibly longer. An alternative would be to add
TelephonyManager.PROPERTY_WAKE_LOCK_TIMEOUT for but I feel a 60
second default is appropriate for all platforms.
Bug: 3392618
Change-Id: I63f6b211b584857999174524d4ea4efa1994dfba
Wakelock will get released while
1) no request pending to be sent out, in which mRequestMessagesPending increases
before calling EVENT_SEND and decreases while handling EVENT_SEND.
and
2) no waiting requests sent to RIL but no replied, in which mRequestMessagesWaiting
increases while sending request and decreases while handling response.
Both will be cleared while WAKE_LOCK_TIMEOUT occurs to recovery from out of sync situation.
bug: 3369427, 3370827
Change-Id: Ib2fc54db3b155bd3fb1296ad83720b7836708caf
