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
The NetworkStack.getService() API should be used instead.
Bug: 151243982
Test: atest FrameworksNetTests TetheringTests
Manual tethering test
Change-Id: I7855090bffbe895c8349ad4903b8f2eb55515f0b
Currently, in NetworkStats, there are many methods to manipulate
the records. However, some methods are similar and ambiguous,
such as addEntry, addValues, setValues, addIfaceValues,
combineValues and combineAllValues.
Thus, properly grouping and renaming methods are necessary.
In this change, for methods that add one record conditionally,
name them addEntry.
addValues -> addEntry
Test: atest FrameworksNetTests ImsPhoneCallTrackerTest TetheringTests
Fix: 148895143
Change-Id: I9495a198cf247e6c79100f7ac1edcea370b071de
Add comments to getters as requested in API review, and remove the
expirationTime private field that was planned to be replaced with
LinkAddress expiration.
Test: atest TetheringTests
Fixes: 150878126
Change-Id: Iecf65859cdeeaac2fa7b817b4f505c510424ac89
Merged-In: Iecf65859cdeeaac2fa7b817b4f505c510424ac89
(cherry picked from commit 594d0eae38c13e2bb03de0b3ae1f8781991c321e)
There are lots of Carrier/OEM requests for tethering
notification customization. So add a new tethering notification
updater class which can let OEM customize the behavior they
wanted.
Bug: 122085773
Test: atest TetheringTests
Change-Id: I7faacde7ac84e93ea0dfe03dd33d2cc41c589225
Merged-In: I7faacde7ac84e93ea0dfe03dd33d2cc41c589225
(cherry picked from aosp/1137358)
Add separate publicapi, systemapi and module_libs stubs for tethering.
Bug: 147768409
Test: m
Test: m framework-tethering-stubs-{public,system,module_libs_}api
Change-Id: I0ed44691b4e7080818442a9d0eb37d874f707195
The callback would be fired when offload started, stopped, or failed.
If offload is not supported, "failed" callback would be fired when user
enable tethering. Enabling multiple tethering would not have multiple
offload status callbacks because offload should already be started or
failed.
Bug: 130596697
Test: -build, flash, boot
-atest TetheringTests
-ON/OFF hotspotf
Change-Id: Ifb16dcedc8081833fa95a39596fe5cdc309ededd
Merged-In: Ifb16dcedc8081833fa95a39596fe5cdc309ededd
Merged-In: Ia0398601144b0e5f61dc0c5771eacf13e7cfbb59
(cherry picked from commit cd266076bed28459234c5d74ad373867944df116)
setLimit can be ignored if the quota is unlimited and not
changed, and the log could be omitted since it will still be
logged in HAL. Request stats update will print error log in
service if it is not correctly responded in time.
Test: atest TetheringTests
Test: manual
Fix: 149735152
AOSP-Change: 1242601
Change-Id: I01c0191d5b89942fa69b167b8a6b40ed2821300b
Merged-In: I92d214f4648fec6be13e04147290ecdd156fab4e
(cherry picked from commit b9565c7db00e44b50f9983691b603ebd6918ee45)
======
Fix a logic error in IpServerTest#addRemoveipv6ForwardingRules
When checking that link-local and multicast neighbours are
ignored, make sure the test neighbours are added on the correct
interface. Otherwise, they might be ignored because events on the
wrong interface are ignored, and not necessarily because
link-local and multicast neighbours are ignored.
Test: atest TetheringTests
Change-Id: I4a624ea4ce9ee9a9352afccbc7bf866587d4cdfa
======
Clear IPv6 forwarding rules when losing upstream or stopping.
Test: new unit test
Change-Id: I8626932e43e0daa300dad5fe6a81f47a6d667030
======
Bug: 149963652
Change-Id: I691053b22cb0b20e49419212f378cc473b1f35dc
(cherry picked from commit 3384bb9a4d7bd85370fe64e59f2872a5cab644d7)
Allow dispatchTetherConnectionChanged to pass in a null
upstream interface and/or null LinkProperties. This will allow
future tests to check what happens when the upstream interface
goes away.
Bug: 149963652
Test: test-only change
Change-Id: I7cfc32d072f23644159d33700d6cd830c426ea19
Merged-In: I7cfc32d072f23644159d33700d6cd830c426ea19
(cherry picked from commit 62457f17e72c7ef0bee5c5bb1a04935a549b9fe6)
BT tethering need to know whether tethering is supported for its caller
that call isTetheringSupported in binder thread under BT's process.
Current isTetheringSupported API is getting callerPkg inside
TetheringManager that would be BT's package name for bt tethering case.
Provide isTetheringSupported(String callerPkg) for caller to pass its
caller's package name if the use case is under binder IPC.
Bug: 146915889
Test: -boot, flash, boot
Change-Id: I01646fe045772c57b4e39a5e129531f8a2cea89f
Merged-In: I01646fe045772c57b4e39a5e129531f8a2cea89f
Merged-In: I2a35e1b6851e7a799c343be0dd60da23514768ba
(cherry picked from commit e09a92fabe7956692f34e94c198d9763bf76e53d)
This change fix two things:
1. Handle ethernet callback in internal thread to avoid crash. IpServer
should be created from tethering thread, otherwise mIpNeighborMonitor of
IpServer would throw
IllegalStateException("start() called from off-thread")
2. Ethernet tethering request may be duplicated if multiple
startTethering is called but no stopTethering
Bug: 130840861
Bug: 148824036
Test: ON/OFF ethernet tehtering manually
atest TetheringTests
Change-Id: Ibd3ea6bc6751bd65647ff381f9b0124bc3395c09
Merged-In: I7c5127e96d80d077735010d2e62c7227805ccb10
Merged-In: Ibd3ea6bc6751bd65647ff381f9b0124bc3395c09
(cherry picked from commit 72702b979654234c18045f04270040056a74cf90)
The build system collects transtive deps from jni_libs for APKs.
No need to list them explicitly in android_app definition.
Bug: 146992436
Test: m com.android.tethering
deapexer extract com.android.tethering.apex apex
unzip apex/priv-app/Tethering/Tethering.apk -u apk
ls apk/lib/arm64-v8a
Merged-In: Icba6ea3611c443cbf22ad6363d0239377d16ac9e
Change-Id: Icba6ea3611c443cbf22ad6363d0239377d16ac9e
(cherry picked from commit 9618b66f285ad5baa50b004b788d60272958a04d)
Mark updatable APEXes as updatable: true so that they are opted-out from
optimizations that make sense only for non-updatable modules; such as
symlinking to the libs in the system partition.
Bug: 149805758
Test: m and check that there is no symlink from the APEX to the system
partition.
Change-Id: Idb55300a60a261c7bb6359439ed220ff51fcf06c
The permissions are checked by Tethering; mainline modules should be
able to do permission checks based on these permissions.
Bug: 135411507
Test: m
Change-Id: Ib7f2aedfaaa909bbc356196114c62af9345f2593
am skip reason: Change-Id Ia4222fa35a9a2f3c75cebb12f75c536f27e2fe16 with SHA-1 e814258f09 is in history
Change-Id: I51ef292d3a4d28c62bbe8156b907183a0b56208b
am skip reason: Change-Id I96291038cf7b39a67547a5f74fcd7cbedc1ca002 with SHA-1 c8871c1b66 is in history
Change-Id: I046ad2de1e65468df9f70f189abfa1162f15a7c0
am skip reason: Change-Id I1fae97a1c1e0ba07fa3e2d64cde7650cd26d0acd with SHA-1 63dc279dfc is in history
Change-Id: Ifdfeae4e43afd3892ced4964d54e532a1f46e8fc
am skip reason: Change-Id I97ef83f7f9b4c1376f373713036f5256318f1050 with SHA-1 44fc26d19e is in history
Change-Id: I1771917998eeda2d18abb1f576e5091828651ea0
r.android.com/1213016 seems to have caused the following crash on devices
without wifi:
FATAL EXCEPTION: main
Process: com.android.networkstack.process, PID: 1041
java.lang.RuntimeException: Unable to create service com.android.server.connectivity.tethering.TetheringService: java.lang.NullPointerException: Attempt to invoke virtual method 'void android.net.wifi.WifiManager.registerSoftApCallback(java.util.concurrent.Executor, android.net.wifi.WifiManager$SoftApCallback)' on a null object reference
at android.app.ActivityThread.handleCreateService(ActivityThread.java:4005)
at android.app.ActivityThread.access$1500(ActivityThread.java:220)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1891)
at android.os.Handler.dispatchMessage(Handler.java:106)
at android.os.Looper.loop(Looper.java:216)
at android.app.ActivityThread.main(ActivityThread.java:7396)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:949)
Caused by: java.lang.NullPointerException: Attempt to invoke virtual method 'void android.net.wifi.WifiManager.registerSoftApCallback(java.util.concurrent.Executor, android.net.wifi.WifiManager$SoftApCallback)' on a null object reference
at com.android.server.connectivity.tethering.Tethering.<init>(Tethering.java:317)
at com.android.server.connectivity.tethering.TetheringService.makeTethering(TetheringService.java:90)
at com.android.server.connectivity.tethering.TetheringService.onCreate(TetheringService.java:81)
at android.app.ActivityThread.handleCreateService(ActivityThread.java:3993)
Fix it by null checking wifiManager before calling a method on it.
Bug: 142352330
Change-Id: I46e2f3053a59d3dba6a186a9eed34fa63b45d03e
We don't want new modules exposing stable aidl directly. APIs should
be defined as java @SystemApi. It also seems like nothing actually
depend on these interfaces, except one simple exception.
Bug: 147200698
Test: m
Change-Id: Ia4222fa35a9a2f3c75cebb12f75c536f27e2fe16
