And adjust the existing ENCLAVE_SECRET tests and examples to use this
(including Rust and Node's).
This also requires adding an AndroidManifest.xml that notes the tests
might use the network.
Specifically, make this on the Rust side bridge layer, and tack it on
to the end of per-member endorsements for the app side to peel off
later, rather than the app layer calling back down to Rust to compute
it. This saves a fair amount of marshalling work.
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.
And use this to cut down CI testing time: only build armv7 and aarch64
slices of the real library, and x86_64 for the testing library (which
we don't even run in the every-commit CI, but we want to make sure we
haven't broken something in that configuration).
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 path within the directory specified by srcDir without the common
prefix. Verified with ./gradlew test :android:connectedDebugAndroidTest
locally.
- We weren't loading the native library as "signal_jni.dll"
- The Gradle build commands, though still requiring a shell environment,
shouldn't rely on Unix-style #! lines to execute shell scripts
These are intertwined: older versions of Rust don't support the newer
NDK, but the newer Rust can't successfully compile BoringSSL against
the older NDK.
This requires a boring-sys update to find the Android NDK sysroot in
the right place.
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.
The Java and Android targets are set up to both run common tests in
the top-level tests/ directory, which will be useful if we ever want
tests that only run in the Android emulator, or do *not* run in the
Android emulator. However, that top-level folder doesn't need to be a
Gradle module itself.
