Like ProtocolAddresses in 88a2d5c, these APIs will eventually only
support ACIs, so introducing strong types now helps move in that
direction. However, the existing APIs that produce strings have not
been removed yet.
These work the same as the equivalent factory methods on ServiceId,
but throw if the resulting parsed ServiceId doesn't match the specific
type you were trying to parse.
Only the iOS client ever used this extra parameter, and it's one
that's easily stored alongside the reference to a store. This is
massively simpler than having it threaded down to the Rust
libsignal_protocol and back up through the bridging layer.
This does mean that the 'bytes' field in a UidStruct isn't as useful
anymore, because it can't distinguish different kinds of ServiceIds
without extra work. Unfortunately, it was serialized inside a
client-stored AuthCredential, so we can't just change it or take it
out. Fortunately, nothing actually reads this field anyway except when
decrypting, so it's okay to change how decryption works and ignore the
'bytes' field going forward.
Signal Desktop only supports Ubuntu 20.04 and newer, so we no longer
need to build against Ubuntu 16.04 to ensure compatibility. And
bullseye-slim is a smaller base image than the Ubuntu images, so if we
don't specifically need an Ubuntu package this should be an easy
improvement.
In a future release ProtocolAddresses will *only* support ServiceIds,
so these APIs are designed to be the nullable version of the signature
they'll eventually have. Since ProtocolAddresses are created by the
client app in nearly all cases, they should be able to ignore the null
case if they only use ServiceIds in their input.
The Android emulator works a lot better with hardware acceleration,
but as of 2023-02-23 that can be done with larger Linux runners as
well as macOS instances. Switch over for better reliability (and lower
cost).
0.1.49 includes some changes to "improve" cross-compilation that
interfere with the "implicit" cross-compilation happening for Windows
(using Visual Studio on an "AMD64" host to compile for "ARM64") and
for Mac Catalyst (using a macOS SDK to compile for an "ios-macabi"
target).
This is a minimal change to not lose information that we already have
in Rust; there may be further changes in the future (such as avoiding
the redundancy now in ProtocolNoSessionException, or splitting out
missing Sender Key sessions, which don't have an address, from missing
Double Ratchet sessions).