I’m crazy enough for it, after all BTEP+{bash,vim,coreutils,etc} on the TF101 is about as pleasant as on a netbook. The difference between BTEP and XTerm, makes something like Screen or TMUX a necessity IMHO and I favour the latter. Also copying and pasting from vim to Android apps is different. Without vim’s X support, a temp file is the best solution until BTEP gains real support for text selections.
My point being, if you can use a netbook and a command line environment, doing it on Android is no different. Hell you could even SSH into a phone from a PC if you lack a Transformer or a tablet+Bluetooth keyboard setup. Only people that _require_ something like Eclipse or Visual Studio are seriously impacted, and emacs and vim are good tools when combined with GNU tools (BusyBox a bit less so). I have the equal of Debian without X.Org running on my transformer, a decent terminal emulator, and a real keyboard. So I am well equipped.
Now, the sticky part is actually being able to compile and run Android Java programs. You can write the code on a napkin if you want but that doesn’t work with your devices CPU quite so easily.
Android developers should already know the compilation model:
*.java -> *.class -> *.dex -> classes.dex
A compiler is used to convert the source code into Java bytecode. This technically means that any language that you can get running on a JVM, and interface with Java code, you can probably use for Android development; in practice I’m sure there are more devils in the finer details.
After we get the Java bytecode, we have to convert it into a format for the Davlik VM to run. That’s where the dx program comes in. It translates Java to Davlik.
Because applications are rarely composed of pure source code, especially Android ones, things get slightly more complicated to create a .apk file you can install. The packaging tool aapt, apkbuilder, and aidl programs join javac and dx in creating the .apk file, the end goal of our the toolchain. In practice: .apk is pretty much .jar, which is pretty much .zip. Only classes.dex is used instead of a .class file per class in your code, and something I wonder why Sun never thought of!
Now, the issue is obviously how to run all this shit on an Android device, like my Transformer.
Google only publishes SDKs for Windows, Linux, and OS X systems on x86, Linux+ARM isn’t supported, sadly. Installing an x86 emulator and a mini distro with Java and ssh is over kill, even for my Debian chroot loving self! BUT most of the SDK is in Java or BASH!
Java runs on Debian/ARM, so we can install a JDK and JRE, and thus get access to the Java side. Bash is already available for Android, let along Debian/ARM. So! The point of concern becomes x86 binaries. That seems to amount to most programs in platform-tools/ and tools, but what do we /actually/ need? Well guess what Jack, if we’re doing development on device, we don’t need the emulator! AFAIK the tools we do need are: apkbuilder, dx, javac, probably jarsigner. The aapt and android programs being good to have, ditto for ant I’m sure.
aapt is a binary, so at best it would have to be natively or cross compiled, and much like make in C country, we can probably do it another way. The source is probably in the Android Open Source Project (AOSP) somewhere, which would make this easier.
android, apkbuilder, and dx are bash scripts.
android sets up an invocation of the Java VM (java) with tools/lib/sdkmanager.jar and a suitable SWT JAR and runs the program. I don’t know if SWT needs to be in the classpath when running it in command line mode, but hell, Debian/ARM = SWT deb somewhere.
dx is similar but uses platform-tools/lib/dx.jar.
ditto for apkbuilder, but using tools/lib/sdklib.jar
In looking at the manifests, a suitable Java execution environment is all that is needed for the serious leg work. That surely can be done using the JRE and/or JDK debs. Hoorah! And obviously the point of the “platforms/android-*” stuff is for javac and the emulator to work, android.jar in particular is our interest.
One downside, dealing with Renderscript or NDK stuff is another delema as obviously those rely on binary stuffs that are not Java, and AFAIK the toolchain for Renderscript depends on an LLVM frontend, so idk how to deal with that yet, but I’m not worried about it — most applications shouldn’t be using renderscript, unless maybe you’re making Modern Warfare 4 on Android >_<.
So I think, I is in business.
PostScript: I am aware of the Terminal IDE app but prefer to be closer to the official SDK and I would rather stick closer to my Debian chroot, especially because BTEP+tmux is a better place for using VIM with a real keyboard.