- Expose ScanResult#untrusted to inform NetworkRecommendationProviders
that a ScanResult does not correspond to a saved network.
- Add static construction methods and assertions to RecommendationResult
Test: runtest frameworks-services
Bug: 33490132
Change-Id: If7006040f63843c1c468c9d95c5c017383c5c5dd
Merged-In: If7006040f63843c1c468c9d95c5c017383c5c5dd
Updated the NetworkScorerAppManager to examine the list of configured
network recommendation providers and to select the first valid
provider.
As part of this update the old logic of looking for a valid network
scorer has been removed. Scorers/recommendation providers are only
selected from the configured list now. The setActiveScorer() method
has been deprecated as a result.
The NetworkScoreService has been updated to monitor the list of
potential recommendation providers and to reevaluate the binding
whenever they change. It also monitors the new setting for
NETWORK_RECOMMENDATIONS_ENABLED to connect or disconnect from the
provider as needed.
Test: runtest frameworks-services -c com.android.server.NetworkScoreServiceTest
BUG: 33158362
Change-Id: I450981261aa5355c1c91ec2e3a0a3b58cc65316b
Merged-In: I42aeb5223da794f71f7e58cb1bdf18817200cbf2
readParcelableArray() wasn't working as expected so I just parceled
the array myself.
Test: adb shell am instrument -e class android.net.RecommendationRequestTest -w com.android.frameworks.coretests/android.support.test.runner.AndroidJUnitRunner
Change-Id: I83939d17769930b707b8bc579542c74a05e31d19
Merged-In: I47bc31adbedea817feaa5953cb6ee48506f9c6d6
It looks like one operation was done out of order and some of the times used in
the calculations were leading to incorrect results.
BUG: 31023263
Test: bit FrameworksCoreTests:com.android.internal.os.BatteryStatsDurationTimerTest
Change-Id: I417cc28c5a55748067b6c7f682a66fe3dbc09f09
(cherry picked from commit 47db5a8bf7)
Migrating the NetworkScoreManager.requestScores() method to use an
IPC rather than a broadcast.
Defined the new IPC in the AIDL files for NetworkScoreService and
NetworkRecommendationProvider. Added a no-op implementation in
NetworkScoreService and a full implementation in
NetworkRecommendationProvider (plus tests).
Test: adb shell am instrument -e class android.net.NetworkRecommendationProviderTest -w com.android.frameworks.coretests/android.support.test.runner.AndroidJUnitRunner
BUG: 33593157
Change-Id: Iacf7b6d424ec3c57e8b89e5abc6bc3e8414097b9
Merged-In: I951f6186aa11ddbe5a94e374173a1fd40b2a4cce
Converted the NetworkRecommendationProvider.onRequestRecommendation()
method into an async call to give implementors more flexibility.
Added unit tests for NetworkRecommendationProvider.
Test: Added NetworkRecommendationProviderTest.
BUG: 32909424
Change-Id: I8c1d2e11baa539744d77a012e85351f750523e3b
Merged-In: Iebe72f260133e9ad1946b0b75e2f69635e154ef3
This patch uses the previously introduced TokenBucket to rate limit
ApfProgramEvents, still allowing for burst of ApfProgramEvents when a
new interface is set up (due to ipv4 provisioning, multicast lock, ipv6 RAs
triggering new APF program events in short amounts of time).
Test: new test in IpConnectivityMetricsTest
Bug: 1550402
(cherry picked from commit e1c173d224)
Change-Id: Ibe41e9a76db36ea502697a5f19fc0d91c40a3087
This patch adds a TokenBucket class that can accumulate and distribute
tokens over time.
Test: comes with unit tests.
Bug: 32198637
(cherry picked from commit 998493f0ee)
Change-Id: Iaf477c7bb14f8ddb293b7a907e2ab0cf76d09e07
Dependent on ag/1550196 where API is defined.
Bug: 31015360
Bug: 26545374
Test: runtest --path
frameworks/base/core/tests/coretests/src/android/net/NetworkStatsTest.java,
other test classes.
(cherry picked from commit 2514787897)
Change-Id: I46da93ba4afa968facf98f7c3d844fd0c469095a
Properly account for VPN apps that make heavy use of the tun
interface. Prior to this change a VPN app could be incorrectly charged
for more data than it actually used if it sent more traffic through
the tun interface than the underlying interface.
This change excludes VPN app traffic on the tun interface from the
adjustment pool and doesn't redistribute traffic to the VPN app.
Instead all of the redistributed traffic is deducted from the VPN app
which effectively represents any overhead incurred by the VPN app.
BUG: 30557871
(cherry picked from commit 8b436d865c)
Change-Id: I06f01aa8fe5fdc06b2d36cfb9c68feb244c2e5de
This patch uses the previously introduced TokenBucket to rate limit
ApfProgramEvents, still allowing for burst of ApfProgramEvents when a
new interface is set up (due to ipv4 provisioning, multicast lock, ipv6 RAs
triggering new APF program events in short amounts of time).
Test: new test in IpConnectivityMetricsTest
Bug: 1550402
(cherry picked from commit e1c173d224)
Change-Id: Idb640dec13ba64180985544b9709a586af66eb6e
This patch adds a TokenBucket class that can accumulate and distribute
tokens over time.
Test: comes with unit tests.
Bug: 32198637
(cherry picked from commit 998493f0ee)
Change-Id: I4012ae6d02f7004bceee9a2ba03914f2a2506031
MemoryIntArray was using the size of the undelying
ashmem region to mmap the data but the ashmem size
can be changed until the former is memory mapped.
Since we use the ashmem region size for boundary
checking and memory unmapping if it does not match
the size used while mapping an attacker can force
the system to unmap memory or to access undefined
memory and crash.
Also we were passing the memory address where the
ashmem region is mapped in the owner process to
support cases where the client can pass back the
MemoryIntArray instance. This allows an attacker
to put invalid address and cause arbitrary memory
to be freed.
Now we no longer support passing back the instance
to the owner process (the passed back instance is
read only), so no need to pass the memory adress
of the owner's mapping, thus not allowing freeing
arbitrary memory.
Further, we now check the memory mapped size against
the size of the underlying ashmem region after we do
the memory mapping (to fix the ahsmem size) and if
an attacker changed the size under us we throw.
Tests: Updated the tests and they pass.
bug:33039926
bug:33042690
Change-Id: Ibf56827209a9b791aa83ae679219baf829ffc2ac
MemoryIntArray was using the size of the undelying
ashmem region to mmap the data but the ashmem size
can be changed until the former is memory mapped.
Since we use the ashmem region size for boundary
checking and memory unmapping if it does not match
the size used while mapping an attacker can force
the system to unmap memory or to access undefined
memory and crash.
Also we were passing the memory address where the
ashmem region is mapped in the owner process to
support cases where the client can pass back the
MemoryIntArray instance. This allows an attacker
to put invalid address and cause arbitrary memory
to be freed.
Now we no longer support passing back the instance
to the owner process (the passed back instance is
read only), so no need to pass the memory adress
of the owner's mapping, thus not allowing freeing
arbitrary memory.
Further, we now check the memory mapped size against
the size of the underlying ashmem region after we do
the memory mapping (to fix the ahsmem size) and if
an attacker changed the size under us we throw.
Tests: Updated the tests and they pass.
bug:33039926
bug:33042690
Change-Id: I1004579181ff7a223ef659e85c46100c47ab2409
