| Age | Commit message (Collapse) | Author |
|---|
|
Restore the BigInteger.remainder fallback test to check for small
results. Use RemainderKnuth if either the divisor or result is
short, as was done before. Checking for a short dividend doesn't
really make much sense, since that makes the result short as well.
Failed BN context allocations used to just pass null to the next
operation. Looking at the BN_mul implementation, it doesn't appear
that ends well. Explicitly check for that case.
Remove some potentially useful but unused methods from NativeBN.
Bug: 163898786
Test: Build and boot AOSP
Change-Id: I97a46199d8cf69acf29bcfc2f614c2205ff16262
|
|
The main goal here is performance by avoiding JNI and especially
NativeAllocationRegistry overhead. We gain a factor of 10 or so
on small BigInteger arithmetic. For large computations, we gain
substantially in a few cases where OpenJDK seems to use better
algorithms. AFAIK, with this version we never lose by integral
factors relative to what we had before.
A secondary goal is to clean out open BigInteger bugs.
The base version is 8u252, which for this part of the tree is
identical to June 15 2020 ToT.
Note that this means we included the java.math part of
https://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/a5f5d7fd9be6 (29 Oct 2019)
That appears to be a separable fix that makes no interface changes.
I re-added @NonNull annotations. We also removed some code to write
certain backwards-compatibility fields during serialization, since we
never had those.
This also adds a the <X>ValueExact Java 8 BigInteger methods that had
not been previously supported.
This removes a Harmony test for compatibility with the RI implementation
that the RI implementation itself apparently fails. And, IMO, the
observed behavior is better than what we previously tested for.
Fixed a bunch of comment spelling errors. All of these have now
been fixed in upstream ToT.
Benchmarking showed that a straight move to the RI version slowed down
large multiplications, divisions, and modular exponentiation enough to
make it problematic. Thus I reintroduced NativeBN to allow those to fall
back to boringssl, at least for sufficiently large inputs. It was moved
to a hopefully more appropriate location. The fallback is tuned for
64 bits; for 32 bits it's probably much less useful; much of the
boringssl performance advantage comes from 64-bit "digits".
The boringssl fallbacks are not completely free, since we need extra
conversions on each operation. But since we only do this for large
asymptotically expensive computations, we see at mosts tens of percents
regressions, which probably qualifies as "in the noise" here. If we
find additional performance issues, we can add more boringssl fallbacks;
the required code is now fairly straightforward.
Unlike the old version, this no longer uses NativeAllocationRegistry or
similar mechanisms at all. Native memory is only used on a short-term
basis, with explicit deallocation. We no longer use boringssl for
simple linear-time operations like addition.
Microbenchmark results for the newly added benchmark, and for a
close-to-final BigInteger version, listed as "combined":
Msecs/iteration
Digits: 5/10 50/100 500/1000 5000/10000
Inner product, 1000 terms, factors of larger indicated size:
current 2.1 2.5 6.4 168
RI 0.11 0.66 11.0 486
combined 0.12 0.67 9.1 189
Harmonic series, uses smaller indicated size
current 3.7 3.2 4.3 17.6
RI 0.16 0.34 1.4 14.3
combined 0.17 0.34 1.23 14.2
(1+1/100000)^100000, larger size
current 0.07 0.073 0.33 15.8
RI 0.011 0.049 1.553 63.6
combined 0.011 0.049 0.48 13.6
Single modPow() call, smaller size
current 0.005 0.011 1.1 583
RI 0.006 0.038 7.2 5580
combined 0.011 0.012 1.1 541
Single modInverse call, larger size
current 0.003 0.014 0.375 27.8
RI 0.003 0.003 0.026 1.6
combined 0.002 0.002 0.008 0.4
Bug: 160641142
Bug: 136887041
Bug: 119491938
Bug: 28214673
Bug: 28251030
Bug: 2950143
Test: AOSP Boots. Ran some manual Calculator tests on Cuttlefish.
Change-Id: Id577d99328013b1e3c389973dcb0195fa7f52b0b
|
|
While this does not fix having inconsistent interfaces, at least we
don't fail enumerating them. With this change we still return these
children interfaces without parent set.
Bug: 159277702
Test: atest CtsLibcoreTestCases:libcore.java.net.NetworkInterfaceTest
Change-Id: Ibbe1f273683eb169a0e96425a2c21c5072bf19d7
Merged-In: Ibbe1f273683eb169a0e96425a2c21c5072bf19d7
|
|
The check is not valid across all platforms.
The Long.MAX_VALUE offset can be accepted by some
filesystems (like the default fuse lseek implementation)
without errors.
Bug: 161849068
Fixes: 161849068
Test: none
Change-Id: I477a668d4457b6b0fa13ca007f4e732ed982b7bb
|
|
The infinite rescursion happens in this loop, i.e. LocaleData ->
Compatilibity -> String.format() -> LocaleData. Point fixing can
probably fix the issue now, but a future change could cause an issue
again. Also, there is no easy and reliable way to write a regression test because
various caches in libcore and the compatiblity framework could hide the
issue from the test, but could possibly be triggered in production.
This CL changes from using compatability framework to plain
targetSdkVersion. Facilities, e.g. logging, overrides, provided
by the compatability framework are lost, but it avoids such app crash.
Bug: 160912695
Bug: 159514442
Test: atest CtsLibcoreTestCases:libcore.java.lang.StringTest
Test: atest CtsLibcoreTestCases
Merged-In: Id33ba5433050e17828239e6ea3b3a46766f268c7
Change-Id: Id33ba5433050e17828239e6ea3b3a46766f268c7
(cherry picked from commit 525eac57f090317d165767ae893d2905dc8c7df0)
|
|
Avoids infinite recursion from String.format doing LocalData compat
checking.
Bug: 159514442
Bug: 160912695
Test: art/tools/run-libcore-tests.sh --mode=host -- \
libcore.java.lang.StringTest
Merged-In: I08c90f3478c24a3a06484b882508d564c3d4bb2b
Change-Id: I08c90f3478c24a3a06484b882508d564c3d4bb2b
(cherry picked from commit 3a175f5f9097139adc4d70d2c367ab9c1c0ba6f5)
|
|
English locale for targetSdkVersion <= 29
In Android Q or before, when LocaleData class tries to load {@link
Locale#ROOT} data, en_US_POSIX
locale data is incorrectly loaded.
The class used to pass "und" string as BCP47 language tag to our jni
code, which then
passes the string as as ICU Locale ID to ICU4C. ICU4C 63 or older
version doesn't recognize
"und" as a valid locale id, and fallback the default locale. The default
locale is
normally selected in the Locale picker in the Settings app by the user
and set via
frameworks. But this class statically cached the ROOT locale data before
the
default locale being set by framework. Thus, in Q or before, en_US_POSIX
data is loaded.
As https://unicode-org.atlassian.net/browse/ICU-20273, an upstream bug,
is fixed,
ICU version 64.1 resolved inconsistent behavior of
"root", "und" and "" (empty) Locale ID which libcore previously relied
on, and they are
recognized correctly as {@link Locale#ROOT} since R. This ChangeId gated
the change,
and fallback to the old behavior by checking targetSdkVersion version.
Bug: 159514442
Bug: 159047832
Test: atest CtsLibcoreTestCases
Change-Id: I62207fcb104bbc5d1d970b57b13d8f8ecb1e1ba0
Merged-In: I62207fcb104bbc5d1d970b57b13d8f8ecb1e1ba0
(cherry picked from commit 7d61b511bd75e3b950fc3357e774eee5ac455776)
|
|
into rvc-dev
|
|
This isn't required by the ZIP spec, and is inconsistent with the
behaviour of java.util.ZipFile.
Test: atest ZipInputStreamTest
Bug: 152027785
Change-Id: If9803e5dd48ba897cd0a24c54d47e0a439cf2998
|
|
For Arrays.stream(T[]) tests
* Expected results when streaming and mapping
* Streaming and collecting with toArray() returns an identical array
* Streaming and collecting to a list results in a list with the same values
* Providing start and end indices works as expected
Also adds basic tests for Stream.of(T t) and Stream.of(T... t) to
ensure the returned stream contains the expected contents.
Bug: 150642149
Bug: 151111571
Test: atest CtsLibcoreTestCases:libcore.java.util.ArraysTest
Test: atest CtsLibcoreTestCases:libcore.java.util.stream.StreamTest
Change-Id: If9ed6fe160b7a55f0758392da9929d78ee25a293
Merged-In: If9ed6fe160b7a55f0758392da9929d78ee25a293
(cherry picked from commit dcf0a57e12851f41e5e7929921be1f9beff16b75)
|
|
Some tests that validate Conscrypt dependencies live outside of
Conscrypt - luni tests in this case. Extracting relevant ones into a
separate lib so it can be referenced by MtsConscryptTestCases.
Test: mts mts-conscrypt
Bug: 150644123
Bug: 150644835
Change-Id: Ib595a01bde5806bfd3a73ab92e03159525c52ca6
Merged-In: Ib595a01bde5806bfd3a73ab92e03159525c52ca6
(cherry picked from commit da4cab3883094d3602f563fb44366afbf2f06dfd)
|
|
For each of the primitive overloads of Arrays.stream() tests
* Expected results when streaming and mapping
* Streaming and collecting with toArray() returns an identical array
* Streaming and collecting to a list results ina list with the same
values
* Providing start and end indices works as expected
Bug: 151111571
Test: atest CtsLibcoreTestCases:libcore.java.util.ArraysTest
Change-Id: Ifd24588b0b01f823146bef3ee60b2d487aeae070
Merged-In: Ifd24588b0b01f823146bef3ee60b2d487aeae070
(cherry picked from commit 95dd7b876d7df2ad87c8cfdc247c340730fc60ed)
|
|
Also convert to Junit 4. Needed for Mainline coverage but there
are probably further testing gaps for this class.
Bug: 150637798
Test: atest CtsLibcoreTestCases:libcore.javax.net.ssl.SSLParametersTest
Change-Id: Ia25b5258ec8e0fde3fd4955d6e445d9ccc42c069
Merged-In: Ia25b5258ec8e0fde3fd4955d6e445d9ccc42c069
(cherry picked from commit 8e9551607f30407efdfb57f29f8d923b5e2b63c4)
|
|
This reverts commit Ie9fa5a25d5352f214a16e10d5bbbe45da9f3c486.
Original commit message:
Moves cloning of FileDescriptor in, out, and err descriptors
into a ZygoteHook. This avoids the need to run JNI methods
in FileDescriptor.<clinit> and enables native Core Platform
API checking of FileDescriptor descriptor and ownerId fields.
Changes in reland:
Force UnixChannelFactory to fail initialization during AOT
compilation. UnixChannelFactory is on the preloaded-classes-blacklist
and the changes in the original CL unintentionally allowed
it to be initialized. It used to be that FileDescriptor and
UnixChannelFactory initialization failed in the same transaction
due to the FileDescriptor clinit method making native calls (dup(s)).
Bug: 144502743
Bug: 150680645
Test: art/test/run-test --host 001-HelloWorld
Test: art/tools/run-libcore-tests.sh --mode=host --variant=X64
Test: atest -s <serial> -c \
CtsLibcoreTestCases:libcore.java.io.FileDescriptorTest
Test: atest PreloadCheck
Change-Id: I81e1af1d13ec81b3e51ce1d2f3c202f807d9f9bb
Merged-In: I81e1af1d13ec81b3e51ce1d2f3c202f807d9f9bb
(cherry picked from commit 32ea49e614fc79873148ae974df55b0d8ba15396)
|
|
|
|
IoBridge.open() had an Android-specific change that expicitly sets the
mode passed in to open() to 0600 or even 0. This means that users of
this API (eg RandomAccessFile) create files that are not readable to
either the group or others.
Before Android R, this didn't matter much, because we had an in-kernel
filesystem (sdcardfs) that magically fixed up permissions. Devices
launching with Android R however can no longer use sdcardfs. This means
that when apps create files on storage, permissions need to be setup
correctly.
This is done in 2 ways:
1) All Android Java processes have a umask of 0077, which means that in
the absence of a default ACL, files that are created would anyway end up
with a mode of at most 0600.
2) Some directories on external storage, like Android/obb or
Android/media do have a default ACL, which ensures that files that apps
create there can still be read/written by the correct group.
It's important to point out that both the umask and the default ACL only
act as a mask for the permissions passed in to open(); that is, if you
call open with mode 0600, but the default ACL has 0660, the resulting
file will still only have mode 0600.
This change modifies IoBridge.open() to pass in mode 0666 when calling
open(). This is a no-op on all files without a default ACL, because in
that case the 0077 umask will effectively still result in a mode of
0600. The only place where it makes a difference is in places where we
have a default ACL that is wider than the umask, eg in Android/data on
devices without sdcardfs. In those cases, we have already made sure the
default ACL is secure and correct (it cannot be modified by apps).
This also makes IoBridge.open() consistent with say
File.createNewFile(), the underlying implementation of which also calls
open() with mode 0666, not 0600. Another example is File.mkdir(), which
calls mkdir(2) with mode 0777.
Bug: 150456744
Test: atest DrmTest
manually verify files created outside these dirs still have mode
0600
Change-Id: I676ff90d46a512a847d0f7aa7af782bdc8cc5c1e
|
|
These are used in frameworks, particularly in generated OpenGL JNI
code.
(cherry picked from commit 6cb0ae710a03f94b023ce4054c63d6eb612c7e33)
Bug: 144502743
Test: boot device, grep for "Core platform.*NIOAccess"
Change-Id: I854de6be3b1d9841d961bc116e459f2c9e9154b8
|
|
|
|
* changes:
Improve fast-path in SimpleDateFormat.matchString()
Improve test coverage for SimpleDateFormat
|
|
Commit 5a2c0fcc0f7030758b6bc13b828ed40a8a55ad75 added an Android-removed
section to matchString() to fix a bug in fast-path logic.
This CL adds test coverage for the distinction between the buggy vs. the
fixed logic.
Specifically, the buggy logic assumed that the first key matched is the
one needed but it has a faulty justification: it relyies on the fact
that "first match is the answer" is wrong in case when key set traversed
has two keys so that one is a prefix of another.
For example, imagine matching "15 července 2020" which is "15
June 2020" in Czech. When SimpleDateFormat parses date it tries to
match all field names with current text chunk. This set of field names
in this case would contain month names in nominative and genitive cases
so it containts "července" (July in genitive) and "červen" (July in
nominative). Since the real answer is "července" but "červen" would
still match it picks the wrong shorter field and parsing fails.
This can be fixed by iterating keys in descending order but this is
still may be faulty if Map's comparator is overridden.
This test creates two custom calendars that behave as GregorianCalendar
except they override getDisplayNames() so it wraps it's return value in
in TreeMap instead of HashMap which is used by default so it becomes an
instance of SortedMap. This makes SimpleDateFormat with enabled buggy
code to fail to parse such dates.
The second calendar in addition overrides comparator with a inverted
(descending) version to demonstrate that iterating key set in descending
order does not fix the issue.
Bug: 119913354
Test: atest core-tests:libcore.java.text.SimpleDateFormatTest#testMatchStringSortedMap
Change-Id: Iede082f5972ae6288674db08fda4f32cceef5441
|
|
This test is designed to ensure that a server bound to
a loopback address is not reachable via an external IP
address. However it could receive false positives if some
other server was bound to the same port on an external IP.
This change ensures that the test only fails only if its
own server socket is reached via an external address. If a
different server on an external IP is reached then the test
passes but does not re-test that external IP. In practice
such port collisions happen very infrequently (approx once per
month in continuous CTS tests) so there is a very low chance
of the test passing more than once if it should be failing.
Even though this change adds a latch to synchronise the threads,
there is still a small window where a client connect can arrive
and get closed between the latch being released and the server
calling accept(). This is mitigated by adding a listen backlog
to the bind() call however there is still a very low probability
that this test will incorrectly pass if this happens.
Also convert to JUnit 4 and misc tidy-ups.
Fixes: 148476993
Test: atest --iterations 200 libcore.java.nio.channels.ServerSocketChannelTest
Change-Id: I8cad7a2ede549184aff399690c6484da9d12929e
|
|
|
|
Make sure that all Cleaners corresponding to reclaimed Java objects
have been run before checking native heap size. Without this, the
ReferenceQueueDaemon could fall behind, meaning that an unbounded
number of free calls could still be pending.
Bug: 131560790
Test: Treehugger
Change-Id: Iaa6a1e2fcd2143b4c256d05dafa2d4f4b5c32021
|
|
Original commit:
This CL topic fixes shared libraries not being reporter via Reporter.
This particular CL changes the BaseDexClassLoader.Reporter interface to
report ClassLoader context strings rather than ClassLoader instances.
These ClassLoader context strings are computed directly by the runtime
(see the changes within art in the same topic).
Test: atest libcore.dalvik.system.BaseDexClassLoaderTest
Bug: 148494302
Reason for revert: Re-land
Reverted Changes:
I295a6e99e:Revert "Fix shared libraries not being reported vi...
Ib58066e8f:Revert "[DexLoadReporter] Report classloader conte...
Change-Id: I63db10d85c3316dd9f08c0d75ab34dd3f1b62d28
|
|
|
|
SwitchTargetSdkVersionRule is not supported for use with SELinux
target-SDK checks. Moving this specific test into
cts/tests/tests/selinux downstream (Change-Id
I9b9ba084dd1c58d01b97f807d7e0122f059c5121), which will be
cherrypicked into AOSP as soon as SELinux kernel changes trickled
down.
Change-Id: I50b5524c0903b2b72f8de14ba4f321f2f894f397
Bug: 141455849
Fix: 149544376
Test: atest NetworkInterfaceTest
|
|
|
|
Revert submission 1198456-slclc
Reason for revert: Fails on luci:
https://ci.chromium.org/p/art/builders/ci/host-x86_64-cdex-fast/3123
Bug: 148494302
Reverted Changes:
I46d8d9105: Fix shared libraries not being reported via Report...
I00357cfe0: [DexLoadReporter] Report classloader contexts dire...
Change-Id: I295a6e99e58d5b953cb9b91bf55c2ea654de8612
|
|
|
|
Various test expectations in StandardNames are determined by
CpuFeatures.isAESHardwareAccelerated(). Currently this also
acts as a test for AES not being available when expected because
assorted tests will fail in that scenario.
This change makes CpuFeatures.isAESHardwareAccelerated() return
the actual state of hardware acceleration as determined by
BoringSSL and adds a test for AES being enabled on platforms
where we know we should expect it.
Once this change lands I propose to make the equivalent change
in Conscrypt's copy of CpuFeatures.isAESHardwareAccelerated()
but only run the test for expected acceleration on non-Android
platforms where there is no need to handle emulated environments.
This is intended as a cleaner replacement for
https://r.android.com/1214558 to avoid adding native test code.
Test results:
Taimen:
ABI arm64-v8a: PASSED
ABI armeabi-v7a: PASSED
Cuttlefish:
ABI x86: ASSUMPTION_FAILED
x86 AVD:
ABI x86: ASSUMPTION_FAILED
x86_64 AVD:
ABI x86_64: PASSED
ABI x86: ASSUMPTION_FAILED
ABI in the above results is the ABI reported by atest.
ASSUMPTION_FAILED means that isKnownToSupportHardwareAes()
returned false for this ABI/hardware combination and so
isAesHardwareAccelerated() was not tested.
PASSED means isKnownToSupportHardwareAes() and
isAesHardwareAccelerated() both returned true.
Not tested: Physical x86_64 hardware or 32 bit only ARM,
but the results above demonstrate that our test expectations
are correct.
Bug: 144885685
Test: atest -a CtsLibcoreTestCases:libcore.javax.crypto.HardwareAesTest
(See above for results on different platforms)
Change-Id: Ifec9b8f95eb71d4aa26fd0dc6df295a213b43a0b
|
|
This CL topic fixes shared libraries not being reporter via Reporter.
This particular CL changes the BaseDexClassLoader.Reporter interface to
report ClassLoader context strings rather than ClassLoader instances.
These ClassLoader context strings are computed directly by the runtime
(see the changes within art in the same topic).
Test: atest libcore.dalvik.system.BaseDexClassLoaderTest
Bug: 148494302
Change-Id: I46d8d9105bbdefdd058711b74a841500671cc050
|
|
Use unit tests for the CoreCompatChangeRule and CTS test.
Bug: 137821288
Test: cd libcore/luni/src/main/java/android/compat && atest
Change-Id: I78156521516447aca73ed3079dce0f77b8d2b6db
|
|
|
|
It was currently disabled, and Play are going to bundle their own known
version.
Bug: http://b/135038583
Test: treehugger
Change-Id: I9c90d4464293fd7e89aadf4fa40d82ff22f23016
|
|
To avoid a @Nullable Boolean one method has been split into two. After
some changes in the last release this also removes an optional parameter
from the two new methods as it is now always null.
Bug: 148450671
Test: treehugger
Test: atest libcore.libcore.timezone.CountryTimeZonesTest
Change-Id: I45d4944074069a1461273e18a18ba23d2a2db0bd
|
|
|
|
Non-system apps targeting the latest SDK are no longer able to
bind() to NETLINK_ROUTE sockets (see https://r.android.com/1219477).
Bug: 141455849
Bug: 148621612
Test: atest CtsLibcoreTestCases:libcore.android.system.OsTest
Change-Id: Ie4a5321711d5fda5c8df9004b41988f8521e53ea
|
|
|
|
Behavioral change to remove the possibility of null from getTimeZone().
The rest are naming and documentation improvements.
Bug: 148450671
Test: treehugger
Change-Id: Ifd15e55b1d8a9a8ace99e4193aa2d6abf0ec061d
|
|
Tidy up the libcore.timezone APIs to make them as close as possible to
android.timezone. In future, these classes should be repackages to be
the actual android.timezone classes, so the APIs need to be in sync.
Bug: 148086409
Test: treehugger
Change-Id: Ia8e903655a843baeb539febfd201132be94cf7b1
|
|
Rename ZoneInfoDB -> ZoneInfoDb to conform with coding standards.
Bug: 148086409
Test: treehugger
Change-Id: I1054d129cc4d53587a187c32927311f7311754fe
|
|
|
|
Non-system apps targeting the latest SDK will no longer have access to
the MAC addresses of network interfaces. This change updates
NetworkInterfaceTest to include tests for the new behavior, and to check
that apps targeting SDK 29 can still rely on the old behavior.
In addition, testGetNetworkInterfaces() is updated to handle cases
where the "ip" command is not available (because of bind() on
NETLINK_ROUTE sockets not being allowed). It compares its results to
those returned by getifaddrs() instead.
Bug: 141455849
Test: atest NetworkInterfaceTest
Change-Id: I74f558ec9a14c71405bf56305547c9c10117bf33
|
|
|
|
Bug: 147884233
Test: build
Test: atest luni/src/test/java/libcore/libcore/timezone/TimeZoneDataFilesTest.java
Change-Id: Idab0ada3bd7da46a414016acbb9d6914f18ac154
|
|
|
|
This change also adds it to the last-api.txt for the intra-core as it
will be required as part of the long-term "stable" intra-core API in
order to run mainline Conscrypt on Android 10. This API is unchanged
since Android 10 and so this is a backwards compatible change.
Note that AsynchronousCloseMonitor is implicitly part of the intra-core
API already as its native component is invoked from Conscrypt JNI code.
Bug: 147870945
Test: TreeHugger
Change-Id: I61c52fc1499860db887c4cce38817913536cc98a
|
|
Consider any of the www.google.com addresses being reachable as
success, as we're testing the logic of isReachableByICMP(), not
the actual reachability of Google.
Bug: 145340261
Test: atest CtsLibcoreTestCases:libcore.java.net.InetAddressTest
Change-Id: I45adc1f70ab39af290a4b4630c2852e0acf83e2c
|
|
|
|
Remove ZoneInfoDB.TzData as it is not pulling its weight.
This is before potentially exposing a new API in android.timezone that
mirrors the same class structure as libcore.timezone.
Bug: 147884233
Test: build
Change-Id: Ibcf4cddc957b6d46aa8ad16ed619b40aeb59ddc3
|
