I am unable to test a feature. If the user tries to navigate into external storage when it is unavailable then a toast says that it is unavailable. If a path is entered into the path window that is a subdirectory of the external storage root then the path gets set to the external storage root. My Android version (4.3) does not permit mounting external storage to the PC so I can't test this feature.

I'm not a GUI guy but this is better then the previous, and this will probably be my last GUI improvement to shortcuts. I still need to export strings and spend some time on cleaning up and fine-tuning the code.

I also intend to update the example (examples/intents/src/jackpal/androidterm/sample/intents/IntentSampleActivity.java) but it will have to be more than simply replacing one procedure for the other. In the old procedure an entire command line was sent as a single string and in the new procedure the command and arguments are separate. Because they are separate they can be used differently. Here is basically what can now be done:

• If the Uri.path is specified it must be the full path, and this full path gets quoted for BASH. It must be the full path because it gets prefixed with '/' otherwise -- so 'ls' becomes '/ls'.
• The Uri.path may be left unused and the command placed in the Uri.fragment with the arguments, and the fragment may be a complete script. For example 'uri.fragment("cd /sdcard; curl http://ti.com/ >ti.html")'.

So in the example I would convert the existing two sample scripts to fragments only, then add a third script sample which places the command in Uri.path.

Frank

Allows for the user to set a custom font with a fallback to MONOSPACE as a default

feature request #290

Currently the path input is a little bit non-user-friendly as it requires to type the path of the font in the preferences text field. But it is better than writing the font path to an arbitrary config file.

The cursor positioning, of course, go very wrong when using a non-monospaced font.

Currently looking to improve it by using a file picking intent if possible, but the feature is usable enough, and, in my opinion, would be greatly appreciated by the users for day to day task with the terminal emulator.

New Intent.data procedure for launching scripts. The new procedure is to build the path and arguments into a Uri and set that into Intent.data.

intent.setDataAndType(
  new Uri.Builder().setScheme("File").setPath(path).setFragment(arguments)
, "text/plain"
)

The old procedure of using an Extra is still available but is discouraged and will be attempted only if Intent.data is null.

If both Intent.data and the extra are null then an empty string is sent to simply open ATE.

Solves #381 Solves #169 More or less fixes #156 Fixes #120

This pull request aims to replace existing Intent-based interface for launching commands with AIDL-based API. The API uses Android/Linux ability to pass file descriptors between processes to grant ATE access to /dev/ptmx handle, created by someone else. In effect this means, that another program launches an executable (with it's own permissions), but leaves ATE in charge of showing it's console output.

The AIDL interface is more or less a draft. There is, probably, no way to do it right except by letting people use it a bit and gathering suggestions. Feel free to ask, if you want to know, why it looks this way.

I am personally interested in this for my aria2 port. I will do my best to help with supporting the new code, as long as I am able to use it myself. You can look how an integration is done in ate-support branch or get this build to get a peek at preliminary implementation on device.

This PR introduces new library in addition to emulatorview. It is called libtermexec and contains AIDL files, native code and Java wrapper for launching binaries with inbuilt console support. It can be very useful on it's own to replace java.lang.System and ProcessBuilder for launching executable files (and gives access to the PID unlike those). The library in Android AAR format, with AIDL and native binaries included, can be published on Maven to let people use it readily without using NDK themselves.

This PR may have an impact on various parts of ATE. I tried to keep it minimal without refactoring unnecessary parts, other important changes may have to be done later, see below for details. Biggest changes done here are:

• Splittig ShellSession in few subclasses
• Changes to open /dev/ptmx in Java code and using ParcelFileDescriptor instead of digging integer fd out of FileDescriptor with Reflection. Some reflection still remains, but only on older versions.

Perfomance considerations:

• Foreground mode probably should not be used unless necessary (e.g. don't go foreground when someone is still binding to the TermService). See also this question;
• There should probably be some form of window recycling to prevent single client from opening loads of windows in the "keep window open after session end" mode. Also valid for exesting RUN_SCRIPT-based API.

Security considerations:

• No need for permissions, because no work is done on ATE side besides displaying text from file.
• Someone can pass weird file descriptor (such as /dev/full or just some binary file) instead of /dev/ptmx handle to screw with emulator. Not exactly dangerous and can be mitigated by properly handling failures of native tty-related methods.
• May be abused to impersonate important windows, same as RUN_SCRIPT-based API. I didn't notice any defense there either. Can be mitigated by prepending name of originating app in title. This is already done in AIDL binder, but something seems to be wrong with whole "displaying window title thing", it just does not work for me.

Documentation considerations:

• Must tell people to use Context.BIND_AUTO_CREATE to prevent restart of TermService upon unbind. Maybe there is a way to disallow binding without the flag. Alternatively TermService can keep itself alive with startService and do stopSelf only when necessary.

Hopefully, size and complexity of these changes won't stop you from reviewing them. If you'd rather look at iterative lineage of commits instead of single squashed one, see this branch.

PS I have changed the language level to Java 7, because Java 6 is dead, and multi-catch and string-switch are too good to miss out on. This won't introduce any compatibility changes, unless you try to use try-block resource management (aka try-with-resources), in which case the IDE will loudly warn you. I can roll that one back, if you don't want it.

The java process maintains many open file descriptors that are inherited by the shell process (and later on by any command spawned by the shell). This code closes all of them by iterating over the /proc/self/fd directory. Also includes an ioctl call to make the pseudoterminal a controlling one for the shell process group.

This addition adds "Term here" to the "Send" or "Send to" option on many file managers, accessable by a long press. Long-press a file or directory in a file manager and select "Term here"; Term will open to a new window at that location.

The permission.RUN_SCRIPT permission is not used because no executables other than 'cd' are invoked. Choosing "Term here" performs essentially the same action as merely opening Term, but with the addition of the specified starting directory.

I chose to use the "send" intent option instead of a normal intent with 'data' because I think showing "Term here" for every file you wish to open normally is excessive, so for the special case where you want to open a terminal at a file or directory location the "send" feature can be used.

It might be desired to later add a the ability to launch scripts from a file manager by selecting the script, or other executable, and choosing "Term", or "Run with Term". This would be implemented with a normal Intent which uses 'data' to communicate the file and would be selected after a short-press in most or all file managers.

Related to all this, I'll soon pull-request a shortcut interface so that ATE can place icons on the desktop which will launch scripts.

This patch provides an option to send xterm mouse tracking codes to the terminal. When the option is enabled, and when the console application requests mouse tracking, tap events are forwarded as clicks and drag/fling events are forwarded as scroll wheel events. Examples of applications which can be configured to accept mouse events are vim and tmux.

Currently less does not scroll. Terminals such as gnome-terminal and konsole forward scroll events as cursor keys when applications are using the alternate screen buffer. If the present patch is accepted, I plan to next implement this kludge so that less can scroll as well.

I have not implemented the DEC save and restore commands for the mouse tracking flags, although this probably doesn't matter. Probably the way forward here is to use a BitSet rather than an integer to store the flags, as this will enable handling flags greater than 32 in a unified way.

This push adds keyboard shortcuts for switching and creating new windows. This is something I find useful when using an external bluetooth keyboard.

The push also refactors out the keycode constants from TermKeyListener and improves the explanatory comment.

This is an update to https://github.com/jackpal/Android-Terminal-Emulator/pull/234 .

This change modifies TextIcon.java to create a multi-line image if the input test contains multiple lines, and ColorValue.java to change the applicable EditText to multi-line.

This change requires a simple test before acceptance. After build, create a shortcut with a single line of text and verify that it appears normal, and create a shortcut with two or three short lines of text and verify that it appears as expected.

I apologize for not testing but I cannot run Android Studio. I have tested the code in another application, but not in TEA.

On TF101 intercepted the specified key combination in the keyDown handler to replace the event and keycode with one that simulate pressing the the delete key.

As requested the feature request #240

(c) 2013 Kendall Stewart

This pull request contains code to implement clickable URLs in Android Terminal Emulator.

The general idea is that the EmulatorView class now contains a data structure called mLinkLayer, to store potential URLs at each row/column position on the current view. The data structure is cleared every time updateSize is called (so, when the size is actually changed, or when something a new character is drawn to the screen, etc), and lines of links are parsed one line at a time by a method called createLinks, which is called by the onDraw method after a line of text is drawn.

createLinks supports multi-line-wrap links, and works by getting the Transcript line at the row being drawn, checking if its wrap flag is set, and concatenating multiple rows together if necessary. The result is then turned into a SpannableString, and URLs are matched using the Linkify class.

The resulting URLs are then painted into mLinkLayer at the location of the text, such that they can be retrieved by touching the screen anywhere on the link. Retrieval is handled by the getURLat method, which converts screen coordinates into matrix coordinates, and then returns the link at that location, if any.

To handle touch events, the onSingleTapUp method of the Term class has been updated to check for links at the tap location. An execURL method has also been added to create an Intent that allows the URL to be opened by a web browser, etc.

Other changes:

• A couple of wrapper functions have been added to the TranscriptScreen class to facilitate getting data from UnicodeTranscript to EmulatorView
• For some reason, the lineWrap flag was not getting set for lines being typed by the user; instead, it was only being set for lines output by the terminal. I added a fix by forcing the current line's lineWrap flag to be set when the mAboutToAutoWrap flag becomes true. This may be a kludge; I am not sure if it has side-effects.

Issues:

• Links are not automatically underlined. As structured, this would be a challenge to implement. Several routines would have to be modified to allow the EmulatorView to signal the Renderer to change the text style. However, I don't think this is a necessary feature, especially since touch screens don't really have a concept of "hovering" over a link.
• Only web URLs are linkified, not other types of links such as email addresses. This would not be too difficult to implement - one would have to change the type of the data structure from URLSpan to a more general type of Span, and do some type checking to make sure the right Intent gets generated.