GitLab

Without this our generation number gets out of sync and
we ignore disconnection results.

bug:24462721
Change-Id: I348c70c4368c4d4d9ad466e4a6803f935bb43bc1

Change had already been applied to mnc-dr-dev, so merging with -s ours

Merge "Add forground flag for retry intent to avoid long delayed cellular data setup." into mnc-dr-dev

We should only be retrying things if there was a substantial change.

Don't call trySetupData from Dct.setupDataOnConnectableApns when
in ONLY_ON_CHANGE mode unless there was a change for the FAILED
APN.

bug:24179336
Change-Id: Ia65dbd9789978548b70fb990ccfd5c55dcc51163

Bug: b/24151359
Change-Id: I9e0231f1ecb8ddccf5fee3071fc0327568918887

b/24215857

Change-Id: Ic7371b4e84a19d095f3e544c94658456184cb4ea
(cherry picked from commit 4c3aa35e)

Currently, if user selects "Choose automatically"
in Settings > More > Cellular networks > Network operators,
dialog is shown infinitely, and user can not cancel with back key.
Because COMPLETE message is not sent in case of already automatic mode.
To fix it, change to send COMPLETE message even if already automatic mode.

Bug: 24270612
Change-Id: Id312ac846c95a32337aebbd815de03416f2b614f

am 463068b8: am e2840825: am 1904f9d4: am aa1b0618: am b7710d07: resolved conflicts for 70dd1f77 to lmp-sprout-dev

* commit '463068b8':
  Fix NOT_RESTRICTED network capability and enforce it.

am e2840825: am 1904f9d4: am aa1b0618: am b7710d07: resolved conflicts for 70dd1f77 to lmp-sprout-dev

* commit 'e2840825':
  Fix NOT_RESTRICTED network capability and enforce it.

* commit '1904f9d4':
  Fix NOT_RESTRICTED network capability and enforce it.

* commit 'aa1b0618':
  Fix NOT_RESTRICTED network capability and enforce it.

* commit 'b7710d07':
  Fix NOT_RESTRICTED network capability and enforce it.

Change-Id: I6998f13b2c3b76315c285e85f3ae485f83e418d0

A previous fix to help us ignore obsolete messages introduced a bug:
in the DataConnection.mRetryingState if we get a request to CONNECT
we noted we already had that apnContext in our list and would not re-add.
This was a loose translation from when the list really was a list,
but now that it's a map we need to update the ConnectionParams with the
latest or we'll remember the old obsolete generation number.

The fix is a simple removal of the if(contains).  The rest is some logging
improvements to help out next time.

bug:24242653
bug:22776917
Change-Id: I934cc6bdb4f165e84f19f9cdb05a86a44912bdf8

We rely on this intent to trigger IMS config update.

Bug: 24270744
Change-Id: I69494c5269352ed6afa567661752b484918c4b6b

Call updateMediaCapabilities() from ImsPhoneConnection.update().
This code was accidentally deleted in d9c3a08d.

Bug: 24256715
Change-Id: I65e8c39b00e3cfd9cc3bde3d7dddaba7953eb562

bug:24106542
Change-Id: Ic749b05845309412804d782b242dc7ecb516c5be

Allow the API to specify if the selection should be persisted across reboots.
This also has the side affect of not notifying the user when signal is lost.

Necessary becasue the API might be used transparent to the user and the
notifications will be bizarre.

Bug: 23971948
Change-Id: Ic07d3a4b531b0bc89f26617ffae4bb678488d958

The check was looking at last character to determine if dialed
number is UT which is not correct. Should look at the last character
of the network portion.

Bug: 24125413
Change-Id: I21e0d2ffac4548d74e68355db86a98516daee304

ImsPhone might be created when we are starting monitoring IMS service.
When we are creating ImsPhone, we are opening IMS service.
When IMS service is being opened, it might request default phone (which
might not be ready yet).

Bug: 24130556
Change-Id: I7677b3131b15c78f6c6ac008f0cbb06b1a427b5d

We changed the params on these messages from an ApnContext to a
Pair<ApnContext, Integer>.  There were some call sites using the old
style and leading to errors.

bug:24115252
Change-Id: Ice3f075b3b93b9e76c0f0be7923f5ae2041f7ab1

Ignoring phone switching during shutdown prevents initializing
the new phone, which sends attach request to the modem.

Bug: 23508972
Change-Id: I2a7bfaaebfc9ed3bc4a265b4fa0a31384195251e

* commit 'a61a2087':
  Let some messages get processed in emergency state

Some pings and infrastructure events were getting defered in
emergency mode.  This led to hung processes.

bug:24097705
Change-Id: I5415ae69bcf17a293d5af9ae093d7346b1dc076f

We should query the signal stregnth information from the modem
when RAT family changes instead of relying on the next unsolicited
signal strength information indication coming from the modem,
which might take a long time to come or even not come. By proactively
querying the info, we can make sure the up-to-date signal strength
is showing up on the UI.

bug: 22724699
Change-Id: I4c80b281cffb28a871d4e754f43c43b9809244a4

- This was a nit from a previous commit.  Adding an early-bail in the
method which cleanses instant lettering messages.

Bug: 22779583
Change-Id: I76010fca96323284cc06e5cbe596218e30d59dcf

Bug: 23804201
Change-Id: I62a00530200d81a7494637bc760f258219389c42

Currently call extras are closely coupled with call state changes.
To propagate call extras from internal.telephony.Connection the
PRECISE_CALL_STATE_CHANGED event shall be triggered which is genarally
triggered when phone/call changes its state. This change removes the
above mentioned dependency by raising onExtrasChanged event when
changes in extras are detected.

Bug: 22329706

Change-Id: I7c0f5dc3229b2d7ae83d06a8e3fade45d1b62c90