Test: build / treehugger
Bug: 146727827
Exempt-From-Owner-Approval: Cherry-picking from goog/master to aosp/master
Merged-in: Ie1ad6711c490c679ebcfacd97154380a8810ba1c
Change-Id: Ie1ad6711c490c679ebcfacd97154380a8810ba1c

Test: atest TetheringTests FrameworksNetTests NetworkStackTests
Bug: 152055812
Change-Id: I0158d88e364772f9ac258bd18955edcdad266ad8
Merged-In: I0158d88e364772f9ac258bd18955edcdad266ad8
(this is a clean cherry-pick from ag/10796412)

Change-Id: I64f1527d79085cc5dfd78c01a6c49c4df87c82e7

Test: atest TetheringTests FrameworksNetTests NetworkStackTests
Bug: 152055812
Change-Id: I0158d88e364772f9ac258bd18955edcdad266ad8

Bug: 147768409
Test: m checkapi
Merged-In: Idd041f0fbeca411ea23e49786a50dd7feb77ef45
Change-Id: I3da71661048b1f66522696e9333c2c14a224fe9f

This adds metalava api tracking generation to the module
stub rules, to make sure we know exactly what API a
particular module stub exports.

Bug: 147768409
Test: m update-api check-api
Exempt-From-Owner-Approval: approved internally
Change-Id: Iaf2ef5b5751eb208d119ddbc74481239366fe581
Merged-In: Iaf2ef5b5751eb208d119ddbc74481239366fe581
(cherry picked from commit e7c52c7e)

Per API review:
- @IntDef defined on the type integer parameter
- have getters on each parameter that is set in the
  TetheringRequest.Builder
- new added API should not be deprecated
Below APIs is moved from system-current to module-lib-current that only
plafrom code(e.g. ConnectivityManager and Settings) can use them.
TetheringRequest.
onTetherableInterfaceRegexpsChanged, TetheringInterfaceRegexps:
Only platform code can use them because interfaces by regular
expressions are a mechanism which is planning to be deprecated.

Also rename some constants for easier to understand.

Bug: 149858697
Bug: 151243337
Test: m doc-comment-check-docs
      atest TetheringTests
Change-Id: Idd041f0fbeca411ea23e49786a50dd7feb77ef45

Application can specify static ipv4 server and client address to setup
tethering and this is one shot configuration. Tethering service would
not save the configuration and the configuration would be reset when
tethering stop or start failure.

When startTethering callback fired, it just mean tethering is requested
successful. Therefore, callers may call startTethering again if
startTethering successful but do not receive following tethering active
notification for a while. Tethering service never actually does anything
synchronously when startTethering is called:
  -startProvisioningIfNeeded just posts a message to the handler thread.
  -enableTetheringInternal doesn't do anything synchronously, it just
  asks the downstreams to get their interfaces ready and waits for
  callbacks.
If tethering is already enabled with a different request,
tethering would be disabled and re-enabled.

Bug: 141256482
Test: -build, flash, boot
      -atest TetheringTests
      -atest CtsTetheringTest

Change-Id: I2b2dd965a673e6f1626738d41b5d443f0f9fbd0e
Merged-In: I0399917e7cefa1547d617e688225544c4fc1a231
(cherry picked from commit 5d6723e24e21154bef3967585a8adc069e007f49)

This adds metalava api tracking generation to the module
stub rules, to make sure we know exactly what API a
particular module stub exports.

Bug: 147768409
Test: m update-api
Exempt-From-Owner-Approval: Approved in master
Change-Id: Iaf2ef5b5751eb208d119ddbc74481239366fe581
Merged-In: Iaf2ef5b5751eb208d119ddbc74481239366fe581
(cherry picked from commit b602b0b2f18d96866a5d7e5d27958af774d1f802)

This adds metalava api tracking generation to the module
stub rules, to make sure we know exactly what API a
particular module stub exports.

Bug: 147768409
Test: m update-api
Exempt-From-Owner-Approval: Approved in master
Change-Id: Iaf2ef5b5751eb208d119ddbc74481239366fe581
Merged-In: Iaf2ef5b5751eb208d119ddbc74481239366fe581