Add UidNetdPermissionInfo class to store netd permission info of
each uid. Use the bit mask for combining all netd permission into
one value which can update and get the uid permission easily.
Moreover, aosp/1340042 add carryover package info into this class
which centralizes all netd permissions relevant data.
Bug: 132784544
Test: atest FrameworksNetTests
Change-Id: I3b81ea2a5017e8f4d0d603144a33c9b08640d7ba
The semantics of FileDescriptor in AIDL are that the callee must close
the file descriptor it receives manually.
Bug: http://b/157789860
Test: treehugger
Change-Id: Ice9fc9abe2959a84ad138a95c900dff676653665
There are two parts in hasRestrictedNetworkPermission method.
One is carryover package check and one is uid permission
check. Seperate carryover package check part to another method
to be clearer the usage of hasRestrictedNetworkPermission method.
Bug: 132784544
Test: atest FrameworksNetTests
Change-Id: Iab0609fcaa52acb0dfcb31ca957f22bfe8d62392
PermissionMonitor check permission by each package name but only
update the uid permission to netd. It's better to check
permission by uid directly. Thus, use
ActivityManager#checkUidPermission to check permissions for each
uid.
Bug: 132784544
Test: atest FrameworksNetTests
Change-Id: I057d34383b4dc408b2773e4c6b146774ba0c5eb2
Add Dependencies class in PermissionMonitor for injection
in tests easily.
Bug: 132784544
Test: atests FrameworksNetTests
Change-Id: Ibb84d548908f7a955fa0ff206794486733259978
Update all callers to use ProxyInfo(Uri) and remove ProxyInfo(String).
Bug: 160557668
Test: build pass
atest FrameworksNetTests
Change-Id: I4c980764c8839c48acf03208bb68cd53eb910121
This change updates ConnectivityService to notify the
ConnectivityDiagnosticsHandler of app-reported connectivity before
attempting to revalidate the network. This change forces an ordering on
Connectivity Diagnostics events in the case that the reported
connectivity does not match the known connectivity for the network -
this leads to the network being revalidated and the
ConnectivityDiagnostics event onConnectivityReportAvailable. Passing the
onNetworkConnectivityReported event to the
ConnectivityDiagnosticsHandler first ensures that it is passed to
callbacks before any potential ConnectivityReports are.
Bug: 159718782
Test: android.net.cts.ConnectivityDiagnosticsManagerTest
Change-Id: Ic7bc7138c54c47bbfdf56af5811709fde66f8606
There are two methods to handle package added/removed from
two differnt listeners. It can use one of listener to handle the
changes. Thus, keep PackageManagerInternal#PackageListObserver
but remove the listening from ConnectivityService.
Bug: 132784544
Test: atests FrameworksNetTests
Change-Id: Ib2db85e4108f9fda731bf6667d0af0610fc79fea
ConnectivityService puts up some notifications with pending
intents, but these pending intents are mutable that content can
be changed by someone. So make these pending intents to be
immutable.
Some OEMs have their own Settings package. Thus, need to get the
current using Settings package name instead of just use default
name "com.android.settings".
Bug: 154928507
Test: atest FrameworksNetTests
Change-Id: I02e3277358623400aa03dc8996af3d7c46a8ce76
Merged-In: I02e3277358623400aa03dc8996af3d7c46a8ce76
ConnectivityService puts up some notifications with pending
intents, but these pending intents are mutable that content can
be changed by someone. So make these pending intents to be
immutable.
Some OEMs have their own Settings package. Thus, need to get the
current using Settings package name instead of just use default
name "com.android.settings".
Bug: 154928507
Test: atest FrameworksNetTests
Change-Id: I02e3277358623400aa03dc8996af3d7c46a8ce76
Probe DNS servers to see they support DNS-over-TLS. Use system
CAs to verify whether the certificates sent by DNS servers are
trusted or not. An error is thrown to cause the probe failed if
DNS servers send untrusted certificates.
Unlike the DnsResolver which doesn't verify the certificates
in opportunistic mode, all of the DoT probes from NetworkDiagnostics
check certificates.
DoT probes apply to the DNS servers gotten from LinkProperties
and the DoT servers gotten from PrivateDnsConfig whatever private
DNS mode is.
A common example in DNS strict mode:
. DNS TLS dst{8.8.8.8} hostname{dns.google} src{192.168.43.2:48436} qtype{1} qname{815149-android-ds.metric.gstatic.com}: SUCCEEDED: 1/1 NOERROR (432ms)
F DNS TLS dst{192.168.43.144} hostname{}: FAILED: java.net.ConnectException: failed to connect to /192.168.43.144 (port 853) from /192.168.43.2 (port 41770) after 2500ms: isConnected failed: ECONNREFUSED (Connection refused) (172ms)
. DNS TLS dst{8.8.4.4} hostname{dns.google} src{192.168.43.2:37598} qtype{1} qname{759312-android-ds.metric.gstatic.com}: SUCCEEDED: 1/1 NOERROR (427ms)
An example when the CA is not trusted:
F DNS TLS dst{8.8.8.8} hostname{dns.google}: FAILED: javax.net.ssl.SSLHandshakeException: java.security.cert.CertPathValidatorException: Trust anchor for certification path not found. (16ms)
An example when TCP/TLS handshake timeout:
F DNS TLS dst{8.8.8.8} hostname{dns.google}: FAILED: java.net.SocketTimeoutException: failed to connect to /8.8.8.8 (port 853) from /192.168.2.108 (port 45680) after 2500ms (2514ms)
Bug: 132925257
Bug: 118369977
Test: atest FrameworksNetTests
Change-Id: I1b54abed0e931ca4b8a97149459cde54da1c3d6f
Previously, we read the global proxy settings from Settings.Global
database after reboot. This works for manual proxies, but not for
proxies based on PAC rules, as PacManager is never invoked when
ConnectivityService starts up. As a consequence, services required for
PAC-based proxies (PacService and ProxyService) are never started.
In this CL, we make sure PacManager is called during boot, so that PAC
rules will take effect.
Bug: 35943997
Test: set a PAC proxy and observe it still works after reboot
Change-Id: I69edb5fcd3e84663d338ff4b93c40fd5ee2c8c51
This commit changes agentConnect to set the owner UID as the mOwnerUid
field instead of the Binder.getCallingUid().
Binder.getCallingUid() can return incorrect results for platform VPNs,
as agentConnect() is called under a clean calling UID.
Additionally, this relaxes the ownerUid sanitization check to allow a
VPN network's owner to see it's own ownership information.
Vpn.mOwnerUid is guaranteed to be correct, as all VPNs MUST have called
prepareInternal() at some previous point, which sets mOwnerUid as the
package's UID (or SYSTEM_UID if this is legacy VPN).
Bug: 150135470
Test: CTS tests showing ownership information
Merged-In: Ic979dad73983d722365849fbfb0becfd432b894c
Change-Id: Ic979dad73983d722365849fbfb0becfd432b894c
(cherry picked from commit e29bf99a7fc1067c546d7fa6cbcb9001fb110d16)
Some developers have been surprised by this limitation and had trouble
figuring out what the issue was. Add documentation to address this.
This also includes a drive-by removal of a duplicate check.
Bug: 149867479
Test: doc-only change
Original-Change: https://android-review.googlesource.com/1313813
Merged-In: I5911d01984695550b6c9afe7a8eb535bf5e320a1
Change-Id: I5911d01984695550b6c9afe7a8eb535bf5e320a1
Some developers have been surprised by this limitation and had trouble
figuring out what the issue was. Add documentation to address this.
This also includes a drive-by removal of a duplicate check.
Bug: 149867479
Test: doc-only change
Change-Id: I5911d01984695550b6c9afe7a8eb535bf5e320a1
This commit changes agentConnect to set the owner UID as the mOwnerUid
field instead of the Binder.getCallingUid().
Binder.getCallingUid() can return incorrect results for platform VPNs,
as agentConnect() is called under a clean calling UID.
Additionally, this relaxes the ownerUid sanitization check to allow a
VPN network's owner to see it's own ownership information.
Vpn.mOwnerUid is guaranteed to be correct, as all VPNs MUST have called
prepareInternal() at some previous point, which sets mOwnerUid as the
package's UID (or SYSTEM_UID if this is legacy VPN).
Bug: 150135470
Test: CTS tests showing ownership information
Change-Id: Ic979dad73983d722365849fbfb0becfd432b894c
This consumes ~3.5% system logs, however it is not very useful
when debugging since similar information could be obtained from
dumpsys {connectivity|netpolicy}. Thus, remove the log.
Test: manual
Bug: 135504481
Change-Id: I04d2b7402f892546722fe6868c521afd9534f183
Merged-In: I04d2b7402f892546722fe6868c521afd9534f183
(cherry picked from commit 21a352f761ce558bea6fa9ab2a4e49a164228b56)
This consumes ~3.5% system logs, however it is not very useful
when debugging since similar information could be obtained from
dumpsys {connectivity|netpolicy}. Thus, remove the log.
Test: manual
Bug: 135504481
Change-Id: I04d2b7402f892546722fe6868c521afd9534f183
This change adds a comment to CS#simulateDataStall to explain why the
Data Stall is wrapped in a DataStallReportParcelable before being passed
to the ConnectivityDiagnostics handler. This approach is taken to ensure
that simulated data stalls are handled the exact same as Data Stalls
received directly from NetworkMonitor (including Data Stalls detected by
methods that the platform does not understand).
Bug: 156294356
Test: atest ConnectivityDiagnosticsManager
Change-Id: I751054418bf328c72b977a1cc99c27cb9b8ab7ba
Merged-In: I751054418bf328c72b977a1cc99c27cb9b8ab7ba
(cherry picked from commit c86db7497a27cfbac5c662911a295598b1335bc0)
This is only necessary when learning the NAT64 prefix from the
RA, because if the NAT64 prefix is learned from DNS, the DNS
resolver already knows the prefix and automatically enables
DNS64 synthesis.
The DNS resolver needs to be informed of the prefix any time
clat is running on a prefix learned from an RA. This is simple to
implement: just set the prefix when starting clat if prefix
discovery is not running, and clear the prefix when stopping clat
if prefix discovery was not running. This ensures that the prefix
is cleared iff it was set.
Bug: 156914456
Test: new unit test coverage
Original-Change: https://android-review.googlesource.com/1315578
Merged-In: If8ad2d30712a6df3e207c8d3e8a129705242191e
Change-Id: If8ad2d30712a6df3e207c8d3e8a129705242191e
This CL forwards suspected Data Stall events detected with unknown
detection methods to ConnectivityDiagnostics.
Currently, ConnectivityService drops any data stall events with unknown
detection methods, which leads to false negatives for Connectivity
Diagnostics registrants. This change ensures that registrants will still
be notified as NetworkStack is updated to use new detection methods.
The documentation for ConnectivityDiagnosticsManager#DataStallReport is
also updated to reflect that the detection methods included in the
report are a bit mask of detection methods used. Implicitly, this means
that data stalls detected via unknown methods will have an empty bit
mask (0x00).
Bug: 156294356
Test: atest ConnectivityDiagnosticsManager
Change-Id: I62d0bf91fcc17c7921afd519c72551399906bd6b
Merged-In: I62d0bf91fcc17c7921afd519c72551399906bd6b
(cherry picked from commit a1d9d811a05bf3447ebb90a39343b53eee79f0db)
