- CallbackInfo becomes a static class so that it can be instantiated
and looked at more easily than before.
- CallbackInfo gains hashCode() because it has equals().
- effectively final field are qualified final
- fixes bug when polling the next callback: poll() on a LinkedBlockingQueue
returns null when timing out, which was not failing the test cleanly.
Test: ConnectivityServiceTest passes
Bug: 32561414
(cherry picked from commit b573a2964c)
Change-Id: Ica5f1609975e4b256f4e2f3dc2ac84362e762da2
Network usage is tracked by the kernel at the UID level, which is
granular enough for normal apps, but large components (such as the
system server) are impossible to debug without adding additional
socket tagging to help identify subsystems within a UID.
To help ensure that system components tag all their network traffic,
this change offers a new StrictMode option to detect and report
untagged sockets.
Test: builds, boots, all common traffic tagged
Bug: 30943431, 30414041
Change-Id: I825c7941076054732264690247de2863342638e2
Symptom : Infinite reboot
Reproduce step :
1. Set the Always-on VPN in M OS
2. OS upgrade from M to N
Reproduce frequency : 100%
Reason of issue :
https://android.googlesource.com/platform/frameworks/base/+/9b74791
As you know, in M OS, Always-on VPN information is stored in keystore with encryted.
However, in N OS, there is no encryption when it put in keystore.
So, You deleted keystore check(locked/unlock) logic on ConnectivityService.
By this reason, when device upgrade to N OS(set Always-on VPN), it goes infinite boot.
(Cannot read old always-on vpn information untill device unlock.)
Solution :
I founded exception handling when this case as follows:
If getting Credentials.LOCKDOWN_VPN information has null value(catch the exception),
updateLockdownVpn returns false value.
Signed-off-by: SangJin Cha <sj.cha@lge.com>
Change-Id: I6fd980152440bb5248aab45e2f8fda448d3f6c7b
This is the same notification as the one shown during legacy lockdown
mode, sans the 'reset' button.
The notification is only shown during times when VPN has not yet
established or has failed, for example during boot or after a crash.
Bug: 29123115
(cherry picked from commit 9ca892f698)
(cherry picked from commit c777123d5c)
Change-Id: I42b4b24e25175bb7628b46a79431d2592644803c
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 9369e9d105)
(cherry picked from commit 757658193d)
Change-Id: I79e401fc4159264a075febba82bd8c295b8e677f
This patch introduces an assertEventuallyThat helper function in
ConnectivityServiceTest which given a boolean function retries until the
function returns true or until a maximum retry time is reached.
This function is used to fix flakyness of testAvoidBadWifiSetting where
the Message posted by reevaluate() could reach the Handler's
MessageQueue after waitForIdle takes effect, resulting in the test to
fail.
Instead of fixing the flakyness by introdcing hard sleep times,
assertEventuallyThat is used to reduce the overall test time.
With this change the test has been observed to pass with 100% success
rate over 50000 invocations.
Test: $ runtest frameworks-net
Bug: 32561414
(cherry picked from commit b54c8cffa8)
(cherry picked from commit b1bddc92c5)
Change-Id: I432f90a699dadfef37a5d0a69e25050753340964
This patch fixes flakyness of testRequestBenchmark by adjusting time
limit for callback registration from 100ms to 180ms, and time limits for
onAvailable and onLost triggers from 30ms to 40ms.
With these timeouts the test succeeds 100% over 5000 iterations.
When using 150ms for registration timeout, running the test 5000 times
fails 2 times.
When using 30ms for onLost timeout, running the test 5000 times fails
1 times.
In addition, this patch also cleans testRequestBenchmark and uses the
more stable SystemClock.elapsedRealtime() for duration measurements.
Test: $ runtest frameworks-net
Bug: 32561414
(cherry picked from commit 766e564647)
(cherry picked from commit 8436dae4c3)
Change-Id: I3caf10025f203156a297c0b522f24768a18accc9
Most tests were failing because due to a null NetworkCapabilities.
Example:
1) testNetworkStatsWifi(com.android.server.net.NetworkStatsServiceTest)
java.lang.NullPointerException: Attempt to invoke virtual method 'boolean android.net.NetworkCapabilities.hasCapability(int)' on a null object reference
at
com.android.server.net.NetworkStatsService.updateIfacesLocked(NetworkStatsService.java:983)
BUG: 30839080
(cherry picked from commit f96df4b298)
(cherry picked from commit 00a6e6c111)
Change-Id: I6eee96178ade6adfc1406e06d5376206ca2420e5
This patch changes the way that the ConnectivityThread is lazily
instantiated by using the "lazy initialization holder class idiom".
The first code point that tries to obtain a reference to the unique
ConnectivityThread instance will trigger the creation of the Singleton
class, which will guarantee a thread-safe initialization of the static
INSTANCE field inside Singleton according to the language specs.
This is the Item #71 of Effective Java.
The unique static instance of ConnectivityThread is not stored directly
inside ConnectivityThread class but is stored in a static nested class.
This is to avoid triggering the creation of that unique instance when
Zygote does class preloading at phone startup. Otherwise this would lead
to Zygote creating a new OS thread during preloading, which is a fatal
error.
Test: frameworks-wifi tests pass
Bug: 26749700
Bug: 28537383
Bug: 32130437
(cherry picked from commit 3ab84b087a)
(cherry picked from commit 8f201294fe)
Change-Id: Ic9a31809ef19e618246f9aa17f5df29bd65f8510
This patch removes the static singleton looper used by
ConnectivityManager and instead uses the common ConnectivityThread.
This allows to removes the static atomic counter used to track
the number of registered NetworkCallback in ConnectivityManager, because
the looper is not turned off anymore when no callbacks are registered.
Also an overloaded version of sendRequestForNetwork is added taking as a
new parameter a Handler. This will allow to overload various callback
and request related API calls with user provided Handlers.
Test: ConnectivityServiceTest passes
Bug: 26749700
Bug: 28537383
Bug: 32130437
(cherry picked from commit 3b41f05d68)
(cherry picked from commit 301b09738a)
Change-Id: If5c1e46ca6c4a09ef526cbe09654c5f55ef8d6ce
This patch simplifies CallbackHandler in the following way:
- CallbackHandler directly uses the static references to
sNetworkCallback and sCallbackRefCount. This allows to remove
instance fields in CallbackHandler.
- CallbackHandler does not have a reference to ConnectivityManager
anymore
- CallbackHandler.getObject() is now generic in a type-safe way.
Test: ConnectivityServiceTest passes
Bug: 28537383
Bug: 32130437
(cherry picked from commit 0b42baf68a)
(cherry picked from commit 56260ed9cb)
Change-Id: I4d0b2441b6af76bc56b19218210a2a381532a3c4
