A char array copy optimization (libcore).

- Based on measurements, copy char by char for arrays of length <= 64.
- With this change, the Ritz MemAllocBench got ~25% faster on Nexus 4
  and ~20% faster on host.
- This change only handles arraycopy calls in the core libraries and
  char arrays with the rest future work.

Bug: 7103825

(cherry picked from commit a3eb10feba1c3479ad99ef5c5323d011a5365f4b)

Change-Id: Ic002ced3bc2f2a682cd4b8cec07ede990edd7463
Fix an array copy optimization bug.

When we copy within the same array, we need to take care of
overlapping range cases and copy backward in some cases. Verifed with
TestBigDecimal and CTS tests.api.java.math.BigDecimalTest.

Bug: 11233386
Bug: 9986565

(cherry picked from commit 7f2504897c33ab3c312028b4546818bc2d037bc7)

Change-Id: I5243c01222c58c137ad2595048372022c689576d
Throw an error when parsing an obviously bad Double

Thanks to Robbie Hott for the bug report.

Bug: https://code.google.com/p/android/issues/detail?id=71216
Change-Id: I402fa27e0b90c1c1d26169d79c7061e4a2caa138
Make ByteBuffer.allocateDirect be 8 byte aligned.

Bug: 16449607

Change-Id: I4a854d55f49fe709965c6b6a769fb58c356627dc
Fix serialization / deserialization of SealedObject

Thanks to apphelia@ for the report.

The readObject() implementation had hardcoded the
field order incorrectly leading to a couple of
fields being swapped on each serialization:
paramsAlg and sealAlg. This was wrong as far back
as 2009 so the class has likely never worked for
its intended purpose. Field order during
Serialization is primitives first, then fields.
Secondary ordering is alphabetical.

The purpose of overriding readObject() at all is for
safety in the event of compromised stream data.

It would be more appropriate to clone() rather than
readUnshared(). readUnshared() assumes a
corresponding writeUnshared(), which is not present.
The readUnshared() probably only works here because
the byte[] arrays typically are not shared anyway.

From reading latest guidelines on safe serialization
the code need not be order-specific: it can use
readFields(). s.defaultReadObject() could have been
used instead but the guidelines recommend against.
Performance is probably not a concern.

Until now nobody could have been using SealedObject
for its intended purpose otherwise they would have
noticed this bug (or they were always serializing /
deserializing an even number of times!).

Anybody attempting to use SealedObject on earlier
versions of Android will need to serialize /
deserialize twice to avoid the bug. After this fix
the class will work as intended.

Additional:

Some duplicated code has been extracted into methods,
and streams are now closed when they are finished
with. In reality this will have no effect
given the stream implementations involved.

Bug: https://code.google.com/p/android/issues/detail?id=73235
Change-Id: If745d6556437ae7839543e66dd15f912afd4ec98
Avoid running Runtime.gc() until we need to run finalization.

This prevents excessive explicit GC which are called from apps to get
good GC behavior on Dalvik. Calling System.gc() does not help on ART
since GC for alloc is much rarer.

If running finalizers is requested following a System.gc we remember
that a GC was requested and perform it ahead of finalization.

Bug: 12004934

Change-Id: Id1343ce8b5378c5f53c1e5649c06ddd045f56a3b
Don't account buffer.arrayOffset() twice.

data[OUTPUT_OFFSET] from the perspective of native
code must always be the offset from the start of the
buffer passed in to it.

Change-Id: I4a5c9595aebd105c57ce2239dc95cf85d5bd6256