Support Android SQLite native classifier

[dvrdnz]

Summary

Add the Android native SQLite JDBC classifier to the Termux/Android runtime when the existing androidClassifier Gradle property is used.

Changes

• Keep org.xerial:sqlite-jdbc:3.53.2.1 as the regular compile/runtime dependency.
• Add the natives-android classifier as a runtime-only dependency for Android builds.
• Reuse the existing androidClassifier property introduced for Android JNI support.

The additional artifact is:

org.xerial:sqlite-jdbc:3.53.2.1:natives-android

It provides the Android-specific libsqlitejdbc.so resources required by Xerial's SQLite loader.

Behavior

Without androidClassifier:

sqlite-jdbc-3.53.2.1.jar

With:

-PandroidClassifier=android-aarch64

the distribution contains both:

sqlite-jdbc-3.53.2.1.jar
sqlite-jdbc-3.53.2.1-natives-android.jar

The normal artifact continues to provide the Java API; the classifier provides the Android native libraries.

Validation

Verified on Termux / Android aarch64:

./gradlew clean classes
./gradlew --offline \
  -PandroidClassifier=android-aarch64 \
  installDist

The resulting distribution contains both SQLite artifacts.

Runtime verification:

org.sqlite.util.OSInfo
→ Linux-Android/aarch64

A JDBC jdbc:sqlite::memory: test succeeds.

signal-cli --version succeeds and the local account initialization path reaches the normal Signal registration flow without SQLite native-loading errors.

The existing libsignal Android-classifier regression test also remains successful:

./gradlew --offline \
  -PandroidClassifier=android-aarch64 \
  :libsignal-cli:test

Scope

This change only adds the Android SQLite native runtime artifact. It does not introduce automatic Android detection and does not modify the SQLite loader.

[dvrdnz]

Additional end-to-end verification (Termux / Android aarch64)

I also ran the complete registration and messaging flow on a real Termux/Android aarch64 environment using the resulting distribution:

./gradlew --offline -PandroidClassifier=android-aarch64 installDist
./build/install/signal-cli/bin/signal-cli --version
# signal-cli 0.14.8

XDG_DATA_HOME="$HOME/.signal-cli-termux-test" \
  ./build/install/signal-cli/bin/signal-cli -a <ACCOUNT> register
# → requested CAPTCHA as expected

XDG_DATA_HOME="$HOME/.signal-cli-termux-test" \
  ./build/install/signal-cli/bin/signal-cli \
  -a <ACCOUNT> register --captcha 'signalcaptcha://...'

XDG_DATA_HOME="$HOME/.signal-cli-termux-test" \
  ./build/install/signal-cli/bin/signal-cli \
  verify <CODE>

XDG_DATA_HOME="$HOME/.signal-cli-termux-test" \
  ./build/install/signal-cli/bin/signal-cli \
  -a <ACCOUNT> send -m "Test" <RECIPIENT>

The message was successfully delivered.

This verifies that the Android SQLite native artifact works through the actual signal-cli registration, verification, and message-sending path on Termux, rather than only through isolated build or JDBC tests.