Bug: 79161490
Test: build
Change-Id: Icf8c24f6d5b63a28272e383e5ab0641032710cdd

The actual target sdk for this changeid is currently irrelevant; it does
need to be larger than the target SDK of the CTS test app (to allow
opting in), and invisible in dev UI. The latter was already the case,
however made it explicit.

Bug: 149103556
Bug: 149469819
Test: adb shell dumpsys platform_compat | grep CTS_SYSTEM_API_CHANGEID
Change-Id: I64a10bb0964349eb212d26cf40e9f15ad2ba61da

Code Migration from frameworks/base/packages/Tethering ->
packages/modules/Connectivity/Tethering

BUG: 167962976
Test: m com.android.tethering + TH
Merged-In: Ib4a3a7a14d7d0e544aadf1bfb21ad390f1ba76a7
Change-Id: Ifae56d991b43c02f1e3496abbafc87d1869add8a

It's confusing that NetworkNotificationManager uses
NotificationManager to put up notifcation which is passed from
ConnectivityService. And that NotificationManager should be
gotten from a context with UserHandle.ALL because the
notification should notify to all users. But the future developer
may not know this and pass incorrect NotificationManager
probably. Therefore, adjust the design that
NetworkNotificationManager will get NotificationManager locally.

Bug: 170593746
Test: atest FrameworksNetTests
Change-Id: Id65c998052b7b223171c5194ea46b49d7e84729d

Fix NPMS lock contention:
Between 'com.android.server.net.NetworkPolicyManagerService$NetworkPolicyManagerInternalImpl.isUidNetworkingBlocked(int, java.lang.String)' and 'com.android.server.net.NetworkPolicyManagerService$NetworkPolicyManagerInternalImpl.getSubscriptionPlan(android.net.NetworkTemplate) on lock mNetworkPoliciesSecondLock.

Bug: 162350812
Test: regresstion test.
Change-Id: Ibbb4325c7380a2febf3682b3ae3436647ae82e16
Merged-In: Ibbb4325c7380a2febf3682b3ae3436647ae82e16

Since we created a new package(android.net.networkstack.aidl)
particularly for new added stable AIDL files, using generic
wildcards instead of enumerating each specific parcelable name.

Bug: 157534516
Test: atest FrameworksNetTests
Change-Id: I83f7ef42d0af1d691abd4b5892b079d4ab17e6b4

Merge "Introduce a BluetoothConnectionCallback that will fire off events when a device is connected or disconnected."

device is connected or disconnected.

Tag: #feature
Bug: 171902843
Test: Manual
Change-Id: I194a35a69fe0c5d960ea88a1a0fa52c8df7738e2

Clarify that NR is for NR NSA and LTE is for NR SA

Test: build
Fix: 165204098
Change-Id: I48259a0dce53b7a6a02c5e211b0ef7fc3d2aea30
Merged-In: I48259a0dce53b7a6a02c5e211b0ef7fc3d2aea30

Bug: 170360865
Test: manually check dumpsys
Change-Id: Ib4a3a7a14d7d0e544aadf1bfb21ad390f1ba76a7
Merged-In: Ib4a3a7a14d7d0e544aadf1bfb21ad390f1ba76a7

Strictly speaking other owners for SettingsProvider/test/...
should exist but there aren't any right now, so it's not
worth keeping a per-file rule since I don't think that
those can be combined with include.

Bug: 159055442
Test: Treehugger
Change-Id: I38c9c227e16c91f72ee0fc761670f82160e46ae2

This achieves two things:
- it's been noted that non-updatable-api is a confusing term as it has
  to be updated every time the API changes
- the api-review logic trigers on txt files in subdirs named 'api',
  which non-updatable-api does not trigger on

I will (less urgently) try to get rid of the term "non-updatable" from
other places too, perhaps going for "non-module" or "core" as a
replacement.

Bug: 171029603
Test: m checkapi
Change-Id: I843efb4880b6caaf3872e9b0918fd710fb93d979
Merged-In: I843efb4880b6caaf3872e9b0918fd710fb93d979

This target existed just to track the "full" module lib API surface,
until the individual pieces had the same standards. However, now:
- the full current.txt file is available as a build target
- all the individual .txt files are API reviewed, checked against
last api, linted, and changes result on API council bug updates

The .txt files will be removed in a separate CL.

Bug: 171029603
Test: m checkapi
Change-Id: Ib8ec547871045f77fb73aa82f192b5a7767d0c33

Change VibrateWaveformThread logic around delays while playing a
waveform to amortize processing/scheduling delays into the sleep part of
the thread. This should make the actual waveform duration closer to the
requested one.

Bug: 171133221
Test: manually check waveform vibration durations with dumpsys
Change-Id: I0ac88baf4127e9aebe56041a3a334ef8a2f8d43d
Merged-In: Iafe7f031444f68cd2cdc16883812874f385cba8e

INJECT_INPUT_EVENT_MODE_WAIT_FOR_FINISH appears to be used by espresso.

Bug: 171972397
Merged-In: Ic9df340620bf6c4e2cdd0dff077548f5807fa8e3
Change-Id: I4515f3029e86b63d2b05aa737243318ad20549ea

Bug: 171971817
Change-Id: Ib8367f9b310903d63eb000e4cce238693c1544b2

Bug: 171962076
Change-Id: Id2e731f471199a368b5a22046e0899d7b37f7337

Modern network agents are supposed to have the following
lifecycle :
• Construct the agent
• Declare itself to connectivity by calling #register()
• Possibly do some setup
• Declare connected by calling #markConnected()
• Declare disconnected by calling #unregister()

Internally ConnectivityService still manages the state
with deprecated NetworkInfo, which has a lot of possible
detailed states, most of which are now unused. Internally,
the steps above translate to the states below :
• When the agent calls #register() it starts in state
  CONNECTING
• When it calls #markConnected() it goes to CONNECTED
• When it calls #unregister() it goes to DISCONNECTED which
  triggers the flow that disconnects it immediately
• ConnectivityService also synthesizes the SUSPENDED state
  under some situations, but that's not relevant here.

The translation above is done by the NetworkAgent class,
which translates #register(), #markConnected() and
The only valid lifecyle for new agents is thus :

CONNECTING → CONNECTED → disconnect
                          ↑
             SUSPENDED ───┘

Note that in the above scheme, there is no space for the
UNKNOWN state, which is only used by legacy network agents.
However, the constructor for NetworkInfo still starts with
UNKNOWN. Ideally the constructor for NetworkInfo would set
the info to CONNECTING instead, but this would be a very
visible change in behavior affecting many apps (especially
their tests), so for backward compatibility we can't do
that.

New network agents however don't expose their NetworkInfo
to the client code, so they can just be made to start in
CONNECTING the way it was meant.

Note that this didn't really have a concrete impact beyond
printing some logs as by and large the ConnectivityService
code handles UNKNOWN and CONNECTING the same way, or more
exactly it handles transitions to CONNECTED from UNKNOWN
and CONNECTING in the same way. The exception to this is
VPNs, which are not using the new agent API yet, and the
upcoming conversion is why this fix is actually needed now.

Bug: 170904131
Test: FrameworksNetTests NetworkStackTests
Test: new test in aosp/1460705
Change-Id: Ib7d906a7b29a0b9f000b90bc78558a7402852fa3

Test: cts builds
Test: the new cts tests run
Bug: 170981222
Reference: I39921ef80c62cc331bb2d72a8d614986d3166eb9
Change-Id: I82d9581c2892eff282de02ce5810cf819a35d1d4

* changes:
  Fix comments from aosp/1455975
  Manage VPN legacy state separately from NetworkInfo