This undoes the automerger skip which occured in
commit e740c84dc32180214a7fd157105d6c18d30408ee and
replays it as a standard (NOT -s ours) merge.
Change-Id: If5a47be26f73d6a0735c425cd66310a3e2a89086
Since mnc 00 is represented as undefined it needs to be replaced
with MNC_ZERO 0xffff for retrieving proper resources.
bug:28219719
Change-Id: I7e1630c2f5c31959306d862b10e7987bb449ea9f
Instead of calling out to external processes with a blocking IPC,
pass along a Binder on which the external process can pass back
the response. The calling process can then wait for the reply with
a timeout.
This eliminates watchdog restarts of the system_server when an external
process like telephony or bluetooth hangs.
Bug:26842468
Change-Id: I1b242e4ed22a63f1a4a0be8c78de8ac4d7bf56c5
This configuration parameter aims to address the following requirement.
a) If the Wifi radio on the UE is in turned on state (and the UE is not
connected to any WWAN) and the user dials 911 and the UE is not
capable of making E911-VoIP over WiFi calls, then the UE shall turn
off its WiFi radio and shall try to attach to one of the WWANs,
depending upon the air interfaces supported by the UE for setting
up the 911 call to the relevant PSAP. After the 911 call ends,and
after the callback period ends, then the UE shall turn on the WiFi radio.
b) If the Wifi radio on the UE is in turned on state and the UE is connected
to a WWAN and the user dials 911 and the UE is not capable of making
E911-VoIP over WiFi calls, then the UE shall turn off its WiFi radio and
shall set up the 911 call over the WWAN to which it is already attached,
if that WWAN is available and able to support 911 calling. If that WWAN
is not available or is not capable of supporting 911 calling, then the UE
shall select an available WWAN for setting up the 911 call. Assumption is
that while a LTE network may not have 911 calling support capability, all
1x, GSM and UMTS networks will be 911 capable. After the 911 call ends,
and after the callback period ends, then the UE shall turn on the WiFi radio.
c) If the Wifi radio on the UE is in turned on state (and the UE is not connected
to any WWAN) and the user dials 911 and the UE is capable of making E911-VoIP
over WiFi calls, then the UE shall not turn off its WiFi radio but shall first
try to attach to one of the WWANs, depending upon the air interfaces supported
by the UE , for setting up the 911 call to the relevant PSAP.
d) If the Wifi radio on the UE is in turned on state (and the UE is also connected
to a WWAN) and the user dials 911 and the UE is capable of making E911-VoIP over
WiFi calls, then the UE shall not turn off its WiFi radio but shall first try to
attach to one of the WWANs, depending upon the air interfaces supported by the
UE,for setting up the 911 call to the relevant PSAP.
Thus,the following address the requirement above.
1) Introduce a parameter (KEY_CONFIG_WIFI_DISABLED_IN_ECBM) to conifgure Wifi disable
in ECBM for the requirement c & d. This key shall be overridden in the specific
carrier overlay configuration file (defaulted to FALSE).
2) Already existing API (setWifiEnabled()) to turn ON/OFF Wi-Fi cater the requirement a & b .
Bug: 27854016
Change-Id: I5af370c143630bdd4b075f4730fd1de1bbe1fe7d
These particular boradcasts need to expose phoneId since they are valid even
when there is no SIM.
ACTION_SERVICE_STATE_CHANGED
- Added phoneId to broadcast.
- Removed TelephonyRegistry non subId call.
ACTION_SIGNAL_STRENGTH_CHANGED
- Added phoneId to broadcast.
- Removed TelephonyRegistry non subId call.
ACTION_PHONE_STATE_CHANGED
- Added phoneId to broadcast.
- The non-subId version is called by Telecomm to communicate overall state.
Telephony sends its own version, so only the Telephony call needs to add
phoneId.
Bug: 27378995
Change-Id: I554f7ee18b9ae19919f4724328dcff3ef9cbd092
The new getIccAuthentication should be used. All callers have been updated
to the new API. Remove the old API in this change.
Bug: b/27360179
Change-Id: I160974d53bb6477666b3e1d457accac45cc06bfc
Adding getVideoStateFromCallType method to ImsCallProfile, which basically
just breaks out some of the existing logic in getVideoStateFromImsCallProfile.
This is used to translate the CALL_TYPE_* from an external call to a
video state (used when pulling the call).
Added a new ImsReasonInfo code for when multi-endpoint fails to configure
because the modem does not support it.
Bug: 27458894
Change-Id: I226e79005dccf3e8cae30e4d448543adbe59f922
- move wfcOperatorErrorCodes to CarrierConfig
- corresponding error alert and notification messages are moved to the
main string.xml and are accessed by index defined in wfcOperatorErrorCodes
- make a list of supported SPN formats and use CarrierConfig to define
index of appropriate format string
Bug: 27170754
Change-Id: I698908157c1022f47a43ef70f03a571f1d0c75da
* getDeviceSoftwareVersion - Fixed to work for no SIM by not looking up subId.
* getImei - Fixed to work for no SIM by not looking up subId.
* getActivePhoneTypeForSlot - Adding a method (hidden).
* getCallState - Adding slotId version (hidden).
Bug: 27378995
Change-Id: Ib67ae3df5562d75727dc7e4ac023021fb331d3b5
Used Carrier Config to load correct ERI configuration file since
there are MCC/MNC shared by different carriers.
bug: 23887558
Change-Id: I61632045486929a5f0f1266fcf3b772a969d5836
Preinstalled carrier apps start in state DEFAULT (== ENABLED); the
telephony stack marks them as DISABLED_UNTIL_USED during
initialization, and eventually ENABLED once a SIM for that carrier is
inserted.
However, this can cause a race as telephony initialization may happen
after the carrier app is started, while it is still in the DEFAULT
state. In this case, the app is disabled, and though PackageManager
will subsequently kill it, this may lead to a race as the app will
briefly remain running while disabled. In this state, crashes are
likely to occur in the app.
So, make sure we perform the first disable as soon as PackageManager
is ready. This ensures the app is not started until it has been
explicitly enabled.
Bug: 27821069
Change-Id: I771d7dde7880fd98b1df3d011be44164abf402f4
This is a no-op refactoring which will allow us to access
CarrierAppUtils from PackageManagerService.
Bug: 27821069
Change-Id: Id6ac33020395f7fc03b285ffa8c3d421a02270ec
Added not_metered capability to a mobile network if none
of its associated APN types are metered. Also used not_metered
capability to determine if a network should be accounted for
data usage or not instead of using network type, which is
always MOBILE after refactoring. Will add VT usage support
in next phase.
bug: 20888836
Change-Id: Id692cb856be9a47d0e918371112630128965b1bb
By default we set this to "true", however it is anticipated in the future
that some carrier may desire to not allow the wifi-only option, hence
this carrier config option.
Bug: 27858149
Change-Id: I55b09655a590a661780cd9ed89c1e1b0d87d54dc
While the device is being provisioned we can default to
mobile-data-off and let the provisioning app turn mobile
data back on if the user wants it. After provisioning
control is restored.
Settings in play:
Settings.Global.DEVICE_PROVISIONED (existing)
SystemProperty ro.com.android.mobiledata (existing)
Settings.Global.MOBILE_DATA (existing)
SystemProperty ro.com.android.prov_mobiledata (new)
Settings.Global.DEVICE_PROVISIONING_MOBILE_DATA_ENABLED (new)
If the new settings aren't used, the old behvior is used.
bug:26638209
Change-Id: I92617ed6e588a5c50cf39054412a15273a9e03ff
- Per suggestion of API council, moving properties of a Connection from
CAPABILITIES_* to PROPERTIES_*.
Bug: 27458894
Change-Id: Icce921b03cda514a991646ed39a26559c7e91230
- Removed BOOL_ALLOW_VIDEO_PAUSE as it appears it was already added
as KEY_SUPPORT_PAUSE_IMS_VIDEO_CALLS_BOOL.
- Renamed BOOL_ALLOW_EMERGENCY_VIDEO_CALLS to KEY_ALLOW_EMERGENCY_VIDEO_CALLS_BOOL.
Bug: 27346047
Change-Id: I9f772e68ad9e78ce5a0419387c85a7f9630ecd5f
