Add finals and annotations. Remove comments that have lost their
context (they were in the context of disabling a permission check
that had been added, but constituted an API change that would not
serve any real purpose).
Test: runtest
Change-Id: I1f879b2c105d2127072b88233d72097a0d78fe14
No logic changes. Only changes are adding nullability annotations,
final modifiers, and adding an s in a comment.
Test: runtests
Change-Id: If4986a25bb36819de8ff459c4c0439c56d4e5a50
The goal of this is to simplify ConnectivityService by reducing
the amount of code it contains. This is small enough to be obviously
correct and followup changes will move code into this class.
Test: runtest
Change-Id: Ic5ab19b521e98ae397c9bf657856820304362fbb
Funny how these things accumulate. Not exhaustive of course, but
still an improvement.
- Remove unused imports.
- Remove unused variables and members.
- Replace members with locals where applicable.
- Remove useless type parameters and explicit unboxings for Java 7.
- Conversely add the diamond operator for auto-genericity for
Java 6.
- Reduce visibility of members where possible.
Test: runtest frameworks-net
Change-Id: I13586aee09b4cd1c87c525fafb5eee44dedb5360
updateLinkProperties copied the linkProperties in networkAgent,
but the clat fix-up function did not copy stacked link into new one.
This caused an incorrect clat iface removal, and the IPv4 network
to be unreachable.
Clean cherry-pick of ag/4260470
Bug: 80261579
Test: 1. ping after ipv6 only data call with 2g voice call on/off
2. runtest frameworks-net
3. run cts -m CtsNetTestCases
Change-Id: Ide47a3b0680dddfcf3e2e759a59b19aee3605050
...as opposed to after the async channel finished disconnecting.
Clean cherry-pick of ag/4043255
Bug: 78308259
Test: runtest frameworks-net
also used a device with this patch over the weekend and
tried all I could think of
Merged-In: Ic4c7520e907de353a01c2a3a8a50d661dee4a994
Merged-In: I0617f0ff6e46a1d3764335a1e7ad01b34c8cc5a8
Change-Id: I4e4b41bbdf25d7d7bea4124cb58da004d47f1090
This is a pinpoint fix against the bug listed below. While a client
is synchronously reading the LinkProperties of a network, the
ConnectivityServiceThread is updating its properties. Make sure
that update is done atomically.
This is a stopgap countermeasure against a problem that is
pervasive with usage of LinkProperties, but fixing the problem
itself will happen later.
Clean cherry-pick of ag/4174798
Bug: 80077223
Test: runtest frameworks-net
Change-Id: I61b262d824c98b4ced36395a597b73de9193a199
Merged-In: I25007ac26349e451bb47f966af70d590d699c347
Merged-In: I03526187645b6955eb89ca4d2e4a930ebac236b8
Also add it in the logs of the notification manager.
Clean cherry-pick of ag/4022397
Bug: 78547904
Test: manual
Change-Id: I0afc18c94adf97154c61af2a5bdf933fb5f0e622
Merged-In: Iad5388a31a1502bc1944346276bb9600ac1386bd
Merged-In: I8bdd4a020e9d04f46847ef3c7e80ccf5c5cd19ea
Almost clean cherry-pick of ag/3889538.
Bug: 77737389
Test: runtest framework-net
new test don't pass without the main code change, but they
do with it
Change-Id: I0cd83a935ab0b349aa47e065b830e5a43ab9a091
Merged-In: Iaa0285825735d3f16bba6e4946723a437fd9b0b9
Merged-In: Ia8f985b448251f911484e6bd63fa562bffc1b0e4
Clean cherry-pick of ag/3918295
One-line adjustment for ag/3638326 which has not been put in AOSP.
Bug: 77737389
Test: runtest frameworks-net
Change-Id: I03ae2bbb08559f2cd44979e291c1f5d50eb215da
Merged-In: Iaa0285825735d3f16bba6e4946723a437fd9b0b9
Merged-In: Ia8f985b448251f911484e6bd63fa562bffc1b0e4
Cherry-picked from ag/3887738 ; almost clean CP, only had
to add an import.
Bug: 77114259
Test: frameworks-net pass
manual test shows the SSID is now displayed again
Change-Id: I5cb2b4777ad78d972031e8f2ff22e2155f4ab894
Merged-In: I588fedba49ea5d08e40bd2b3ea8ba2c2383958ec
Merged-In: I663a59ff2847a9f44ea1395326f6cb00e97237b6
Clean cherry-pick of ag/3580901
Bug: 72871435
Test: flashed and verified, also ran runtest framework-net
Merged-In: I177eff1237dd59514ccf91397a3d307148bc37b1
Change-Id: Ic5919a32f91f7baee5f1370703ad166e6ea52b58
ApfFilter maintains separate counters for each reason why a packet was
passed or dropped by the filter logic.
There's also a total which should match the individual counters,
*unless* the APF interpreter aborted execution early due to an illegal
instruction or an out-of-bounds access.
Test: both on APFv2 and APFv4-capable device:
runtest -x tests/net/java/android/net/ip/IpClientTest.java
runtest -x tests/net/java/android/net/apf/ApfTest.java
manual tests connected to an AP
Bug: 73804303
Change-Id: I54b17fcbb95dfaea5db975d282314ce73d79d6ec
Merged-In: I54b17fcbb95dfaea5db975d282314ce73d79d6ec
(cherry picked from commit f1089bfa95)
Support keeping IpClient logs around and dumping them
during dumpsys. Previously we got this benefit for
wifi by virtue of WifiStateMachine's long-lived nature.
Now that this is changing we need to be sure we have
logs, and this method gets us Ethernet logs as well.
Bug: 62476366
Bug: 77999594
Test: as follows
- built
- flashed
- booted
- runtest frameworks-net passes
- dumpsys connmetrics [ipclient] works
Merged-In: Ib4daf0902cae91acadbe9965de1fb73c96a47bec
Merged-In: Ie947394fabcaca7fc1d067f095c2442ee2704593
Change-Id: I1136a83de8097fdb4130debe1eaf689be7132fe5
(cherry picked from commit 78b85e6ca3)
Relies on events sent from netd in aosp/578162.
Test: Added tests to ConnectivityServiceTest. Added a new test
class DnsManagerTest. Built a simple app that appears to
receive onLinkProperties events correctly upon manual changes
to the private DNS settings on a Pixel.
Bug: 71828272
Change-Id: I68665aaf74b7d59182cc6f9586b80b55b0dfe427
Moves this out of ConnectivityService and into each NetworkMonitor
(where it's more self-contained).
Test: as follows
- builds, flashes, boots
- runtest frameworks-net passes
- manual testing with working and non-working hostnames behaves
somewhat (but not entirely) as expected, and not always quickly
Bug: 64133961
Bug: 72345192
Bug: 73872000
Bug: 77140445
Change-Id: Ic4322af3cb49149f2d975cb31f54b2ac7927f907
This change comprises the following parts:
[1] android.net.dns.ResolvUtil, containing methods that encapsulate the
use of the high bit in netids used in DNS resolution contexts.
[2] Updates to captive portal apps to call the ResolvUtil method that
enables DNS-over-TLS bypass for the captive portal app process.
Test: as follows
- builds
- flashes
- boots
- runtest frameworks-net passes
Bug: 64133961
Bug: 72345192
Change-Id: I2072c1f68d6978fa0d7e9d8693135a2c51bb0f87
Tethering currently wants access to complex isTetheringSupported
logic that is only available in ConnectivityService. Instead of
trying to access that via ConnectivityManager, pass this capability
in to Tethering directly, in the TetheringDependencies object.
Also:
- ConnectivityManager is only a source of static constants now,
so "import static" all the constants that are actually used.
Test: as follows
- built
- flashed
- booted
- runtest frameworks-net works
- manual USB towards WiFi tethering works
Bug: 68951715
Change-Id: Ia64faaadefb4a5d84a50da98bdebd544b6fda101
This will let ConnectivityService send the right callbacks to the
relevant apps.
Test: manual with apps
runtest frameworks-net
cts
new tests for this functionality
Bug: 67408339
Change-Id: I6f08efd9e73c7e191f833d7f307a3bf4c9e2f0b4
Useful for clients such as BatteryStats which currently rely
on NetworkStatsFactory. Data at that stage is incomplete as
it does not account for tethering, VT data and corresponding
464xlat corrections.
Test: runtest frameworks-net, CTS tests pass.
Change-Id: I763b77f601c827fd2963204694fb5b45425cc791
Currently, when a network goes into CONNECTED state, we call
updateLinkProperties and then notifyIfacesChangedForNetworkStats.
The latter is unnecessary, as there are exactly two cases:
1. networkAgent.linkProperties != null: updateLinkProperties will
call notifyIfacesChangedForNetworkStats, because oldLp is null
and networkAgent.linkProperties is not null.
2. networkAgent.linkProperties is null: there is no need to call
notifyIfacesChangedForNetworkStats, because no interfaces were
added or removed. When they are, updateLinkProperties will be
called again.
Removing the call to notifyIfacesChangedForNetworkStats avoids
a stats poll, which is a minor performance improvement.
Also, remove the NetworkStatsService code to do asynchronous
interface updates, since it has no callers.
Bug: 72107146
Test: builds, boots
Test: runtest frameworks-net
Change-Id: I9337ea26c0505a1c66ceda01254b68e25cd7972c
Fix test breakages I caused when adding cell
support for NATT keepalives.
-Make the minimum keepalive interval a constant in
ConnectivityManager and use it in tests.
-Re-Disallow IPv6 Keepalives
Bug: 73327535
Test: 'runtest -x ConnectivityServiceTest' now passes
Change-Id: I5ec4367d250ee371014e65c897c3897a25a05e2d
This has no concrete impact on the behavior of ConnectivityService,
but in principle TRACK_DEFAULT requests should not be counted toward
requests that make a network foreground. It does not have an impact
because only VPNs could be affected by this, and VPNs are always in
the foreground by definition.
Test: runtest frameworks-net
Test: cts
Change-Id: Id2ae6b5c9d542fe168e64ed713b6ec0a04062c82
NOT_SUSPENDED and FOREGROUND are capabilities that need to
be public so as to reach feature parity with what information
can be gotten through the use of CONNECTIVITY_ACTION and
synchronous calls to ConnectivityManager. This change makes
them public, and wires up the NOT_SUSPENDED capability.
This deprecates in effect the old onSuspended and onResumed
callbacks, but these have never been public.
This also converts the onAvailable path from a multiple
binder call design to a simpler, single binder call. This
is only for internal convenience
Test: runtest frameworks-net
Test: cts
Test: also manual testing
Change-Id: I6ea524bb361ecef0569ea2f9006c1e516378bc25
Prior to this change ConnectivityManager used to patch in the UID
of the requesting app inside the NetworkCapabilities sent to it.
The rationale was that the app may not know what other apps may
use the network, so the view it should have of the network should
always say the network only applies to that app.
But this has an unfortunate side effect : apps can't match the
received network against a default NetworkCapabilities. Ostensibly
this only applies to the system because all involved calls are
@hide, but still : system code would get some NetworkCapabilities,
for example using networkCapabilitiesForType, and then try to
match the capabilities of an available network using
satisfiedByNetworkCapabilities. Because the passed network is
declared to only apply to one's own UID and the UIDs of the
NetworkCapabilities are set to null meaning "I need this network
to apply to all UIDs", the answer will be "false".
While this is WAI in a sense, it is very counter-intuitive that
code trying to match a network would be required to patch in its
own UIDs.
There are three ways of fixing this :
1. Require all apps to do the above. It's correct, but it's
cumbersome and counterintuitive. Multiple places in existing
code needs to be fixed, Tethering is an example.
2. Write the UIDs of the caller in any NetworkCapabilities object
that is created. This is not very practical, because it imposes
the converse requirement on all NetworkAgents, which would then
have to clear the UIDs before they send the capabilities to
ConnectivityService. All NetworkAgents need to be fixed.
3. Instead of sending an object with a list of one UID to apps,
send a null list. The drawback is that the networks nominally
look to apps like they apply to all apps. I argue this does
not matter ; what matters is that the UID lists do not leak.
Clients just see a null list of UIDs (and third party can't
even access them without using reflection). No other changes
are required besides this two-line patch.
This patch implements 3. I believe it is the saner approach, with
both the most intuitive behavior and the best backward compatibility
characteristics, as well as the easiest change.
This does not encroach on the future plans to make the actual
UID list available to apps with NETWORK_SETTINGS.
Test: runtest frameworks-net
Change-Id: I978d91197668119e051c24e1d04aafe1644a41cf
KeepalivePacketData currently mixes multiple concepts: the
list of parameters that are used to generate a keepalive
packet, the keepalive packet itself, and the parameters that
are needed to send a keepalive packet over an ethernet link.
The KeepalivePacketData is now a parcelable that can be used
generically by any NetworkAgent, regardless of how that Agent
fulfills its duty to initiate and maintain a keepalive session.
Bug: 69063212
Test: verified with SL4A, additional tests pending
Merged-In: I23dc4827ae729583356a8ff0f02e39a2ad2b81f5
Change-Id: I23dc4827ae729583356a8ff0f02e39a2ad2b81f5
(cherry picked from commit 5be3f5a2b1)
Due to an issue resolving the boot classpath, the
KeepalivePacketData structure cannot be referenced
by frameworks/opt/telephony while it is in services.
-Move KeepalivePacketData to android.net
-Also, relocate IpUtils without changing the package
name.
Bug: 38350389
Test: compilation
Merged-In: If5fc63e9ad8b9b2d4c2fee47ff4bab2ab190a05a
Change-Id: If5fc63e9ad8b9b2d4c2fee47ff4bab2ab190a05a
(cherry picked from commit f8a2bc3eee)
