The Maven publication will still contain a -javadoc jar for
consistency, but the -dokka jar is likely to have superior rendering
in practice, particularly for Kotlin-only APIs!
Use `./gradlew -P jniTypeTagging` to build with type tags enabled.
This has a moderate code size cost, and an unmeasured cost in run-time
performance. On 64-bit targets, the tagging relies on bits 48..56 of
pointers produced by the default Rust memory allocator being unused
(specifically 0), which they are on all our current targets.
This means they'll be shipped to clients, but still filtered out of
the device builds on Android (via having two separate libraries on
disk) and iOS (by not being included in non-simulator builds). The
biggest benefit of this is dropping the :android:makeTestJniLibraries
step for running libsignal's Android tests.
This *greatly* increases the size of the artifacts uploaded to Maven,
but it looks like the libraries do correctly get stripped when the
final APK is built. (This was not true in the past.)
Also, make sure the built library includes a "build ID", or else the
stripped version of the library will be treated as a different
library, and all the line tables will go to waste.
This parallels the exiting libsignal-jni crate but exports functions from
libsignal-bridge-testing instead of libsignal-bridge. The crate is compiled as
a separate shared object that is included in the published libsignal package,
but which can be excluded at Android packaging time.
Similar to the previous commits, but for Java/Android. If invoking
build_jni.sh directly, use `--debug-level-logs` like build_ffi.sh.
As a consequence, LOGGING IS NO LONGER AUTOMATICALLY ENABLED FOR
JAVA/ANDROID. Clients must call SignalProtocolLoggerProvider.
initializeLogging() in addition to setting a provider.
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.
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.
