Moved from Stack Overflow, where I realize it was off-topic since it was asking for sources – far as I can tell, the rules forbid that there but not here.
I know that the kernel in Android is now mostly the Linux kernel with a few exceptions like wakelocks (as described by John Stultz.) But is it close enough to be compliant with the Linux Standard Base? (Or for that matter with POSIX and/or the Single Unix Specification?)
I'm writing about this in an academic term paper, so as well as the answer itself it would be great to have a relatively reliable source I can cite for it: a peer-reviewed article or book would be ideal, but something from Google's developer docs or a person with established cred (Torvalds, Andrew Josey, etc.) would be fine.
Best Answer
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.
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.