summaryrefslogtreecommitdiff
path: root/harmony-tests
AgeCommit message (Collapse)Author
2021-09-27Switch to OpenJDK 8 java/mathHans Boehm
The main goal here is performance by avoiding JNI and especially NativeAllocationRegistry overhead. We gain a factor of 10 or so on small BigInteger arithmetic. For large computations, we gain substantially in a few cases where OpenJDK seems to use better algorithms. AFAIK, with this version we never lose by integral factors relative to what we had before. A secondary goal is to clean out open BigInteger bugs. The base version is 8u252, which for this part of the tree is identical to June 15 2020 ToT. Note that this means we included the java.math part of https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/a5f5d7fd9be6 (29 Oct 2019) That appears to be a separable fix that makes no interface changes. I re-added @NonNull annotations. We also removed some code to write certain backwards-compatibility fields during serialization, since we never had those. This also adds a the <X>ValueExact Java 8 BigInteger methods that had not been previously supported. This removes a Harmony test for compatibility with the RI implementation that the RI implementation itself apparently fails. And, IMO, the observed behavior is better than what we previously tested for. Fixed a bunch of comment spelling errors. All of these have now been fixed in upstream ToT. Benchmarking showed that a straight move to the RI version slowed down large multiplications, divisions, and modular exponentiation enough to make it problematic. Thus I reintroduced NativeBN to allow those to fall back to boringssl, at least for sufficiently large inputs. It was moved to a hopefully more appropriate location. The fallback is tuned for 64 bits; for 32 bits it's probably much less useful; much of the boringssl performance advantage comes from 64-bit "digits". The boringssl fallbacks are not completely free, since we need extra conversions on each operation. But since we only do this for large asymptotically expensive computations, we see at mosts tens of percents regressions, which probably qualifies as "in the noise" here. If we find additional performance issues, we can add more boringssl fallbacks; the required code is now fairly straightforward. Unlike the old version, this no longer uses NativeAllocationRegistry or similar mechanisms at all. Native memory is only used on a short-term basis, with explicit deallocation. We no longer use boringssl for simple linear-time operations like addition. Microbenchmark results for the newly added benchmark, and for a close-to-final BigInteger version, listed as "combined": Msecs/iteration Digits: 5/10 50/100 500/1000 5000/10000 Inner product, 1000 terms, factors of larger indicated size: current 2.1 2.5 6.4 168 RI 0.11 0.66 11.0 486 combined 0.12 0.67 9.1 189 Harmonic series, uses smaller indicated size current 3.7 3.2 4.3 17.6 RI 0.16 0.34 1.4 14.3 combined 0.17 0.34 1.23 14.2 (1+1/100000)^100000, larger size current 0.07 0.073 0.33 15.8 RI 0.011 0.049 1.553 63.6 combined 0.011 0.049 0.48 13.6 Single modPow() call, smaller size current 0.005 0.011 1.1 583 RI 0.006 0.038 7.2 5580 combined 0.011 0.012 1.1 541 Single modInverse call, larger size current 0.003 0.014 0.375 27.8 RI 0.003 0.003 0.026 1.6 combined 0.002 0.002 0.008 0.4 Bug: 160641142 Bug: 136887041 Bug: 119491938 Bug: 28214673 Bug: 28251030 Bug: 2950143 Test: AOSP Boots. Ran some manual Calculator tests on Cuttlefish. Change-Id: Id577d99328013b1e3c389973dcb0195fa7f52b0b
2020-12-04Reject non-ASCII hostnames and SANs.Pete Bentley
Updates test expectations to match OkHostnameVerifier behaviour changes in the same topic. Bug: 171980069 Test: atest CtsLibcoreTestCases CtsLibcoreOkHttpTestCases Change-Id: I7ccd2c6d4255d29112e9a6d58640316c364bf67a
2020-07-13Disable test causing oom failures.Christopher Ferris
Bug: 160171148 Bug: 160965370 Test: Verified the test does not run, and that no oom failure occur. Change-Id: I872aa89176b666964261d1303e20eb8f98e7e2ae
2020-05-26ScannerTest#testPerformance(): Improve failure reporting.Tobias Thierer
This test apparently sometimes fails to match "123 " against the floatPattern constructed at runtime, but I can't reproduce and can't see why it would. It might be related to an issue inside ICU that only occurs a rare fraction of the time, or it might be related to a nonstandard Locale. This CL adds more detail to the failure case in order to narrow this down. I've also slightly tweaked the initialization part of the test. Bug: 150310094 Test: atest CtsLibcoreTestCases:org.apache.harmony.tests.java.util.ScannerTest#testPerformance (takes about 15 seconds on a Pixel 2). Test: To make sure that I didn't have a bug in my String.format(), temporarily moved the initialization of String message to in front of the try block and checked that the test still passed (but then took 21sec, unsurprisingly). Merged-In: Ib7d29e798515ebd7da474916078f6f3b39fd8a62 Change-Id: Ib7d29e798515ebd7da474916078f6f3b39fd8a62 (cherry picked from commit 1495b25cfc20d4f27472506fb713e5b011a70094)
2020-04-27Track tzdb 2020a changesNeil Fuller
This commit changes a test that hardcodes knowledge of the zones with a raw offset of UTC-8. In 2020a America/Whitehorse and America/Dawson (and their aliases) no longer qualify. Bug: 155048115 Test: run cts-dev -m CtsLibcoreTestCases Merged-In: Icdbab139b91b5882b42d986b6b85bd9cef41dcf0 Change-Id: Icdbab139b91b5882b42d986b6b85bd9cef41dcf0 (cherry picked from commit 40bc89f47fbf9237f2921d54ab1ef861ef4c5f32)
2020-04-01Add tests for SSLContextSpi base class methods.Pete Bentley
Also refactor the existing tests for readabilioty and Junit4. Bug: 150645191 Test: atest org.apache.harmony.tests.javax.net.ssl.SSLContextSpiTest Change-Id: I70b8522222108f9497867ada83ec15693f8c15ac Merged-In: I70b8522222108f9497867ada83ec15693f8c15ac (cherry picked from commit 46a3e9f6f83bf888b4e5656532d0ced82b22ed22)
2020-01-14Update test expectations with Unicode 13 valuesNikita Iashchenko
After upgrading ICU to 66.0.1 and CLDR to 36.1 preview the character 0x30000 is moved from unassigned to new defined range 0x30000–0x3134A. This CL updates various test expectations for this character and new range's boundaries. See more: * New range: https://www.unicode.org/Public/13.0.0/charts/blocks/U30000.pdf * Unicode 12.1 to 13.0 diff: https://www.unicode.org/Public/13.0.0/diffs/12.1.0-13.0.0.all.all.diffs * Full Unicode 13.0 code charts: https://unicode.org/Public/13.0.0/charts/CodeCharts.pdf Bug: 135752089 Test: atest CtsLibcoreTestCases:org.apache.harmony.tests.java.lang.CharacterTest Change-Id: Idf80749e768e93323591e491d80d89f6c1cfe7e7
2019-12-13Update java.io.FilterOutputStream#close test.Daulet Zhanguzin
Accidentally missed from https://android-review.googlesource.com/c/platform/libcore/+/1182688 Bug: 122733269 Test: atest CtsLibcoreTestCases:org.apache.harmony.tests.java.io.FilterOutputStreamTest Test: atest CtsLibcoreTestCases:libcore.java.io.OldFilterOutputStreamTest Test: new CtsLibcoreTestCases:org.apache.harmony.tests.java.io.FilterOutputStreamTest#test_close_flushthrows fails in previous implementation Change-Id: I1755e9defa284261e71c970d9f8b6e454c426b65
2019-12-13Integrate OpenJDK 9 fix for double-close.Daulet Zhanguzin
Added a test to verify new behavior. Fixes: b/122733269 Test: atest CtsLibcoreTestCases:org.apache.harmony.tests.java.io.FilterOutputStreamTest Test: atest CtsLibcoreTestCases:libcore.java.io.OldFilterOutputStreamTest Test: new CtsLibcoreTestCases:org.apache.harmony.tests.java.io.FilterOutputStreamTest#test_close_flushthrows fails in previous implementation Change-Id: Iaa0113fe1cb81a74cc19feedae38b0a97dd34768
2019-11-13Don't close SSLSocket streams during HandshakeCompletedEventTest.Pete Bentley
Closing the InputStream returned by SSLSocket.getInputStream() should cause the associated socket to be closed: https://developer.android.com/reference/java/net/Socket.html#getInputStream() Similarly for SSLSocket.getOutStream(). ConscryptEngineSocket actually implements that behaviour whereas ConscryptFileDescriptorSocket does not, causing this test to fail when using engine-based sockets. As the stream closure is not really relevant to the rest of the test, simply remove it so the test passes on both implementations of SSLSocket. Bug: 143682035 Test: atest CtsLibcoreTestCases:HandshakeCompletedEventTest for both Conscrypt implementations of SSLSocket Change-Id: I5cff8a40fcfc1c26fa685f7dbdd72d63b5df5f4f
2019-07-08Minimal fix for ControlTest (attempt 2)Neil Fuller
Make minimal changes to ControlTest to get it passing; ControlTest is not loaded by the System ClassLoader on Android so needs to be changed. Now fixed, the test can be removed from the knownfailures.txt list. This commit fixes up ControlTest.test_needsReload_LStringLLocaleLStringLClassLoaderResourceBundleJ with minimal changes. The original intent of the test wasn't obvious in some places and those lines have been removed. Previously the change broke on the ART build bots but also exited early due to a hardcoded "return". This return has been removed and replaced with a fail(). Tested for the ART build bots with an approximation of their vogar commandline: vogar --toolchain d8 --language CUR --expectations art/tools/libcore_failures.txt \ --classpath out/target/common/obj/JAVA_LIBRARIES/core-tests_intermediates/classes.jar \ --classpath out/target/common/obj/JAVA_LIBRARIES/jsr166-tests_intermediates/classes.jar \ --classpath out/target/common/obj/JAVA_LIBRARIES/mockito-target_intermediates/classes.jar \ org.apache.harmony.tests.java.util.ControlTest Test: atest CtsLibcoreTestCases Test: See vogar details above Bug: 13747957 Bug: 28686280 Change-Id: Ib6c24a6d977a4197350a3db1299c76fa4ac5fbdf
2019-07-04Revert "Minimal fix for ControlTest"Neil Fuller
This reverts commit d45e69ceec5cf523d771ac118b64d1b350418ae1. Reason for revert: Broke ART bots Change-Id: I5d487172d408e1d79b78bb7dabb69e263901a2f9
2019-07-02Minimal fix for ControlTestNeil Fuller
Make minimal changes to ControlTest to get it passing; ControlTest is not loaded by the System ClassLoader on Android so needs to be changed. Now fixed, the test can be removed from the knownfailures.txt list. This commit moves hyts_resource_fr_FR.properties file from libcore so that hyts_resource_fr_FR.properties is with hyts_resource.properties in external/apache-harmony/. Test: atest CtsLibcoreTestCases Bug: 13747957 Bug: 28686280 Change-Id: I4ce32aff83dc0be7e3e830415ae890464d11d36d
2019-06-25Merge "Change Math.pow() test / docs to match actual"Treehugger Robot
2019-06-25Change Math.pow() test / docs to match actualNeil Fuller
The Math.pow() implementation does one thing, the docs say another and the tests match the docs. There are good reasons for the behavior so this commit adjusts the affected docs/test accordingly. Bug: 11669804 Test: vogar harmony-tests/src/test/java/org/apache/harmony/tests/java/lang/MathTest.java Change-Id: I727dbd82ca06c9bba3d6e8cec113b21aa1f923bc
2019-06-17Fix isJavaIdentifierStart test testing wrong functionColin Cross
test_isJavaIdentifierStart_I is sometimes calling isJavaIdentifierPart. Change-Id: I8cfe36d79b849faa4934b60e2e28b1666e703555 Test: treehugger
2019-05-22Replace DecimalFormat_ICU58_Android with ICU4J DecimalFormat in compat modeVictor Chang
DecimalFormat_ICU58_Android is a technical debt and is not guaranteed to be compiled and work in the future due to internal dependency in ICU. The goal is to replace it with slightly patched ICU4J DecimalFormat, while the j.t.DecimalFormat has a behavior close to the current version. 1. Introduction of a new parse mode called "compatibility" Parse mode is an existing concept in ICU, but it has only strict mode or not. Android adds 3rd parse mode called "compatibility" to ICU4J. The current version of j.t.DecimalFormat exhibits some behaviors that strict mode ICU4J DecimalFormat doesn't have. The difference between strict and compatibility mode: a. Compatibility mode ignores grouping size in parsing. b. Compatibility mode does NOT ignore bidi control characters. It's stricter than strict mode. 2. Update DecimalFormat prefix/suffix setter API to throw NPE - In Android Q, when null prefix/suffix is set, DecimalFormat becomes an invalid object effectively, and throws NPE when format/parse is called. To avoid crashes in apps expecting old Android behavior, NPE is only thrown when target SDK level > 29 (API level in Q). - For target SDK level <= 29, the behavior is more permissive than Android Q was, i.e. doesn't throw NPE when calling {prefix|suffix} setter/format /parse. In Android Q, it throws NPE when calling format/parse. - For target SDK level > 29, the behavior is more restrictive than Android Q was, i.e. throws NPE immediately when calling prefix setter. - Test changes libcore.java.text.DecimalFormatTest#testPatternSeparator - Bug fix. The input and output pattern are now consistent in the test. libcore.java.text.DecimalFormatTest#testWhitespaceTolerated - Extra space before prefix of " " could be parsed inconsistently. Example: Whitespace(U+0020) before + sign prefix or no prefix is not tolerated before this change. With pattern " 0", input " 1 " could be parsed. Now it can't. This new behavior is consistent with RI, i.e. DecimalFormatTest#testWhitespaceError and #testWhitespaceTolerated pass on RI. libcore.java.text.OldDecimalFormatTestICU#test_sigDigitPatterns - The test has been asserting undefined behavior. Now Pattern "@.###" (undefined behavior) doesn't cause IllegalArgumentException. libcore.java.text.OldNumberFormatTest#test_setMaximumIntegerDigits - Bug fix. No more integer digit in output format when the maximum integer digits is <= 0 org.apache.harmony.tests.java.text.DecimalFormatTest#test_applyLocalizedPattern org.apache.harmony.tests.java.text.DecimalFormatTest#test_applyPattern org.apache.harmony.tests.java.text.DecimalFormatTest#test_applyPattern_icu2GroupingSizes org.apache.harmony.tests.java.text.DecimalFormatTest#test_toLocalizedPattern org.apache.harmony.tests.java.text.DecimalFormatTest#test_toPattern - Undefined behavior. Remove unnecessary leading # optional integer digit in output pattern. Leading # optional integer digit has always ignored, when no other symbol, e.g. grouping separator, is given. Now the change is also reflected in the output pattern. The return value of DecimalFormat.getMaximumIntegerDigits is not affected by this change. libcore.java.text.DecimalFormatTest#testBug15081434 org.apache.harmony.tests.java.text.DecimalFormatTest#test_setNegativePrefix org.apache.harmony.tests.java.text.DecimalFormatTest#test_setNegativeSuffix org.apache.harmony.tests.java.text.DecimalFormatTest#test_setPositivePrefix org.apache.harmony.tests.java.text.DecimalFormatTest#test_setPositiveSuffix - DecimalFormat prefix/suffix setter API to throw NPE libcore.java.text.OldNumberFormatTest#test_equals - DecimalFormat.equals has always been broken, e.g. the implementation wasn't symmetric in ICU 58. The following bugs are the examples. https://unicode-org.atlassian.net/browse/ICU-12567 https://unicode-org.atlassian.net/browse/ICU-11646 The new ICU DecimalFormat implementation fixed the above bugs, but broke the weak guarantee of equals(), which return false even though the MaximumIntegerDigits is set back to the original value (See the reason below.) This old behavior is not guaranteed by the java doc. Internally, the new ICU DecimalFormat implementation keeps tracking both input properties and the exported properties. After calling the setter, the input property is no longer the same. In general, a class can freely define their own internal states, and compare the states in equals() implementation. In favour of new behavior as it's now symmetric, but breaks weak guarantee that the instances externally returns the same state, e.g. MaximumIntegerDigits, but the internal states are still different, and becomes not equal. The test case ensures that setting the same state, e.g. call setMaximumIntegerDigits(100), makes 2 instances equal. Detailed discussion: https://unicode-org.atlassian.net/browse/ICU-13266 org.apache.harmony.tests.java.text.DecimalFormatTest#test_formatDouble_scientificNotation org.apache.harmony.tests.java.text.DecimalFormatTest#test_formatDouble_scientificNotationMinusZero org.apache.harmony.tests.java.text.DecimalFormatTest#test_formatLong_scientificNotation - New test expectation is more aligned to the following java doc in DecimalFormat - The doc says "The number of significant digits in the mantissa is the sum of the minimum integer and maximum fraction digits, and is unaffected by the maximum integer digits." - #.0E0 pattern has min integer digit of 0 and max fraction digit of 1. According to the spec, the number of significant digits should be 1 instead of 2. Thus, the test expectation is changed accordingly. Bug: 69445420 Bug: 112023169 Bug: 112127077 Bug: 112355520 Test: CtsLibcoreTestCases Test: CtsLibcoreOjTestCases: Change-Id: I8178b6b46205146647bf9b79c8efca72a9cc70f9 Merged-In: Iddcaa94c6949b5c6c6550d9a865f5e0e7ee0b4a8 Merged-In: I4becc7fa077ff6699f3d737b52c3ee000db752b5 Merged-In: Ie8530c816e47a15abef011823cd3f2cb90d4c88b Merged-In: I1c6c33707404fe94bcf51d54e98254b1a5bc8127 Merged-In: Ia223a6a9f920aff12ea23835eca5739ff17daa28 Merged-In: I136612050e3f18c28572029bccc006401b6d4e28
2019-04-01Add tests for CipherSpi.updateAAD() and SSLEngine(String, int)Adam Vartanian
We added tests for the implementations in Conscrypt, but these test the behavior of the underlying CipherSpi and SSLEngine classes themselves. Test: cts -m CtsLibcoreTestCases -t org.apache.harmony Bug: 129008943 Change-Id: I2eecebdabfe34aafaacab4a974383becd8eed63e
2019-03-21Refactor/add tests for ObjectStreamClass computeDefaultSUIDPaul Duffin
b/29064453 added a patch to the computeDefaultSUID() method to maintain backwards compatibility in how it is calculated for apps that target <= 23. This change clarifies the behavior by refactoring the code and adding a comment as well as adding appropriate change markers to ObjectStreamClass.c. It also adds tests to verify the impact of those changes on the calculation of the serial version UID. The original code used a variable/parameter called checkSuperclass that was confusing as it related to how the native method was implemented rather than the external effect. The native code works as follows: 1) In order to find the <clinit> method the native code uses a method that searches up the super class hierarchy. That means that if a class does not have a <clinit> method but a superclass does then it will find the superclass' method. 2) If it does not find a method then it returns false which is correct behavior. If it does find a method then it checks the value of the checkSuperclass parameter. 3) If checkSuperclass is false then the native code returns true because it assumes the method it found belongs to the initial class. That is incorrect behavior (kept for backwards compatibility) and confusing because even though checkSuperclass is false it has actually checked the super class. 4) If checkSuperclass is true then the native code will run the same search as it did in #1 but on the super class. If no method could be found or the method was different to the one found in #1 then it returns true as the method found in #1 must have come from the original class. Otherwise, it returns false as the method found in #1 was actually from the super class. This is confusing because it actually checks the super class twice. Hence the checkSuperclass parameter was inverted and renamed to inheritStaticInitializer as that describes the behavior and seems clearer. That broke the harmony test ObjectStreamClassTest#testHasClinit(). That test was very low level that does not test any externally visible behavior but calls the hasStaticInitializer(...) method directly. Rather than fix that the test was removed and replaced with tests that check the behavior of that class by its external impact. The test is described below. The supported way to access the SUID for a class is to use: ObjectStreamClass.lookup(Class).getSerialVersionUID() If the Class supplied to the lookup() method does not have a serialVersionUID field then that will call the computeDefaultSUID(Class) method to compute the default SUID. Unfortunately, the lookup(Class) method caches the results of the class lookup (including the computed default SUID) which makes it impossible to test the behavior of the method on the same Class for version <= 23 and for version > 23 in the same application. Each test has to have its own Class, with its own default SUID making it difficult to understand which tests are affected by the version and which are not. So, instead of using the lookup(Class) method the tests use reflection to invoke the computeDefaultSUID(Class) method directly, bypassing the lookup cache and allowing the default SUID to be computed multiple times for the same class. Each Class has two tests, one for testing version <= 23 and one for version > 23. For those Classes whose default SUID is unaffected by the version the tests use a common constant for the expected SUID. Tested by running the tests on the device before and after cleaning up the code. Test: atest \ core-tests:libcore.java.io.ObjectStreamClassTest \ org.apache.harmony.tests.java.io.ObjectStreamClassTest Bug: 109930347 Change-Id: I245118af8a81ffba123d773e37560ef655e108a3
2019-03-21Add JUnit 4 TestRule for running tests with a specific target SDKPaul Duffin
Refactors code to replace lots of custom code for testing behavior for specific target SDK versions, whether it is try...finally... blocks or methods using lambdas with a JUnit 4 TestRule. As the tests were JUnit 3 that also required switching them from extending TestCase to extending TestCaseWithRules which adds support for JUnit 4 TestRules to TestCase. This is preparation work for some follow up work on ObjectStreamClass. Test: atest \ core-tests:org.apache.harmony.tests.java.io.ObjectStreamClassTest \ core-tests:libcore.java.lang.OldRuntimeTest \ core-tests:libcore.java.lang.PackageTest \ core-tests:libcore.java.lang.reflect.annotations.AnnotationsTest \ core-tests:libcore.java.util.CollectionsTest \ core-tests:org.apache.harmony.regex.tests.java.util.regex.PatternTest \ core-tests:libcore.junit.util.SwitchTargetSdkVersionRuleTest Bug: 109930347 Change-Id: I4ea11288eb344eaeb2e6cc9f3225748e518e1827
2019-02-26Allow "." as a valid internationalised domain name.Pete Bentley
Rejecting "." causes issues for developers using DNSSEC libraries (see bug) and is inconsistent with RI. My upstream fix to ICU was initially rejected so adding a workaround in java.net.IDN until I can resolve that. Bug: 113787610 Test: atest CtsLibcoreTestCases:org.apache.harmony.tests.java.net.IDNTest Change-Id: Ic10099eb106980389dc19edf0e20c7105377ff6e
2019-02-18Merge "ConcurrentModificationException: Add test coverage for message, cause."Treehugger Robot
2019-02-18Merge changes Ib8491242,I695758c4Treehugger Robot
* changes: EnumSet.isEmpty(): Provide test coverage. Lists: test coverage for misc corner cases.
2019-02-18ConcurrentModificationException: Add test coverage for message, cause.Tobias Thierer
Adding such coverage for other exceptions is left to follow-up CLs. Test: atest CtsLibcoreTestCases:org.apache.harmony.tests.java.util.ConcurrentModificationExceptionTest Change-Id: I5c02571c63d5a2203b4aa0a49e4348304e40eca2
2019-02-18EnumSet.isEmpty(): Provide test coverage.Tobias Thierer
Previously, only size() was covered by tests. Test: atest CtsLibcoreTestCases:org.apache.harmony.tests.java.util.EnumSetTest Change-Id: Ib849124295207f80b1152c0692bb53e77d209dae
2019-02-18Lists: test coverage for misc corner cases.Tobias Thierer
Add test coverage for minor functionality that was not previously exercised by tests, according to coverage analysis. This CL refactors ForEachRemainingTester to take a Supplier<Collection> rather than a Collection class, in order to be able to test List.subList().forEachRemaining(). The majority of the uncovered logic is left for future CLs. Test: atest CtsLibcoreTestCases:org.apache.harmony.tests.java.util.{ArrayList,LinkedList,Vector}Test Change-Id: I695758c4bef54086a66c270cc157ed35f95689cd
2019-02-12SimpleDateFormat: Improve test coverage for whitespace within dates.Pete Bentley
Bug: 119659713 Test: atest CtsLibcoreTestCases:org.apache.harmony.tests.java.text.SimpleDateFormatTest Test: The test for whitespace before two digit years will fail on Pie and below Change-Id: I8b3e225fc16e6f149a9d1a0ef0db9ae9711481da
2019-01-21DirectXBufferTest: Replace int literals with X.BYTES constants.Tobias Thierer
Also, drop one redundant throws clause. This makes the tests more readable. Bug: 123174577 Test: CtsLibcoreTestCases Change-Id: If027315feb9338bd86f4ad19bea354523b22cbc6
2019-01-21Replace use of libcore.io.SizeOf with X.BYTES.Tobias Thierer
X.BYTES is part of the Android API since API level 24. Since its introduction, the internal API SizeOf.X is obsolete. This CL topic removes use of the obsolete API so that it can be dropped in a follow-up CL. Bug: 123174577 Test: Ran CtsLibcoreTestCases at a follow-up CL. Change-Id: I4087c8c4bc8c60afa38103125139d5db689294c4
2019-01-15Update tests for TLS 1.3 by defaultAdam Vartanian
Fix tests that excluded TLS 1.3 cipher suites from the list of suites expected to be enabled. Also remove one test that assumed key exchange mechanisms must be part of the cipher suite names. TLS 1.3 cipher suites do not include the key exchange mechanism, which is negotiated separately. Test: cts -m CtsLibcoreTestCases Change-Id: I99509c3c813a16b045629acc1c861fa06c077ca8
2018-11-19Fix harmony URLConnectionTest hanging for 25sec.Tobias Thierer
The Handler for file:// URLs contains a fallback to FtpURLConnection for URLs with nonempty host (with some exceptions). URLConnectionTest.test_getContentType() contained a typo ("file:/" instead of "file://"). This led to the URL having a non-empty host value ("data"), which triggered a fallback to FtpURLConnection in the Handler for file:// URLs. The test attempted to resolve the host "data", eventually timing out. getContentType() by itself swallows any IOException and just returns null, and the test was written to tolerate null, so it didn't fail. The test code hasn't been touched since the initial commit in 2009, which makes it hard to tell whether the null tolerance was because someone had observed the test failing (but not understood why), or perhaps wanted to make the test tolerant of poor contentType detection. This CL fixes the typo, which makes the test pass in milliseconds rather than in 25+ seconds. This CL also makes the test stricter by checking specifically for "text/html" rather than a case-insensitive version of it or null. It also checks for a file:// (as opposed to ftp://) URLConnection for the two cases fixed by this CL and by http://r.android.com/82755 (commit 2587ef91ba693d73e97704e8163c050b286e7330). The logic for fallback to FtpURLConnection remains in place; basic test coverage for it exists in org.apache.harmony.tests.java.net.URLTest#test_openConnection_FileProtocol (this CL fixes a minor typo in that test name). The test appears to derive from code written for https://issues.apache.org/jira/browse/HARMONY-5779 Test: atest CtsLibcoreTestCases:org.apache.harmony.luni.tests.java.net.URLConnectionTest Test: atest CtsLibcoreTestCases:org.apache.harmony.tests.java.net.URLTest Test: CtsLibcoreTestCases Test: Checked that nothing else in CtsLibcoreTestCases relies on the fallback to FtpURLConnection by locally replacing it with an AssertionError and checking that the only failing test is test_openConnection_FileProtocol(). Fixes: 119607552 Change-Id: Ib5bf45f11e49c56a34fda5fe3cb27485c2d7176c
2018-10-18Libcore: Suppress SubstringOfZeroAndreas Gampe
The test checks the behavior of substring(0). Bug: 114129741 Test: m javac-check RUN_ERROR_PRONE=true Change-Id: Ib9d169340971f78c3d3dbd121202145bb577091e
2018-10-10Add testing support code: TestIoUtilsNeil Fuller
Add testing support code that CTS can use instead of private platform APIs. Bug: 117535564 Bug: 113148576 Test: Run cts Change-Id: I63ad197744075c14886a639bfba83392ac39854f
2018-09-13Update tests for Conscrypt updateAdam Vartanian
This mainly updates the tests to account for the existence of TLS 1.3. In particular, add the new TLS 1.3-related constants to StandardNames and update some old harmony tests to handle the fact that we now report TLS 1.3 cipher suites as being supported. Bug: 110403171 Test: cts -m CtsLibcoreTestCases Test: cts -m CtsLibcoreOkHttpTestCases Test: cts -m CtsLibcoreWycheproofConscryptTestCases Change-Id: I1ff6aa5961438527b0eb882488a5dbfaaeaacc6c
2018-07-16Verify ZipInputStream against upstream OpenJDK 8u121-b13Paul Duffin
Made change markers follow the standard and updated comments to provide more context. Also modified test slightly to give more information in the event of failure. Bug: 111061052 Test: no functional changes but used vogar to run zip tests Change-Id: I1756af9b35afca442d761a7b3dfe088b9fb69230
2018-07-12Inflater: Revert ensureOpen() changes to upstream 8u121-b13Paul Duffin
The luni implementation of Inflater threw an IllegalStateException if it was used after its end() method had been called but upstream throws NullPointerException in that situation. The ojluni version was patched in change b3c5785d in order to fix some failing tests. This change reverts that patch and fixes the affected tests. Throwing an NPE instead of an ISE could cause app compatibility issues but it seems unlikely and in that case the application could simply catch both. An ISE is a more meaningful exception to throw but the benefit is minor especially given that the message clearly indicates why it was thrown and does not seem sufficient to justify carrying an additional patch. Bug: 111061052 Test: flash, CtsLibcoreTestCases Change-Id: I91ca999a7d3e81c571f960e01b5a2557a1676592
2018-07-05BigDecimal: Treat zero consistently in stripTrailingZeros().Pete Bentley
Reverts changes 5c2b841724e903a06efdfb854bc2cd7c305728ed and 4b8c7d1c8812bf0f6e29d557a5794e126202133e which preserved trailing zeroes as a special case for BigDecimal(0). Bug: 111058784 Test: Flash and run CtsLibcoreTestCases Change-Id: Ib7e928b39d30a44884742847507120d0d2d29be9
2018-06-26Verify Pattern, step 2: Integrate behavior change for Pattern.split().Tobias Thierer
This is the second attempt to submit this CL. The first attempt broke TextUtilsTest which is now updated by another CL in this topic; also, the original CL changed behavior for all apps whereas this CL only changes it for apps targeting API > 28. This CL integrates a behavior change that was forgotten in the update from OpenJDK 7u40 to 8u121-b13. This CL also adds a test to guard against regressions. Bug: 109659282 Test: testMatchBeginningOfInputSequence() fails before this CL, but passes after this CL. Test: cts-tradefed run singleCommand cts -a arm64-v8a -m CtsLibcoreTestCases \ -t org.apache.harmony.tests.java.util.regex.SplitTest Test: cts-tradefed run singleCommand cts -a arm64-v8a -m CtsLibcoreTestCases \ -t org.apache.harmony.regex.tests.java.util.regex.PatternTest Change-Id: Ic3631667de0b5cbc4531d42b342d752a701e822f
2018-06-19Merge "Revert "Verify Pattern, step 2: Integrate behavior change for ↵Colin Cross
Pattern.split().""
2018-06-19Revert "Verify Pattern, step 2: Integrate behavior change for Pattern.split()."Colin Cross
This reverts commit 990d9dfa0432ff598aaf64519a5ce1129e822ee7. Reason for revert: Broke CtsTextTestCases Bug: 109659282 Bug: 110381464 Change-Id: I91e2cf50d17a6822690b375bc9fa83ecea84ce04
2018-06-19Merge "Kill stray processes spawn by some java.lang.Process related tests."Roland Levillain
2018-06-19Kill stray processes spawn by some java.lang.Process related tests.Roland Levillain
The following tests execute "sleep" commands, but did not destroy the corresponding processes: - org.apache.harmony.tests.java.lang.ProcessManagerTest#testSleep - org.apache.harmony.tests.java.lang.ProcessTest#test_exitValue These processes would eventually die (at the end of the sleep period), but in the case of chroot-based on-device testing on the ART Buildbot, these stray processes would prevent the unmounting of the /dev filesystem in the chroot directory by the tear-down script. Explicitly kill these processes at the end of these tests. Test: art/tools/run-libcore-tests.sh --mode=device --variant=X64 && art/tools/teardown-buildbot-device.sh Bug: 34729697 Change-Id: I92c83fa442cd916ce9cce268b784a4a974758132
2018-06-18Merge "Verify Pattern, step 2: Integrate behavior change for Pattern.split()."Treehugger Robot
2018-06-14Libcore: Fix or hide ConstantOverflow errorprone warningsAndreas Gampe
Hide ConstantOverflow in oj code and tests. Mark the warning as suppressed in harmony tests. Bug: 110155920 Test: m javac-check RUN_ERROR_PRONE=true Change-Id: I3aacd13ea726eca999d6f4b64e1e74264bebc3af
2018-06-12Verify Pattern, step 2: Integrate behavior change for Pattern.split().Tobias Thierer
This CL integrates a behavior change that was forgotten in the update from OpenJDK 7u40 to 8u121-b13. This CL also adds a test to guard against regressions. Bug: 109659282 Test: testMatchBeginningOfInputSequence() fails before this CL, but passes after this CL. Test: make cts && cts-tradefed run cts -m CtsLibcoreTestCases Change-Id: Ie7340629a0954fa231d1a1f2a51885c0774ed436
2018-06-12Unify duplicate copies of harmony {Matcher2,Mode,Replace,Split}Test.Tobias Thierer
Android is carrying near-duplicate copies of these tests introduced in: 1.) luni/: commit fdb2704414a9ed92394ada0d1395e4db86889465 (2008-10-21, "Initial Contribution") 2.) harmony-tests/: commit bfd68b1dd4409f61fbc6800ba61f4605ad57945b (2013-05-03, "Add the harmony regex tests.") The initial copies already differed, eg. This CL integrates differences between the two copies. After this CL, the files are pairwise identical except: - they are in different packages - luni's SplitTest.java is missing the file header Most of the changes are integrated luni/ -> harmony-tests, keeping tests that were previously only present in one copy, eg.: - slightly more verbose test case in ReplaceTest.testSimpleReplace() - SplitTest.testEmptySplits() (added in commit 51809b9c7995d8b813f68712b096d23179de3af0 ) - Matcher2Test tests added by http://r.android.com/695546 In cases where the "better" version is not clear, an arbitrary judgement call was made. Examples: - @SuppressWarnings("nls"): Differed in the original imports. Might be Eclipse specific, but kept for now. - minor whitespace changes - formatting of ReplaceTest This CL does not touch the following files / differences: - luni/ has PatternTest but harmony-tests/ has MatcherTest - luni/ has PatternSyntaxExceptionTest but harmony-tests/ has PatternErrorTest Bug: 109727025 Test: Treehugger Test: Ran CtsLibcoreTestCases at a later CL. Change-Id: Ib1c1c25c2010c082e119a0b8b21dadf58576e3f7
2018-05-30Matcher: Adopt behavior changes forgotten in update to OpenJDK 8.Tobias Thierer
This is step 5 of verifying Matcher.java vs. OpenJDK 8u121-b13. Matcher.java was never properly updated from OpenJDK 7u40 to OpenJDK 8 (u60, u121-b13). This CL adopts the following behavior changes that were thus forgotten, and adds unit tests enforcing them: replaceFirst() - Adopt the following behavior even when there is no match: - still throw NPE - don't reset() - Previously, the NPE was not thrown and the Matcher was reset(). start(int group), end(int group): - throw IOOBE rather than ArrayIndexOutOfBoundsException if group < 0 or group > groupCount appendReplacement(StringBuffer, String): - if replacement ends in \ or $ then the method now throws IAE; the old code only checked for training \ and threw an IOOBE instead of IAE. This behavior change required updating an old regression test from Harmony to expect the new behavior. - Note: The implementation of appendReplacement() appears to have previously been done independently from the upstream code. Its implementation could be changed to be based on / much more similar to upstream code, but this is not done as part of this CL. Test: Before but not after this CL, the exceptions encountered by the out-of-bounds tests added to OldMatcherTest were specifically instances of ArrayIndexOutOfBoundsExceptions. The tests as written don't care about the kind of IOOBE they encounter, so they pass both before and after this CL. Test: testReplaceFirst_null_match passes both before and after this CL. Test: All other added tests fail before this CL but pass after this CL. Test: CtsLibcoreTestCases Bug: 80416774 Change-Id: Ibdee4976f5033c7913fa98a65475f2c7a310ebc9
2018-04-27Verify java.nio.{Char,Double,Float,Int,Long,Short}Buffer.Tobias Thierer
After this CL, these classes are verified against upstream OpenJDK8u121-b13. This CL reverts some Android changes in those classes and adopts upstream changes that were forgotten in the update from OpenJDK 8u60 to 8u121-b13. There are two behavior changes in this CL: - Change in behavior of DoubleBuffer.compareTo(), which didn't previously match documentation. A unit test is added. - Change in behavior for bulk put() when both ReadOnlyBuffer and BufferOverflow are encountered. ByteBuffer is handled by separate CLs. Detailed list of changes follows. All classes - Adopt upstream code for early check for readonly buffer during bulk put(). This integrates the upstream fix for JDK-7199551 in OpenJDK8u61, which had been forgotten in the update from 8u60 to 8u121-b13. This changes behavior only for the case where a put() failed for multiple reasons, eg. a read-only buffer that also didn't have enough space; before this CL, this could have thrown BufferOverflowException but will now throw ReadOnlyBufferException. This behavior change is not covered by tests; this CL does not add such tests, since the documentation doesn't specify either behavior and it appears unlikely to affect apps. CharBuffer - Adopt upstream formatting of documentation for get(char[]). - put() had Android changes for ReadOnlyBuffer and BufferOverflow checks, but OpenJDK8u121-13 had nearly identical checks. This CL reverts the Android changes and adopts upstream's version. - Revert an unexplained difference in chars() to match the version from 8u60 and 8u121-b13. The version before this CL had been introduced by commit 5458546631c65f6d375b6a1780d36d0abb5b95af which didn't say whether / from which upstream commit it came. I didn't check whether that other version matched 7u40 or some other upstream revision because I don't have the generated files for those readily available and it seemed unimportant. DoubleBuffer - Revert Android change around using Double.compare() instead of DoubleBuffer.compare(). A comment from commit b304b288d1deafd07ee13e1540acc0a22db07736 suggests that the aim of the change was to avoid "duplicating code pointlessly", but the documentation for DoubleBuffer.compareTo() explicitly lists some differences from Double.compare() that the changed code was not consistent with. Since Android has kept similar differences between Float.compare() vs. FloatBuffer.compareTo(), this CL reverts the Android change in DoubleBuffer.compareTo(). This CL adds a unit tests for the changed behavior, which is consistent with the documentation. Test: CtsLibcoreTestCases Test: DoubleBufferTest.testCompareTo_positiveAndNegativeZero() fails when run against Android 7.1.1. Bug: 35910877 Change-Id: I5167d9da54aaad63778f8519d23222dda14a87ca
2018-04-25Add missing test coverage for ByteBuffer.allocateDirect().Tobias Thierer
This method was called as a side-effect of some other tests, but never as part of a dedicated / comprehensive test. For example, the case of a negative argument was not covered by tests. This CL adds such coverage. This CL also tweaks a couple of assertContentEquals() helper methods to be static. Test: testAllocateDirect() passes. Bug: 35910877 Change-Id: I6807383d0c47d3b8e6d3c8b15fc3ba0432a92b3d
2018-04-20Delete JarFileTest.testGetJarEntry().Tobias Thierer
The first five lines of this test duplicate assertions already present in other tests. The rest of the test attempts to download http://jcltest.apache.org/testres231/../internalres/signedjars/jarlist.txt the host of which no longer exists. Usually this triggers an IOException, which is caught in the test and causes the test to do nothing. However it can also lead to timeouts during the DNS lookup, which makes the test flaky (has been observed to fail with timeout under vogar). This is not the only test that relies on a third party server; the others are left to future CLs. This CL drops the flaky and redundant/nonfunctional test. Bug: 78269207 Bug: 78278018 Test: Treehugger Change-Id: If2baa5d7dc00b899a46422342432f49303ea6d2a
generated by cgit v1.2.3 (git 2.25.1) at 2025-10-03 13:08:05 +0000