0453438d added the capability to prefer arch-specific versions of
libsignal_jni, but it turns out that some Java implementations use
"x86_64" rather than the "amd64" we expected. Rather than doing
something clever and general, just handle this one special case. If
this happens again with "arm64" vs "aarch64", we can spend more time
on it then.
Previously we tried to be Fast by allocating a big local frame, enough
references for all the recipients we parsed. However, that backfired
if there were so many recipients that we couldn't allocate the local
frame. Switch to using AutoLocal references, so we have a fixed
overhead.
One interesting consequence of this is that we can't build the array
of excluded recipients in one go; instead, we now use a helper
java.util.ArrayList that we push into. Fortunately, we only exposed a
List in the public interface anyway.
Normally we'd add these back as dev-dependencies, but in this case the
doctests are all purely syntactic -- they have
`#[cfg(ignore_even_when_running_all_tests)]` in their bodies.
Follow-up to 0453438d. Previously, setting CARGO_BUILD_TARGET before
manually calling build_jni.sh merely did a Cargo build with the same
settings as the host build. However, adding support for cross-compiles
for the server build broke this "ad hoc" cross-compilation.
Fortunately, it was used only in one place: providing both flavors of
Mac library in a built libsignal-client and libsignal-server. We can
use the *new* cross-compilation support for this instead, reducing
special cases.
This also limits the conditions where build_jni.sh will automatically
set CC and other environment variables, and allows that behavior to be
overridden by manually setting them.
`cargo update` performed with Cargo 1.72 to avoid advancing our MSRV. assert_cmd, clap, protobuf, and protobuf-json-mapping needed to be manually held back.
Plus, explicit bumps for
- env_logger 0.11
- heck 0.5
- itertools 0.13
- num_enum 0.7
- prost 0.13
- tungstenite 0.23
And disallowing downgrading curve25519-dalek below the security update in 4.1.3.
This adds a new utility type ObservableEvent, which synchronously runs
any registered callbacks when the event fires. CustomDnsResolver can
then subscribes to a "network changed" event on creation, clearing its
cache. At the other end of the stack, the ConnectionManager contains
the event, to eventually be exposed to the app languages as part of
the Net abstraction.
Additional parts of libsignal-net will subscribe to the "network
changed" event in the future. In particular, it should reset
persistent connection cooldowns.
Previously the Android libraries were stripped as part of the build,
but what we're really trying to track is the download size and
size-on-disk for Android users, so the stripped library is more
relevant (and lets us continue to compare against previous releases).
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.
