This fixes the following cases for us:
android.net.cts.ConnectivityManagerTest#testGetAllNetworkInfo
android.net.cts.ConnectivityManagerTest#testGetNetworkInfo
android.net.cts.ConnectivityManagerTest#testIsNetworkSupported
android.net.cts.ConnectivityManagerTest#testRequestRouteToHost
android.net.cts.ConnectivityManagerTest#testSetNetworkPreference
We need to use the prebuilt binary but that has dependency to
private resource identities that differs in our environment. With
this change the resources are looked up in run-time to avoid the
build time dependency.
Change-Id: I6579338b591ca7a0da3f03f796136269c7789780
(cherry picked from commit b29370db34)
The testcase was manipulating the Wifi / Cell networks,
presumably in an effort to make data pass over each type of
network.
The test was sending / receiving data using the loopback
interface so it doesn't make much sense.
testExecute_withMobile would fail if the device did not
have a SIM / mobile data connection *and* if the wifi
network was up when the test ran; it would fail waiting
for the mobile data network to enter the CONNECTED state.
If the wifi connection was down at the start it would
assume the mobile data connection was up already and
proceed with the test (which passed, because it
didn't actually use the network).
This change chops out parts of this test to leave just
HttpClient-related code.
Bug: 21874093
Change-Id: I8248b840f58f939661eff2345f70a9e786e593f3
It is a issue caused by bad test case.
Please ensure the previous vpn connection is disconnected before running next
vpn test case, this will affect the test result.And the CTS test case also
tries to connect socket before the vpn rule is set in netd.
It is the same issue as http://b/18436087 .
The delay 300ms is too short, and recommend extend to 1000 or 3000 ms.
Since L MR1 is known as supporting some low memory device, we suggest fixing
the new CTS test case for some low-end devices.
Change-Id: I6051c95c663e867fc66c580ce8bd8d25fce0b8fc
Signed-off-by: Junjie Hu <junjie.hu@mediatek.com>
In current implementation it's been assumed that there will be only one
interface registered for service discovery in mdnsresponder. In reality
there's possibility that some real but currently unused interfaces will
have link-local address assigned prior to registration, which will cause
mdnsresponder to register these interfaces for service discovery. This
will result in SERVICE_LOST and SERVICE_FOUND events to be received more
than one time. Current test implementation is not 100% prone for this
situation - depending upon time gap between both events it can PASS or
FAIL.
Fix by removing an assert on number of received events.
Change-Id: I147dc4d600f41f6d63d2b9e4bcb10efe90d5b3ec
(cherry picked from commit 970cbe09b5)
If one sets a *SendBufferSize* value which is less than
(2048 + SKB_DATA_ALIGN(sizeof(struct sk_buff))) then the value
retrieved will be (2 * (2048 + SKB_DATA_ALIGN(sizeof(struct sk_buff)))).
Otherwise, the value will be doubled.
Modify the test to consider both cases.
Change-Id: I2d89393b1ad441783c8a082b072a806b8901830c
Signed-off-by: Constantin Musca <constantin.musca@intel.com>
The test is failing because it expects ::1" to resolve to
"localhost", but it now resolves to "ip6-localhost".
Bug: 18791191
Bug: 19953381
Change-Id: I62279b6219c32e817253c686bf408f0a2fc1fa6b
Revert "DO NOT MERGE ANYWHERE."
This reverts commit b7c798f9b84c7c100aa37e6aa77e7f31460c7bd7, reversing
changes made to 4e8ecc32db5d3a17ccec099681425c34b630d23b.
This allows developers to build the test packages individually without
needing to build the entire CTS release.
Add new build target for support packages
bug: 18945639
Change-Id: I60b79797b2d254b96aa98f88cfd5b19d195ea982
Test modules that depend on the CTS testserver must declare
explicit dependencies on org.apache.http.legacy.
Also fix some bizarre build rules; ctstestserver builds directly
against the framework but compiled into apps that target SDK 16.
bug: 18027885
Change-Id: I905942d8ed71812499df94e3e5970c0b08716528
In current implementation it's been assumed that there will be only one
interface registered for service discovery in mdnsresponder. In reality
there's possibility that some real but currently unused interfaces will
have link-local address assigned prior to registration, which will cause
mdnsresponder to register these interfaces for service discovery. This
will result in SERVICE_LOST and SERVICE_FOUND events to be received more
than one time. Current test implementation is not 100% prone for this
situation - depending upon time gap between both events it can PASS or
FAIL.
Fix by removing an assert on number of received events.
Change-Id: I147dc4d600f41f6d63d2b9e4bcb10efe90d5b3ec
Moving HttpResponseCacheTest.java from
frameworks/base/core/tests/coretests/src/android/net/http
to
cts/tests/tests/net/src/android/net/http/cts
And making it work in the CTS runner by setting
temp directory permissions and making sure the
cache is initialized.
Change-Id: I032014789f27a66c1a7a0aee0fa0494f6041238e
