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.
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.
- Switch to the modern maven-publish plugin.
- Bump the Android target SDK version to 30 to match the app.
(The minimum is still 19.)
- Bump the Java source compatibility version to 1.8.
- Bump the Android command line tools used in Docker to match the app.
- Bump the JDK used in Docker to OpenJDK 11, matching the app.
- Switch to the androidx testing libraries for emulator testing.
- Drop unused trove4j Gradle plugin.
- Lots of cleanup and refactoring.
Previously all APIs were available through the top-level index.ts, but
now the zkgroup APIs are in their own module. To access that in the
old packaging required writing
import * from '@signalapp/signal-client/node/dist/zkgroup'
This commit moves the package root into the node/ directory to
eliminate the 'node/' component, then adds a top-level, precompiled
zkgroup.js/.d.ts so that clients can use
import * from '@signalapp/signal-client/zkgroup'
This is like signal-client-java, but also contains dylibs for Mac and
Windows for testing purposes. Gradle will automatically fetch these
artifacts from the corresponding GitHub release.
This is overkill for most calls but multi-recipient messages require
potentially a lot of objects. The codegen is in the way of making a
surgical change at the moment so hitting it with a broad fix for
now. May return to add a conditional to the macro definition later.
Neon provides a way to expose *synchronous* JavaScript functions from
Rust. This means that if Rust wants to wait for the result of a
JavaScript promise, it can at best return a callback to continue its
work when the promise resolves. This does not naturally compose with
Rust's `async`, which works in terms of Futures.
This commit adds a new crate, signal-neon-futures, that provides
functionality for (1) wrapping JavaScript futures so they can be
awaited on in Rust, and (2) producing a JavaScript promise that wraps
a Rust future. It does so by synchronously resuming execution of the
Rust future whenever an awaited JavaScript promise is resolved.
This allows the Desktop client to add this module as a dependency and
have its existing build process take care of building it against the
correct version of Electron. (Within the repo, `yarn build` calling
`electron-build-env` is still necessary; a plain `electron-rebuild`
seems to get confused.)
Normally library repositories wouldn't commit their Cargo.lock, but
these libraries are built into staticlibs or cdylibs and thus escape
the crates.io ecosystem for versioning. In particular, recording exact
dependencies keeps us from having multiple versions of the same crate
unexpectedly.
