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.
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.
The main benefit of this is not our *own* type-checking; it's that
mypy will error out if you try to use a too-new Python API. And in
fact, we were already relying on Python 3.9 and didn't realize.
check_code_size.py works with JSON, so it still uses Any a fair bit.
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.
Remove the special handling code that detects EOF now that the upstream crate
has fixed the bug that was being worked around. This also fixes a bug where EOF
was being incorrectly detected when the provided buffer was empty. Add a test
case to prevent regression in the future.
The *contents* were already identical, but jars preserve timestamps by
default, and might not sort their inputs. Fortunately Gradle has
options for both of those.
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.