A number of connectivity checks that protect system-only methods
check for CONNECTIVITY_INTERNAL, but CONNECTIVITY_INTERNAL is a
signature|privileged permission. We should audit the permission
checks, and convert checks that protect code that should not be
called outside the system to a signature permission. So replace
all CONNECTIVITY_INTERNAL to other proper permissions.
Bug: 32963470
Test: atest FrameworksNetTests NetworkPolicyManagerServiceTest
Change-Id: I8f2dd1cd0609056494eaf612d39820e273ae093f
Merged-In: I8f2dd1cd0609056494eaf612d39820e273ae093f
Apps that do their own DNS queries need to know the NAT64 prefix
to resolve v4 addresses on v6-only networks.
Test: FrameworksNetTests NetworkStackTests
Bug: 144877069
Change-Id: I5a255b7afc2038646b93a0ab893f8ad62d0fb34f
This CL deletes the reference to this API as its used in a dead code
which is used for debugging only.
Bug: 140908357
Test: Build
Change-Id: I9fa1996ab5fdb5ab884128d06c2e92bab164dea7
Add formal API's for API's that the wifi mainline module uses:
a) NetworkScoreManager.requestNetworkScores - Request new network scores.
b) NetworkScoreManager.registerNetworkScoreCallback - @SystemApi wrapper
over the existing registerNetworkScoreCache.
c) NetworkKey.createFromScanResult - Create NetworkKey from ScanResult.
Also,
a) Converted the existing WifiNetworkScoreCache callback implementation to
support both the new @SystemApi (used by wifi) and the old @hide API
(used by settings).
b) Stopped invoking dump on all the callbacks from NetworkScoreService.
The dump of each callback should be invoked at their client site (i.e
wifi service should dump state of the callback it registers with the
service).
c) Added a helper method |dumpWithLatestScanResults| to help dump the
state of the WifiNetworkScoreCache from wifi service.
Bug: 144487252
Test: a) Device boots up and connects to wifi network.
b) Manually verified that network scores are being requested & updated
with the new interface.
Change-Id: Id5a66189150e7a088127519373a832f63bdd12ac
Merged-In: Id5a66189150e7a088127519373a832f63bdd12ac
(cherry-picked from c278f80c28)
With Telephony moving to Mainline these constants are not accessible
any more, and should not be made public. As they are only used by
a deprecated method that can only be called by apps with a target
SDK < M and only for one of the features it used to handle, copying
the constants until this method is completely removed is the simplest
way to go.
Test: FrameworksNetTests
Bug: 144454341
Change-Id: Iea18c8d2f2c8a40f04db9383d3f74b917267ba25
Moving IpConfiguration methods to system API
for mainline support.
Public copy constructors of ProxyInfo and add
buildPacProxy(Uri, int) to create a new proxy
properties.
Bug: 139268426
Bug: 135998869
Test: atest android.net.cts
atest android.net.wifi.cts
atest FrameworksNetTests
./frameworks/opt/net/wifi/tests/wifitests/runtests.sh
Change-Id: I07bcd2a34a222ea2b3cf0d8b497f051011c41c2c
This is a regression in performance but it is necessary for
the sake of refactoring ; when the refactoring is over, the
performance will be improved back.
Test: ConnectivityServiceTest
Change-Id: I7069c11193dccb7dce6af65cfb731c0f4ad93629
a) Ensure the Builder.build() does not crash if setDnsServers() is not
invoked.
b) Add a checkNotNull on setDnsServers() since it is marked @NonNull.
Bug: 144487020
Test: Compiles
Change-Id: I2b9f990efa0583c0f067c25e23d8c944ffbdf6a5
(cherry-picked from d0348339c50eeae0fe137c62476f6a01542f4163)
go/cleanup-greylist-txt
These have already been greylisted, however due to bugs/omissions in the tooling have been kept in go/greylist-txt instead of being annotated in the code.
Bug: 137350495
Test: m
Change-Id: Id6c1f5e403a0e66edb1102ee45f3bf19f244fb09
Merged-In: Id6c1f5e403a0e66edb1102ee45f3bf19f244fb09
See go/UnsupportedAppUsage for more details.
These have already been greylisted, however due to bugs/omissions in the tooling have been kept in go/greylist-txt instead of being annotated in the code.
Bug: 137350495
Test: m
Change-Id: I5aa29a49b193db47aaee4d3a756c17f48cc9f0b1
Merged-In: I5aa29a49b193db47aaee4d3a756c17f48cc9f0b1
It's the first patch for refounding network selection. The new
network selection will try to compare the networks by more
factors, and will try to choose the best network after doing
the evaluation of trade-off.
Create the object that will serve to represent network quality
for more comprehensive ranking.
Bug: 143676287
Test: 1. Build pass.
2. atest FrameworksNetTests
Change-Id: I4b6071d14365aa84d06be9802516fedf527e70f7
Problem & Root cause:
the mInterfaceBroadcastAddr.sll_protocol is not assigned when the
interface initializes, sll_protocol is 0x0000 by default.
This causes packets to be filtered incorrectly in packet capture,
typically with tcpdump. The previous API is used by DhcpClient, causing
DHCP tx messages to not be recognized properly.
Background: inside the kernel packets carry both an ethertype metadata
(skb->protocol) and may also carry a real ethertype in the mac header.
Previously skb->protocol would be inherited from the socket either from
the protocol from socket() creation or from bind(). This was zero,
so skb->protocol would end up 0, even though the DHCP packets we actually
wrote would have the right on-the-wire ethertype populated in the bytes
passed to send().
As such DHCP packets would look correctly on the wire, but were lacking
the skb->protocol metadata to correctly tag them as IPv4.
This results in 'tc' and packet hooks potentially not triggering
correctly, and can thus result in tcpdump 'ipv4' filters discarding
these packets leading to confusing/erroneous tcpdump output.
In newer kernels (somewhere around 5.3), if socket protocol is 0, we
actually parse out the right ethertype from the mac header during send().
However, for old kernels we can't rely on this kernel magic, and the
right fix is simply to make sure that socket bound protocol is correctly
set to ipv4 [htons(ETH_P_IP)] in the bind() system call.
Solution:
Add a new constructor in SocketUtils to set the protocol parameter.
Bug: 133196453
Test: manual test
Change-Id: I07887b82e0e32aadb0cbb9f930f2b2fa3e277ca9
Provide a specifc notification to let users know that device
has no internet is because it really doesn't have internet access
or it's caused by private DNS resolution failed.
Bug: 113242081
Test: atest FrameworksNetTests
Change-Id: I710c88a4742f5fd56c39fc797d7fa3ad36dba553
