addpkg(x11/xfce4-battery-plugin): 1.1.5

[knyipab]

Based on termux-battery-status from termux-api. Not perfect, with 30 sec delay by design, but at least available to users who is using DE in full screen.

Showcase

[licy183]

termux-battery-status may hang. It is better to kill it after a specified time if it doesn't output anything.

[knyipab]

I found that each termux-battery-status call is instantaneously cpu intensive. Would it be a better idea to rewrite to launch a long standing JVM instance for monitoring battery level? That should also resolve the time lag issue.

[Grimler91]

How did you measure it? Are you using a termux-app version with termux-am-socket? Check if $TERMUX_APP__AM_SOCKET_SERVER_ENABLED is exported and set to true.

[knyipab]

I used #20393. can be observed running termux-battery-status. or top -d 0.25 shows similar result, but top -d 0.5 does not.

$TERMUX_APP__AM_SOCKET_SERVER_ENABLED is not set, where to do that? Or just TERMUX_APP__AM_SOCKET_SERVER_ENABLED=true termux-battery-status? Or somewhere else?

[Grimler91]

Ah, it requires termux-app 0.119.0-beta1 from github or fdroid, and a recent termux-api app version as well. termux-app should then automatically export that var and use termux-am-socket if it exists

[knyipab]

Thanks a lot, dev members! If BroadcastReceiver is not feasible, I will choose between termux-battery-status (requires Termux:API+termux-api and implementing timeout reading output, but there is official support) and app_process with BatteryManager.

For the latter app_process approach, my only question left is perhaps how can JVM instance communicate back to the native code process. I suppose app_process creates a new Java process, so probably callback or JNI won't work and it will need IPC. Am I right and any suggestions?

[knyipab]

Will it be a plan or even posisble to use a real Android context in Termux Java? What hinders it, Android package policy?
I am intereted because:

• currently adding Android features to Termux requires changes to Termux:App or Temrux:API which can be very slow to make it official.
• Termux:API seems to mostly provide command line interface for terminal users, but not for native program in termux package or perhaps need popen() everytime.
• still, the app_process approach comes with quite many limitations.

It is a bit off-topic to this PR, would it be feasible to implement below features with app_process:

• any startActivityForResult() equivalence? I know there is some startActivity() equivalence in TermuxAm but how about ActivityForResult()?
• any way to open a WebView? It is indeed a highly demanded feature (mentioned many times in reddit). I know about Termux:GUI but looks like a overkill for many users need who just want to beatifully show their locally hosted webpage, e.g. running a command like termux-webview http://localhost:8888.

[twaik]

so probably callback or JNI won't work and it will need IPC. Am I right and any suggestions?

JNI does not need IPC or something to work. It is a feature of JVM. Termux-x11 works with JNI without any issues.

[twaik]

real Android context in Termux Java?

It is only possible in the case if termux's service will instantiate new JVM with custom APK loading. Probably agnostic-apollo can implement that, but this will make coming back to google play impossible.

any startActivityForResult() equivalence

What exactly you need? Your end goal. In the case of app_process started process it is not possible, but in the case if you want establish connection with your app you can use some Binder+broadcast workaround.

any way to open a WebView

You can open webpage in chrome or other browser with termux-open or am start.

[agnostic-apollo]

Context usage will be supported in future with use of reflection APIs, like how Tasker app allows running random java code with Java Function action. startActivityForResult() is not something too difficult and can maybe even be added to termux-am-socket, but maybe in Termux:API redesign where service will be used to keep asynchronous connections. WebView support has already been implemented for Media viewer APIs written for viewing (termux) docs, etc locally, but they aren't complete yet, and will be provided in future Termux app versions.