Actually I have a background in writing low level kernels, in porting c runtime environments to these custom environments. I know about memory management from the hardware up.
Then how could you possibly have confused operating system level memory management with garbage collecting? I am not sure that I would want you working on the Linux kernel, certainly not on the core.
Only you are mixing alloc/new and garbage collection. My point is that whether an operating system offers malloc/new or garbage collection (manual or automatic memory management) to its applications is irrelevant. In either case it ultimately drills down to a kernel, and this drilling down to a kernel is irrelevant to the applications. The application code could care less if the kernel is linux, bsd, mach, hurd, etc ... The kernel is as abstract and as irrelevant to the application code as the hardware itself.
What I don't have is an overly narrow concept of operating systems, a viewpoint stuck on some quiz once taken in an operating system class that expected a student to regurgitate a 1970s list of OS components.
The term "operating system" was recently coopted by marketdroids and PHBs who have not got the faintest clue of what a timer wheel is, to mean something convenient for Apple and Google's respective business plans. Please go get any operating system text, including a recent one, and you will find that the classic meaning of "operating system" is still the only one taught in the schools that produce our kernel engineers.
Your are wrong. Even Andrew Tanengaum says that the definition of an operating systems is fuzzy because it does several different things. Abstracts the hardware, manages resources and provides an API that application programs are written for. That operating systems have evolved and the simple kernel/user mode distinction of years past no longer works. That it is legitimate to define an operating system from both bottom up and top down perspectives. You are simply taking a narrow bottom up perspective, and a further narrowed monolithic perspective on top of that. Android provides an API, it manages memory (automatically), it schedules threads, it performs I/O, etc. Android fits one of Tanenbaum's definitions of an operating system. Tanenbaum specifically refers to Java-based operating systems.
Android is no less of an OS for delegating some low level operations to the host linux kernel than a microkernel based OS that delegates some low level functions to its microkernel.
You seem not to grasp the scale, power or subtlty of "some low level operations" that Android relies on the operating system for.
You guess wrong yet again. Its not the utility of the kernel that matters. Its the visibility of the kernel, the necessity of one particular kernel. Linux is an implementation detail under Android. Android could be ported to use a different POSIX based kernel and applications would not know or care. Why? Because Android is an operating system from an application perspective.
Debian is no longer an OS when it delegates low level functions to HURD?
Debian is referred to by Debian developers as a "distribution". That is exactly what Android is, nothing more and nothing less.
That is an amusing dodge. What developer's call their software only matters when it fits your narrow definition.