The tether bpf offload can be enabled by resource config and
device config. The device config has higher priority and it
could override this config which is set by resource config.
Bug: 149997301
Test: -build, flash, boot
-atest TetheringConfigurationTest
Original-Change: https://android-review.googlesource.com/1276007
Use device option to control BPF offload features
If BPF offload device config is not enabled:
- Does not add/remove offload forwarding rules through disabling IP
neighbor monitor.
- Does not apply the RA MTU reduction.
Bug: 149997301
Test: atest IpServerTest
Original-Change: https://android-review.googlesource.com/1284578
Merged-In: I2d6f80f0229f580c4b16243a064e889a6c37f77a
Change-Id: I2d6f80f0229f580c4b16243a064e889a6c37f77a
To exempt from entitlement check, caller need to hold TETHER_PRIVILEGED
permission.
Bug: 141256482
Test: atest TetheringTests
Change-Id: I2eb37f5e92f5f5150a7fb7c25b945e28704d27a0
Merged-In: I2eb37f5e92f5f5150a7fb7c25b945e28704d27a0
1. Change ArraySet usage to BitSet
2. Change mCellularUpstreamPermitted to mLastCellularUpstreamPermitted.
Before this change:
a member variable(mCellularUpstreamPermitted) is
used to check whether cellular upstream is permitted, the code must
ensure to update this variable once entitlement result is changed or the
entitlement check is triggered but does not have a result yet.
In this change:
Instead of storing the information about whether cellular is permitted in
a member variable. The information is recalculated every time when user
call isCellularUpstreamPermitted(). Now isCellularUpstreamPermitted() is
always be used to check whether cellular upstream is permitted no matter
inside or outside EntitlementManager.
This make the code be easier to maintain that we do not need to care
when mCellularUpstreamPermitted need to be updated because the
information would be recalculated every time. And the recalculation is
lock free because this is only used inside tethering while running in
the same thread.
Bug: 141256482
Test: atest TetheringTests
Merged-In: Ic83f42ff4eec38adf039d55d80fcb9b0f16373cc
Change-Id: Ic83f42ff4eec38adf039d55d80fcb9b0f16373cc
In order to mock constant in unit test, a dependency object is
introduced with minimum code change to achieve this.
Test: atest TetheringTests
Bug: 149467454
Change-Id: I38628daddcb7be7c74846e78d36dc88f065b97d9
Merged-In: I38628daddcb7be7c74846e78d36dc88f065b97d9
(cherry picked from commit 29aee20bfa)
The OEM implemented tether offload does not support
data warning since the HAL only tells the hardware about data limit
but not warning. However, to add such interface in HAL needs OEM to
comply and implement in hardware.
Thus, as a short-term solution, polls network statistics from HAL
and notify upper layer when it reaches the alert quota set by
NetworkStatsService.
Note that when CPU is sleeping, the data warning of tethering offload
will not work since the polling is also suspended.
Test: manual
Test: atest OffloadControllerTest
Bug: 149467454
Change-Id: I2467b64779b74cd5fec73b42fb303584f52cb1cb
Merged-In: I2467b64779b74cd5fec73b42fb303584f52cb1cb
(cherry picked from commit 93660e382c)
Address issues found during AIDL review:
- Rename clientAddr to singleClientAddr
- Do not use a ParcelableBundle for notifyNetworkTested or
notifyDataStallSuspected; instead use AIDL parcelables for stronger
backwards compatibility guarantees.
Test: atest NetworkMonitorTest ConnectivityServiceTest
ConnectivityServiceIntegrationTest, manual
Bug: 153500847
Merged-In: Id9b71784e5f6294d203230e57737979e063ff0f8
Change-Id: Id9b71784e5f6294d203230e57737979e063ff0f8
Stop depending on Preconditions that is not released on the same cadence
as the module, and is maintained as part of the framework.
Bug: 148636687
Test: atest TetheringTests NetworkStackNextTests
Merged-In: Id0dcec44f362f79bc8c046d722635687a7388aa2
Change-Id: Id0dcec44f362f79bc8c046d722635687a7388aa2
Catch NoSuchElementException to unbreak no offload devices.
To consistent with fetching offload config service, retry fetcheing
offload control service.
b/152430668#comment4 assert that the fetch will be retried only
if the service is installed on the device.
Bug: 155026033
Test: run TetheringCoverageTests in virtual devices(do not support
offload)
Merged-In: Ie0a32a9062c722327a27c6de13e3bb8d9588bebb
Change-Id: Ie0a32a9062c722327a27c6de13e3bb8d9588bebb
1. Let restricted notification that can be dismissed.
2. Only put up restricted notification when any of tethering is
activating.
Bug: 154214549
Test: atest TetheringTests
Change-Id: Ib980aca154036828abdab35e3bb11d42f85ff610
Merged-In: Ib980aca154036828abdab35e3bb11d42f85ff610
(cherry picked from commit 2eb66bdbe4, aosp/1290334)
All carriers discarded the requirement to put up a standing
notification when tethering is on. Thus, remove the "tethering
is on" notification.
Bug: 154438388
Test: atest TetheringTests
Change-Id: Ife3915837b6b7b83d3eaaa84b71b6409ff37b71c
Merged-In: Ife3915837b6b7b83d3eaaa84b71b6409ff37b71c
(cherry picked from commit 0171c07d05dd2625c6dcfd47977a701ddc2d5d36, aosp/1289107)
The CL that moved the initialization of the tethering offload
config HAL from C++ to Java caused the code not to retry
fetching the service if it is not ready when tethering is
started. This is because the C++ version of getService() retries,
but the Java version only retries if getService(true) is called.
Make the new code retry as well.
b/152430668#comment4 asserts that the fetch will be retried only
if the service is installed on the device, so the retries should
be attempted (and thus should not have any startup time impact)
on devices that do not support tethering offload.
Bug: 152430668
Test: builds, boots, tethering offload works
Merged-In: I093f127d90b2aa1b13eb0748378a24726d419472
Change-Id: I093f127d90b2aa1b13eb0748378a24726d419472
Warn user of potential data charges if the backhaul is
cellular and user is roaming.
Bug: 145629001
Test: atest TetheringTests
Change-Id: I74b4f87c2f6aad09e05d3f2a779f880396885953
Merged-In: I74b4f87c2f6aad09e05d3f2a779f880396885953
(cherry picked from commit 1af69e5b8f339bde5b70886d80960ce22c847245, aosp/1237026)
EntitlementManager and its callers(Tethering and UpstreamNetworkMonitor)
run in the same threads.
Bug: 141256482
Test: atest TetheringTests
Merged-In: I0a376d28b123eaab2e8d00a98a4719ce983d3bb2
Change-Id: I0a376d28b123eaab2e8d00a98a4719ce983d3bb2
Reminder user of unavailable tethering status if there is no
internet access.
Bug: 147818698
Test: atest TetheringTests
Change-Id: Ic6557f9f7703337596100cd6a477fd7239217166
Merged-In: Ic6557f9f7703337596100cd6a477fd7239217166
(cherry picked from commit ac1b098acc504b60e85b3dcd22941f4e293865ae, aosp/1237036)
This is used to fix the race when quickly OFF/ON wifi tethering.
When IpServer is started/stopped, there is callback update tethering
interface status. Before this change, IpServer is stopped when wifi
ap is disabling. Then the next startTethering may fail in wifi because
wifi is in disabling state.
Error pattern: WifiService: Tethering is already active.
No unitest for this CL but it fixed the CtsTetheringTest flakty rate
than around 30% to 0 for more than 100 runs.
Bug: 153925821
Test: atest CtsTetheringTest --iteration 100
Merged-In: I8b65f621abe20799a3a0d410ba1f06368746ee49
Change-Id: I8b65f621abe20799a3a0d410ba1f06368746ee49
These events don't have MAC addresses, so the code attempts to
create an Ipv6ForwardingRule with a null MAC address. This
crashes when attempting to get the raw MAC address bytes to send
to netd in the TetherOffloadRuleParcel.
This was not caught by unit tests because the test exercise this
code path in a way that is not correct (by sending RTM_DELNEIGH
and NUD_FAILED events with MAC addresses). Fix the unit tests to
properly pass in null MAC addresses for these events.
Bug: 153697068
Test: fixed existing tests to be more realistic
Merged-In: I26d89a81f1c448d9b4809652b079a5f5eace3924
Change-Id: I26d89a81f1c448d9b4809652b079a5f5eace3924
1. Add TETHERING_ETHERNET to vaild downstream type. So starting
ethernet tethering will do entitlement check as well.
2. Ignore request with invalid downstream type on
handleRequestLatestTetheringEntitlementValue()
Bug: 152828758
Bug: 152828142
Test: atests TetheringTests CtsTetheringTest
Change-Id: Id0cb59cc4681f5ffbde7be54de05a05e46f0ffb8
Merged-In: Id0cb59cc4681f5ffbde7be54de05a05e46f0ffb8
(cherry picked from commit c502e050fd9543e8bde45014dd66ea1be91c90ef)
The netd tethering offload IPCs are changing from taking a list
of primitives to taking a TetherOffloadRuleParcel. Modify their
only caller.
Bug: 140541991
Test: atest IpServerTest
Merged-In: I83718c80ef9d31199c87021b4dd5821717fd5ba5
Change-Id: I83718c80ef9d31199c87021b4dd5821717fd5ba5
Tethering service is created after boot complete which means most of
the services are ready before tethering. Once tethering register the
callback, callback event may come-in immediately. Make sure all of
tethering related object is created, then register the callback,
receiver, or listener.
Bug: 149965121
Test: atest TetheringTests
manual on/off tethering
Change-Id: Ifdc427341db7d1313ad4b61207a96ab379d100aa
Merged-In: I3941a186770679e7b476073d774e2310e25e44c6
(cherry picked from commit 285be1ee938ddc9728ccc3e951ed0ed1b2fa7117)
Otherwise, if another downstream of the same type reappears, the
code would fire a callback with the previous list of clients.
Bug: 150644681
Test: atest TetheringIntegrationTests:EthernetTetheringTest --rerun-until-failure 100
Change-Id: I6b34ea747ae1831001077f44879bb6828dcecc96
Merged-In: I6b34ea747ae1831001077f44879bb6828dcecc96
(cherry picked from commit 3984360f642ddd5820ced5a6935e37a8ae0d9d76)
If tethering is restricted to the user, show restricted
notification to notify the user.
Bug: 122085773
Test: atest TetheringTests
Change-Id: Ic5baca2d6102886f4c3530ce1e321b5dab6ea9d7
Merged-In: Ic5baca2d6102886f4c3530ce1e321b5dab6ea9d7
(cherry picked from aosp/1188867)
Add new test for TetheringNotificationUpdater
Bug: 122085773
Bug: 130596698
Test: atest TetheringTests
Change-Id: I0db3df3e85dd6a8c3989c8bc66a06c50f45a0c15
Merged-In: I0db3df3e85dd6a8c3989c8bc66a06c50f45a0c15
(cherry picked from aosp/1209985)
Tethering notification can be customized by different subid. Thus
update notification when active data subid changed.
Bug: 122085773
Bug: 130596698
Test: atest TetheringTests
Change-Id: I799d713326cfbf4dc96c712c6b15ed5a4ac18dd2
Merged-In: I799d713326cfbf4dc96c712c6b15ed5a4ac18dd2
(cherry picked from aosp/1209984)
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
Merged-In: Iaf85e800569f2e08c39f7ebb96f8aa34f6e53133
(cherry picked from commit e54c92e5657abe2ce5da9dcba76b89c5e540cc44)
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)
The NetworkStack.getService() API should be used instead.
Bug: 151243982
Test: atest FrameworksNetTests TetheringTests
Manual tethering test
Change-Id: I7855090bffbe895c8349ad4903b8f2eb55515f0b
