The problem was ConnectvityService was not notified if a permanent error
occurs on the default apn.
bug: 2972138
Change-Id: I7be17061695ae2ba3571d70f24dcc4fe96d9ede9
To fix bug 2968310.
Handle the operation of hangupForegroundResumeBackground while foreground call and background call come from different phones.
Change-Id: Id83ca1b75031a8391c95c7f8b2be40e9067dd4cd
Fix for bug 2382830: new incoming SMS should not be rejected when
running low on internal phone storage.
Testing revealed that the /data partition should have at least 256 KiB
available in order to prevent random app crashes (including system apps)
due to SQLite transaction failures. With 256 KiB free, the device should
safely boot without storage full errors. This takes into account the
36-40 KiB that the YAFFS2 filesystem reports as available even after
the partition has been completely filled. I've set the default full
threshold to 1 MiB to provide a generous safety margin.
For this bug, I changed the DeviceStorageMonitorService demon to send
two new hidden notifications for device storage "full" and "not full",
when the free space falls below the full threshold (default 1 MiB,
but configurable as a system setting), in addition to the existing
storage low/okay notifications sent when the storage crosses the threshold
of 90% full (also configurable).
The SMS code was changed to use these new notifications so that it can
accept messages until the data partition has been filled to the maximum
safe capacity rather than stopping when it hits 90% full. There should
be no negative impact on battery life because the additional check in
the storage polling service should be offset by an optimization to cache
the free threshold values which were previously being computed every time
through the loop.
While testing this change, I discovered that SMSDispatcher was being
instantiated twice, the first time in GSMPhone/CDMAPhone, and the second
time in SimSmsInterfaceManager / RuimSmsInterfaceManager. Changed the code
to pass the original SMSDispatcher to the Sim/RuimSmsInterfaceManager
constructor.
Change-Id: Ie0c6d05294778ab6ee42e0fa01313af96d824c77
and fix the bug of re-assigning connectTime's in SipConnection,
and adding synchronization for SipPhone to be thread-safe,
and set normal audio mode when call not on hold instead of on hold in SipAudioCallImpl,
and fix re-entrance problem in CallManager.setAudioMode() for in-call mode.
Change-Id: I54f39dab052062de1ce141e5358d892d30453a3a
Merge commit '3158cf689f4994ec53c3b727f9b6ad7751a5551b' into gingerbread
* commit '3158cf689f4994ec53c3b727f9b6ad7751a5551b':
Change CDMAPhone.getDeviceId to return MEID or ESN.
Passing Gateway addr info from telephony into ConnectivityService so it can
add/remove the default route as needed. Fixed differently on master.
bug:2927822
Change-Id: I9a3ee7cd23c4717e7c60098f0595aa3f77c44b15
Cleaned up some typos and other small fixes in SMSDispatcher in
preparation for checking in my SMS bug fixes. This change doesn't
fix any bugs, but it shouldn't introduce any either.
- Removed unused import statements
- Removed unused private constants and fields
- Fixed typos in Java comments and private constants
- Added generic type parameter to mSTrackers ArrayList
- Removed unnecessary casts
- Fixed indentation of mResultReceiver in SMSDispatcher
- Removed call to get unused smsc in CDMA sendSMS()
- Changed "|=" to "=" in boolean assignment where the variable
was initialized to false (thus the two operators are equivalent)
Change-Id: Ic19a63a7ef5cdccc7be86043c2a1b863ec8af652
When in a call, different audio modes need to be applied based on phone type.
(For example, SIP call needs to be in MODE_NORMAL while GSM call in MODE_IN_CALL.)
Originally, it's handled in PhoneUtils.setAudioMode(). It makes more sense now
to handle the actual logic in CallManager.
Change-Id: I58d8f31d6b4afe22f88da442daac2010781de801
Fix a character count bug I discovered while working on related SMS
bugs. Includes a new set of test cases to verify the fix for the
buggy calculateLength() methods ("runtest frameworks-telephony").
You can also verify that the counter works properly in the Mms app
by typing characters until the boundary is crossed where an
additional message part is required. The counter should count down
to 0 characters remaining before increasing the message count.
Change-Id: I4de68b82dfc53dcae094865798f2c0235a355d43
Cherry-picked from master.
Add register methods used by PhoneApp into CallManager class.
For most register methods, CallManager acts as an pass-through
register to handle register and unregister phone case.
Change-Id: I9567c2dbffb9e482b906f94c2d991a404ad4626e
Cherry-picked from master.
Update APIs to access foregroudCalls, backgroudCalls, and ringingCalls
* 1. APIs to access list of calls
* 2. APIs to check if any active call, which has connection other than
* disconnected ones, pleaser refer to Call.isIdle()
* 3. APIs to return first active call
* 4. APIs to return the connections of first active call
* 5. APIs to return other property of first active call
Change-Id: Ic30e28018d14e496e9427f96fec8a7c2ff7c1549
PhoneSubInfo.getVoiceMailNumber now returns only the network
portion of the voicemail number. Use the new method
PhoneSubInfo.getCompleteVoiceMailNumber to get the netowrk
portion and the post dial portion.
Bug: 2881483
Change-Id: I7637d4fa0ffa046b4eebc4d599719bb668c940b5
Rather than come out of the user-modifiable APN DB, the DUN APN data will
come first from a built-in resource and then potentially overriden by a secure
setting (which is gservices upgradable).
Also made the "require-dun" setting secure-setting overridable.
bug:2736390
Change-Id: I1e4644c3839f06c977b83797641f3948785146a2
- Fix AdnRecord.buildAdnString() to generate the correct record when alpha
identifier is empty. This allows the user to update an FDN entry to remove
the alpha identifier. Previously the entire entry would be deleted because
an empty record was generated here when the alpha identifier was empty,
rather than a record containing the phone number with an empty alpha tag.
Also, return null if the number or alpha tag are too long.
- Fix bug in IccProvider.delete() where efType was compared against local
FDN constant rather than IccConstants.EF_FDN. This would always return
false. Comparing with IccConstants.EF_FDN gives the intended behavior.
Change-Id: I0ea75d7e107c7318c9a48ae6e0a15845a718f4c0