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
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)
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
Change-Id: I23dc4827ae729583356a8ff0f02e39a2ad2b81f5
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
Change-Id: If5fc63e9ad8b9b2d4c2fee47ff4bab2ab190a05a
(cherry picked from commit bd4093be7cab51d6ad031854324134a9c8637c2c)
