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)
Warn user of potential data charges if the backhaul is
cellular and user is roaming.
Bug: 145629001
Test: atest TetheringTests
Change-Id: I74b4f87c2f6aad09e05d3f2a779f880396885953
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
Since it's not used for now.
Test: TH
Bug: 153304048
Merged-in: I1812818c3d49463c3840a98212bbab58a110359a
Change-Id: I1812818c3d49463c3840a98212bbab58a110359a
EntitlementManager and its callers(Tethering and UpstreamNetworkMonitor)
run in the same threads.
Bug: 141256482
Test: atest TetheringTests
Change-Id: I0a376d28b123eaab2e8d00a98a4719ce983d3bb2
Reminder user of unavailable tethering status if there is no
internet access.
Bug: 147818698
Test: atest TetheringTests
Change-Id: Ic6557f9f7703337596100cd6a477fd7239217166
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
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
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
Change-Id: I26d89a81f1c448d9b4809652b079a5f5eace3924
With b/150232615, we will need an explicit value set for the exported
flag when intent filters are present, as the default behavior is
changing for S+. This change adds the value reflecting the previous
default to the manifest.
Bug: 150232615
Test: TH
Change-Id: I25b55378df393cd4fb8932b7ae64f97eb9f1aa8e
Merged-In: I25b55378df393cd4fb8932b7ae64f97eb9f1aa8e
(cherry picked from commit dc03d15189)
With b/150232615, we will need an explicit value set for the exported
flag when intent filters are present, as the default behavior is
changing for S+. This change adds the value reflecting the previous
default to the manifest.
Bug: 150232615
Test: TH
Change-Id: I25b55378df393cd4fb8932b7ae64f97eb9f1aa8e
Merged-In: I25b55378df393cd4fb8932b7ae64f97eb9f1aa8e
(cherry picked from commit 9226d6c835cd57d10a7562f18143dbaae8601b43)
