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
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
We need to flip() the byte buffer before attempting to read
the data written to it.
bug: 18641009
(cherry picked from commit 96f656c39e)
Change-Id: Ib796fafa1e4cf81351245fff6763ce17924acde9
Change-Id I02eb5f22737720095f646f8db5c87fd66da129d6 adds VPN as a
supported network type to all device configurations directly in
software, independent of any external per-device configuration.
Reflect this expectation in the test.
Bug: 18439110
Bug: 18668362
Change-Id: I7fca77e564219c96e8a78372d4885c7b7f012a48
libcore's SSLDefaultConfigurationAsserts was renamed and refactored
into SSLConfigurationAsserts in
782740701db73dd2dc4fef9df8cde270b0e631a4. This CL adjusts the
affected CTS test for android.net.SSLCertificateSocketFactory
accordingly.
Change-Id: I663042e7c08ad616b2dedc226acda54c95fd6968
We have seen quite a few of these; and it doesn't seem to be pointing to
any device implementation problem. Hence relaxing the test.
Bug: 18005417
Change-Id: Iee983527ddff4f5336ccb48c04ce851102f13349
Removed most of getNetworkPreference() and setNetworkPreference() tests as
these functions are now fully deprecated and do nothing. Just test that
they are still callable.
Adjust startUsingNetworkFeature() and stopUsingNetworkFeature() failure
codes to match new behavior.
Tested on devices with Wifi and Cellular radios, and Wifi-only.
bug:17417896
bug:17354855
Change-Id: Iea8b25e399f4e5b6ec3d2101ebf520f89697c4da
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 use a larger value.
Bug: 16442451
Change-Id: I2d89393b1ad441783c8a082b072a806b8901830c
Signed-off-by: Constantin Musca <constantin.musca@intel.com>
For now, just checks that the kernel sysctls are present and
have the right permissions and expected values.
Bug: 15605143
Change-Id: I5feb6cb5f25b97e88cd0d9e8071213d13d4cc6e8
The return value of mWifiManager.isWifiEnabled()
&& mWifiManager.getConnectionInfo().getSSID() != null can not
correctly identify if WiFi is connected or not.
The fix is to modify the code logic used to judge if WiFi is connected.
Bug 15578218 and 15578219
Change-Id: I8ae40980c9cd1ea91dafe0ca7c893c84b35709bf
Signed-off-by: Benson Huang <benson.huang@mediatek.com>
