use LOCAL_REQUIRED_MODULES to build with android tree

fix LOCAL_MODULE_TAGS issue

Revert "Make sure we build on API level 10."

This reverts commit b2d747b905222292b97ea9736c70cf83debc6120.

Color tweaks

Other terminals which offer color support generally have two sets of
colors, a "dim" set for regular text and backgrounds and a "bright" set
for use with bold text.  At the moment, Android Terminal Emulator uses
the same set of eight colors for backgrounds, normal text, and bold
text, which causes one notable problem: applications generally expect
bold text colored black to be displayed as "bright black" (a dark gray),
but this text is invisible in Android Terminal Emulator in the
white-on-black configuration.

Fix this by extending the array of foreground colors to include "bright"
colors (actually, the same colors we were using before, except for the
addition of a "bright black"), taking advantage of the fact that we're
using the high bit of the foreground color to store bold information.
We dim the regular set of colors slightly, to distinguish them from the
bright colors.

Signed-off-by: Jack Palevich <jackpal@google.com>

Make changes to UTF-8 preference take effect immediately in running sessions

Add a updatePrefs() method in TermSession and TerminalEmulator and call
it from Term's updatePrefs(), so that changes to the UTF-8 preference
will be picked up immediately by running terminal sessions.

Note that a terminal emulator will ignore the UTF-8 preference once any
application running in it uses one of the ESC % codes to request a
specific character set.

Signed-off-by: Jack Palevich <jackpal@google.com>

Fix fast resize when screen shrinks

When the line containing the cursor is blank, and the cursor is not at
the bottom edge of the screen, fast resize will move the line containing
the cursor off the screen.  Fix this by ensuring that fast resize never
considers lines at or above the cursor for shrinking.

This patch prevents a crash which occurs when a full resize operation is
conducted immediately after this bug is triggered (the full resize
attempts to fetch the character at the cursor, which is off the screen,
causing an IllegalArgumentException).

Signed-off-by: Jack Palevich <jackpal@google.com>

Declare version 1.0.35

Create Android 1.5 version of notification icon.

Use MDPI version, as Android 1.5 devices are defined to be MDPI.

Update documentation checklist.

Add notification icon for use with Android 1.5

Update service notification icon.

Used "Android Asset Studio" to create the icons from a template.

Update checklist.

Add a publish checklist.

Bump version number.

Revert "Return empty ExtractedText instead of null from getExtractedText()"

This reverts commit 2d640ff2381925d9784248712671b7c47f2b7f56.

The original commit broke Swype soft keyboard support.

Make sure we build on API level 10.

(Previously our manifest said we used API level 10, but we actually built
against API level 11.)

Avoid possible overflow if the text ends in a high surrogate.

Add link to Android Market.

A UTF-8 encoded text file

From http://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-demo.txt

This test file shows that we don't currently handle many obscure parts
of unicode rendering, including combining diacritics, brail, etc.

Create a status bar notification icon.

See http://developer.android.com/guide/practices/ui_guidelines/icon_design_status_bar.html

Remove executable bit.

These files are not executable, and should not have executable bits
set.

These bits sometimes gets set when importing files from Windows.

Move atari font notice out of res directory.

Increment version number.

Implement fast resize for cases where width remains constant

A resize operation currently requires getting the entire transcript
text, throwing away the backing store, constructing a new one, and then
writing the transcript to the new store.  Particularly when the
transcript is large, this is a slow and inefficient operation.

As it turns out, it's really quite easy to change the number of screen
rows for a particular backing store, which allows much faster resize
operations in the case where the number of columns does not change.
This is particularly useful when using soft keyboards, where the number
of rows will change depending on whether the keyboard is displayed, but
the number of columns doesn't.

Signed-off-by: Jack Palevich <jackpal@google.com>

Make the screen a movable window in the transcript buffer

Instead of the current scheme of having 0..mScreenRows-1 be the screen,
and everything else be the transcript, let the screen be a movable
window into the circular buffer.  This allows scrolling the whole screen
to be much faster (just move the window), and should make fast resize
easier.

Signed-off-by: Jack Palevich <jackpal@google.com>

Preserve colors and formatting across screen size changes

Currently, getTranscriptText() has no option for preserving
color/formatting information, so this information is lost when resizing
the screen.  Fix this by adding a variant of getTranscriptText() which
accepts a StringBuilder in which color information will be stored, and
using it during resize operations.

To save memory, this implementation only preserves color information for
regions of the screen which contain text, so blank areas of the screen
with colored backgrounds will still revert to the default background
color.

(Why StringBuilder?  Post-Unicode, we cannot store information in the
upper bits of a char, as we would have before.  An ArrayList<Byte> would
be the most natural fit, but the need to box the values creates serious
memory overhead.  StringBuilder handles dynamic sizing of the array for
us and uses less memory per cell than an ArrayList.)

Signed-off-by: Jack Palevich <jackpal@google.com>

Add a hack to remember the cursor position across screen size changes

As it stands, the cursor ends up immediately after the last
non-whitespace character in the transcript after a screen resize, which
is very frequently incorrect (the last character in the output is
often a space or newline, and it's possible the cursor has been moved,
as during command line editing).

Since lines could be re-wrapped during the screen size update, there's
no easy way to calculate where the cursor should end up.  Therefore, we
use a hack: since ASCII ESC (\033) is non-printable and should never be
part of the transcript, we mark the cursor location with an ESC before
resizing, and restore the cursor to the location where the ESC ends up
afterwards (taking care to save and restore the real character at the
cursor position correctly).

Signed-off-by: Jack Palevich <jackpal@google.com>

Return empty ExtractedText instead of null from getExtractedText()

This silences the following error message in logs:

E/InputMethodService(29043): Unexpected null in startExtractingText : mExtractedText = null, input connection = com.android.internal.view.InputConnectionWrapper@405ef968

Signed-off-by: Jack Palevich <jackpal@google.com>

Hide the soft keyboard when pausing the activity

Otherwise, the keyboard will remain open after the user leaves the
activity, possibly covering up part of whatever the user is now doing.

Signed-off-by: Jack Palevich <jackpal@google.com>

Return early from charWidth() for all ASCII printable chars, not just space

Signed-off-by: Jack Palevich <jackpal@google.com>

Fix off-by-one error in getting selected text

Signed-off-by: Jack Palevich <jackpal@google.com>

Fix getTranscriptText() behavior with autowrapped lines

Since the Unicode patches, internalGetTranscriptText() has been
ignoring trailing whitespace for lines that were autowrapped, which
causes the content which was wrapped to the next line to be appended
immediately after the last printing character -- not its original
location.  This patch fixes that regression.

Signed-off-by: Jack Palevich <jackpal@google.com>

Avoid going off end of offset array when going from width 2 to 1 at end of line

Why this is happening is somewhat puzzling in the first place (since a
width 2 character doesn't fit at the end of the line), but this prevents
a crash.

Signed-off-by: Jack Palevich <jackpal@google.com>

getEastAsianWidth: Actually invoke method after initializing when first called

Signed-off-by: Jack Palevich <jackpal@google.com>

Update project organization for SDK version 14

Enable code to run pre-SDK-level 8.

Introduce a utility class to deal with post-SDK-level-3 APIs.

Cache the SDK level as an integer at start-up.

Use reflection to access post-SDK-level-3 APIs.

Add early out for space character, which shows up frequently.

Micro optimization: avoid unnescessary shifts.

Shorten UI message for "Default to UTF-8 mode".

The original message text, while more accurate, did not fit in the UI.

Restore SCREEN_CHECK_PERIOD constant.

(I think Steven has a patch in his source tree that removes the need to
use SCREEN_CHECK_PERIOD, but that patch wasn't accepted for the main
branch, so SCREEN_CHECK_PERIOD is unused in Steven's tree, but is still
required for the main branch.)

Support for Unicode text input and UTF-8 I/O to process

* Ensure all output paths produce UTF-8
* Decode UTF-8 sequences in the input
* Support switching to/from UTF-8 mode using ESC % escape codes
* Add a preference to control whether the emulator is in UTF-8 mode by
  default

Signed-off-by: Jack Palevich <jack.palevich@gmail.com>

Support displaying Unicode text

The current scheme, whereby we store the contents of our screen in an
array of char (two bytes in Java) with the upper byte used to encode
color and formatting information, is fundamentally incompatible with
Unicode, where the available encodings all either need more than one
byte per character or are variable-length encodings.

Instead, we use a new UnicodeTranscript class, which stores the
transcript row by row and includes facilities to handle combining
characters and East Asian wide characters.

We also need to make some minor changes to the code which displays text
on screen to support Unicode output.

Signed-off-by: Jack Palevich <jack.palevich@gmail.com>

Add a transcript backing store suitable for Unicode text

Storing Unicode text in a form suitable for a terminal emulator poses
several challenges:

* In Java's native UTF-16 encoding, some Unicode code points (those
  outside the Basic Multilingual Plane) require two chars to express.
* The use of combining characters means that it's possible for the
  character displayed in one column/screen position to require several
  Unicode code points to express.
* Some Unicode code points (particularly East Asian wide characters,
  which include all of the CJK ideographs) take up two columns/screen
  positions.

The UnicodeTranscript class is designed to make the operations we need
most frequently -- storing a character to a particular screen position,
and getting all or part of a line -- as fast as possible.  The design
uses an array of two types of lines: "basic", which is just an array of
char[], and is used to store a line as long as it has no combining
characters, wide characters, or non-BMP characters; and "full", which is
an array of char[] together with an array of offsets allowing us to
easily find a particular column in the line.  Basic lines in the
transcript are automatically converted to full lines as needed.
Color/formatting information and line wrapping information are stored in
separate arrays.

We also expose a static method, charWidth(), which returns the number of
columns/screen positions that a particular Unicode code point will use.
This information is needed by other parts of the emulator to correctly
handle Unicode.

Correct support for East Asian wide characters requires Android 2.2 or
later -- 2.2 introduced a getEastAsianWidth() method, which we use to
determine the width of a character.  On older platforms, we just pretend
all characters which aren't combining or control characters have width
1.

Signed-off-by: Jack Palevich <jack.palevich@gmail.com>

Optimize getTranscriptText()

The current implementation is going through each line character by
character, even for lines that are known to be unwanted in the final
output; this is silly and easy to fix.

Signed-off-by: Jack Palevich <jack.palevich@gmail.com>

Basque localization.

Courtesy asier.iturralde@gmail.com

Update Italian translations

Courtesy fireb33@gmail.com

Generate native code for x86 as well as armeabi.

In theory this will allow Android Terminal Emulator to run on an
x86 version of Android.

Update config file for latest Android SDK

Update private build tool to support NDK r6b

Increment version number.

Handle fractional-pixel-width fixed-width fonts.

This should fix the problems people have been having with text rendering
when using non-standard fixed-width fonts.

Remove JDK 1.5-incompatible interface method @Override annotations

Allows building with JDK 1.5.

Avoid accessing a finished TranscriptScreen when resuming the terminal activity

updatePrefs() may ask each terminal session in the list to update its
size, which requires accessing the TranscriptScreen.  Therefore, we need
to update the list of running terminal sessions before calling
updatePrefs(), to preclude the possibility of accessing a finished
TranscriptScreen.

Also, if a window was closed in the WindowList activity, and then the
user selected a specific window, the window number passed to us in
onActivityResult() refers to the window list *after* taking window
closures into account.  We therefore need to defer switching to the
user's selected window until after the list of running sessions is
updated (onActivityResult() is called before onResume(), so it can't be
done there); this avoids calling onResume() on a stale EmulatorView,
which results in an attempt to access a finished TranscriptScreen.

Fix resource-related problems when running on Android 1.5 to 2.2

Hurray for the emulator for making it easy to test older versions

+ Use our own copies of system drawables not available in older versions.

+ Make sure there's a (mdpi resolution) copy of every drawable in the
 plain "drawable" directory, since that's where Android 1.5 looks.

Add UI for switching and managing terminal sessions.

We expose three different ways to manage terminal sessions:

* Options menu items to open a new window and close the current window.
* A WindowList activity, reachable from the options menu, which lists
  all the open windows and allows opening, closing, and switching of
  windows.  The behavior is patterned after the window list activity in
  the Android browser.
* Gestures to change windows -- swipe right-to-left for the next window,
  left-to-right for the previous window.

The options menu items have been reordered to make what should be the
five most frequently used items (new window, close window, window list,
toggle keyboard, special keys reference) appear in the icon menu so that
the user doesn't have to touch "More" to reach them.

This patch adds several icons.  btn_close_window and ic_menu_windows
come from the Android browser source, while the rest come from the
Android 2.3.3 SDK platform, revision 2 (platforms/android-10/data/res).

Support multiple sessions per terminal activity.

This patch does the following:

* Replace the EmulatorView widget in the activity layout with a
  TermViewFlipper, which is a ViewFlipper with a couple of added
  conveniences for dealing with EmulatorViews (e.g. pausing/resuming
  them when changing the view).
* Add an ArrayList in the service to hold TermSessions, and make the
  activity bind to the service so that it can retrieve the list.  This isn't
  strictly necessary for multisession support, but allows us to decouple
  the activity from the sessions, which will (in the future) allow us to
  restart or even close the activity without losing running sessions.
* Now that EmulatorViews aren't being created automatically when the
  layout is inflated, but are instead created by hand, move a bunch of
  initialization stuff to the EmulatorView constructor.
* Make the input reader threads for each session exit on EOF.  These
  threads hold a reference to their TermSession objects, which would
  leak otherwise.

For now, one EmulatorView and TermSession are created as soon as the
activity binds to the service, if none exist; no UI to create additional
sessions is included.

Don't accept input from process after TranscriptScreen is finished.

This prevents a bunch of noise in the logs.

Throw away TranscriptScreen backing store on session finish

Android's InputMethodManager seems to hold a reference to a finished
activity object for a while after the activity is destroyed.  This
keeps everything the activity holds a reference to in memory, which in
our case includes a fairly significant chunk of memory: the backing
store to the TranscriptScreen.  Throw this away when it's not needed, to
reduce the memory impact of this behavior.

Use TermSession in activity and view instead of old terminal-handling code

This completes the process of isolating the code for each terminal
session, which should considerably simplify the task of adding support
for multiple sessions.

Add TermSession class to represent a terminal session

At the moment, the assumption that each terminal activity contains only
one EmulatorView and hosts only one terminal session is fairly deeply
embedded into the code.  To help break this assumption, we introduce a
new TermSession class, which holds the TerminalEmulator and
TranscriptScreen for a session, and handles the launching and watching
of the process and the setup of the I/O streams.

Modify the activity and view to use the new TermSettings class.

For multisession support, we eventually want to keep the terminal
sessions in the service instead of tying them to the activity.  This
implies that we have to stop holding SharedPreferences objects in all of
the classes tied to the session.  To this end, introduce a new
TermSettings class, which is responsible for reading SharedPreferences
and holding the current value of config settings.

This patch isn't really necessary, but it makes life easier for me.  For
local builds, I change the package name to
net.steven676.android.terminal, which allows co-installation with the
Market version; however, if the debug constants stay in the Term class,
I have to change every file using them to either belong to the new
package, or else import net.steven676.android.terminal.Term.

The fact that Term.java contains substantially all of the classes of the
application clashes with Java's model of one class per file, and is
inconvenient when refactoring the code to allow for multiple terminal
sessions in the activity.  This patch splits out all of the classes into
separate files, and groups related classes into packages; no actual
changes to the code are made.

Ignore local.properties

contains machine-specific information, not useful to save in repo.

Shrink market icon to match "safe" bounds

See http://www.google.com/support/androidmarket/developer/bin/answer.py?answer=1078870

Improve market icon.

Shinier, and more like a terminal.

Updated translations

Thanks to fireb33@gmail.com

Increment version number.

Update in-app documentation for special keys

Contributed by Steven Luo steven+android@steven676.net

Add F1-F12 and Ins/Del/Home/End keys

Contributed by Steven Luo steven+android@steven676.net who writes:

The mapping is as follows:

Fn-[1-9]: F1-F9
Fn-0: F10
Ctrl-9: F11
Ctrl-0: F12
Fn-I: Ins
Fn-X: Del
Fn-H: Home
Fn-F: End

It should be noted that a real VT100 does not have Home/End keys, and as
such, the terminfo entry for TERM=vt100 doesn't contain escape codes for
Home and End.  This bothers some applications, but not others.  The
codes generated match those sent by the Linux console (TERM=linux),
which appears to work fine as a TERM setting since the emulation fixes
in 1.0.30.  xterm sends different escape codes, though; I left the
escape codes at their present values because TERM=xterm causes problems
with some applications.

Addresses GitHub issue #9.
---
I'm unhappy with the reintroduction of different behaviors for the Ctrl
key, but I couldn't think of another choice that's guaranteed to make
sense on any soft keyboard layout.  (Fn-J/K and Fn-(/) are the two other
possibilities that occurred to me.)  Feel free to change.

Fix behavior of Ctrl-[0-9]

Patch contributed by Steven Luo. steven+android@steven676.net

Steven writes:

In xterm on my Debian system, the Ctrl-[0-9] combinations appear to map
to the following:

Ctrl-2: ^@ (NUL)
Ctrl-3: ^[ (ESC)
Ctrl-4: ^\
Ctrl-5: ^]
Ctrl-6: ^^
Ctrl-7: ^_
Ctrl-8: \177 (DEL)

Ctrl-1, Ctrl-9, and Ctrl-0 appear to send 1, 9, and 0 respectively.

I have no idea whether anyone actually seriously uses these, but make
these key combinations behave in that manner, and remove the bogus
Ctrl-[0-9] and superfluous Fn-[234] combos.

Make Ctrl/Fn-[A-Z] work with uppercase as well as lowercase letters

Patch courtesy Steven Luo steven+android@steven676.net

Steven says:
For Ctrl-[A-Z], this matches the behavior of xterm running on my Debian
box; for Fn-[A-Z], there are no possible compatibility issues and it
seems like the most natural thing to do.

Add link to Downloads page to README file.

Enable an initial command string to be passed as part of the intent.

Thanks to Christoph Schmidt-Hieber, M.D., c.schmidt-hieber@ucl.ac.uk
for the idea and the patch.

Update Italian localization

Thanks to fireb33@gmail.com

Increment version number.

Implement a "None" setting for control and function keys.

Thanks to Eli Grey <me@eligrey.com> for the idea.

Also made the "Special keys" dialog text localizable.

Rename the rt tool to pushAndRun

This tool is used to build and test the terminal emulator.

Allow application to be installed on the SD Card.

Fix insert and delete line code.

Thanks to Sam Jacobson <sam.jacobson@snitchinc.com> for the
bug report and fix!

Implement missing SGR escape codes

Thanks to Sam Jacobson <sam.jacobson@snitchinc.com> for the bug report!

Escape single quote character so string resource compiles.

Merge pull request #20 from cpasmoi/master

missing translations

missing translations

missing translations

Increment version number.

Use a global reference to hold onto a class object between JNI calls.

This bug was detected by using CheckJNI

(setprop dalvik.vm.checkjni true; stop; start).

Update local properties for building on a new machine.

(Maybe I shouldn't check this file in at all.)

Increment version number.

Change shared library name (again) to make sure our copy takes precedence on CyanogenMod

Commit 28d47b8... ("Fix java.lang.UnsatisfiedLinkError error.") changed
the name of the shared library from libandroidterm to libandroidterm2,
to avoid a potential library conflict with API/ABI incompatible versions
being shipped in some custom firmwares.  Unfortunately, CyanogenMod also
uses the name libandroidterm2:

https://github.com/CyanogenMod/android_packages_apps_AndroidTerm/commit/7d0de89f0ed5231a7d7eb3ca7917accb83c8eaee

Change the name again, this time to something that should hopefully be
unique, which should fix the problems that CyanogenMod users have been
reporting in the Android Market comments.  (A big scary warning to
firmware distributors that the shared library ABI must not be modified
without consulting upstream might be appropriate somewhere ...)

Signed-off-by: Jack Palevich <jackpal@google.com>

Bump version number.

Fix java.lang.UnsatisfiedLinkError error.

Change shared library name from libandroidterm to libandroidterm2

My theory is that this bug is happening on systems that have
system versions of the libandroidterm shared library.

Version 1.0.26 of Android Terminal Emulator added a new API,
hangupProcessGroup, to the libandroidterm library.

I think on devices that have libandroidterm in their system library,
that version takes precedence over the version in the application,
and so the hangupProcessGroup API is not found.

By changing the name of the libandroidterm library to libandroidterm2
we should avoid loading the system version of the
libandroidterm library.

Housekeeping odds-and-ends.

Make sure the release build is a clean build.
Regenerate build.xml
Add update.sh script for regenerating build.xml

Rename buld tool, and make it build the JNI code as well.

Bump version number.

Add commitCorrection() to our InputConnection

Required in order to compile under API level 10.

Add setComposingRegion() and getSelectedText() to our InputConnection

The definition of the InputConnection interface for SDK version >= 9
includes new functions setComposingRegion() and getSelectedText().  If
we don't include them in our implementation, the build fails with

   [javac] /home/steven/devel/android-terminal-emulator/src/jackpal/androidterm/Term.java:2955: <anonymous jackpal.androidterm.EmulatorView$4> is not abstract and does not override abstract method setComposingRegion(int,int) in android.view.inputmethod.InputConnection

(at least when building with SDK 10).

Make the Terminal activity singleTask instead of singleInstance

With the Terminal activity's launchMode set to singleInstance, the
Preferences activity starts a new task, which can lead to some very
strange back stack behavior.  Set launchMode to singleTask instead,
which will allow the Preferences activity into the same task.

Add menu options to take WakeLock and WifiLock

It can be very useful to prevent the device from sleeping or from
turning off the wifi radio -- but in a general terminal application it's
difficult to guess when this is wanted.  Consider the following:

(1) Nothing is happening.  We don't want to hold either a WakeLock or
WifiLock.
(2) The user is logged into a remote system via SSH on wifi.  We don't
need to hold a WakeLock, but should take a WifiLock to prevent the SSH
session from being disconnected.
(3) The user is doing some long-running computation (locally on the
device) in the shell.  We should take a WakeLock, but not a WifiLock.
(4) The user is doing apt-get dist-upgrade in her Debian chroot on the
device.  We should hold both a WakeLock and a WifiLock.

Therefore, assume the user knows best, and add menu options to take/drop
a WakeLock and a WifiLock.  Note that this requires adding WAKE_LOCK to
the set of permissions we use.

Add a service to prevent Android from killing our process

By default, an Android process is liable to be killed whenever it's
not in the foreground.  When this happens to us, it leaves the user
unable to resume her terminal session, which is still running.

By starting a service in our process (even one which, like this one,
does nothing at all) and marking it as a foreground service, we prevent
the system from killing our process except in out-of-memory situations.