tree b217a7a1c969bf732d6fdd7c8e22b9758c8eaf99
parent 4d8a37233981df346feb2be0651e0ed46719c159
author Pete Gillin <peteg@google.com> 1500287213 +0100
committer Pete Gillin <peteg@google.com> 1500384738 +0000

Fix the byte ordering behaviour of the UTF-16 Charset.

The behavioural change here is that the UTF-16 Charset (obtained via
java.nio.charset.Charset.forName("UTF-16") or
java.nio.charset.StandardCharsets.UTF_16) now encodes Strings into
big-endian UTF-16 bytes with a byte-order marker, as the javadoc says
it does. Previously, it encoded as little-endian with a byte-order
marker. (Users wanting to encode as little-endian with a byte-order
marker can use x-UTF-16LE-BOM.)

The test changes are as follows.

CharsetTest#test_UTF_16: This was suppressed. It now passes thanks to
the above change, and we un-suppress it.

CharsetTest#test_UTF_16BE and _UTF_16LE: These were suppressed. We remove the
assertions about how it handles a reverse-BOM (i.e. a BOM with the
wrong byte order), and un-suppress them. The javadoc doesn't specify
how reverse-BOMs should be handled, so this change means we go from
not testing anything to testing the specified behaviour.

CharsetTest#test_x-UTF_16LE_BOM, _UTF_32, _UTF_32BE, UTF_32LE: These
were suppressed. The javadoc doesn't mention these, but developers
might reasonably expect them to exist and have sensible behaviour, and
they do, so we make some tweaks to the assertions and remove the
assertions about reverse-BOM-handling and un-suppress the tests. We
also remove the 'hack' which prevented it testing that UTF-32 exists,
since that doesn't seem to be needed any more.

CharsetTest#test_X_UTF_32BE_BOM, _X_UTF_32LE_BOM: These were
suppressed. We don't support these and don't expect to do so in the
foreseeable future, so we just remove the tests.

UTF16CharsetEncoderTest: Previously, this class overrode the
assertByteArray method in its superclass so that, instead of asserting
byte array equality, it just asserted that the byte arrays decoded to
the same strings. This made this test almost
endian-agnostic... although, presumably thanks to an oversight,
testDefaultValue was actually asserting that UTF-16 encodes as LE. We
remove the override and change the byte arrays so that the test now
asserts that UTF-16 encodes as BE as required.

OldCharset_MultiByte_UTF_16: This test asserts that UTF-16 encodes as
BE, and was suppressed. We un-suppress it.

OldCharset_MultiByte_UTF_16_Android: This test was a variant of the
previous one what asserted that UTF-16 encodes as LE. We remove it.

String2Test: Previously asserted that UTF-16 encodes as LE, now
correctly asserts that it encodes as BE. Also slightly strengthened
assertion.

Bug: 2702411
Fixes: 2702411
Bug: 37074504
Fixes: 37074504
Test: cts-tradefed run cts -m CtsLibcoreTestCases -a arm64-v8a
Change-Id: If174cd9ff0105008bd18a63e58ab3fa9a90c7475