| 3e8ed63d0a4f974f8929cf44d7e77a3baa25f321 |
|
07-Feb-2018 |
Pete Gillin <peteg@google.com> |
Make NetworkInterface.isUp() test for IFF_RUNNING.
This makes java.net.NetworkInterface.isUp() return true only if the
interface has both IFF_UP and IFF_RUNNING flags set. This restores the
behaviour of nougat[1], and makes the behaviour match the javadoc. The
behaviour in oreo[2] was changed during a rewrite[3] which replaced
the native implementation with a pure java implementation that dropped
the IFF_RUNNING check (compare the new java code with the removed
native code). There is no evidence that this behaviour change was
intentional.
This change also reverts the changes to CTS made for oreo to work
around the behavioural change.
This reverts commit acd3bea08043a3c0a4272f1584f9f5475c550bb2.
[1] https://android.googlesource.com/platform/libcore/+/nougat-release/ojluni/src/main/native/NetworkInterface.c#393
[2] https://android.googlesource.com/platform/libcore/+/oreo-release/ojluni/src/main/java/java/net/NetworkInterface.java#452
[3] https://android-review.googlesource.com/c/platform/libcore/+/231080
Bug: 71977275
Test: cts-tradefed run cts-dev -m CtsLibcoreTestCases
Change-Id: I75066e49c5f864828adc928cc3687311f2f05011
|
| acd3bea08043a3c0a4272f1584f9f5475c550bb2 |
|
15-Jan-2018 |
Neil Fuller <nfuller@google.com> |
Add additional checks to multicast tests
MulticastSocketTest and DatagramChannelMulticastTest have identical
requirements for picking network interfaces but the logic was
slightly different. This commit brings them into line.
Also, Nougat used to check the IFF_RUNNING flag in
NetworkInterface.isUp() as well as IFF_UP, but this stopped in Oreo.
The IFF_RUNNING flag check is added explicitly in the tests here since
the tests cannot work over an interace that is not "running" either.
See issue 71977275 for the bug that considers altering isUp() behavior.
Bug: 71977275
Bug: 65037707
Test: CTS: run cts -m CtsLibcoreTestCases -t org.apache.harmony.tests.java.net.MulticastSocketTest
Test: CTS: run cts -m CtsLibcoreTestCases -t libcore.java.nio.channels.DatagramChannelMulticastTest
Merged-In: I227a436ff19f2c235d2a3e567fcfc55c909b47fd
Change-Id: I227a436ff19f2c235d2a3e567fcfc55c909b47fd
(cherry picked from commit b9de38da5633c5e87201d9a6dbe56e100f206966)
|
| b9de38da5633c5e87201d9a6dbe56e100f206966 |
|
15-Jan-2018 |
Neil Fuller <nfuller@google.com> |
Add additional checks to multicast tests
MulticastSocketTest and DatagramChannelMulticastTest have identical
requirements for picking network interfaces but the logic was
slightly different. This commit brings them into line.
Also, Nougat used to check the IFF_RUNNING flag in
NetworkInterface.isUp() as well as IFF_UP, but this stopped in Oreo.
The IFF_RUNNING flag check is added explicitly in the tests here since
the tests cannot work over an interace that is not "running" either.
See issue 71977275 for the bug that considers altering isUp() behavior.
Bug: 71977275
Bug: 65037707
Test: CTS: run cts -m CtsLibcoreTestCases -t org.apache.harmony.tests.java.net.MulticastSocketTest
Test: CTS: run cts -m CtsLibcoreTestCases -t libcore.java.nio.channels.DatagramChannelMulticastTest
Change-Id: I227a436ff19f2c235d2a3e567fcfc55c909b47fd
|
| 27604018f783bf6354a13870b3e7785edca69b5f |
|
28-Sep-2016 |
Paul Duffin <paulduffin@google.com> |
Detect and fix resource leakages in tests
Tests that test those classes that use CloseGuard to detect
reosurce leakages are switched to use TestCaseWithRules and
ResourceLeakageDetector.getRule() to detect any resource
leakages and the leaks fixed.
A number of tests could not be fixed due to bugs in the core
classes so a new DisableResourceLeakageDetection annotation was
added as part of this change. A method annotated with that does
not perform resource leakage detection. The affected tests were
annotated with a description and a reference to an associated
bug.
This uses try-with-resources to aid in closing resources. While
that does provide some benefits it is all too easy to change the
behavior of the test unless care is taken. To avoid that it is
important not to merge it with an existing try block such as
those which follow the following pattern:
try {... fail()} catch(..) {}
Merging them could result in the test catching and ignoring
exceptions thrown during the creation of the resource which is
almost certainly not what the test was intending.
Test: Tested with vogar and CTS
Bug: 31542223
Change-Id: Id32bb40fe04eb9719d7e6cd367abb53118b21832
|
| a5448c0d798644d549426f037ebc6676b1f4de3e |
|
21-Apr-2016 |
Tobias Thierer <tobiast@google.com> |
Avoid additional Object allocations that are immediately unboxed
This should catch most of the remaining cases in libcore, although
I was more hesitant in tests; for example, TreeMapExtendTest does
a lot of unnecessary boxing but the benefit of optimising the test
doesn't seem worth the risk of potentially introducing bugs.
Bug: 28289401
Change-Id: I911d2b5cf130f974427b4fe7e1916f1632e5f4fa
|
| a82ee5c37b22ec0dc71fef010982919caa8b9ecc |
|
04-Sep-2015 |
Neil Fuller <nfuller@google.com> |
Avoid using point-to-point interfaces in multicast socket tests
Multicast on a point-to-point interface isn't really multicast.
Bug: 23279677
(cherry-picked from commit 67d7597da46910e65a089bcce0afa8e0c2bed668)
Change-Id: Ib102e9d04744d3e99b8828ac31d9548e72b703dd
|
| 67d7597da46910e65a089bcce0afa8e0c2bed668 |
|
04-Sep-2015 |
Neil Fuller <nfuller@google.com> |
Avoid using point-to-point interfaces in multicast socket tests
Multicast on a point-to-point interface isn't really multicast.
Bug: 23279677
Change-Id: I64b1d17c6d7fcab66ecb14960a2e4493b144f7a9
|
| b35aca285aeb796d65b1b723364cb8a37a7d359a |
|
17-Mar-2015 |
Neil Fuller <nfuller@google.com> |
Fix for devices with multiple multicast-capable interfaces
test_joinGroupLjava_net_SocketAddressLjava_net_NetworkInterface
was wrong:
1) The sending socket was joining a group for no obvious reason except,
perhaps, to test null NetworkInterface handling.
2) The sending socket was always using the default interface to send
multicast packets, but receiving on a specified interface.
For devices with several interfaces we have reports of the test failing.
It is assumed to be because of (2) when the specified interface and
the default interface differ in the presence of multiple interfaces.
To explicitly test null handling for joinGroup() more tests have been
added.
Thanks to swl77wade for helping to track this down.
Bug: 159740
Change-Id: Ibb180f6d93770a95f70a6bfa34bfadd93aa3187e
(cherry picked from commit ef97a43c64f9b80714177ae16b5432fab7bdffde)
|
| 94279b64bcc98d8e28170204cf4aef0d803c7705 |
|
19-Feb-2015 |
Neil Fuller <nfuller@google.com> |
Fix for MulticastSocketTest for non-multicast interfaces
test_setNetworkInterfaceLjava_net_NetworkInterface does not check that
the interface supports multicast.
Bug: 19232216
Change-Id: I755287c06c99f36d209a3a8d11b2c75fccfa630b
(cherry picked from commit f6e066e95859d3366a24da89736f487d980854ce)
|
| ef97a43c64f9b80714177ae16b5432fab7bdffde |
|
17-Mar-2015 |
Neil Fuller <nfuller@google.com> |
Fix for devices with multiple multicast-capable interfaces
test_joinGroupLjava_net_SocketAddressLjava_net_NetworkInterface
was wrong:
1) The sending socket was joining a group for no obvious reason except,
perhaps, to test null NetworkInterface handling.
2) The sending socket was always using the default interface to send
multicast packets, but receiving on a specified interface.
For devices with several interfaces we have reports of the test failing.
It is assumed to be because of (2) when the specified interface and
the default interface differ in the presence of multiple interfaces.
To explicitly test null handling for joinGroup() more tests have been
added.
Thanks to swl77wade for helping to track this down.
Bug: 159740
Change-Id: Ibb180f6d93770a95f70a6bfa34bfadd93aa3187e
|
| f6e066e95859d3366a24da89736f487d980854ce |
|
19-Feb-2015 |
Neil Fuller <nfuller@google.com> |
Fix for MulticastSocketTest for non-multicast interfaces
test_setNetworkInterfaceLjava_net_NetworkInterface does not check that
the interface supports multicast.
Bug: 19232216
Change-Id: I755287c06c99f36d209a3a8d11b2c75fccfa630b
|
| 944632aa6018d04d5acfa12879fb7f01ba2959ff |
|
21-Nov-2014 |
Jason Parks <jparks@google.com> |
Do not run the multicast tests if the device doesn’t support multicast.
Bug: 18449007
Change-Id: Ia7511083cc36dd7d6835191bf4b79d23ed039b5b
|
| 0233d6a99b5c2bd1f643909403977b373e6e2400 |
|
10-Jun-2014 |
Neil Fuller <nfuller@google.com> |
Tidy up MulticastSocketTest and fix execution on hammerhead
Similar to the fixes for DatagramChannelMulticastTest
in 6d7b081971d12b25426c46e4989e7df3a5995eae but
for java.net.MulticastSocket.
Because MulticastSocketTest was the genesis of
DatagramChannelMulticastTest it had similar issues to that one,
but also contained other unnecessary or badly formatted code.
The main changes here are:
1) Fix the tests that were implicitly assuming that the
IPv6NetworkInterface1 was the same interface as the IPv4
version (networkInterface1).
2) Renamed variables / moved setUp to the top of the class /
closed sockets after use / fixed try/catch blocks to only wrap
expected throwing code / pulled out common code into new methods
and generally tidied up.
3) Removed the use of the "MulticastServer" class entirely.
This "server" would listen to socket on a separate thread and
was the source of multiple Thread.sleep(1000) calls in the test.
The tests rely exclusively on multicast loopback mode anyway
(MulticastSocket.setLoopbackMode()) and
MulticastSocket.receive() is blocking, which means it either
gets an immediate result or the test can rely on the
setSoTimeout() method to limit the time spent waiting. The use
of multiple threads was therefore unnecessary.
Bug: 15509450
Change-Id: Ie448cc3b2d7432012957db34c72949a7b4da359f
|
| df29508a7aa622f265aaebdc472eb7d679185ebb |
|
30-Jan-2014 |
Neil Fuller <nfuller@google.com> |
Implementation of MulticastChannel.
Note: ProtocolFamily / StandardProtocolFamily /
DatagramChannel.open(ProtocolFamily) have not been
implemented.
There is a related change to libnativehelper that
must be merged at the same time to avoid
build breakage. See
https://android-review.googlesource.com/#/c/81371/
Bug: 12464155
Change-Id: I07fc049b429a2d373e9bd7b07149632f5cd69f9d
|
| 82c642531ba3c9ad29cb3125f7547a226b661b11 |
|
02-Jan-2014 |
Narayan Kamath <narayan@google.com> |
Delete Support_PortManager & OldDatagramSocketTest
Support_PortManager didn't really work, so rewrite all tests
that use it.
Also, dedup OldDatagramSocketTest with the harmony DatagramSocketTest.
Fix various broken test cases and terribly written tests.
bug: 11689863
Change-Id: I4efb9e02eb88517273fff50a0dec1d0262feafb2
|
| ab762bb740405d0fefcccf4a0899a234f995be13 |
|
15-Nov-2013 |
Narayan Kamath <narayan@google.com> |
Move tests from tests/api to harmony-tests. (Take 2)
This reverts commit d5e281743e55e1daa297fd8043b2d9b6e8e1bed2.
The makefile issue that caused the original build break
has been resolved.
|
| d5e281743e55e1daa297fd8043b2d9b6e8e1bed2 |
|
15-Nov-2013 |
Narayan Kamath <narayan@google.com> |
Revert "Move tests from tests/api to harmony-tests."
This reverts commit 81bf28ad31131815d0a36a43a0eca3c29aefdfcd.
Breaks build
Change-Id: I3f1562921ffe8fdbec36971dd65db398c27c92db
|
| 81bf28ad31131815d0a36a43a0eca3c29aefdfcd |
|
15-Nov-2013 |
Narayan Kamath <narayan@google.com> |
Move tests from tests/api to harmony-tests.
The vast majority of cleaned up harmony tests
are now in harmony-tests/src/test/org/apache/harmony/tests/
Change-Id: I56c2e484ff434b5618cf6751d602ae9f0db96b30
|