[nulld3v]

> the android development kit really is very heavy. compared to `gcc -o main main.cpp && ./main`, it is several orders of magnitude away.

> the jetpack stuff and whatnot - the big android app shops probably do actually appreciate that stuff. but i wish the dev env 'scaled to zero' as they say, but in the sense of cognitive overload.

I tried to build a small binary that listens for events and launches/wakes an app to do some automation. But apparently there's no way to send Intents or Broadcasts from native code? So I need to boot a JVM in the binary if I want it to communicate with anything else on the system!

Of course, you can always communicate via stdio, but that's useless because everything in Android speaks Intents/Broadcasts. Native code can also do raw Binder calls, but nothing on the system speaks raw Binder.

[ActorNightly]

>But apparently there's no way to send Intents or Broadcasts from native code? So I need to boot a JVM in the binary if I want it to communicate with anything else on the system!

There is "am" i think which can be invoked to do this.

However, Termux API exists, and is a nice package for calling other services. They have the scripts interface, which calls the actual app over a socket. Kinda inefficient, but at least the work is done.

[nulld3v]

Yes, but the 'am' command is just a CLI Java program. At that point, it would be more efficient to just boot a JVM in the binary to avoid the JVM startup cost every time a Intent/Broadcast needs to be sent.

I believe the Termux API relies on a Java/app process that runs in the background to do stuff in response to API calls. Though I guess you get it for free if you already have the API running for other reasons.