Failures would still have been caught in the aggregate test results;
but if we're going to print successes we should print skips and
failures too. (This was just an oversight.)
Each of these updates is required for the following update, and the
final one allows us to use 'record'.
The target SDK version is set to 33, matching the Android app.
Then, use FilterExceptions to filter out any exceptions that aren't
declared in the calling method's exception spec. Note that this isn't
perfect: Java's checks for typed exceptions prevents an *extra*
exception from being thrown this way, but it's still possible to
forget to *allow* an exception using FilterExceptions.
This is 99% a mechanical change; the interesting bit is in
gen_java_decl.py and one unusual pattern in NativeErrorsTest.java. No
exception specs were changed here.
Run tests that call native TESTING_ functions on Android. This requires
building a separate version of libsignal_jni.so with the testing functions
included. The test code is still omitted from the published artifacts.
Use the string bridging code introduced previously to provide string arrays to
client directly instead of joining and splitting. This eliminates the use of a
magic ',' character as a delimiter.
- use int instead of promoting to long
- add missing return type to fix compilation
- run auto-formatter
Also add the check that would have caught all of these to CI
Fix the behavior of CompletableFuture.thenApply so that if the applied function
throws an exception, the pending future receives the exception (instead of never
completing). Add tests.
This can give better error messages for JNI mistakes that might
otherwise crash or go unnoticed. Tested by introducing such a mistake.
(Though it's hard to do with the jni crate's safe interfaces, which is
a good thing!)
The Android Emulator always has its equivalent checks on, so the Slow
Tests are also giving us some confidence about our JNI usage.
The format hasn't changed, so we don't need to bump the version number
for the messages the server sends to recipients.
This is implemented in two places: the Rust side for round-trip
testing, and the Java side for what the server actually does. (Both
are implemented to avoid unnecessary copies and unfortunately the two
aren't conveniently compatible with one another, but it's a simple
implementation anyway.)
This takes advantage of the fact that multiple devices for the same
user will have the same identity key and therefore will use the same
per-recipient SSv2 data anyway.
This commit also enforces (on the server side) that device IDs are in
the range 1..=127 for destinations of a SSv2 message; previously they
were varint-encoded.
When send support is added, the round-trip Rust tests will
automatically start testing this as well.
For now, the "runtime" is spawning a thread that then uses
now_or_never, but eventually this will be a persistent tokio runtime
of some kind.
Also for now, this is only implemented for Java. Swift and Node
support coming soon.
Adds a java method for libsignal-server that enables extracting
attestation metrics from serialized evidence and endorsements.
Certificate and endorsement validity periods are exposed, so servers
can track if any attestation material is overly stale.
This helper task was supposed to only execute when publishing the
client or server artifacts, but at the point where that was checked
the task graph *hasn't been built yet*. Instead, add the task to the
task graph unconditionally, but disable it by default, and have its
dependents enable it only when publishing.
Rather than have a separate "testable" artifact, always include Mac
and Windows versions of libsignal_jni.so when publishing
signal-client-java *and* libsignal_server (though not when just
building locally).
Also, finally attach these tasks to the correct step (processResources
rather than compileJava).
Reorganize the Gradle build with three targets:
- signal-client-java (client/)
- signal-client-android (android/)
- libsignal-server (server/)
plus an additional shared/ directory for sources shared between
client/ and server/.
This maintains the distinction between signal-client-java (the Java
parts, plus a Linux libsignal_jni.so for running tests outside of the
Android emulator) and signal-client-android (contains the Android JNI
libraries, plus any Android-specific code, which for now is just
AndroidSignalProtocolLogger, which the app doesn't even use).
The new libsignal-server is built very similarly to
signal-client-java, but only contains the Java sources relevant for
the server...plus the base org.whispersystems.libsignal classes from
the original libsignal-protocol-java, because some of them are
referenced directly in our generated Native.java. (We can improve on
this in the future.) The "testable" artifact that includes macOS and
Windows versions of libsignal_jni.so is now only built for
libsignal-server, not signal-client-java; our Android development
happens on Linux, but server development happens on multiple
platforms.
Tests were recently reorganized into a top-level tests/ directory, but
now there's been another reorganization:
- client/src/test/ - tests to run on any clients
- android/src/androidTest/ - tests to run only on Android devices /
emulators (currently none)
- server/src/test/ - tests to run specifically for the server
(currently none)
- shared/test/ - does not exist to avoid running the same tests twice
There are no tests to run "only not on Android devices", and it's
currently assumed that all server functionality is tested by the
client tests. The Android device tests run all the client tests as
well (by direct path reference). This may not be the "best" Gradle
layout, but it's at least straightforward to read the Gradle files.
For now there's still only one native library built for both
signal-client-java and libsignal-server, but that could change in the
future.
