Linux – How to get most of the standard Linux utilities and commands on Android 3.1

QNX is a microkernel system, with (obviously) mostly POSIX userland interfaces. Linux is a monolithic kernel, with mostly POSIX interface.

The Linux kernel inside Android is heavily modified and configured for the hardware it runs on. It has a lot of non-standard interfaces and devices under its control on your random phone/tablet. Just look at the struggle to get Android derivatives running on the machines. I presume something similar, with other changes, and particular devices, is also valid for QNX on whatever you are contemplating.

Running Android userland over QNX is perhaps possible, but a very large undertaking. Look at the massive work done by the k-FreeBSD Debian (sorry if the spelling is wrong) folks to make a much more similar pair of kernel-userland, where moreover much of the userland was build to be portable, work well together.

Running Android on the machine might be more doable, but you'll lack most (as in "almost all") of the documentation required to use any of the special devices that make the machine worthwile. That is also applicable to the last point.

The LSB, POSIX, and the Single UNIX Specification all significantly involve userland. Simply using a kernel that is also used as the basis of a "unix-like", "mostly POSIX compliant" operating system -- GNU/Linux -- is not sufficient to make Android such as well. There are, however, some *nix-ish elements, such as the shell, which is a "largely compatible" Korn shell implementation (on pre-4.0, it may actually be the ash shell, which is used on embedded GNU/Linux systems via busybox) and various POSIX-y command line utilities to go along with it. There is not the complete set most people would recognize from the "unix-like" world, however.

is it close enough to be compliant with the Linux Standard Base?

A centrepiece of the LSB is the filesystem hierarchy, and Android does not use this. LSB really adds stuff to POSIX, and since Android is not nearly that, it is even further from being LSB compliant. This is pretty explicitly not a goal for the platform, I believe. The linux kernel was used for its own properties, and not because it could be used as the core of a POSIX system; it was taken up by GNU originally for both reasons.

To clarify this distinction regarding a user space oriented specification -- such as POSIX, Unix, or the LSB extensions -- consider some of the things POSIX has to say about the native C library. This is where we run into platform specific things such as networking and most system calls, such as read() -- read() isn't, in fact, standard C. It's a Unix thing, historically. POSIX does define these as interfaces but they are implemented in the userland C library, then everything else uses this library as its foundation. The C library on GNU/Linux is the GNU C Library, a completely separate work from the kernel. Although these two things work together as the core of the OS, none of the standards under discussion here say anything about how this must happen, and so in effect, they don't say anything about what the kernel is or must do. They say a lot of things about what the C library is and must do, meaning, if you wrote a C library to work with a given kernel -- any kernel, regardless of form or characteristics -- and that library provides a user land API that satisfies the POSIX spec, you have a POSIX compliant OS.

LSB does, I think, have some things to say about /proc, which linux provides as a kernel interface. However, the fact that this (for example) is provided directly by the kernel does not mean that the LSB says it has to be -- it just says this should/could be available, and if so what the nature of the information is.