This matches the split that has already happened in the TypeScript and
Swift APIs. For now, both AuthChat and UnauthChat are wrappers around
the same type, a fully general chat::Chat, but we expect to eventually
split that into authenticated and unauthenticated variants as well. At
that point we can consider whether the common implementation here is
still pulling its weight.
...specifically in the case where the most recent commit didn't run
the Java checks, and therefore we don't have a previous run of
check_code_size to compare to. (We could go back until we find one,
but that seems like overkill.)
The class loader is a rare process-wide variable for us. When the
testing crates are compiled into the same .so as the main bridge
crates, they all use the same variable, but when we build for Android
we have two separate native library files that get loaded, and so we
need to initialize both.
- Fix the format matcher after 0147989
- When merging into a branch other than main, compare against that branch
- When running on GitHub on the main branch itself, compare against HEAD^
- Adjust the plot view to have flexible columns
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.
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.
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.
