SensorAPI: killing termux-sensor CLI leaves sensors registered; later -c is a no-op

Summary

When a continuous termux-sensor -s … stream is stopped by killing the CLI process (broken output socket) instead of sending termux-sensor -c first, sensor listeners stay registered in Termux:API. A subsequent termux-sensor -c then prints Sensor cleanup unnecessary and does not unregister, so gravity/accelerometer stay occupied until Termux:API (and often Termux) are force-stopped.

Expected

1. Closing/killing the streaming client should unregister listeners (or otherwise release sensors).
2. termux-sensor -c should always unregister listeners if any are still registered, even when outputWriter is already null.

Actual

From current SensorAPI.java:

• SensorOutputWriter error path only nulls outputWriter via onErrorListener — it does not call unregisterListener.
• cleanupHandler (-c) only unregisters when outputWriter != null:

if (outputWriter != null) {
    outputWriter.interrupt();
    outputWriter = null;
    sensorManager.unregisterListener(sensorEventListener);
    result.message = "Sensor cleanup successful!";
} else {
    result.message = "Sensor cleanup unnecessary";
}

So the failure order is:

1. termux-sensor -s gravity -d 100 (stream)
2. Kill the CLI → socket error → outputWriter = null, listeners still registered
3. termux-sensor -c → “cleanup unnecessary” → sensors still held

Contrast with SensorReaderService.cleanup() / onDestroy(), which always unregisters when sensorManager != null.

Repro

# terminal A
termux-sensor -s gravity -d 100

# terminal B — kill the PID of the process in A, then:
termux-sensor -c
# often: Sensor cleanup unnecessary
# sensors remain stuck for other apps / a new termux-sensor -s until force-stop

Suggested fix

1. In the SensorOutputWriter error / finish path: always unregisterListener (same as cleanup()).
2. In cleanupHandler: always unregister if listeners may still be active (do not gate solely on outputWriter != null), or track a separate “listening” flag.

Impact / consumers

fount’s Termux logo gravity (termux-sensor child process) must call -c before killing the stream CLI to avoid this. After a kill-first leak, -c cannot recover without force-stopping apps.

When this is fixed upstream, clients can still keep -c-before-kill as the documented stop sequence; kill-then--c and abrupt CLI death should also release sensors.

Follow-up for fount (when closed)

Repo: https://github.com/steve02081504/fount

After upstream fix lands in a Termux:API release:

• Re-check imgs/icon_anime/gravity_acquire/termux.mjs stop path — keep -c before kill (correct API usage), but abrupt kill / exit-only paths should no longer brick sensors.
• Optional: simplify or drop process-exit belt-and-suspenders if no longer needed for this leak.
• Manual Termux: start fount logo, kill -s CLI without -c, confirm sensors still release / -c recovers.

Start in SensorAPI.java by reading the SensorOutputWriter error or finish path and cleanupHandler, then compare their listener handling with SensorReaderService.cleanup() and onDestroy(). Reproduce the kill-first sequence with termux-sensor -s gravity -d 100 and termux-sensor -c. Done means abrupt stream termination releases listeners and a later cleanup command can unregister any remaining listeners.