Publish Android JNI libraries as JVM client classifiers

[dvrdnz]

Summary

Add Android JNI libraries as classifier artifacts to the existing libsignal-client JVM publication.

The normal libsignal-client JAR remains unchanged and continues to provide the Java API. Android JNI libraries are published separately as architecture-specific classifier JARs containing only libsignal_jni.so.

Published artifacts

For each Android ABI, the JVM client publication additionally produces:

libsignal-client-<version>-android-aarch64.jar
libsignal-client-<version>-android-arm.jar
libsignal-client-<version>-android-x86_64.jar
libsignal-client-<version>-android-x86.jar

Each classifier JAR contains:

libsignal_jni.so

The classifier artifacts are therefore usable independently from the normal JVM artifact while avoiding changes to the existing desktop JNI packaging.

Implementation

The :client publication now:

1. depends on the existing Android JNI build;
2. collects the JNI libraries from the corresponding Android ABI directories;
3. creates one classifier JAR per Android ABI;
4. attaches those JARs to the existing mavenJava publication.

The existing desktop JNI artifacts and normal libsignal-client JAR are unchanged.

Validation

The implementation was verified with the complete Android JNI build:

aarch64-linux-android
armv7-linux-androideabi
x86_64-linux-android
i686-linux-android

The resulting local Maven publication contains:

libsignal-client-<version>.jar
libsignal-client-<version>-android-aarch64.jar
libsignal-client-<version>-android-arm.jar
libsignal-client-<version>-android-x86_64.jar
libsignal-client-<version>-android-x86.jar

The classifier JARs were inspected and each contains exactly:

META-INF/
META-INF/MANIFEST.MF
libsignal_jni.so

The publication was successfully built and published to Maven Local.

Consumer model

The intended consumer model is:

Desktop JVM
  → org.signal:libsignal-client:<version>

Android aarch64
  → org.signal:libsignal-client:<version>
  → org.signal:libsignal-client:<version>:android-aarch64

The normal artifact remains responsible for the Java classes; the classifier artifact supplies the platform-specific JNI library.

Notes

This change intentionally does not introduce Android platform detection or modify consumers. Consumer-side selection of the appropriate classifier is handled separately.

[jrose-signal]

What's the motivation here? What happens to the existing Android-specific JVM classes?

[dvrdnz]

The motivation is that "signal-cli" on Termux runs as a plain JVM app, but on Android it still needs the Android-built libsignal_jni.so. The existing Android JNI is packaged as part of libsignal-android, which isn't directly usable as a JVM-only dependency.

This PR doesn't change the Android packaging. It only adds the Android JNI .so files as additional classifier JARs to the existing libsignal-client publication. The normal libsignal-client JAR remains unchanged; each classifier JAR contains only libsignal_jni.so.

The existing Android-specific JVM classes aren't touched. They remain in the Android library/AAR, and :android continues to depend on :client as before.

So Android apps keep using libsignal-android as-is, while JVM consumers on Android (such as Termux) can use libsignal-client together with the matching Android JNI classifier.

I've also verified this end-to-end with signal-cli on Termux (AsamK/signal-cli#2106), including build, registration, verification, and successfully sending a message.

[dvrdnz]

Hi @jrose-signal, following up on this — hope the explanation above answers your question about motivation and the existing Android JVM classes. If it looks good, would you (or another maintainer) be able to approve the pending CI workflows so the build can run? Also happy to adjust anything if something's still unclear.