Open Neo-Oli opened 7 years ago
Maybe instead of just a media button receiver, this could become a general event monitor. I imagine something like this:
$ termux-event-monitor
{"type"="media_key", "value": "play"}
{"type"="media_key", "value": "next"}
{"type": "telephony","value": {"direction": "incoming","event": "start", "number":"0123456789"}}
{"type": "telephony","value": {"direction": "incoming","event": "end", "number":"0123456789"}}
{"type"="media_key", "value": "play"}
Events that I would like to be able to receive:
I wonder how Tasker does it. Is there some event log in Android that has all this information?
Afaik most of those are intents or broadcasts. It would require to register for each of those intents and broadcasts to receive them, something that would be very useful.
Roughly the problem could be separated in this parts:
I use mpv on termux and I would love to show media buttons, then write a script to interact with mpv when pressed
Events that I would like to be able to receive:
Media button keys (to control mpv)
Telephony events (to automatically play/pause mpv)
Screen on/off
Wifi on/off
Wifi connected/disconnected
Bluetooth connected/disconnected
Impending reboot
SMS received
Device Plugged/unplugged
Orientation changed
I wonder how Tasker does it. Is there some event log in Android that has all this information?
@Neo-Oli I know this is years later, but there's a FOSS alternative to Tasker that can detect most of these things called "Automation" on FDroid, though not media buttons. Unfortunately, it doesn't yet utilize Termux's RUN_COMMAND, but it can click buttons on a notification, such as those created with termux-notification
and it can make GET/POST requests, which can trigger things in Termux if running a uvicorn server.
"Automation" on FDroid
Git repo: https://git.server47.de/jens/Automation FDroid page: https://f-droid.org/packages/com.jens.automation2/
We talked about this on the IRC before. A command that would register itself as Media Key Receiver, so that the Play/Pause, Next and Back could be captured. It would probably make sense if it would just print something like "KEY_NEXT" (but as close to the Android API as possible) to stdout.