Fix conflicting display issue with ERI and CSIM SPN test.
Do not display them together but only override ERI text with CSIM
SPN in home area.
Bug: 5008969
Change-Id: I88383acd1c7f4c5bfb1f66349ff2f37b2edbbc9c
When DCT tears down a link due to error, the ApnContexts which are in INITING state are
not torndown. Due to this the DC refCount does not hit 0, and the Data Link is not torndown.
Bug: 4973894
Change-Id: If1263f360d55f6874220235fede294909db4837e
Make sure FAILED ApnContext state is reset to IDLE regarless of
existence of the reconnect alarm. This is to let FW re-evaluate
call setup conditions properly on data setup triggers.
Bug: 4989604
Change-Id: Ia9ec439db1df03bbd2e56803d3558542ba5f5400
Use ERI mechanism for roaming determination in CDMA-LTE mode.
Also display SPN name from CSIM card as "SPN" field in the status bar.
PLMN field will be derived from ERI text as done in original CDMA phone.
Bug: 4970448
Change-Id: I21382b15e148a8451f4c3fcbbb5d1ed296e41b5a
Report out of service if we don't know any better. Sometimes when switching radios
we were finding nulls reported - it crashed some code and highlighted this problem.
If we don't have a service state we're certainly out of service, so this isn't a lie.
bug:4553701
Change-Id: I094798a5f9f39f45c0ba30179aaa8f88f9b3e405
As "startUsingNetworkFeature()" now can trigger the initial data
connection instead of default data, FW needs to make sure each
MobileDataStateTracker is updated with the data availability
on each "data-setup capable" trigger.
Bug: 4970825
Change-Id: I6a7e479ecc1534cd723a2e8beece6b8bcd398ea7
If the system says a dependency isn't met for accessing the default APN,
apps should not be able to turn on the hipri APN either. This change
prevents apps from adjusting the dependencyMet setting on hipri and
internally ties its dependencyMet to that of the default APN.
bug:4643411
Change-Id: I7e609ff9bb1b85a3a6a41095052f0194d03be979
Previously external/libphonenumber accepted lower case
country codes (e.g. "us") but now it doesn't for performance reason.
Actually ISO 3166-1 doesn't allow lower cases, so we should not rely
on them.
Need to fix unit tests for PhoneNumberUtils, as it implicitly
relies on the previous behavior.
See also I3a3e6db84ed0d24290b1be19651fa9a82de4cc39
Bug: 4941319
Change-Id: If16f6531f274a0faf5e28724854409ca9b00a669
If a DataConnection is pending re-connect alarm, the new request
from another ApnContext sharing the same DC could disrupt
the re-connection pattern currently engaged.
This patch is to ensure the new request for PDP sharing
scenario will not trigger another SETUP_DATA request if
reconnection alarm is set in AlarmManager.
Bug: 4901019
Change-Id: I98b0d9af8b58fb880efdbc0246009de5cb116a54
With the latest version of the external/libphonenumber library
<https://android-git.corp.google.com/g/117190> we now have real data for
the PhoneNumberOfflineGeocoder.getDescriptionForNumber() feature.
So enable it in the CallerInfo query. This means that the incoming call
UI will now show a geo description like "California" or "Maryland" (along
with the number) for unknown incoming numbers.
I also needed to work around an issue with the latest phonenumber library:
The new library apparently requires countryIso to be uppercase (e.g. "US")
but the CountryDetector.detectCountry().getCountryIso() call currently
returns "us", which causes PhoneNumberUtil.parse() to fail. (This also
broke some ContactsProvider tests too.) So force the countryIso to
uppercase for now.
TESTED (on Crespo):
- Incoming calls from an unknown number:
==> State name is now displayed.
- Incoming calls from a number that matches a contact:
==> no change in behavior
Bug: 4595580
Change-Id: I03126e1eee99d428e76bbbad5b3856be3874f549
