| Age | Commit message (Collapse) | Author |
|---|
|
This CL establishes 8u222-b01 as expected upstream for files related to
new Japanese era changes.
Originally 8u212-b10 was used as a reference but it was an internal
revision than never got tagged publically. Instead of it 8u222-b01 is
used as next revision that includes all necessary changes.
Bug: 129873482
Test: n/a
Change-Id: I8b2499d74494dc1f7c1c871470f808eb70aa26a8
|
|
These files were updated to OpenJDK 9+181 in https://r.android.com/1205847
(Flow was already at OpenJDK 9+181 as of https://r.android.com/1205254).
This isn't really currently used anywhere, but can serve as documentation.
I have manually verified that there were no changes to any of these files
between OpenJDK 9+181 and 9.0.4+12, so it would be equivalent to say that
they derive from that, but OpenJDK 9+181 is the revision that is already
present within StandardRepositories.java.
Test: Treehugger
Bug: 147483640
Change-Id: I232d88bc5dc32000cea1143c1db94c3fd3598f33
|
|
When that file is introduced into libcore, it will be derived from
OpenJDK 9+181. This CL updates StandardRepositories.referenceUpstream()
accordingly, which is safe to do ahead of the file existing.
Bug: 129875045
Test: Treehugger
Change-Id: I31c46e18c83d563fd2e015465c02e4a209702b88
|
|
This affects the behavior of the CompareUpstreams and CopyUpstreamFiles tools.
I haven't re-run those tools because they don't currently work for another
reason (I haven't managed to rebuild OpenJDK 8) but it should this change
should be correct.
CompareUpstreams.java's toplevel documentation already lists
instructions for how to check out OpenJDK 9+181.
This CL is a prerequisite for being able to refer to OpenJDK 9+181 as a
potential reference upstream for particular files.
I also renamed referenceUpstreamAsOfAndroidP() -> referenceUpstream(),
since the semantics of that method have changed over time rather than
being tied specifically to Android P.
Test: Nothing.
Bug: 129875045
Change-Id: I66b3768eb0ab807f2fe58fb7cfff4bee4d1e3583
|
|
CompareUpstreams used to compare ojluni sources vs. copies of
the upstream sources stored in a "Repository" (checked-out
and built source repositories).
Since I've not recently been able to build OpenJDK 8 (requires
an older C++ compiler than what is installed on my machine),
I couldn't run CompareUpstreams without losing the information
for the files that are only generated during the OpenJDK 8 build.
This CL changes CompareUpstreams to instead compare against the
snapshot of only the files of interest from the upstream
repository (which in turn is a copy of a historic output of
CopyUpstreamFiles at a time when I still had a compiled version
of OpenJDK 8 on my local disk).
The old functionality is still available/present in the code,
but it's turned off by a hard-coded boolean constant for now.
Note that the CompareUpstreams tool still requires the environment
variable OPENJDK_HOME (which points to a directory with checked-out
upstream repositories) to be set, but the files in those directories
are not looked at unless the aforementioned hard-coded boolean
constant is changed; I didn't bother refactoring that part for now.
Test: Re-generated the verification spreadsheet and checked
that the latest version as well as the changes relative
to the previous version look sane and doesn't lose the
comparison information for generated files.
Change-Id: Ibde72b898c48ad2a29456e2af8b54708696c9bf3
|
|
Currently, five paths are listed more than once in that file (bug 138207002).
This CL changes the above method to silently discard any duplicates.
Previously, the CompareUpstreams tool would have processed such
duplicate files more than once, and would have produced duplicate
output; after this CL, they are processed (and produce output) only
once.
I considered throwing an exception instead in the case of duplicates,
but figured that it wasn't this code's responsibility to enforce
this.
Bug: 138207002
Test: Manually checked that the output of CompareUpstreams no longer
contains duplicate lines.
Change-Id: I36e8ef141ddd3029c57a83e912f5e8181e2e3bf4
|
|
Remove unused script.
Test: try and upload a commit with a badly formatted *.bp file
Change-Id: I97731a2c8f7cb95d3ffa69e81e3c1178d63da579
|
|
The bpfmt tool will not always be on the path, e.g. if it has not been
compiled. This switches to use the version that is available in
prebuilts/build-tools/... The path to the bpfmt executable is passed in
to the check-bpfmt.sh script because it depends on the ${BUILD_OS}
placeholder. See tools/repohooks/README.md for more information about
placeholders.
Test: attempted to upload change with badly formatted .bp file.
Change-Id: I4d0d12ed9ef533dae7e47d4ea9d840585d831a3b
|
|
Bug: 132757397
Test: tools/check-bpfmt.sh 16a057f0c8ed4f7212043615228da9311760850a
Change-Id: Ia3cd3f7fa075d469b5b6126fb739df915a65bab6
|
|
Test: make checkbuild
Change-Id: Ie495d6ce870a60460b36130dbc271e0cd045c940
|
|
This CL adds two hooks for checkstyle tool that will ensure that java
files under luni/ and ojluni/ directories do not contain undesired
licenses: ojluni/ generally must not have APACHE-licensed files, and
luni/ must not have GPL-licensed files.
This will help to prevent errors when wrong license is added
accidentally.
Bug: 38121042
Test: run ${ANDROID_BUILD_TOP}/tools/repohooks/pre-upload.py -- script fails as expected
Test: Add GPL license in the header of java file under luni/, commited it and tried to
upload such change -- failed to upload as expected
Did the same thing but for Apache license and java file under
ojluni/ -- same results as expected
Change-Id: Ia15091e1cff1e76eda9c2708345d2d09cdc5b7f3
|
|
Test: make docs
Bug: 117818628
Change-Id: Id9669326c725143be362fa03f2d6bf5a4bd19312
|
|
This CL adds the instructions to CompareUpstreams.java, just because
similar instructions were already there (note that no file in Android
is based on OpenJDK head / ToT, so strictly speaking it isn't an upstream).
Test: Treehugger
Change-Id: I2c19967bb39cae538fee5f1f78fc0b31b05cca57
|
|
Unlike most ojluni .java files derived from OpenJDK, the six files
ByteBufferAs{Char,Double,Float,Int,Long,Short}Buffer.java
do not correspond 1:1 to an upstream file; upstream instead has
24 .java files generated from a single .template file.
This CL tweaks the upstream tooling to consider those six
files to be derived from ByteBufferAs<X>BufferB.java
(upstream's file specialized on read-write big-endian).
Because of the nonexact correspondence, this is only of
limited use for verification purposes; further work could
potentially improve this ( http://b/111583940#comment4 ).
The benefit of this CL is the upstream comparison tools
will have at least *some* upstream file to compare against,
rather than not being able to find any corresponding upstream
file at all.
Bug: 111583940
Test: Ran libcore-compare-upstream and libcore-copy-upstream-files
to update snapshots and the verification tracking spreadsheet:
make libcore-copy-upstream-files && rm -rf ~/ojluni-upstreams && \
java -jar out/host/linux-x86/framework/libcore-copy-upstream-files.jar \
~/ojluni-upstreams
make libcore-compare-upstreams && java -jar \
out/host/linux-x86/framework/libcore-compare-upstreams.jar \
> ~/upstreams.tsv
Change-Id: Iac1f4f0fc593c2d432a2bf4ab5669eed6587c414
|
|
After this CL, CopyUpstreamFiles creates an additional snapshot "9+181"
with files from OpenJDK 9+181. The behavior of the CompareUpstreams
and upstream-diff tools is unchanged (the default reference upstream
is still OpenJDK 8u121-b13).
Test: Verified that the following command produces the same
output before/after this CL:
make libcore-compare-upstreams && java -jar \
out/host/linux-x86/framework/libcore-compare-upstreams.jar
Test: Verified that the following command produces the same
output before/after this CL, except that it now also produces
a subdirectory 9+181 with a snapshot of OpenJDK 9+181 files:
make libcore-copy-upstream-files && java -jar \
out/host/linux-x86/framework/libcore-copy-upstream-files.jar \
~/ojluni-upstreams
Bug: 63554956
Change-Id: I85bfb7556263232ed4e2f9192ebeb5acca04b184
|
|
The java{,x}.sql classes were missing from the snapshot of
files in the 'expected' upstream revision because CopyUpstreamFiles
was checking for
upstream.equals(expectedUpstream)
before copying a file to the "expected/" subfolder, but
Repository.equals() was based on object identity and the
StandardRepositories constructor created two instances of the
OpenJDK 7u40 repository, which were then not considered equal.
This bug was probably introduced by http://r.android.com/640021
(commit 2af621453187a8ce05724575a2749aca890a3976).
Test: After this CL, the directory ~/ojluni-upstreams/java/sql
gets created by the following command:
make libcore-copy-upstream-files && java -jar \
out/host/linux-x86/framework/libcore-copy-upstream-files.jar \
~/ojluni-upstreams
Bug: 35910877
Change-Id: Icacedb46e6b922206aa5603ae668eb8bddf9ade2
|
|
This CL changes the comparison command lines in the verification
spreadsheet to explicitly include the command line parameters of
the form:
-r ojluni,<revision>
to do a two-way comparison between the ojluni source and the particular
OpenJDK <revision> (eg. 8u121-b13) that is the expected upstream for the
particular file as of Android O / P.
This does not change behavior because:
- the current default value of the -r parameter for the upstream-diff
tool is "ojluni,expected"
- the snapshot "expected" contains a copy of the same upstream revision
identified by <revision> (ie. "-r ojluni,<revision>" is the same diff
as "-r ojluni,expected")
The advantage of passing -r as an explicit parameter is that the
behavior remains the same if the default value of the -r parameter of
upstream-diff changes in future; for example, the default behavior
might change in future to be a three-way comparison for integration of
future upstream changes, as opposed to (currently) defaulting to
verifying integration of the currently expected upstream.
Passing a particular <revision> rather than the verbatim string "expected"
communicates to the user of this command line what the expected revision is,
although it's less clear that this is an advantage. It also prepares us
for perhaps renaming "expected" to "android-p-reference" or similar in
future, when "expected" may no longer an appropriate name.
For reference, the expected upstream OpenJDK revision for each .java
file is currently (as of Android O / P):
- for java{,x}.sql: 7u40
- for files covered by JSR166 (java.util.concurrent and parts of
java.util): 8b113+
- for everything else: 8u121-b13
Test: Ran the following and tried some example command lines
include in the output:
make libcore-compare-upstreams && java -jar \
out/host/linux-x86/framework/libcore-compare-upstreams.jar
Bug: 63554956
Change-Id: I59cb9534ddf83e28490ecb41f42bd12b7c6b9470
|
|
Test: libcore-copy-upstream-files on a version that also includes
upstream 9+181
Change-Id: I4c8a005eb14da4383f74ebbfd2eec66881cd1f68
|
|
Previously, the upstream tools (CompareUpstreams and CopyUpstreamFiles)
supported (via Repository.loadRelPathsFromMakefile()) only .java files
in ojluni. This CL adds support for .c and .cpp files (but not.h).
The tools now process the .java files followed by the native files,
each list of files sorted amongst themselves but not globally sorted.
From now on, the ojluni repository has two different sourceDirs, namely
ojluni/src/main/{java,native} relative to which the "relPath"
identifying a particular file is taken. The "relPath" does not contain
the "java/" or "native/" prefix - files from these two locations live
in the same namespace. If a path exists in both sourceDirs then only
the first is found.
The upstream-diff tool (in Python) was slightly enhanced to guess the
correct source directory for a file based on its extension, and to
distinguish fully qualified java class names from native source files.
I intend to update the tracking spreadsheets and reference snapshots
of upstream revisions accordingly once this CL has completed initial
review.
Bug: 77572714
Test: Treehugger
Test: The output from the following appears sane, at first glance:
make libcore-compare-upstreams \
&& java -jar out/host/linux-x86/framework/libcore-compare-upstreams.jar
Test: make libcore-copy-upstream-files && java -jar \
out/host/linux-x86/framework/libcore-copy-upstream-files.jar ~/upstreams-new
Test: ${ANDROID_BUILD_TOP}/libcore/tools/upstream/upstream-diff zip_util.c
Change-Id: I1686b1bf4d467e50db0c428b5ec51870bdab8691
|
|
|
|
These packages have not currently been updated to OpenJDK 8u121-b13.
Bug: 35910877
Test: Regenerated the upstream comparison spreadsheet via the following
command, and verified that everything looked correct:
make libcore-compare-upstreams && java -jar \
out/host/linux-x86/framework/libcore-compare-upstreams.jar > u.tsv
Change-Id: I9776d2d642fe79a381cd686795d2b4d5675fb1b7
|
|
This CL makes the following improvements:
1. show default values through use of ArgumentDefaultsHelpFormatter;
it doesn't allow custom newlines, but it didn't seem worth fixing
with a custom formatter
2. show possible values for --repositories
Before this CL, the help text for --repositories reads:
-r REPOSITORIES, --repositories REPOSITORIES
Comma-separated list of >= 2 repositories to compare.
After this CL, the help text for --repositories reads:
-r REPOSITORIES, --repositories REPOSITORIES
Comma-separated list of 2-3 repositories, to compare,
in order; available repositories: ojluni 7u40
8u121-b13 8u60 9b113+ expected. (default:
ojluni,expected)
Test: Treehugger
Change-Id: Ide837281aeb342022476d231724db8f48699547b
|
|
Add the ability to include notes, and add a note to ChaCha20
specifying the exact ChaCha variant that's included.
Prefer the existing name over the name coming from the device,
allowing us to customize names by updating them in the JSON file. Use
AES/GCM/NoPadding over AES/GCM/NOPADDING to match other ciphers.
Wrap a number of fields with white-space:nowrap, so that algorithm
names and other identifiers aren't awkwardly broken in the middle,
like in OAEPwithSHA-1andMGF1Padding.
Add the ability to only output a single category, to more easily allow
updating Javadoc for a single class.
Bug: 70936054
Test: update_crypto_support_test.py
Change-Id: I4b2bb59adca7b003e357776783ee723bdf82302c
|
|
Done using the process as described in libcore/tools/docs/crypto/README.
Bug: 70704157
Test: make docs
Change-Id: Ie28826c0a752297b4b5f0115279d59b762400d20
|
|
This is a more flexible version of the 'meld' command that
was previously in the .tsv produced by libcore-compare-upstreams
The code that produces that .tsv has been changed to call the
new script.
The new script ads the following features:
1.) Compare multiple files against upstream in a single command
(this will launch multiple 'meld' processes in sequence):
./upstream-diff java/util/ArrayList.java java/util/LinkedList
2.) Specify files to compare via their fully qualified name
rather than the relative path of the .java file:
./upstream-diff java.util.ArrayList
3.) Use a diff/merge tool other than meld:
./upstream-diff -d kdiff3 java.util.ArrayList
./upstream-diff -d diff java.util.ArrayList
4.) Customize repositories to diff against, eg. three-way merge
for integrating upstream changes:
./upstream-diff -r 7u40,ojluni,8u121-b13 java.util.ArrayList
Test: libcore/tools/upstream/upstream-diff java.nio.ByteBuffer
Test: make libcore-compare-upstreams && java -jar \
${ANDROID_HOST_OUT}/framework/libcore-compare-upstreams.jar \
> ~/compare-upstreams.tsv
Change-Id: I5bc2354049f0a9a087dce588a441b09ea531bc3a
|
|
- Read list of files/relPaths from openjdk_java_files.bp
which has replaced the .mk file previously used.
- Read .java files generated during OpenJDK's build process
(bash ./configure ; make JOBS=10 jdk).
After this CL, the difference to generated classes such as:
java.lang.invoke.VarHandle
java.nio.*Buffer
java.nio.*Exception
java.nio.channels.*Exception
java.nio.charset.Charset{En,De}coder
java.nio.charset.*Exception
sun.misc.Version
sun.nio.ch.SocketOptionRegistry
sun.nio.fs.UnixConstants
is now reported by libcorecompare-upstreams and included in
the snapshot taken by libcore-copy-upstream-files.
Test: make libcore-copy-upstream-files && java -jar \
${ANDROID_HOST_OUT}/framework/libcore-copy-upstream-files.jar \
~/ojluni-upstreams.new/
Test: make libcore-compare-upstreams && java -jar \
${ANDROID_HOST_OUT}/framework/libcore-compare-upstreams.jar \
> ~/compare-upstreams.csv
Test: Checked that the following shows the added files (it also
shows that java/lang/StringCoding.java was removed because it
was removed from openjdk_java_files.bp):
cd ; meld ojluni-upstreams{,.new}
Bug: 70329267
Change-Id: I7eb6b8e600e3c72ef6bb054098290c0542ef62a4
|
|
The previous set of commands would check out the head copy of all of the
code rather than the version specified, because get_source.sh always
fetches the head revision.
Test: make
Change-Id: Id42534ff21d1a6849836a00785d896572e6f1694
|
|
|
|
Remove --toolchain jdk : it is the default and
it's changing in vogar code.
Bug: 67934307
Test: None
Change-Id: Ife4cb2566ee5a0ece329908d7e21b99b61190b4a
|
|
The first step in deprecating the BC implementations of algorithms that
are also provided by Conscrypt. This checks whether the app's target
API level is greater than a given threshold (currently O, but subject
to change later) and disallows access to those algorithms when true.
This limit only applies to requests from the system-created BC provider.
Apps can install their own provider, in which case they get the
implementations they requested.
This doesn't yet implement the deprecation for Cipher instances, since
the transformation scheme makes that more complicated.
The ultimate removal of these algorithms, once a sufficient deprecation
period has elapsed, is tracked in b/67761667.
Bug: 67626877
Test: cts -m CtsLibcoreTestCases
Test: cts -m CtsLibcoreOkHttpTestCases
Test: cts -m CtsLibcoreWycheproofBCTestCases
Test: cts -m CtsLibcoreWycheproofConscryptTestCases
Change-Id: I48f07226e66873a65859121af32028c1547952ac
|
|
jdk-9+181 (added 3 August 2017) is currently the latest
tag at http://hg.openjdk.java.net/jdk9/jdk9/
This CL arbitrarily picks that commit as an initial reference
point, from which one may want to integrate upstream sources.
This tag should be pretty close to the public availability build
of OpenJDK 9, but I don't know whether it is exactly identical.
This CL adds toplevel documentation to CompareUpstream for how to
check out that upstream revision, but does not change the expected
upstream version of any particular ojluni class and doesn't change
the tool to compare ojluni files against the new upstream.
The purpose of this CL is merely to pick, and name, a new upstream
revision that other CLs may want to refer to.
Test: Ran the given commands to check out upstream sources.
Test: Treehugger.
Change-Id: I89e95a98268d38224f663c449f019624f8d1c685
|
|
This version runs ~ 50x faster than the .py version, is configured via
environment variables rather than command line parameters, and has
additional features:
* Summarize change comments that occur in each file
* Add support for OpenJDK 9 upstreams.
* Know expected upstream for each file (hard coded), currently 9b113+
for java.util.concurrent and parts of java.util, but 8u121-b13 for
everything else.
* Add functionality to copy files from each upstream
(rather than just 8u121-b13) to $OJLUNI_UPSTREAMS
* As a side effect, this fixes the counting of line numbers: If a file
ends with a newline, Python counts that as an additional (empty) line,
whereas the Java version counts the newline character as belonging to
the line that it terminates; Java's interpretation matches that of
unix tools such as wc -l.
Bug: 35910877
Test: make libcore-compare-upstreams && \
java -jar out/host/linux-x86/framework/libcore-compare-upstreams.jar
Test: make libcore-copy-upstream-files && \
java -jar out/host/linux-x86/framework/libcore-copy-upstream-files.jar \
/tmp/upstreams
Change-Id: I1604b4c4430fe032250f694b7db42456c7653d64
|
|
Bug: 35793879
Test: N/A
Change-Id: Ie1b8b2ad54db79f0ba1381712fc4bf3243a83630
|
|
Bug: 35793879
Test: Executed, replaced tables in Javadoc
Change-Id: I9c0c857f2facc4b724b8c95b773c73f4060e18bd
|
|
Before this CL, the upstream comparison tool only produced an
*absolute* measure of the difference between a file and its
upstream version, namely the edit distance (minimum number of
lines to add/remove/replace to transform the content of one
file into the other's).
After this CL, the tool also notes the *relative* difference,
using the formula:
edit_distance / max(N, M)
where N and M are the number of lines in the two files.
- A relative distance of 0% means the files are identical.
- A relative distance of 100% can mean that one file is empty
(the other file has additional lines), or that all lines are
different, or a mixture of the two (e.g. a file being twice
as long as the other but with no lines in common).
The following more complex approaches were also implemented:
- Use the number of lines matched (from the calculation
of the edit distance) in the relative distance formula.
- Compute the edit distance in time O((N+M)*D*log(D)) rather
than O(N*M) by restricting the search to at most D
insertions/deletions and performing a one-sided binary
search for D, where D is the edit distance.
However, those approaches:
- involved more complex code
- were slower or at least not faster in practice
- yielded nearly the same output as this simpler approximation
Therefore, this CL only contains the simpler code based on the
simpler formula.
The tool takes about 18min20sec to compare all ojluni .java files
against three upstreams.
Test: oj_upstream_comparison.py --upstream_root /tmp/openjdk
Change-Id: I6fda8b3f389f45affd920107718d0e9fe2973e9f
|
|
Add functionality to quantify the size of the difference (line-based
edit distance) against each upstream. The tool now prints out a guess
of the upstream (based on minimal edit distance) as well as the
quantified difference against each upstream, in tab separated values
format. The comparison currently runs in O(N^2) and takes 10-15min
on a laptop but could be improved to run in O(N * D) for files with
less than D lines difference.
This helps identify which files we have forgotten to update to
OpenJDK8u121, in cases where Android changes exist (i.e. the file
contents are not identical to any upstream).
This reveals that on top of the 111 files without Android changes
that had been forgotten, there are about again that many that had
Android changes. The forgotten files tend to cluster by packages,
i.e. we seem to have forgotten several entire packages.
Test: ./oj_upstream_comparison.py --upstream_root /tmp/openjdk/
Bug: 35910877
Change-Id: If268785de40cd078d5b722c952480cd46fc3470a
|
|
|
|
Add a python script that:
- Produces a comparison matrix of upstreams vs. openjdk_java_files,
listing whether the file is identical to, different from, or
missing from the upstream. Upstream default to OpenJDK7u40,
8u60 and 8u121-b13 (instructions for checking them out are
included in the toplevel documentation).
- Can copy all files from OpenJDK8u121-b13 that correspond to
ojluni openjdk_java_files to a new directory, to allow easy
directory comparison (and detailed diff inspection for each
file) using standard tools such as kdiff3.
This python script will likely be improved in future, but it is
already useful so it seems worth checking into version control.
Bug: 35910877
Test: Downloaded all OpenJDK upstreams per instructions from the
documentation, then ran:
./oj_upstream_comparison.py --upstream_root=/tmp/openjdk/
- Used the output to identify the set of openjdk_java_files
missing from OpenJDK8u121-b13 (bug 36429512).
- Used the output to identify an incomplete list of 111 .java
files that seem to have been missed in the OpenJDK8u121-b13
/ 8u60 update (bug 36461944).
Test: ./oj_upstream_comparison.py --upstream_root=/tmp/openjdk/ \
--output_dir=tmp
- Used kdiff3 to inspect some sample differences between
tmp and ojluni/src/main/java.
Change-Id: I85959f41f1b1555af77a149306a5abb95d7f6bc8
|
|
Also add some manual fixing of various inconsistencies in algorithm name
capitalization used by providers.
Bug: 35793879
Test: Ran run_update_crypto_support.sh
Change-Id: I24a7403cf604e866bd372261f6f1a7e4742e9e55
|
|
This required changing the output to be built up in a list and
then output at the end rather than just printed.
Bug: 35793879
Test: Ran format_supported_algorithm_table.py
Change-Id: I720a1884f77f455de00b6f6aa601ea2f6a2005a5
|
|
Extracts a new file for JSON loading and cleans up a couple style issues.
Updates the support for GCM to 10+, it was available at least in that
version.
Bug: 35793879
Test: Manual inspection of output
Change-Id: I84f74fd14506cb36e0744a77c0223f5e3b86ca1b
|
|
Ciphers are more complicated than other categories because providers can
declare that they provide a base algorithm but users request an
algorithm/mode/padding triple, so we need to investigate the possible
values of that triple and see which ones actually end up available.
We ignore all the PBE ciphers because they're a mess and we don't
want them to show up in the documentation.
The starting API level for AES/GCM/NOPADDING is actually an educated
guess, it's approximately correct but might be off by one or two.
I'll update it if I later get better information.
Bug: 35793879
Test: Ran run_update_crypto_support.sh
Change-Id: Ifb827818626690ff223f691c8297731790074283
|
|
There are a few algorithms that used to be known by one name but now are
known by another, but the first name still shows up in our documentation,
so I added handling to continue to support those names.
I also had to do a little bit of sleuthing on when certain algorithms
appeared, because they certainly were before API 26 but our API 25 docs
don't mention them. They may be slightly off in one direction or another.
Bug: 35793879
Test: Ran run_update_crypto_support.sh
Change-Id: Ifc3e6fa3177afd82012d75eaaf7ecb26d750659d
|
|
Contrary to what I thought before, our documentation includes Android KeyStore
providers in our list of algorithm support, so run ListProviders as an
activity so that those providers are included.
Bug: 35793879
Test: Ran run_update_crypto_support.sh
Change-Id: I88332bfa1faa67d113e5fd4bc94d0c651a59c51d
|
|
Add a README.
Add an autogenerated-file warning to the top of the JSON file.
Clean up trailing whitespace in the JSON file.
Bug: 35793879
Test: Ran run_update_crypto_support.sh
Change-Id: I7a997b6d13d397769132b553269313594f6c8ad4
|
|
This update includes all categories except Cipher and Signature, both of
which are complicated and have lots of weird entries. Those will be
added in another change.
Bug: 35793879
Test: Ran run_update_crypto_support.sh
Change-Id: I6e320486b5cfb2b4f6cba5575733bea959988f9b
|
|
The tool suite consists of:
* crypto_support.json, a JSON file that stores the name and API levels
of all the algorithms we provide or have provided in the past.
* ListProviders.java, which runs on a device and outputs a list of
all the algorithms provided by the security providers.
* update_crypto_support.py, which consumes the output of ListProviders
and rewrites the JSON file to reflect the currently-supported
algorithms.
* run_update_crypto_support.sh, which ties the previous two together
to make it more convenient to run.
* format_supported_algorithm_table.py, which reads the JSON file and
generates a set of HTML tables that can be copied-and-pasted into
documentation.
The intermediate JSON file makes it a lot easier to verify that the
tools have done the right thing after an update, instead of having
to compare the HTML output.
Only Mac and MessageDigest are included for now. I'll add additional
categories of algorithms in a future change, but I wanted to send the
code out for review before spending the time to add the data on
formerly-provided algorithms that's in the class documentation.
Bug: 35793879
Test: libcore/tools/update_crypto_support_test.py
Change-Id: Ib14722b2703cbbc45438d1168395e4e1194515a2
|
|
http://code.google.com/p/vogar/
|
|
|
|
Add expectations for broken harmony tests, add our own equivalent (but correct)
tets, and fix the bug turned up by the correct tests: the icu4jni
RuleBasedCollator was using toString to convert a CharacterIterator to a
String, resulting in iteration over the result of Object.toString (the class
name and identity hash code) rather than the characters of interest.
Also shut javac up about non-ASCII characters in Locale.java.
Bug: 2608742
Bug: 2608750
Change-Id: I2171789058c8116eacd7e5815bd483f0bc07c69b
|
