When the Ethernet interface becomes unavailable (e.g., because
the cable was unplugged or the interface was removed), or when
setEthernetTethering(false) is called, release the Ethernet
interface request.
This ensures that:
- The Ethernet interface immediately becomes available for use in
client mode.
- If an interface later becomes available, tethering is not
automatically started. This is consistent with what happens for
other downstream types such as wifi and USB. Evey time one of
those downstreams goes down, tethering is stopped and will not
be restarted.
Test: manual
Bug: 148824036
Change-Id: Iaf85e800569f2e08c39f7ebb96f8aa34f6e53133
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
Merged-In: I9495a198cf247e6c79100f7ac1edcea370b071de
(cherry picked from ag/10700816)
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: I0399917e7cefa1547d617e688225544c4fc1a231
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
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 hotspot
Change-Id: Ia0398601144b0e5f61dc0c5771eacf13e7cfbb59
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
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: I7c5127e96d80d077735010d2e62c7227805ccb10
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
Change-Id: I01c0191d5b89942fa69b167b8a6b40ed2821300b
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
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
Use IpNeighborMonitor to listen for ND cache events on the
downstream interface, and push downstream IPv6 fowarding rules
to netd.
Rules are pushed when:
- IPv6 neighbours appear/disappear on the downstream interface.
- The upstream changes.
Test: new unit test
Change-Id: I7b01ba179a4d6bb248fd6c4994e48800613a4efa
This is a temporary hack to workaround the inability of current
kernel's ebpf bpf_skb_change_mode() function to prefix a 14-byte
ethernet header on to a packet without going over the upstream
(source, rawip) interface's mtu *before* we bpf_redirect() to
the downstream (destination, ethernet) interface.
Test: build, atest, atest TetheringTests
Bug: 149816401
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I646148ebfd978a2489c0cd065e4b671b01150add
The callbacks are fired when the list of connected clients or their IP
addresses / hostname change.
Test: flashed, connected 2 devices, verified callbacks
Test: atest TetheringTests
Bug: 135411507
Change-Id: I96291038cf7b39a67547a5f74fcd7cbedc1ca002
Merged-In: I96291038cf7b39a67547a5f74fcd7cbedc1ca002
TetheringUtil JNI is too big that it statically linking hidl and its
dependency library. To remove these static libraries, calling hidl in java
directly instead of using JNI.
Bug: 148984662
Test: -build, flash, boot
-manually ON/OFF tethering
Change-Id: Id5a9759eb453fddaf0c3b7a31da17224e35e963e
Before this change, tetherStatesParcel may be null when there is no
avaialbe tethering interface yet. TetheringManager should handle null
case. But it is annoy to check null case each time and easy to have error.
Report non-null empty TetherStatesParcel object instead.
Bug: 148874619
Test: -build, flash, boot
-atest TetheringTests
-OFF/ON hotspot
Change-Id: I0717e7958c9409648170498d5e76322207856de3
mUserManager should be ready before #makeTethering because mTethering may
call isTetheringSupported which need to reference mUserManager
Bug: 148642028
Test: build
Change-Id: I100b5d6cc8f49640c33fa930b819033de5d6492c
Ethernet tethering can be started via
startTethering(TETHERING_ETHERNET).
Test: flashed, enabled ethernet tethering, verified internet access on
downstream.
Bug: 130840861
Merged-In: I34842acd94b972e440c3622f7617df10c18acf65
Change-Id: I34842acd94b972e440c3622f7617df10c18acf65
(cherry-pick with conflicts in test-current.txt)
This is initial work to allow caller to pass their prefered
configuration to start tethering. Caller may able to specify the
downstream interface ipv4 address with dhcp server disabled for
static IP configuration, or able to exempt entitlement check if
they have permission in follow up CL.
Bug: 141256482
Test: -atest TetheringTest
-ON/OFF wifi tethering
Change-Id: Ic7c3a33195bbd7e72f9b8e73fa148be476b87bf3
Merged-In: Ic7c3a33195bbd7e72f9b8e73fa148be476b87bf3
Also deprecated tethering APIs in ConnectivityManager.
Will have follow up change to remove @hide tethering function in
ConnectivityManager.
Bug: 145093446
Bug: 148038547
Test: -build, flash, boot
-atest TetheringTests
Change-Id: Ia432057bf9056727c4a0ca97d160a49274d33581
Merged-In: Ia432057bf9056727c4a0ca97d160a49274d33581
When leaving a group, all information are erased and no group interface
is passed to tethering service.
For separate group interface, tethering could be stopped
on p2p group interface removed. For shared group interface,
i.e. management interface and group interface share one
interface, ex. p2p0, tethering has no chance to be stopped since management
interface won't be removed after leaving a group.
Bug: 141382930
Test: atest FrameworksNetTests
Test: atest FrameworksWifiTests
Test: atest TetheringTests
Change-Id: Ib611018b67c76ff79c7e6658136721090feb145b
When data saver enabled, tethering would be OFF.
Currently settings would not allow user to turning tethering back.
After aosp/1181583 is merged, user can turn tethering back without
turning data saver OFF.
Bug: 145711175
Bug: 142374233
Test: atest TetheringTests
OFF/ON tethering when data saver ON
Change-Id: I59e662ba771a563f5f1766ba29e05246b8280220
Currently NetworkStatsService is notified when downstream is
updated. However, it seems unnecessary given that tether stats
is persist since boot, and there is no any upstream change when
downstream is changed.
Test: atest NetworkStatsServiceTest IpServerTest
Bug: 130855321
Change-Id: Ie300bfeb0a04678fcfcf300843b6f859af9df91d
