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.
Best Answer
Linux standards base is a set of APIs that are guaranteed to be available on an LSB compliant installation. This mostly requires installing some other free software libraries that most distributions already have available - such as POSIX compliant libc, C++ compiler support, Python, Perl, GTK+ and Qt.
All major Linux vendors today ship LSB compliant operating systems, that includes RedHat, Debian, Ubuntu and Novell - so I don't believe there is much contention about it.
Back when LSB first started people were a bit "meh - who cares". Later there was contention about which APIs to include: if Perl is to be required then what about Python? If GTK+ is required then what about Qt developers? This would have made for some pretty fancy flame wars if not for the "meh" attitude of many operating system vendors towards LSB. Eventually all this was settled by the Linux Foundation being all inclusive and supporting multiple APIs that do the same thing and now it looks that everyone is content.