Seperate dataRoaming from gsmRoaming. dataRoaming is based on +CGREG returns in GSM while gsmRoaming is based on +CREG returns. Previously, the status of dataRoaming is always treated the same as gsmRoaming. However there is a situation where +CREG returns 0 and +CGREG returns 5, i.e., gsmRoaming is off and dataRoaming is on. In such situation, the phone should setup data connection if the phone enables data service when roaming (for example, data only card). The phone shouldn't setup data connection if the phone disable data service when roaming (to prevent roaming data charge). So gsmDataConnectionTracker should use dataRoaming instead of gsmRoaming to decide if data service allowed.
modified: GsmDataConnectionTracker.java
modified: GsmServiceStateTracker.java
Merge commit 'c41dca14ee9a9513e547a54a6356b4dab41d781c'
* commit 'c41dca14ee9a9513e547a54a6356b4dab41d781c':
Last minute change: Replace default app icon with a prettier one - droid on a software box sort of thing. :)
Merge commit '370e1f7439fd2688220bfc9615ea70fa3d397cea'
* commit '370e1f7439fd2688220bfc9615ea70fa3d397cea':
Propagate info about whether a "call" command was issued in RecognitionResult.
This was a problem with not dealing well with how the driver was
reporting data in the old touch protocol.
Also fixed issue with not correctly rotating non-primary touches.
This also refactors ConnectivityService a bit towards supporting multiple simultaneous connections by making each a seem like a seperate Network with it's own stateTracker, etc.
Also adds tracking of process death to clean orphaned startUsingNetworkFeature features.
This unfortunately requires API changes because the existing text markup
classes had no access to the screen density.
TextPaint gains a "density" field so that TextView can pass the density
along. AbsoluteSizeSpan gains a new flag to indicate that its argument
is in dip instead of in physical pixels. LineHeightSpan gains an inner
interface whose chooseHeight() method includes a TextPaint argument so
it can get at the density. And when StringBlock creates the markup
objects, it now uses the density-aware versions.
Bug 1976971, Bug 2031746
The issue is that the plus sign in a dial string is always converted
to the IDP (International Dial Prefix).
This fix implements a plus sign conversion mechanism based on the default
telephone numbering system that the phone is activated and the current telephone
number system that the phone is camped on. Currently, we only support the cases
where the default and current telephone numbering system are NANP.