feat: Add Signal-CLI (not packaged for aarch64 debian)

[deftdawg]

I tried a lot of different ways to get Signal-CLI to work without changing the image, all of them failed (the Signal messenger HA addon doesn't implement the correct API endpoints /api/v1/{check,rpc,events})...

This approach is the simplest and even then isn't that straight forward because libsignal isn't available for aarch64 by default.

This is how I got it going:

1. Shutdown Signal Messenger setup (I previously registered a new number following the steps in their docs)... I'm not sure if it can two devices can use the same registration info at the same time
2. Copy the signal data from the Signal Messenger; open Home Assistant's terminal

   # This assumes you have only one instance of each addon installed
   cp -r addon_configs/*_signal_messenger/* addon_configs/*_openclaw_assistant_dev
   mv addon_configs/*_openclaw_assistant_dev/*_signal_messenger addon_configs/*_openclaw_assistant_dev/signal-data

3. Create a wrapper for signal-cli that will tell it to get it's config from /config/signal-data because the default location /root/.local/share/signal-cli would not persisted across container upgrades
   signal-cli-wrapper:

   #!/bin/bash
   /opt/signal-cli/bin/signal-cli --config /config/signal-data "$@"

4. change cliPath to /config/signal-cli-wrapper so it uses our wrapper; then configure normally... turn on autostart, set openclaw account phone number, allowlist your real phone number, set dmPolicy to allowlist, etc....
5. restart the container, and ask openclaw to test the connection

[Copilot]

Pull request overview

Adds Signal-CLI to the openclaw_assistant_dev Home Assistant add-on image by building it from source in a dedicated build stage and shipping the resulting distribution (plus a Java runtime) in the final image, with an arm64-specific libsignal native library patch.

Changes:

• Introduces a signal-cli-builder stage that clones/builds AsamK/signal-cli via Gradle.
• Patches libsignal-client on arm64 by injecting an externally-provided libsignal_jni.so into the jar.
• Copies the built Signal-CLI distribution and Java runtime into the final add-on image and updates PATH/JAVA_HOME.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[deftdawg]

New build worked, this can merge

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

This patching logic only handles TARGETARCH=arm64, but the add-on declares armv7 support in config.yaml. If the upstream libsignal-client jar only contains x86_64 natives (as noted in the comment above), the armv7 image will ship a signal-cli that cannot load its JNI library at runtime. Either add an armv7 native library path (if available) or explicitly fail/disable the signal-cli build/copy steps for armv7 to avoid producing a broken image for a listed architecture.

Suggested change

	rm /tmp/libsignal.tar.gz /tmp/libsignal_jni.so; \
	rm /tmp/libsignal.tar.gz /tmp/libsignal_jni.so; \
	elif [ "${TARGETARCH}" = "armv7" ] || [ "${TARGETARCH}" = "arm/v7" ]; then \
	echo "ERROR: signal-cli JNI library is not available for TARGETARCH=${TARGETARCH} (armv7). Failing build to avoid producing a broken image." >&2; \
	exit 1; \
	else \
	echo "No architecture-specific libsignal-client patching performed for TARGETARCH=${TARGETARCH}."; \

[deftdawg]

This patching logic only handles TARGETARCH=arm64, but the add-on declares armv7 support in config.yaml. If the upstream libsignal-client jar only contains x86_64 natives (as noted in the comment above), the armv7 image will ship a signal-cli that cannot load its JNI library at runtime. Either add an armv7 native library path (if available) or explicitly fail/disable the signal-cli build/copy steps for armv7 to avoid producing a broken image for a listed architecture.

Hey copilot; go read this, then tell me why we should add your block of code!

[deftdawg]

@techartdev Copilot didn't read my comment in the previous round about armv7 support having been discontinued from Home Assistant OS more than 10 months ago... Can you talk to it? Or tell me how I can @ it, so it will stop suggesting changes for unsupported configs? 😅

[techartdev]

@techartdev Copilot didn't read my comment in the previous round about armv7 support having been discontinued from Home Assistant OS more than 10 months ago... Can you talk to it? Or tell me how I can @ it, so it will stop suggesting changes for unsupported configs? 😅

Yeah, I know it is dropped but we have users who are still on it. Couple of people requested adding support of it.

What I'm more worried about this is it will add bloat to the install. Java JRE is 150-200MB compressed. Signal-CLI + Gradle build artifacts are another 50-100MB. Then you have a slow build process, especially in low end devices. I cannot agree we have to push compilation of signal-cli directly into the image.

Why isn't possible to use signal-cli-rest-api? (https://github.com/bbernhard/signal-cli-rest-api). I know it need to be a second addon but it's much better, as people who do not need Signal won't need to run all of this on their devices.

Also git clone main + ad-hoc jar patching is tricky and could be risky. If we really decide to push it inside we need to define the deps clearly, pin an exact signal-cli version and not bad to verify the signatures on build. And if something breaks in this process in future it will fail the whole App/Add-On.

[deftdawg]

Ok let's close this.

If anyone asks, you can point them at my signal-cli-rest-api fork, it implements the 3 missing jsonrpc endpoints prevent the upstream one from working with openclaw. I couldn't get openclaw to receive messages w/ my fork even though it appeared to be 100% working in openclaw and when subscribed via a curl web socket.

Before that I also tried modifying openclaw's signal implementation to support Normal/Native polling based message reception. That worked a single time out of the dozen or so times I ran and tested it, polling was also very slow vs the jsonrpc web socket. So I wouldn't recommend that approach.