...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.
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.
