| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| |
| |
| |
| |
| | |
device doesn’t support multicast." into lmp-sprout-dev
* commit 'fc91c292a8cc5aaba60470f3057bc915e713109d':
Do not run the multicast tests if the device doesn’t support multicast.
|
| | |\
| | |
| | |
| | |
| | |
| | |
| | | |
support multicast." into lmp-sprout-dev
* commit '80a166b4cbdf3ea41e0e35db21208a8e5df78993':
Do not run the multicast tests if the device doesn’t support multicast.
|
| | | |
| | |
| | |
| | | |
Bug: 18449007
Change-Id: Ia7511083cc36dd7d6835191bf4b79d23ed039b5b
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Bug: 18016320
(cherry picked from commit cf5f86467f5be5f1c3ae2a5518c65f496ac93e33)
Change-Id: I05c3810320d035323e5fec07712b47586eb100bb
(cherry picked from commit 8afb381342e073b3bfcc8700b370e381ac23b2e0)
|
| |\ \ \
| |/ /
| | |
| | |
| | |
| | |
| | | |
length" into lmp-mr1-dev
* commit '657afa6cd8da378f30afe7b491e6d9de6c7c23fd':
JarUtils: stop trying to build chain past candidates length
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
If the certs in the PKCS#7 bag are in a loop, it will go on forever
trying to build a chain. Instead just stop trying to build the chain
when our chain exceeds the length of the candidates.
Bug: 17972577
Change-Id: If4f92e3eeabe893612a618bab0068a0f8cf75ea9
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Sometimes "digest encryption algorithm" would be "RSA" which would match
a Signature provider, but its default setup would be whatever the
provider chose. This works fine with newer algorithms that have a
specific OID for their signature format (e.g., ECDSA and SHA256), but
not with algorithms that just have a generic OID for all possible uses
(e.g., RSA). Stock Android never hits this problem, because nothing
registers a "Signature.RSA" provider, but Spongycastle does so using
JarURLClassLoader after inserting Spongycastle causes a problem.
Flip the order of tries to make this work more uniformly with more JAR
and provider combinations.
(cherry picked from commit b1da6d3df5f9cce6e6d77c63599eba62edb465d6)
Bug: 17790692
Bug: https://code.google.com/p/android/issues/detail?id=68562
Change-Id: I3bb07ea25d7bf1d55fa2466b204594179ac38932
|
| | |/
| |
| |
| |
| |
| |
| |
| | |
Bug: 18016320
(cherry picked from commit cf5f86467f5be5f1c3ae2a5518c65f496ac93e33)
Change-Id: I05c3810320d035323e5fec07712b47586eb100bb
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Sometimes "digest encryption algorithm" would be "RSA" which would match
a Signature provider, but its default setup would be whatever the
provider chose. This works fine with newer algorithms that have a
specific OID for their signature format (e.g., ECDSA and SHA256), but
not with algorithms that just have a generic OID for all possible uses
(e.g., RSA). Stock Android never hits this problem, because nothing
registers a "Signature.RSA" provider, but Spongycastle does so using
JarURLClassLoader after inserting Spongycastle causes a problem.
Flip the order of tries to make this work more uniformly with more JAR
and provider combinations.
Bug: 17790692
Bug: https://code.google.com/p/android/issues/detail?id=68562
Change-Id: I3bb07ea25d7bf1d55fa2466b204594179ac38932
|
| |\ \
| | |
| | |
| | |
| | | |
* commit 'be4e0fd06b44731bbe617a5a59e2d7c969a5d5cd':
Allow 1 ulp difference in test_cbrt_D and test_sinh_D.
|
| | | |
| | |
| | |
| | |
| | | |
Bug: 18016320
Change-Id: Ic1d09473d42922c75274635029a2d21f3691e674
|
| |\ \ \
| | |/
| |/|
| | |
| | | |
* commit '593a2e1667f8923dff875268169bb5dfa4c67bef':
Fix FileTest.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
FileTest.testParent expects "user.home" to be non empty. The test
uses "user.home" because the author of the test (mistakenly) assumed
that calling "new File(path)" creates a new file. The value can be
safely replaced by a non-empty and non-existent path.
This test was broken by commit 566618403d002719a94a6624 changed
"user.home" from "/" to "" to match the documented value of the
property and to match all older versions of android *except* for
kitkat (which sets "/").
Note that this test is new with "L".
bug: 17906647
Change-Id: I21ca18c8d53095c37a9068ce18bcf937a0ccf877
|
| |\ \ \
| |/ /
| | |
| | |
| | | |
* commit 'a912bd88ce8001c65d367d06cde1680bd344b9ce':
Fix RuntimeTest.freeMemory
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Previously the test asserted that freeMemory > 0, but it can be 0 if
the heap is full. Now we check that it is non negative.
Bug: 17448025
Change-Id: If8198e8f76543caea665caf77a37ac33dda38517
|
| |\ \ \
| |/ /
| | |
| | |
| | | |
* commit 'd3b74a8affe39699df64469c955d0e925e1566fb':
Delete RuntimeTest.test_gc.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This test is flaky (see below), and it's not testing anything useful.
- the value returned by totalMemory() can increase if the heap expands
- similar issue with freeMemory(), which is only measured against the
current heap size
- the test assumes that there aren't any other threads in the process
allocating objects.
bug: 17663212
Change-Id: I43fb4c2d4412033cd01bb3a533a34e47905ff229
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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 ef91d1dbd60e9a245b121e3d31c8aad0332a64c7 and
44b0a574cbc3a54e421f5c79020cc59fbd4f34b9.
Bug: 12781028
(cherry picked from commit d90019a2d2e56ef56b412f7c11264148b075f4ba)
Change-Id: I050473f19646942a8ba4bde4b2c2847f4b516f7b
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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
(cherry picked from commit 279c42d3171bb72601f24de842a8770f903edcfe)
Change-Id: I2968e1d977a8a4e40381da330e38209a268d90fb
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
(cherry picked from commit 8f4123761cebf7a925b1df887282014e420ac14e)
Change-Id: Ia0e99d3620c30933f9a6ed1143b915dd843e521e
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Fix IllegalAccessException from Preferences when this
test is run "stand alone".
The java.util.prefs.Preferences class is normally already
initialized by the time this test runs (and initialized
when there is no system property). However, in
standalone cases the system property is pointing to a
class that cannot be instantiated by ServiceLoader.
The normal fallback process when the system property is
not set would lead to FilePreferencesFactoryImpl being
instantiated directly by java.util.prefs.Preferences,
which is legal.
Removing the system property fixes the issue. The
FilePreferencesFactoryImpl is not intended to be created
by ServiceLoader and so it is reasonable that the class
is declared as package-protected. This test is for
the implementation so it's reasonable just to bypass
Preferences entirely.
Bug: 17515057
(cherry picked from commit 95c68ff724f7cf1afc2970b0d25e108e580307ed)
Change-Id: Ia860e299983b7b87753fe1dc0259b0d4ea2477f3
|
| |\ \ \
| | |/
| |/|
| | |
| | | |
* commit '972b728220e3d85eb549aa3451e872f5a06e25c1':
Rewrite tests and add tests that demonstrate a bug
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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
|
| |\ \ \
| |/ /
| | |
| | |
| | | |
* commit '77afa6c64f0af91224368452e3cce74338d667d2':
Fix test_formatToCharacterIterator_original
|
| | |\ \ |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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 ef91d1dbd60e9a245b121e3d31c8aad0332a64c7 and
44b0a574cbc3a54e421f5c79020cc59fbd4f34b9.
Bug: 12781028
Change-Id: I6187f7f1feed915b1d8fd5fb398caef7998bfa04
|
| |\ \ \ \
| |/ / /
| | | |
| | | |
| | | | |
* commit 'df014f5f051130daf16599c8989bc157fe8dda5b':
Fixing formatDouble scientific notation tests
|
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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
|
| |\ \ \
| |/ /
| | |
| | |
| | | |
* commit 'b632c3020038351efe98a0a87ac0394c89b8b2d1':
Tidy up DecimalFormatTest
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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
|
| |\ \ \
| |/ /
| | |
| | |
| | | |
* commit 'bf5b79fd518a0a769f7fae74d8704bdebc744f03':
Fix FilePreferencesImplTest test initialization errors.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Fix IllegalAccessException from Preferences when this
test is run "stand alone".
The java.util.prefs.Preferences class is normally already
initialized by the time this test runs (and initialized
when there is no system property). However, in
standalone cases the system property is pointing to a
class that cannot be instantiated by ServiceLoader.
The normal fallback process when the system property is
not set would lead to FilePreferencesFactoryImpl being
instantiated directly by java.util.prefs.Preferences,
which is legal.
Removing the system property fixes the issue. The
FilePreferencesFactoryImpl is not intended to be created
by ServiceLoader and so it is reasonable that the class
is declared as package-protected. This test is for
the implementation so it's reasonable just to bypass
Preferences entirely.
Bug: 17515057
Change-Id: I02ea38b4a50fc3b7299a35d0a1050455cb9ca970
|
| |\ \ \
| |/ /
| | /
| |/
|/| |
* commit '64bbdb2e53712e7acc77fbb8b61a8888767610e0':
Removing some compiler-warning suppressions from EnumMap
|
| | |\ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The original motivation was to fix a report that
line 162 does not compile with newer compilers:
https://code.google.com/p/android/issues/detail?id=73244
There are a lot of compiler warning suppressions which made
the problem less obvious than it should have been.
The fact it compiled before was possibly a compiler bug.
This change removes a lot of the suppression, and where it
cannot be removed it narrows the scope to just local-variable
declarations. One method-level suppression remains.
This commit also adds a bug fix for situations where the raw
type is being used and an EnumMap is being created from an
existing Map. Previously a NullPointerException would have been
thrown if the first key found was not actually an enum, now a
ClassCastException will be thrown.
Some additional comments have been added and some loops made
into foreach.
Bug: https://code.google.com/p/android/issues/detail?id=73244
Change-Id: I7f23744dc55237a94e5906e77720a9595caa64e8
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Test was flaky due to bad assumptions, Runtime.freeMemory is already
tested by test_memory, test_gc.
Bug: 17448025
(cherry picked from commit e2233ca92da0339686da18db4a1e27b9a4c76b91)
Change-Id: I88d09ee5cd1c4e34c97814afd2cbadc870222738
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Turkey switched from "123,45 TL" to "₺123,45" in 2012. It's taken
a while for our font to catch up, but now it has.
(cherry-pick of c56ec7b571ba6cc02ae9c1b5a790b7141b4de394.)
Bug: 16727554
Change-Id: I3c80f95d5f620c905247c9f227171717180106b4
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Also fixes all remaining failures. Most of them were
due to us not setting "user.dir" and "user.home" correctly.
Android has traditionally left those values blank. To fix
these tests, we need to change the default prefs factory
to one rooted at a temporary directory.
Note that this change attempts the minimal possible cleanup
(mainly style, commented code formatting etc.) to these files.
bug: 13881847
Change-Id: I1918ee9af07be9612a7da142b3e584aabc860085
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This was broken by the removal of the pre-computed raw offsets from
the tzdata file. I think that's still the direction we want to go (with
us hopefully using more of icu4j at some point, and eventually relying
solely on the icu time zone data), so this patch adds code to lazily
evaluate all the offsets by instantiating all the time zones.
(cherry-pick of 065d7764ac1dfe74ee94d17ca6c810de37b57d3e.)
Bug: 16947622
Change-Id: I6d1dfe5ee6c99338f9807c3af5b6f04539c256c3
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Test was flaky due to bad assumptions, Runtime.freeMemory is already
tested by test_memory, test_gc.
Bug: 17448025
Change-Id: I62a8e0240a8a8a95dcb9a8a2423bb57dfcff3c1a
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Also fixes all remaining failures. Most of them were
due to us not setting "user.dir" and "user.home" correctly.
Android has traditionally left those values blank. To fix
these tests, we need to change the default prefs factory
to one rooted at a temporary directory.
Note that this change attempts the minimal possible cleanup
(mainly style, commented code formatting etc.) to these files.
bug: 13881847
(cherry picked from commit a152f62d4d81ef6500b3e02dbc381e2414f9a11f)
Change-Id: Ie32a61e1b911dcd317c688f86e487f9ea778b31f
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Turkey switched from "123,45 TL" to "₺123,45" in 2012. It's taken
a while for our font to catch up, but now it has.
Bug: 16727554
Change-Id: I3c80f95d5f620c905247c9f227171717180106b4
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This was broken by the removal of the pre-computed raw offsets from
the tzdata file. I think that's still the direction we want to go (with
us hopefully using more of icu4j at some point, and eventually relying
solely on the icu time zone data), so this patch adds code to lazily
evaluate all the offsets by instantiating all the time zones.
Bug: 16947622
Change-Id: I6d1dfe5ee6c99338f9807c3af5b6f04539c256c3
|
| |\ \
| |/
| |
| |
| | |
* commit '1aea503e8f568f9c17c14335783a89d41787e657':
Fix SimpleDateFormatTest when run outside California
|
| | |\ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
If the device was set to a timezone besides America/Los_Angeles
the test would fail. Under cts-tradefed the SimpleDateFormat
was being created at class load time (using the device default)
and then the timezone default was being set to
America/Los_Angeles during setUp().
Contains refactoring to remove nested test case and
reformatting.
Change-Id: I26a7a2c6ce0d6205cf6d20c9b4cbebf550da19ce
|
| |\ \ \
| |/ /
| | |
| | |
| | | |
* commit 'f814c4f5445887275d9d58d21843e6d80fbdae27':
Fix the OOME in ScannerParseLargeFileBenchmarkTest
|
| | |\ \ |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Scanner had no mechanism for recovering buffer space it didn't
need.
Now, if the buffer is more than 50% full of ignorable characters
the remaining characters are shuffled to the beginning to recover
space. For most expected usecases this means that the buffer will
stay 1k and contain up to 512 characters of useful data. A
growable, circular character buffer could have been introduced
to avoid the copy but is not worth the effort.
Previously the buffer would double in size until the data or memory
was exhausted, and each read would also double in size to fill the
empty half of the buffer. This was fine providing the input
could fit in memory.
On top of that the 1k, 2k, 4k, etc. buffer was repeatedly turned
into a String and passed to the (native) matcher, and then the
matcher was told to ignore more than half of it.
As a consequence of keeping the buffer a fixed size (and only
filling 50% of it at a time), this change may cause a performance
regression: for most usecases where delimiters are closer together
than 512 bytes, reads after the first will now usually be 512 bytes
and not the 1k, 2k, 4k, etc. it was previously.
Having fixed the test so it doesn't OOM, the test now
takes 6 minutes to pass on host and so is unsuitable for inclusion
in CTS tests and so is being suppressed.
This change also includes so tidy up changes to the test and the
Scanner class.
The implementation could no doubt be improved but the API makes
it inherently slow. It would be surprising if anybody uses the
Scanner class on Android with so many better alternatives.
Bug: 14865710
Change-Id: I40a7fc0c2bfaf6db4e42108efe417303e76bde24
|
