PermissionMonitor only saves netd network permissions by appId.
Then apply same permision to uids which are same appId. But
UIDS_ALLOWED_ON_RESTRICTED_NETWORKS can allow single uid has
restricted network permission. Thus, save the netd network
permissions by uid that can apply different permission to each
uid.
Bug: 192431153
Test: atest FrameworksNetTests
Change-Id: I942cbe0fa30758a7497c47a1b684ed70c4e3b09e
NetworkRequest is expecting transport type Ethernet or test. This
causes the test 'testApiCallbacks' to fail for devices that have a
non-test Ethernet network since that network is being chosen instead of
the expected test Ethernet network.
Remove network capability TRANSPORT_ETHERNET from CaptivePortalApiTest.
Bug: 204329523
Test: atest android.net.cts.CaptivePortalApiTest#testApiCallbacks
Signed-off-by: Davor Majdandzic <davor.majdandzic@aptiv.com>
Change-Id: Ie7b4d00c08f1497044e63462f1d899d1f3dea2df
see kernel/private/wembley/+/refs/heads/tm-4.19/include/uapi/linux/if_arp.h
which has #define ARPHRD_PUREIP 520 (and is a Mediatek based device)
or Qualcomm based Pixel 3 and older kernels (<=4.9) which #define ARPHRD_RAWIP 530
(unlike Pixel 4/5 which are 4.14/4.19 and use the upstream ARPHRD_RAWIP of 519)
We stop supporting 520/530 starting with 5.11+ since those as GKI 2.0 only kernels
cannot be using non-upstream-ed constants (btw. this is probably true for 5.10-S
as well, but let's play it safe). For pre-5.11 we're lucky because even now
(with 5.15 released) upstream has yet to define an ARPHRD_* for either one of
520 or 530, so there's no harm in 'squatting' on this unused space.
This approach also means there's absolutely no change in behaviour on
pre-launch-T devices, since they all are at most running 5.10 kernels.
We'll be able to get rid of this code in the far future once we stop shipping
mainline tethering updates to pre-5.10 Mediatek or pre-4.14 Qualcomm devices.
This will likely be many years.
Test: TreeHugger
Bug: 207057951
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I767b5fc56bc826e088507aea8ae7a30aa8aa424a
The defaults can be used to enable/disable connectivity next targets
depending on the branch, while minimizing merge conflicts.
The "next" target may use unstable APIs. It need to be disabled in the
branch which only have the last stable SDK available.
Also correct TetheringTestsLatestSdkLib which should use stable API.
Test: TH
Change-Id: I00d91bbd513277c1cedf67d18ac9f56cc4037309
The TODO is used to track to remove dependencies from
ConnectivityService. Remove it since that was already done.
Test: remove comment only
Change-Id: Ida8c1124e110f64262a693dcddfbc7a9549510da
The header file is referenced by the part going to be mainlined in Netd.
Note that some platform visibility is required with this commit, since
users of bpf_shared.h is currently located in platform. The visibility
can be removed when all users are moved out of platform.
Bug: 202086915
Test: m; flash; boot
Test: cd system/netd && atest
Test: cd packages/modules/Connectivity && atest
Test: atest FrameworksNetTests
Change-Id: I5c16511b6a2d4eb80dfd93157cbc98d5030bd5ac
The folder is currently used by tether offload only. Because we will
move netd.c and clatd.c to it, the folder should be moved to the upper
tier.
Also, rename bpf_tethering_headers to bpf_connectivity_headers so that
other connectivity code besides to tethering are justified to use it.
Bug: 202086915
Test: atest FrameworksNetTests
Change-Id: I95943c6e909f1fdca12604ef0c55d67c39ca686b
Nothing uses StateMachine in service-connectivity, and
FrameworksNetTestsLib pulled a lot of unused dependencies with
services.core and services.net.
Remove unused dependencies. This helps measure code coverage more
accurately.
Bug: 207020032
Test: atest ConnectivityCoverageTests
Change-Id: I39857865594a3263c4b1deeda23312c8e4f86a77
(this is required to make ipv6 tethering work with at least S.LSI modems)
Test: TreeHugger
Bug: 207057951
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Ic178db928ec7f74f69d7d4739b3b8439ff026625
Update the tests to use the newer NsdManager based on Binder interfaces
instead of AsyncChannel.
Bug: 190249673
Test: atest NsdManagerTest NsdServiceTest
Change-Id: I0991b598331e335a0bc211f010da7f034fb2441b
Note: due to the release version of the Connectivity/Tethering mainline
module being built from sc-mainline-prod, this won't actually take effect
until system/bpf bpfloader at version 0.6+ is merged in to that tree.
This doesn't really matter, since currently things default to v0.0+.
But there is no mainline module updatable pre-v0.2 supported OS
anyway. BpfLoader v0.2 is what shipped in Android S Beta 4 through
Android S Final.
Before S there simply was no bpfloader support for mainline updatable
ebpf code, while S Beta 3 and earlier shipped v0.0 which is badly
incompatible with even the current version of the mainline module.
Additionally v0.0 doesn't even parse this field, while v0.1 which
does was very short lived [~3 days] and can thus be utterly ignored.
As such this change is effectively a no-op, and even post merge
of bpfloader v0.6+ into sc-mainline-prod will still be effectively
a no-op.
So why do it? I want to explicitly document that these programs are S+,
so that I can change the default in the future to be T+.
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I7e5d0124700c7045abe16b1f3b504c9e88054ff2
Since you cannot include yourself we need an extra level of indirection,
to make sure that OWNERS remains current even in historical branches.
Also vastly increase the number of OWNERS
Test: N/A
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I19723fd9fbcee8fe3d8c9386ec5290d2764f2104
Apply NetworkStackNextEnableDefaults to CtsNetTestCases to disable it
in branches where NetworkStackNext and related targets should not be
built.
Test: presubmit
Change-Id: I850b4294aa4c3c01f8871760185ca7fedc0f8584
When NetworkInfo(null) or setDetailedState(null, any, any) are
called, S used to not crash but plant a null bomb for later
which may explode in some calls (notably, parceling) : see the
bug referenced below for details.
To help catching these errors earlier a patch was made to crash
as soon as one of these methods is called with a null argument,
but this will also crash incorrect use on existing code that
may never actually step on the mine, crashing code that used not
to crash. For safety, implement the new behavior only on T.
Bug: 145972387
Test: NetworkInfoTest
Change-Id: Ib710497d83b2d26439c2bd4d2f572310db97d6fd
Currently CS test uses a mock ProxyTracker object to verify that
the sendProxyBroadcast() is called. Also, if the network is a
default network then sendProxyBroadcast() will be indirectly
called in setDefaultProxy(). This only verifies that the method
is called but it doesn't verify that the broadcast is sent.
Instead of testing setDefaultProxy() is called, it is better to
verify that the broadcast is actually sent. Therefore, use a
real ProxyTracker in the test to verify the broadcast is sent.
Test: FrameworksNetTests:ConnectivityServiceTest
Change-Id: Id5c9e07e8326f24bd2665b4bb08f96d6d57d999c
1. There is a theoretical issue where the callback is not yet
registered when wifi is disabled, but there is no evidence
of it actually happening
2. 2 minutes timeout makes no sense for these tests that have a
total 1 minute timeout anyway
Bug: 196387278
Test: CtsNetTestCases
Change-Id: I120af9b312ca34431d0e62dd85233fcdaa1b09b9
Mark NetworkCapabilitiesTest as ConnectivityModuleTest so that it is
only run in MTS with the Connectivity module installed, and fix
parceling tests to use the right number of fields in that case.
NetworkCapabilitiesTest is only useful to test the Connectivity module,
and not other modules like NetworkStack, as it is a unit test of a class
in the Connectivity module.
Bug: 205901761
Test: atest NetworkCapabilitiesTest
Change-Id: I10ba0f866bc7a39b2c90bdde12a79feefea2d5ee
