summaryrefslogtreecommitdiffstats
path: root/expectations
Commit message (Collapse)AuthorAgeFilesLines
* expectations: add SSL_renegotiate tests to known failuresSergio Giro2015-06-231-0/+9
| | | | | | | | | | SSL_renegotiate was deprecated and is currently a no-op. We need to rewrite tests for the client response to renegotiation. Bug: 21876068 Bug: 21875889 Change-Id: I8c228cc4d6a388ca740316aa970fd54755b22bb1 (cherry picked from commit 7f3c9cd05a61da205137195e115135a66eb8f6a6)
* Add test_PacketSocketAddress to the list of known failures.Narayan Kamath2015-06-011-0/+8
| | | | | | | | | | | Needs CAP_NET_RAW which means it can only ever run successfully as root. bug: 19764047 (cherry picked from commit 676fbcf150d23bb81da6dccd40bcd085a2eeee8a) Change-Id: I6c24cb9a781340d4c92fb53aa2670ddb99031c73
* resolved conflicts for merge of 72b26859 to lmp-mr1-ub-devNeil Fuller2015-05-261-0/+8
|\ | | | | | | Change-Id: Id188dacbfd8e83fd884f838e392444890a231e5e
| * Suppress a couple of tests that need quite a lot of memoryNeil Fuller2015-05-231-0/+8
| | | | | | | | | | | | | | | | | | | | | | These tests fail on some Android Watch devices. Suppressing them until we have a mechanism to detect low memory devices that would allow them to be suppressed more selectively. Bug: 20055487 (cherry-picked from commit fcee6ab5383ee0ad68fcc74ced7581a24d2521de) Change-Id: I53792de9081774b36d03f2de718e73a1c6ff32d5
| * am 3eb44e34: Merge "Delete ContentHandlerFactoryTest." into lmp-sprout-devNarayan Kamath2014-12-041-7/+0
| |\ | | | | | | | | | | | | * commit '3eb44e343bfd8bcda4be8650aff310feda4d5562': Delete ContentHandlerFactoryTest.
| | * Delete ContentHandlerFactoryTest.Narayan Kamath2014-12-041-7/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It uses reflection, has all sorts of weird stuff in it and isn't run as part of CTS because it has irreversible side effects (the last of these isn't the tests fault). There's no good reason to keep it, and it seems infeasible to write a half-decent test without adding lots of hidden api (which defeats the purpose of the test in the first place). bug: 18619181 (cherry picked from commit e9847f0ca58cec293b3a6298b7549cfabe6a30c9) Change-Id: Ia69c0011683eac90e4cca70a8f3f15fb82cece44
| * | Revert "Suppress zip & spdy tests that are OOMing with a 48MB max heap."Narayan Kamath2014-11-241-15/+0
| | | | | | | | | | | | | | | | | | This reverts commit 15e853493f013a5397288088c20354e2bd436a5a. bug: 18256012
| * | am fd7ab0e2: Merge "Suppress zip & spdy tests that are OOMing with a 48MB ↵Narayan Kamath2014-11-241-0/+15
| |\ \ | | |/ | | | | | | | | | | | | | | | max heap." into lmp-sprout-dev * commit 'fd7ab0e2f9626ca5233eea7373e99e3fbd4e83f1': Suppress zip & spdy tests that are OOMing with a 48MB max heap.
| | * Suppress zip & spdy tests that are OOMing with a 48MB max heap.Narayan Kamath2014-11-211-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | Some of these tests allocate only about 2mb of ram, so we need to analyze the state of the heap to figure out where this memory is going. bug: 18256012 Change-Id: I11ed892d9798bb24d7e5cedc7e93e9c8e7afe80d
| * | Suppress okhttp's ResponseCacheAdapterTest.Takayuki Hoshi2014-11-071-0/+1
| |/ | | | | | | | | | | | | This avoids a known SPDY issue that sometimes makes the related CTS tests fail. Bug: 18066923 Change-Id: I9540dc3ad6b6a3d7ab37eb77d46dba39b7bbbb7b
* | Update test expectations after rename.Narayan Kamath2015-04-031-3/+3
| | | | | | | | | | | | Zip64 tests were moved to Zip64FileTest. Change-Id: I653e63268e174d4f70e8eecd2d5535fbf6556588
* | Implement zip64 support for ZipFile/ZipInputStream/ZipOutputStream.Narayan Kamath2015-02-271-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are several open questions that I hope to resolve in future changes : - Our heuristics for detecting whether a zip outputstream should switch over to zip64 or not are imprecise. - Also, given that we now officially support zip64, we have to assume new entries whose size is unknown need the zip64 header / footer. This will make output files slightly larger and less compatible with older tools. If we don't do this, we'll have to go back and rewrite & compact parts of the stream we'd already flushed, which isn't always possible. The other option is to assume zip32 for streams of unknown length and throw if more than 4G of data is written to them. Change-Id: Ibb4a97b5f83fd3ab850d7c407ecfda663968a6b9
* | Set the test as large, it can reach the 1 minute timeout.Nicolas Geoffray2015-01-291-0/+1
| | | | | | | | | | BUG: 19165288 Change-Id: I1112170a917fe9f5c5482544edae3d326832f638
* | Fix the infinite loop issue of the conversion from string to doubleJingwei Zhang2015-01-231-9/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch provide the additional check for “z”. The “if” statement checks whether the double precision value z, is at the end of a binade (a term used to describe the set of numbers in a binary IEEE 754 floating-point format that all have the same exponent, i.e., a binade is the interval [2n, 2n+1) for some value of n.) If so, it needs to adjust for the change of ulp (unit of least precision is the spacing between two consecutive floating-point numbers, i.e., the value the least significant digit represents if it is 1). The adjustment is done by the “simpleShiftLeftHighPrecision” routine. This is all necessary, except when z is close to denormal (i.e. DOUBLE_TO_LONGBITS(z)==DOUBLE_NORMAL_MASK) where no adjustment is needed since the ulp should remain the same once z becomes denormal. This means we can remove the old hack that counted how many times we'd incremented or decremented, so this patch removes the DECREMENT_DOUBLE and INCREMENT_DOUBLE macros. This patch also contains the float equivalent of everything mentioned above, plus some new tests. Finally, this patch removes the USE_LL conditional compilation because it was always true. Bug: 18087920 Change-Id: I4a9112f012dfd9eeb8db89f0652528b6c02e8f1e Signed-off-by: Jingwei Zhang <jingwei.zhang@intel.com> Signed-off-by: Mingwei Shi <mingwei.shi@intel.com>
* | Merge "Add a unit test to demonstrate ICU CharsetProvider problems"Narayan Kamath2015-01-201-0/+7
|\ \
| * | Add a unit test to demonstrate ICU CharsetProvider problemsNarayan Kamath2015-01-201-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | Also add a single FakeCharsetProvider for unit tests that does nothing by default, so that we can stub it in for tests that do care about it and none of our other tests are affected. Change-Id: I03abb8f1aff53c160935b4cdbeaef764d30f240a
* | | Merge "Changes needed to support OkHttp upgrade"Neil Fuller2015-01-201-39/+4
|\ \ \ | |/ / |/| |
| * | Changes needed to support OkHttp upgradeNeil Fuller2015-01-201-39/+4
| | | | | | | | | | | | Change-Id: Ifd6ed8ab22e7fd5d8cb8c9eb28976291d125c0e4
* | | Fix the hostname for the IPv6 loopback addressNeil Fuller2015-01-141-1/+0
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously the hostname was "localhost", which resolves to the IPv4 loopback address. Also fixed the documentation for getAllByName(null) which has returned the loopback addresses all the way back to 2009 and not thrown an exception as suggested in the docs. Test fixes and new tests included. Depends on commit 25147416bb105914c3cdf8fd65ca7cc20dae0f3e Bug: 18991397 Bug: https://code.google.com/p/android/issues/detail?id=96801 Change-Id: I9723516a977e2a3b97412bc1d7e58b36df327feb
* | Update expectations, tests don't fail.Nicolas Geoffray2014-12-051-2/+0
| | | | | | | | Change-Id: I26b1e65db8814833dff0607db0bd4c5dadef2957
* | Delete ContentHandlerFactoryTest.Narayan Kamath2014-12-041-7/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | It uses reflection, has all sorts of weird stuff in it and isn't run as part of CTS because it has irreversible side effects (the last of these isn't the tests fault). There's no good reason to keep it, and it seems infeasible to write a half-decent test without adding lots of hidden api (which defeats the purpose of the test in the first place). bug: 18619181 Change-Id: I1507a42e12210869b727f46b543e0cebfc50f184
* | Update expectations of cbrt test.Nicolas Geoffray2014-12-031-0/+9
| | | | | | | | Change-Id: Ic89252d1379ba25f46b8dc06833ab9bbe769c846
* | Update expectations for host.Nicolas Geoffray2014-11-272-0/+26
| | | | | | | | Change-Id: Idd63b469726a1b6529d3aed931f02024ba04b903
* | am bc1ea657: Suppress failing OkHttp CTS testsNeil Fuller2014-10-151-0/+13
|\ \ | |/ | | | | | | * commit 'bc1ea6573c76663718d441f7b0b849a91f3eefbd': Suppress failing OkHttp CTS tests
| * Suppress failing OkHttp CTS testsNeil Fuller2014-10-131-0/+13
| | | | | | | | | | | | | | | | Added an additional regression test for SSLSocketTest. Bug: 17962997 Bug: 17750026 Change-Id: Ic1171a916a8dbfe4f0ae486d650583de2547175b
| * Rewrite tests and add tests that demonstrate a bugNeil Fuller2014-09-291-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The bug: DecimalFormat.format() behavior is slightly lossy around 15 decimal digits even without any digit constraints. This change isolates the test failures that result from this bug to 2 test cases: test_formatDouble_bug17656132 test_formatDouble_roundingProblemCases Example of the bug: Double: 999999999999999.9 is represented as an IEEE 754 value which is exactly decimal 999999999999999.875 When format(999999999999999.9) is called on a DecimalFormat with large MaxIntegerDigit and MaxFractionDigit.... Correct answer: "999999999999999.9" Actual answer: "1000000000000000" By contrast Double.toString() prints 9.999999999999999E14 for Android and the RI (correctly). The DecimalFormat is printing to 16 decimal digits: The inclusion of the 16th digit implies slightly more precision than IEEE 754 provides (~15.9 decimal digits for most of the representable range). However, the use of 16 decimal digits for outputting IEEE 754 appears consistent with Double.toString() and elsewhere. Before printing, DecimalFormat appears to be rounding to 15 decimal digits internally (or something similar). Parsing "1000000000000000" produces a different double representation than the original double (one that is closer to 1000000000000000 than 999999999999999.9). This is the bug - we just lost information. We should be able to round-trip a double if there is no rounding since every double is representable with decimal and we have sufficient digits available to represent it (close enough) in decimal. Additional tests have been added to demonstrate the bug and also demonstrate the (correct) formatting behavior when the formatter is rounding. test_formatDouble_maxFractionDigits: rounding at 1, 10, 14 digits after the dp. test_formatDouble_roundingTo15Digits: rounding at 15 total digits overall test_formatDouble_bug17656132: Demonstrates the bug concisely. The test changes: test_formatDouble_wideRange(): implicitly assumed that the any loss of accuracy when a decimal string was turned into a double would be undone when format() was called, and it would always arrive back at the original string. The test has been re-written here to use BigDecimal rather than Double.parseDouble(), and to compare two doubles rather than original string with the output from format(). The test was previously failing with the RI for 1E23: the closest representable double to 1E23 is exactly 99999999999999991611392. The value produces "99999999999999990000000" when formatted with the RI and not "100000000000000000000000". On Android it was passing for 1E23 because of bug 17656132 rounding back to the original decimal value. This test was previously failing on Android with 1E-309 because below 1E-308 IEEE 754 starts losing precision and the closest representable value is not close to the original string. The test now isn't affected if the double being tested is not close to the original decimal; it passes providing the can be round tripped. test_formatDouble_roundingProblemCases: Re-written like the _wideRange test but continues to demonstrate the bug due to the test values (intentionally) chosen. Bug: 17656132 (cherry picked from commit 4e92b6265acb1d12109e311819dd64b27ec85df5) Change-Id: I0b3245d8984999b2731508bb90de785492bb211b
* | am 972b7282: Merge "Rewrite tests and add tests that demonstrate a bug"Neil Fuller2014-09-261-0/+8
|\ \ | | | | | | | | | | | | * commit '972b728220e3d85eb549aa3451e872f5a06e25c1': Rewrite tests and add tests that demonstrate a bug
| * | Rewrite tests and add tests that demonstrate a bugNeil Fuller2014-09-261-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The bug: DecimalFormat.format() behavior is slightly lossy around 15 decimal digits even without any digit constraints. This change isolates the test failures that result from this bug to 2 test cases: test_formatDouble_bug17656132 test_formatDouble_roundingProblemCases Example of the bug: Double: 999999999999999.9 is represented as an IEEE 754 value which is exactly decimal 999999999999999.875 When format(999999999999999.9) is called on a DecimalFormat with large MaxIntegerDigit and MaxFractionDigit.... Correct answer: "999999999999999.9" Actual answer: "1000000000000000" By contrast Double.toString() prints 9.999999999999999E14 for Android and the RI (correctly). The DecimalFormat is printing to 16 decimal digits: The inclusion of the 16th digit implies slightly more precision than IEEE 754 provides (~15.9 decimal digits for most of the representable range). However, the use of 16 decimal digits for outputting IEEE 754 appears consistent with Double.toString() and elsewhere. Before printing, DecimalFormat appears to be rounding to 15 decimal digits internally (or something similar). Parsing "1000000000000000" produces a different double representation than the original double (one that is closer to 1000000000000000 than 999999999999999.9). This is the bug - we just lost information. We should be able to round-trip a double if there is no rounding since every double is representable with decimal and we have sufficient digits available to represent it (close enough) in decimal. Additional tests have been added to demonstrate the bug and also demonstrate the (correct) formatting behavior when the formatter is rounding. test_formatDouble_maxFractionDigits: rounding at 1, 10, 14 digits after the dp. test_formatDouble_roundingTo15Digits: rounding at 15 total digits overall test_formatDouble_bug17656132: Demonstrates the bug concisely. The test changes: test_formatDouble_wideRange(): implicitly assumed that the any loss of accuracy when a decimal string was turned into a double would be undone when format() was called, and it would always arrive back at the original string. The test has been re-written here to use BigDecimal rather than Double.parseDouble(), and to compare two doubles rather than original string with the output from format(). The test was previously failing with the RI for 1E23: the closest representable double to 1E23 is exactly 99999999999999991611392. The value produces "99999999999999990000000" when formatted with the RI and not "100000000000000000000000". On Android it was passing for 1E23 because of bug 17656132 rounding back to the original decimal value. This test was previously failing on Android with 1E-309 because below 1E-308 IEEE 754 starts losing precision and the closest representable value is not close to the original string. The test now isn't affected if the double being tested is not close to the original decimal; it passes providing the can be round tripped. test_formatDouble_roundingProblemCases: Re-written like the _wideRange test but continues to demonstrate the bug due to the test values (intentionally) chosen. Bug: 17656132 Change-Id: I7d81e38bd1f9dbfd1e1b2caa60a6bb16b871b925
| * | Mark ↵Elliott Hughes2014-09-261-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | libcore.java.text.DecimalFormatSymbolsTest#test_getInstance_unknown_or_invalid_locale a known failure. The good news is that for the first time we understand why this is failing. Too big to fix for L though, and not a regression. Bug: 17374604 (cherry-picked from commit f887ab7ef74d3ca821aca63ccee2c86cc6a42489) Change-Id: I589fe2eae0643e07e8db8cbcc7df52563aa24604
* | | am 8d848927: am 82404753: Merge "Suppress ConnectionTest: It uses SPDY, ↵Neil Fuller2014-09-111-0/+1
|\ \ \ | | |/ | |/| | | | | | | | | | | | | which can cause IllegalStateException" into lmp-dev * commit '8d848927c29aa2c71809435aeea78a3555842566': Suppress ConnectionTest: It uses SPDY, which can cause IllegalStateException
| * | Suppress ConnectionTest: It uses SPDY, which can cause IllegalStateExceptionNeil Fuller2014-09-111-0/+1
| | | | | | | | | | | | | | | | | | Bug: 17313155 Bug: 14462336 Change-Id: I4b2f09e197f6ccb7fc6bd0a901095919d011d3e8
* | | Remove an erroneous double-merge in the knownfailures.txt fileNeil Fuller2014-09-091-17/+0
| | | | | | | | | | | | | | | | | | | | | The original change in AOSP/master and the patch of the same change in lmp-dev created a monster. Change-Id: Ib6644022384e03b0dc9a268bb3926505adfccfd6
* | | am bcc98757: am d4bbc220: Merge "Suppress broken apache-harmony beans CTS ↵Neil Fuller2014-09-091-0/+17
|\ \ \ | |/ / | | | | | | | | | | | | | | | tests" into lmp-dev * commit 'bcc9875756c27187ff332f855102657411346cd7': Suppress broken apache-harmony beans CTS tests
| * | Suppress broken apache-harmony beans CTS testsNeil Fuller2014-09-091-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | One of the apache-harmony serialization tests is package-sensitive. The other tests suppressed probably broke due to a fix in the Android fork of harmony (commit 19a270e90b1e992c1f6639f355ae13564c2f3a6a). The code may be incorrect but if so it has been broken subtly since Dec 2010. Bug 17433734 has been created to investigate. Bug: 17394106 (cherry picked from commit e9121d6ce39668597349e818135214adc92285e5) Change-Id: Ia53e9390c153f8fc7110c360ac635b4ef8fd783c
| * | Suppress one more apache-harmony sql testNeil Fuller2014-09-091-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The test is broken and is being suppressed: com.android.org.apache.harmony.sql.tests.java.sql.DataTruncationTest Bug: 17342415 (cherry picked from commit 51ff72e84d7f862fc4193dbc747de07cd30e5226) Change-Id: I811a6c032d7c73e77c67d94d47639a6d806b7238
* | | am 2ead7d19: Merge "Suppress one more apache-harmony sql test"Neil Fuller2014-09-091-0/+1
|\ \ \ | | |/ | |/| | | | | | | * commit '2ead7d19c4fe15fbe4dff32866204de6d4c9835c': Suppress one more apache-harmony sql test
| * | Suppress one more apache-harmony sql testNeil Fuller2014-09-091-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | The test is broken and is being suppressed: com.android.org.apache.harmony.sql.tests.java.sql.DataTruncationTest Bug: 17342415 Change-Id: I5dd2f506400fff7c290e27adf4d3bd34f0624044
* | | am b7ddd5ec: Merge "Suppress broken apache-harmony beans CTS tests"Neil Fuller2014-09-091-0/+17
|\ \ \ | |/ / | | | | | | | | | * commit 'b7ddd5ec95ffc8fb698bbcf5cf07aadf528c2cac': Suppress broken apache-harmony beans CTS tests
| * | Suppress broken apache-harmony beans CTS testsNeil Fuller2014-09-091-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | One of the apache-harmony serialization tests is package-sensitive. The other tests suppressed probably broke due to a fix in the Android fork of harmony (commit 19a270e90b1e992c1f6639f355ae13564c2f3a6a). The code may be incorrect but if so it has been broken subtly since Dec 2010. Bug 17433734 has been created to investigate. Bug: 17394106 Change-Id: I654d82b607e5487e0e6614ec4bcc5be98a9394e9
* | | am c5952ec0: am 2b26994c: Merge "Mark ↵Elliott Hughes2014-09-081-0/+7
|\ \ \ | | |/ | |/| | | | | | | | | | | | | libcore.java.text.DecimalFormatSymbolsTest#test_getInstance_unknown_or_invalid_locale a known failure." into lmp-dev * commit 'c5952ec0d8c4c5a4e3fa01081871c2b549782986': Mark libcore.java.text.DecimalFormatSymbolsTest#test_getInstance_unknown_or_invalid_locale a known failure.
| * | Mark ↵Elliott Hughes2014-09-051-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | libcore.java.text.DecimalFormatSymbolsTest#test_getInstance_unknown_or_invalid_locale a known failure. The good news is that for the first time we understand why this is failing. Too big to fix for L though, and not a regression. Bug: 17374604 Change-Id: If9c221ec9e3a401c4ce9a3de4ff8b7c0e747e814
| * | Suppress broken apache-harmony logging CTS testsNeil Fuller2014-09-031-0/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add test suppression entries for differences known to be caused by Android changes and failures that involve java code fixes. Some failures are the result of the test code being newer than the libcore code. Android took its last libcore update from apache-harmony some time after r820767 but before r929953 and its test-code update at r1097236. This explains a few things. java package fixes will be applied via a separate commit. Bug: 13882147 (cherry picked from commit 3b24d91a6c079234f36ca5cbf862eb975cd5fb4a) Change-Id: I45fc103f20ab430b8924174a690c49bee4083f0f
| * | Suppressing broken java.sql apache harmony tests.Neil Fuller2014-09-031-0/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These are long-standing failures that we don't intend to fix in the foreseeable future. Developers have been encouraged to use android classes for database access. Bug: 17342415 Bug: 17321262 Bug: 17320961 Bug: 17093235 (cherry picked from commit 4459407dbfc74376668c7ff3c94c741ce3447d45) Change-Id: If34ab5218e692ea237de12dafa5cda9b65da0b3c
* | | am fc5a9bde: Merge "Fix apache-harmony logging tests"Neil Fuller2014-09-041-8/+0
|\ \ \ | | |/ | |/| | | | | | | * commit 'fc5a9bde9565f9d6d5aaf1155743a669c37f7f08': Fix apache-harmony logging tests
| * | Fix apache-harmony logging testsNeil Fuller2014-09-041-8/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Changed SocketHandler to re-introduce a "socket != 0" check unintentionally removed by commit 232c91dce1760b180155256d1896d0d80375ff6d. Some failures are the result of the test code being newer than the libcore code. Android took its last libcore update from apache-harmony some time after r820767 but before r929953 and its test-code update at r1097236. This explains a few things. Updated FileHandler to deal with null system properties. This is an equivalent change to http://svn.apache.org/viewvc?view=revision&revision=935099 Updated XMLFormatter to handle basic XML escaping. This is an equivalent change to http://svn.apache.org/viewvc?view=revision&revision=929953 Unsuppress tests that are fixed by this. Bug: 13882147 Change-Id: I36321b488da6d4e08fbb0d28d0e366f9b06e6371
* | | am 4f10651f: Merge "Suppress broken apache-harmony logging CTS tests"Neil Fuller2014-09-021-0/+49
|\ \ \ | |/ / | | | | | | | | | * commit '4f10651fff7200d688e5dda1508448f8b34e4d9f': Suppress broken apache-harmony logging CTS tests
| * | Suppress broken apache-harmony logging CTS testsNeil Fuller2014-09-021-0/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add test suppression entries for differences known to be caused by Android changes and failures that involve java code fixes. Some failures are the result of the test code being newer than the libcore code. Android took its last libcore update from apache-harmony some time after r820767 but before r929953 and its test-code update at r1097236. This explains a few things. java package fixes will be applied via a separate commit. Bug: 13882147 Change-Id: Ie5f3d1e5bb80a6aa8e3341a3bceacc65a58b2ca3
* | | am 8d1a9652: Merge "Suppressing broken java.sql apache harmony tests."Neil Fuller2014-09-011-0/+31
|\ \ \ | |/ / | | / | |/ |/| * commit '8d1a96527f86493c56022f64bf38752ff0dc1fa5': Suppressing broken java.sql apache harmony tests.
| * Suppressing broken java.sql apache harmony tests.Neil Fuller2014-09-011-0/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | These are long-standing failures that we don't intend to fix in the foreseeable future. Developers have been encouraged to use android classes for database access. Bug: 17342415 Bug: 17321262 Bug: 17320961 Bug: 17093235 Change-Id: I30ed5576471253f58a63162347966dc11056cb31
* | am c4ec8f34: Merge "Remove knownfailures for "host""Neil Fuller2014-08-011-33/+0
|\ \ | |/ | | | | | | * commit 'c4ec8f34d8464bcadb1bd249915dce18265f5ec9': Remove knownfailures for "host"
generated by cgit v1.1 at 2024-05-28 00:54:43 +0000