The `AmSocketServer` now handles the entire logic for processing of am commands sent by clients and its results. This can be used by other apps as well to run their own am servers. The server started by `termux-app` will be managed by `TermuxAmSocketServer`. Read their javadocs for details.
The extended implementation `TermuxAmSocketServerClient` of `AmSocketServer.AmSocketServerClient`/`ILocalSocketManager` will also send a plugin error notification for all errors to the user instead of just logging to logcat since users are not very good at checking those, this should save dev time debugging problems. We may need to ignore notifications for some errors like broken pipe, based on their `Error` objects if they are normally expected, this requires further investigation.
The `TERMUX_APP_AM_SOCKET_SERVER_ENABLED` env variable will also be exported for all shell sessions and tasks for whether the server was successfully started on app startup. The user can disable the server by adding "run-termux-am-socket-server=false" to the "~/.termux/termux.properties" as implemented in 5f8a9222. The env variable will be checked by `$PREFIX/bin/termux-am` before attempting to connect.
The new path for the server socket is `/data/data/com.termux/files/apps/termux-app/termux-am/am.sock` as per `TERMUX_APP.APPS_DIR_PATH` added in bcd8f4c4.
- Added `LocalSocketManager` to manage the server, `LocalServerSocket` to represent server socket, `LocalClientSocket` to represent client socket, `LocalSocketRunConfig` to store server run config and `ILocalSocketManager` as interface for the `LocalSocketManager` to handle callbacks from the server to handle clients.
- Added support to get full `PeerCred` for client socket, including `pid`, `pname`, `uid`, `uname`, `gid`, `gname` and `cmdline` instead of just `uid`. This should provide more info for error logs about which client failed or tried to connect in case of disallowed clients. Some data is filled in native code and some in java. Native support for added to get process name and `cmdline` of a process with a specific pid.
- Added `JniResult` to get results for JNI calls. Previously only an int was returned and incomplete errors logged. With `JniResult`, both `retval` and `errno` will be returned and full error messages in `errmsg`, including all `strerror()` output for `errno`s. This would provide more helpful info on errors.
- Added `Error` support via `LocalSocketErrno` which contains full error messages and stacktraces for all native and java calls, allowing much better error reporting to users and devs. The errors will be logged by `LocalSocketManagerClientBase` if log level is debug or higher since `PeerCred` `cmdline` may contain private info of users.
- Added support in java to check if socket path was an absolute path and not greater than `108` bytes, after canonicalizing it since otherwise it would result in creation of useless parent directories on failure.
- Added `readDataOnInputStream()` and `sendDataToOutputStream()` functions to `LocalClientSocket` so that server manager client can easily read and send data.
- Renamed the variables and functions as per convention, specially one letter variables. https://source.android.com/setup/contribute/code-style#follow-field-naming-conventions
- Rename `local-filesystem-socket` to `local-filesystem` since abstract namespace sockets can also be created.
- Previously, it was assumed that all local server would expect a shell command string that should be converted to command args with `ArgumentTokenizer` and then should be passed to `LocalSocketHandler.handle()` and then result sent back to client with exit code, stdout and stderr, but there could be any kind of servers in which behaviour is different. Such client handling should not be hard coded and the server manager client should handle the client themselves however they like, including closing the client socket. This will now be done with `ILocalSocketManager. onClientAccepted(LocalSocketManager, LocalClientSocket)`.
- Ensure app does not crash if `local-socket` library is not found or for any other exceptions in the server since anything running in the `Application` class is critical that it does not fail since user would not be able to recover from it, specially non rooted users without SAF support to disable the server with a prop.
- Make sure all reasonable JNI exceptions are caught instead of crashing the app.
- Fixed issue where client logic (`LocalSocketHandler.handle()` was being run in the same thread as the new client acceptable thread, basically blocking new clients until previous client's am command was fully processed. Now all client interface callbacks are started in new threads by `LocalSocketManager`.
- Fix bug where timeout would not be greater than `1000ms` due to only using `tv_usec` which caps at `999,999`.
The user can add `run-termux-am-socket-server=false` entry to `termux.properties` file to disable the `termux-am` server to run at app startup which is connected to by `$PREFIX/bin/termux-am` from the `termux-am-socket` package. The default value is `true`. Changes require `termux-app` to be force stopped and restarted to provide consistent state for all termux sessions and tasks.
The prop will be used in a later commit.
The termux files directory will also be checked and created if required at startup and code related to it will only be run if it is accessible. This can later also be used for init execution commands.
The `TERMUX_APP.APPS_DIR_PATH` will act as app specific directory for `termux-app` app related files. Other plugin apps will have their own directories under `TERMUX_APPS_DIR_PATH` if required.
Execution commands and other errors that may contain potentially private info should not be logged unless user has explicitly allowed it since apps with `READ_LOGS` permission would be able to read the data. A notification for failed executions commands would still be shown if enabled and required.
This is done via addition of the `com.termux.RUN_COMMAND_SESSION_CREATE_MODE` extra, which currently supports two values.
- `always` to always create a new session every time.
- `no-session-with-name` to create a new session only if no existing session exits with the same terminal session name.
The terminal session name will equal executable basename by default and dashes `-` in the basename will no longer be replaced with spaces when session name as done previously. The `com.termux.RUN_COMMAND_SESSION_NAME` extra can be used to set custom session name.
Usage:
You can use this with `Termux:Tasker` or `Termux:Widget`.
For example for `Termux:Widget`
- Create a wrapper script at `~/.shortcuts/tasks/my-script.sh` with following contents under `tasks` directory so that it runs in background app shell instead of a terminal session. Do not use terminal session runner for wrapper script, since it will open two sessions everytime otherwise, first for wrapper script, then for actual target executable. There would also be conflicts if both wrapper script and target executable have the same basename and it would be incorrectly assumed that session is already running.
- Replace the `bash` executable with actual target executable that you want to run in the terminal session if its not already running.
- Optionally set custom session name. By default it will set to executable basename and not the wrapper script name. To set it to wrapper script name, you can pass `$(basename "$0")`.
- Launch the wrapper script with widget. On first launch, a new terminal session should open but on subsequent launches, same terminal session should open.
Note that you can also pass `com.termux.RUN_COMMAND_SESSION_ACTION` to modify session action behaviour. Check https://github.com/termux/termux-app/wiki/RUN_COMMAND-Intent#run_command-intent-command-extras.
```
am startservice --user 0 -n com.termux/com.termux.app.RunCommandService \
-a com.termux.RUN_COMMAND \
--es com.termux.RUN_COMMAND_PATH '/data/data/com.termux/files/usr/bin/bash' \
--es com.termux.RUN_COMMAND_SESSION_CREATE_MODE 'no-session-with-name' \
--es com.termux.RUN_COMMAND_SESSION_NAME "custom-name"
```
Adding `FLAG_ACTIVITY_NEW_TASK` will start permission activity in separate task and `onActivityResult()` will be called early in the calling activity without grant/not-grant result being actually set.
The `delete-tmpdir-files-older-than-x-days-on-exit` key can be used to adjust how many days old the access time should be of files that should be deleted from `$TMPDIR` on termux exit. The user can set an integer value between `-1` and `100000`. Set `-1` to delete no files, `0` to delete all files and `> 0` for `x` days. The default value is `3` days. So adding an entry like `delete-tmpdir-files-older-than-x-days-on-exit=10` to `termux.properties` file will make termux delete files older than `10` when termux is exited. After updating the value, either restart termux or run `termux-reload-settings` for changes to take effect.
Note that currently `> 0` will revert back to `0` since deletion is currently broken for empty sub directories and deletion needs to be done based on access time instead of modified time. It will need to be fixed in a later commit. Check `FileUtils.deleteFilesOlderThanXDays()`.
Related issue #2350
Once plugins integrate changes for `TermuxCrashUtils.onPostLogCrash()`, they will send the `ACTION_NOTIFY_APP_CRASH` broadcast when an uncaught exception is caught by `CrashHandler`. If `TermuxActivity` is in foreground, then it will receive the broadcast and notify user of the crash by reading it from the crash log file without the user having to restart termux app to be notified.
This starts the support for adb, root and other custom runners for shell commands. Previously only terminal and background tasks in app shells were supported.
`TERMUX_SERVICE.EXTRA_BACKGROUND` and `RUN_COMMAND_SERVICE.EXTRA_BACKGROUND` extras have been deprecated and instead respective `EXTRA_RUNNER` extra keys should be used. Currently supported extra values are `terminal-session` and `app-shell`. In future, `adb-shell` and `root-shell` are planned to be supported as well.
The `TermuxAppSharedProperties.properties` will exist in `termux-shared` library and only the single static instance will be reloaded whenever needed, instead of different activities and services maintaining their own instances. The classes in `termux-shared` library will also get access to the properties for their own needs.
The night mode set in `TermuxApplication` and terminal rows set in `TermuxService` will no longer require loading props from disk.
Updating `allow-external-apps` value will now require restarting termux or running `termux-reload-settings` since value will no longer be loaded from disk every time.
MONITOR_PHANTOM_PROCS will only be shown in Android 12+ devices and will be marked "<unsupported>" if its not supported in current android build. It will show in Termux Settings->About->Device Info->Software and in reports. Flag is available on Pixel Android 12L beta 3 and Android 13. Check FeatureFlagUtils for more details.
Getting supported feature flags and their values is done through reflection on android "android.util.FeatureFlagUtils" class and requires bypassing android hidden API restrictions.
Related issue #2366https://issuetracker.google.com/u/1/issues/205156966#comment27
Activity will only be recreated when `termux-reload-settings` is run or `night-mode` config does not equal current system mode when TermuxActivity is initially started. Running `termux-reload-settings` can cause some problems if some variable whose state should be maintained or reset is not being done so correctly, like termux session shortcuts weren't before 4fd48a5a. It requires further testing and any bugs should be reported.
With this commit, activities will automatically change theme between day/night if `night-mode` `termux.properties` is not set or is set to `system` without requiring app restart.
Dialog theming will be fully added in a later commit and may currently be in an inconsistent state or have crashes.
The `uiMode` has been removed from `configChanges` of `TermuxActivity`, this may cause termux app to restart if samsung DEX mode is changed, if it does, then users should report it so that it can be fixed by re-adding the value and ignoring the change inside `TermuxActivity.onConfigurationChanged()`. The docs don't state if its necessary. Check related pull request #1446.
Running `termux-reload-settings` will also restart `TermuxActivity`, the activity data should be preserved.
