GitLab

Verifier.readCertificates and isSignedJar can throw
SecurityException. We should clean up the RandomAccessFile
we've created when that happens.

bug: 17441127
Change-Id: I22532a9660e3a132b700abb32fdabf44b27794bc

These are used by ViewDebug to obtain the declared fields and methods
and then perform type resolution checks on a per-field and per-method
basis. Also updates documentation and naming so that the newly exposed
methods are less likely to be used incorrectly within the framework.

BUG: 17375269

(cherry picked from commit 206773d0)

Change-Id: Ia656d6e8a00ebcb0b729e68aa8a2c1959b9e260b

Previously we started at element 2 and had that element 1 was the
last one finalized. This caused System.runFinalzition to
occasionally finish before all of the objects were finalized.

Bug: 17932313
Change-Id: I410dc1ef97ecd30c35f0fc0c3fdfbcc9caa585dd

Bug: 15476051
Change-Id: I75514c497f18366b2e1320ea6a62df025a50114f

Bug: https://code.google.com/p/android/issues/detail?id=77177
Change-Id: Ia05cdbe5f6da9faf9a8976c50ce4a469acd0b179

This is useful when the environment needs to change under native bridge
emulation.

Bug: 17713104

(cherry picked from commit f8638c30)

Change-Id: If5568d06ec3f7c497653204decc2dafea5fabd01

Bug: 17679443

(cherry picked from commit 75c02d71)

Change-Id: I4cf9113dfedb2981dc9ce219c96fe1f71f4e0e98

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

Merge "Mark libcore.java.text.DecimalFormatSymbolsTest#test_getInstance_unknown_or_invalid_locale a known failure."

Mark 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 f887ab7e)

Change-Id: I589fe2eae0643e07e8db8cbcc7df52563aa24604

This goes with the array allocation path optimization CL 108967.

Bug: 9986565
Change-Id: I96de4725d4517d84af34ad05792fce8aa322f57a

Two issues fixed:
1) The negative currency cases appear to have never been correct. Almost
certainly they would have had the sign bit as the first element in the
format.
2) The recent change in Android to support the Turkish currency format
broke the TR tests (previously obscured by 1). Bug 16727554 /
commits ef91d1db and
44b0a574cbc3a54e421f5c79020cc59fbd4f34b9.

Bug: 12781028
Change-Id: I6187f7f1feed915b1d8fd5fb398caef7998bfa04

Rather than having perpetually failing test cases the current Android
behavior has been captured and compared against the Android docs.
The "problem cases" have been merged into one test.

The tests now execute all format() calls and report at the end if any
fail, rather than failing at the first problem. This makes debugging
and comparison easier.

Each output from the affected tests has been inspected. The formatter
settings and some justification have been documented in the tests for
later engineers.

For format() with scientific notation the desired behavior is often
unclear because some parts of the docs contradict others about how
much the min/max integer/fraction values are used.

Many of the "problem cases" were the result of the significant
digit rules not being obeyed by the RI which probably introduced
doubt as to whether Android/ICU was correct.

None of the results were found to be actually wrong, i.e. they appear
to output the input number to the correct amount of precision.

When using min/max integer/fraction digits (i.e. not using '@'
characters), apparently by design DecimalFormat does
not produce strings that make clear the number of significant digits
used to generate them. e.g. 1.0 output to 4 sig digits does not output
1.000E0, but may output 1.0E0 or 1E0 depending on the pattern.

Bug reports have been created to record why some categories of results
are ok or to follow up where behavior is open to interpretation, e.g.
the choice of exponent, or whether leading or trailing zeros are
present in the output.

Bug: 17654561
Bug: 17653864
Bug: 17652647
Bug: 17652196
Bug: 12781028
Change-Id: I6b3944b40ff837ecafd1b1be62c5824edb979930

In a native bridge environment, it is necessary to change the "os.arch"
system property to reflect the emulated architecture.

Change-Id: I0b93da93251c6b4638de786bf98cf99df07c3fc2
Signed-off-by: jgu21 <jinghui.gu@intel.com>

Rejecting wildcard certs for two- (e.g., *.com) or three-label (e.g.,
*.co.uk) domain name patterns requires having a frequently updated
Prefix Suffix List.

Bug: 17552202
Change-Id: Iecd1dc8e22a51f4d779821094c5f55b310171a74

This reverts commit 716ec14a.

The intent is to clean up the code to make it more obvious
where things are failing and why. The names of the tests now
better reflect their purpose and the code is reformatted.

Some tests have been merged where they overlapped and some
have been split.

Change-Id: Ic31e2062c2682b6b3ac349c8fb76c9b9809e2150

This reverts commit 165e2b40.

Previously, waitForFinalization would hold whatever object was being
finalized live for MAX_FINALIZE_NANOS even though the finalizer on
this object was run much earlier. This caused a test to be flaky since
it was assuming that the JNI weak global reference of a recently
finalized object wouldn't be held live.

Bug: 17305633

(cherry picked from commit 6ba68066)

Change-Id: Ide60db55190a3764c16e4919a7c71a113cbf3968

NativeBN_putULongInt was cleaned up because of a slightly worrying mix
of signed and unsigned ints, and because of an unneeded preprocessor
test. However, as I look down the rest of the file, there's a lot of it
but I didn't get to fixing it all up.

Bug: 17409664
Change-Id: If0adde83bebf04e7e3be163c1b30ebef75a67d05
Signed-off-by: Adam Langley <agl@google.com>

This makes the DefaultHostnameVerifier (the platform default
HostnameVerifier) match relative hostname patterns from CN and DNS
SubjectAltNames fields of TLS/SSL server certificates against
absolute hostnames. Absolute hostname patterns will still never match
relative hostnames because it is not known to what absolute name a
relative name was resolved by DNS.

For example, if hostname is "www.android.com." and server certificate
is for "www.android.com", hostname verification will now pass.
Whereas, if hostname is "www.android.com" and server certificate is
for "www.android.com.", hostname verification will still fail.

All of this is needed because server certificates do not normally
contain absolute hostnames or hostname patterns. At the same time,
connections via absolute hostnames should be supported and even
preferred in most cases, to avoid DNS search suffixes being added.

Bug: 17482685
Change-Id: I3f2006fa1110004b18ce627675334d2a54805c7a