Programming

Thoughts on Android development *ON* Android

by

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.

by

When working off a local clone of code while I’m stuck sitting in a doctors office, I’ve got to admit, it would have been smart to have run make tags, and copied the resulting TAGS file over from the development environment to my transformer. Turns out it depends on more than just the usual tags generator >_<.

Oh well, I guess it’s time to nav it the other way!

Sometimes Linus is a genius

by

When you begin to do more advanced things with subversion (not my idea, trust me), I would have to conclude using tarballs and larger hard drives is more useful than subversion.

For the first 10 years of kernel maintenance, we literally used tarballs and patches, which is a much superior source control management system than CVS is, but I did end up using CVS for 7 years at a commercial company [Transmeta[11]] and I hate it with a passion. When I say I hate CVS with a passion, I have to also say that if there are any SVN (Subversion) users in the audience, you might want to leave. Because my hatred of CVS has meant that I see Subversion as being the most pointless project ever started. The slogan of Subversion for a while was “CVS done right”, or something like that, and if you start with that kind of slogan, there’s nowhere you can go. There is no way to do CVS right.[12]

source: Wikipedia on Git.

Please, for the love of sanity (and science), do not use Subversion…..you have been warned!

by

Right, premake4 is one of my favourite ways to build C/C++ stuff but tonight I’m thinking it has a moron involved. You can specify a project as being one of four kinds: ConsoleApp, WindowedApp, SharedLib, StaticLib. The documentation here states that this likely means /SUBSYSTEM:WINDOWS will be passed to link.exe, and indeed it is. That is how you say call WinMain and do any other I’m a GUI app magic for Windows; other wise you get a main and a command  prompt; simply put.

This FAQ entry on the other hand, is just retarded.

by

I guess like many, this morning I learned that the world recently lost one of it’s biggest contributors. I do not mean Steve Jobs, a man with his own important legacy. Dennis MacAlistair Ritchie has died, he was more commonly known as ‘DMR’ or just ‘Dennis Ritchie’. A G+ entry by Rob Pike is the earliest reporting I’m aware of, but I can’t say I expect this sad news to be found on TV.

Dennis Ritchie has a place in history that few men have ever achieved, because his work helped change the world. I am a young man compared to the late DMR but I does have an interest in history. If it wasn’t for this mans work, I doubt that I could be writing this journal entry, because he helped to enable so many elements that make it possible.

His most famous programming language, C, was so pervasively popular, that I knew of it before I learned to program. My first programming language (C++) was derived from it. A big part of how I fell so deep insane with computers was learning about how C and Unix became self hosting. That  means you could make C and Unix using C and Unix, in laymans terms. Back then that was  almost like revolutionary – today it’s like sliced bread. We take it for granted but someone had to help show us the way; then people started to use it everywhere.

Through C, we gained countless programs. Most Unix operating systems are written in C, most other operating systems are written in C or finally grown from one that was. Unix, DOS, Windows, Linux, OSX, your iPod, your iPhone, your iPad, our Android. None of it would exist just like it does. Most of the stuff we do every day involves C programs, be that reading e-mail, playing games, surfing the web. It is even normal for other programming languages to be implemented in C. The defacto standard Perl, Python, and Ruby included. It is so normal that writing a language implementation in itself is not so big anymore. C is so pervasive that it is also inescapable in other languages: their is almost always a way and a need to interface with C code. Hell, today you might even have C code involved in your toaster. It is that important a programming language. If you ever used a computer or an embedded system, you have probably used software written in C, or are old enough to remember what it was like before punch cards.

C is perhaps the single most important language since programmer’s stopped writing in raw machine code. In fact, sometime after that we stopped writing in assembly and I know no one who goes lower level than reading the machine code. A common portion of C syntax is practically our linga franca—even if C is not a shared language, the syntax (which grew from prior languages) is also widely used and an alternative to pure pseudo code.

Maybe a lot of young programmers don’t know C, or skip it. I love it. It is one of the most beautiful languages that I know, despite it’s trappings. Perhaps some of the greatest lessons I learned about my craft, was that learned from C. Perhaps another was the humility of it’s creator.

Somehow, I doubt his other works will ever be as well known as C, or things he was a big part of (like Unix), but maybe people will study them and see what they can learn from the work of a legendary hacker, like Dennis Ritchie.

A case for autotools that I have only recently begun to understand

by
Like just about anyone who has ever had to install software from source has, I have /used/ autotools before. But like many barely ever scratched the surface. Lately I have been cuddling up with the autotools from a developer perspective, a lot more. To the point perhaps, that I am liking autotools better than I ever thought I would. Like anyone whose used more than 1% of autotools, I know you can (or are supposed to when the developer did it right) be able to run configure/make outside the source tree. Also I know about –prefix and most of the usual configure script goodness. Now, it’s far from the first time that I have mentioned it, but my “Holy Grail” of builds has long been a multi-tree build:  one tree for build files, one tree for distribution files, and trees for whatever source and data files are needed. Then because I may be doing a diverse set of platforms, this usually becomes a need to further grind down into having co-existing build/dist trees: for example to have FreeBSD, OpenBSD, Linux, and Windows NT builds in the same working copy. Including using different toolsets, such as GCC 3.x, 4.x; and MSVC 9.0, 10.0 on the Windows NT builds. Now that my main computer is an ARM, processor architecture will probably end up mandatory. I like stuff like Build/platform/toolset. Hacks to keep this sort of thing working under {insert random OS here} should be kept to a minimum. How well a build system supports helping me with this problem (and file system hier) is one way that I judge build systems. Over the years, I have tried…just about everything except ant and maven but hey, how many C/C++ projects do you see using those at home? Multi-lingual stuff is always idea. At present, my favourite build system is premake4 — it makes setting up such a build pretty painless. After that is probably Qt’s qmake, since it makes compiling fairly painless. With the GNU build system, it is pretty easy to do something like: 


    $ cd Build/Linux/ARMv7/gcc44
    $ ../../../../configure --prefix ../../../../Dist/Linux/ARMv7/gcc44
    $ make install

Which would give something well suited for testing, and there is a config file to save whatever configuration options I usualy test with in $prefix. The check and installcheck targets also do what I will typically do with a `make tests` or a `./tests.sh` in my own working copy. To top it off, autotools probably has one of the best tools for making a distribution: make distcheck. I do not need most of what autoconf can do, and usually prefer to skip it. The ability to have things fail at configure rather than compile time is handy. Being able to e.g. toggle between Deps/{pkg} and the systems {pkg} at configure time is great and something I already do with premake4. Automake can also pretty much do what you could get out of not having to hand write Makefiles. What REALLY shines however is libtool! We have all cursed at something or other involving autoconf, automake, or libtool. But the little secret is libtool is one of the best assets ever given to a developer. If you don’t think so, you should try to alcomplish the same thing in SCONS for a solid week, just to support three platforms with differing toolsets, unless much as changed in a few years: the amount of kludges is a recipee to be pissed off. libtool can pretty much do it all and for a lot of platforms. The real question is how well autotools would really play with doing a Windows NT build with Visual C++. I’ve never tried that. That is also the principal reason I’ve never used autotools on most of my projects lol.

Cassius is now on GitHub!

by

While a very important girl was off visiting her grandparents, I resurrected work on Cassius! Thanks to a few nights and occasional Saturday afternoons, the interface is maturing to the point where I can almost use it, so I’ve decided to put it on GitHub.

Old code never goes away, it just goes back to the compiler.

by

Today, I really got a nice little reward. Basically, the company I work for was getting people together to go over the renewals with our medical insurance provider, and of course, eh, I’d rather be at  my work station getting something done. So this provided me with the impetus to setup my phone as  an impromptu in-building terminal.

Problemo is, I usually use VIM. While I’m stubborn enough to give that a go on a small screen with a virtual keyboard, my phones virtual keyboard doesn’t provide the *PC* keys: namely escape, control, and alt. It’s also not the most convenient to use the programs methods of side stepping this. So I got to thinking for a moment, what is an editor that is light and small enough to use over a text terminal, yet powerful enough to service a programmer without a lot of special keys? –> I found the solution right in my own skills repertoire, or as some say: the default text editor! Some years back, I took the trouble to learn how to use /bin/ed out of an interest in learning how to use vi/vim better.

After a couple minutes of thinking on this, it occurred to me: ed was designed in an era when terminals were SLOW, so slow in fact, that you could probably piss off someone by trying to print to much to standard output, which could be connected to a roll of paper and a true TTY >_>.

So it seems that learning /bin/ed was well worth it, because it makes one hell of a file text editor when using your phone as a terminal 🙂

by
When you write a hash table look up using function call syntax in the morning, you know that it must be time for lunch!

Strawberry Perl + CPAN

by

Well, I’ve figured out one of the problems getting anything to work off CPAN. The installer didn’t have the brains to detect that CPAN configuration should work with $prefix where $prefix != C:strawberryperl. As in my case, the distribution is in C:DevFilesLanguagesPerl. Hehe.

It would be nice to be able to install modules and not have so many WTFs/Minute.