...matching the #[bridge_callbacks] traits in protocol/storage.rs.
This is a place where the different platforms have historically
diverged, but given that the public-facing traits are declared in Java
and the Rust side can handle null, the glue code should not rule it
out.
The new version of BoringSSL requires a C++ library:
- Android: libc++ is linked statically, like WebRTC does
- Swift: libstdc++ is linked on Linux (and libz is dropped everywhere)
- Everywhere else: the system C++ library will be linked dynamically
And makes SSE2 a requirement for 32-bit Linux, matching 32-bit Android.
Previously we'd had jammy's 3.12, but that's missing some things we
use. Newer releases exist, but this is the one we've been using in
node/Dockerfile for a while, so if there's a problem we should update
both.
Adds support for callbacks with results to the JNI bridge, similar to
what f2eafbe6f8 did for the C bridge.
This does require introducing an "internal" version of PreKeyStore
that has simpler signatures for its callbacks; previously, the Java
objects for bridge_handle types were constructed on the Rust side of
the bridge, but that's not how bridge_fn works, and so it's not how
bridge_callbacks works. The additional overhead should not be
prohibitive.
When set, and when not using a transparent proxy, unauth chat
connections will be made over H2 instead of HTTP/1.1. Auth connections
will not be affected.
This required some changes to jni::ResultTypeInfo, because we no
longer have tokens available for the JNI types of a bridged function
to use with the jni_args! macro. Instead, we record signatures for
each type that might appear as a callback argument and use
const_str::concat to put them together.
This does not currently attempt to autogenerate the Java interface on
the other side of the bridge; given the way gen_java_decl builds on
top of cbindgen, this is likely tricky but not impossible. Something
to possibly add later.
