By not starting RILReceiver we don't waste any cycles
trying to communicate with a vendor ril which may
not exist. This allows a wifi-only device to operate
as expected and the system to gracefully handle the
missing radio as ril requests will report RADIO_NOT_AVAILABLE.
Change-Id: I6c6f60830486c5f0447b3b9eb44c8b1f2d70c517
Although our first tablet doesn't support SMS messages there are testing
scenarios where they can be used. To preserve proper behavior now that
getPhoneType can return PHONE_TYPE_NONE use getCurrentPhoneType.
bug: 3198435
Change-Id: I48ef294f563351c66971b4e89e6dcb3326b0ae92
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
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
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
Add DNS and gateway as parameters to RIL_REQUEST_SETUP_DATA_CALL so that
system properties aren't used for passing these to the ril. System
properties that are read right after a write doesn't always see the
result of the write. Another words writing system properties are not
not sequentially consistent.
Bug: 3364487
Change-Id: Ib7cba74346395323f3feb927281695663d9935ac
There are separate settings for AUTO_TIME and AUTO_TIME_ZONE.
Modify *ServiceStateTracker to monitor AUTO_TIME and AUTO_TIME_ZONE changes
separately and reset NITZ time and timezone accordingly.
bug: 3304255
Change-Id: Ie430f7b4a256618bea87672b3628d1223ea6e36a
We were sending a notification before setting mIsMinInfoReady and
mCurrentOtasp. This causes a race and it's possible that
OtaUtils.maybeDoOtasp is called before before they are set.
In this case the activation would not occur.
Bug: 3339109
Change-Id: I3baf8992d58af63a5cc07a14cc33157fd1c5aaa3
Use matching feature type when turning tethering off or the request is ignored.
Also, turn on DUN apn right away so that we don't fail aggressive test cases.
Also don't report connections for enabled apn's that we're no longer connected to.
bug:3332880
bug:3338033
Change-Id: I7db2dfd4879f03465bc9f6d39488c078570dcaf3
Currently, PhoneUtils.getMute() returns the mute state from the foreground phone.
When a SIP call is muted and then put on hold, the call is moved to background
and the SipPhone becomes background phone. At this point, PhoneUtils.getMute()
incorrectly returns false from the idle foreground phone (i.e., GSMPhone).
CallManager provides getMute() but it's not used anywhere. This CL fixes the
method and I'll have another CL to have PhoneUtils.getMute() take advantage of
it.
Bug: 3323789
Change-Id: I6c37500ae93f4e95db3bcd55e24e1ecb58a57c0a
When roaming the plmn might be blank but we want to have
showPlmn true otherwise "No Service" is displayed.
bug: 3265611
Change-Id: Iaed8997ab0bb336c79cef1fc848526ca7a73f9a1
The purpose of these properties is to allow, at boot time, the
enable and disabling of receiving and sending of SMS messages.
These properties are used to initialize two booleans within
[Gsm|Cdma]SMSDispatcher code. The two booleans are initialized
to the value of config_sms_capable and when config_sms_capable
is false the device can neither receive nor send SMS.
Under some conditions, such as testing, it could be desirable
to send and or receive SMS messages on a device where config_sms_capable
is false. With the addition of these two properties it is now possible
to use /data/local.prop to control the booleans independently.
bug: 3315489
Change-Id: I83fe6f2da7d66ff720f28b696d8d76ec388706c0
A bit of a hack so that first trySetupData call uses the proper APN in
strange edge cases. Made a new startUsingNetworkFeature string
that ConnectivityService knows means always pass the request to telephony
even if telephony connections are not currently available.
bug:3133178
Change-Id: I2559b9cbaed4b4ec02bdf7ea78e6003ee2be64f2
Change I1a1adc61 added a new parameter to setupDataCall,
but updated the callers incorrectly (specifying the
arguments in the wrong order). Fix the order.
Change-Id: I0e762de29ac05d387371a7cfe33a33ad16219221
setupDataCallWithProtocol was introduced to introduce a
protocol parameter to setupDataCall without having to
modify its callers. This is not very useful, as there are
only two callers. Get rid of it and make setupDataCall take
the protocol parameter itself.
For now, hardcode IPv4 connectivity. When we add the
protocol field to ApnSettings, it will be fetched from
there.
Change-Id: I1a1adc616ffd9ac68be6911f054790da48e472d6
The wakelock will be kept held if there is outstanding requests
in request list. When WAKE_LOCK_TIMEOUT occurs, all requests
in mRequestList already waited at least DEFAULT_WAKE_LOCK_TIMEOUT
but no response. Those lost requests return GENERIC_FAILURE and
request list is cleared.
bug:3292426
Change-Id: I369c6ba4d6836d65ef616140e48c7304faf888f0
Rewrote interceptKeyBeforeQueueing to make the handling more systematic.
Behavior should be identical except:
- We never pass keys to applications when the screen is off and the keyguard
is not showing (the proximity sensor turned off the screen).
Previously we passed all non-wake keys through in this case which
caused a bug on Crespo where the screen would come back on if a soft key
was held at the time of power off because the resulting key up event
would sneak in just before the keyguard was shown. It would then be
passed through to the dispatcher which would poke user activity and
wake up the screen.
- We propagate the key flags when broadcasting media keys which
ensures that recipients can tell when the key is canceled.
- We ignore endcall or power if canceled (shouldn't happen anyways).
Changed the input dispatcher to not poke user activity for canceled
events since they are synthetic and should not wake the device.
Changed the lock screen so that it does not poke the wake lock when the
grab handle is released. This fixes a bug where the screen would come
back on immediately if the power went off while the user was holding
one of the grab handles because the sliding tab would receive an up
event after screen turned off and release the grab handles.
Bug: 3144874
Change-Id: Iebb91e10592b4ef2de4b1dd3a2e1e4254aacb697
Korean phones write to the ADN record of the SIM in a non-standard way.
When UCS2 is not used, the alphaTag will be written in the KSC5601
encoding. This contribution adds support for reading that format when
a Korean SIM card is used.
Also adds support for KSC5601 in SMS.
Change-Id: I81a4a6949359b4d23a937ac2d813bafed2b85ff6
If device doesn't support sms service, SMSDispatcher
will ignore incoming SMS in dispatching messge and return
ERROR_NO_SERVICE in sending sms messgae.
bug: 3250029
bug: 3038102
Change-Id: Ic72a9192aa128c43cf31da04907620bc680656c6
Removed ACTIVATION_REJECT_GGSN and ACTIVATION_REJECT_UNSPECIFIED from
DataConnection#isPermanentFail() so they won't be detected as permanent.
bug: 3070773
Change-Id: I18d10bc44609e550d7932cd9600116f074bcb8dd
