GitLab

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

bug:24462721
Change-Id: I348c70c4368c4d4d9ad466e4a6803f935bb43bc1

RSSI bar and Signal Strength are not changed when power up.
In booting time, RILJ does not receive any onDisplayChanged().
Thus ScreenState send false in updateScreenState() even if screen on.
So get display manager state after registering with DisplayManager.
As a result, mDefaultDisplayState set proper value.

Bug: 24748088
Change-Id: I8a56810a2a1e6b294d2ce2f3bc5837114312fc49

We remember the phoneId we used to make the request so when the request is released we can
talk to the proper DcTracker even if the subId -> phoneId mapping is lost (removed the sim).
However the list of requests is a singleton and entries are stored per requestId so
a request that applies to multiple phones only has a single entry - we can't record
the phone id at request submission time.

Change it to store the phoneId at request execution time.  This also removes the need
for a separate "has been executed" boolean since we won't have an executed-phoneId if
it's not been executed.

In the future we should get rid of multiple TelephonyNetworkFactories, simplifying all
this.

bug:24411288
Change-Id: Ie430e0a9251c3ae09384e1a4e29b65fe90f46740

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

Bug: 24469962
Change-Id: Iab43684169f9ea6abe7c4844cb8b0173bedb100b

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