▼Як на мене так краще виглядає, і з офіційного сайту розробників
source.android.com написав:Application framework
This is the level that most application developers concern themselves with. You should be aware of the APIs available to developers as many of them map 1:1 to the underlying HAL interfaces and can provide information as to how to implement your driver.
Binder IPC
The Binder Inter-Process Communication mechanism allows the application framework to cross process boundaries and call into the Android system services code. This basically allows high level framework APIs to interact with Android's system services. At the application framework level, all of this communication is hidden from the developer and things appear to "just work."
System services
Most of the functionality exposed through the application framework APIs must communicate with some sort of system service to access the underlying hardware. Services are divided into modular components with focused functionality such as the Window Manager, Search Service, or Notification Manager. System services are grouped into two buckets: system and media. The system services include things such as the Window or Notification Manager. The media services include all the services involved in playing and recording media.
Hardware abstraction layer (HAL)
The HAL serves as a standard interface that allows the Android system to call into the device driver layer while being agnostic about the lower-level implementations of your drivers and hardware. You must implement the corresponding HAL (and driver) for the particular piece of hardware that your product provides. Android does not mandate a standard interaction between your HAL implementation and your device drivers, so you have free reign to do what is best for your situation. However, you must abide by the contract defined in each hardware-specific HAL interface for the Android system to be able to correctly interact with your hardware. HAL implementations are typically built into shared library modules (.so files).
Linux Kernel
For the most part, developing your device drivers is the same as developing a typical Linux device driver. Android uses a specialized version of the Linux kernel with a few special additions such as wakelocks, a memory management system that is more agressive in preserving memory, the Binder IPC driver, and other features that are important for a mobile embedded platform like Android. These additions have less to do with driver development than with the system's functionality. You can use any version of the kernel that you want as long as it supports the required features, such as the binder driver. However, we recommend using the latest version of the Android kernel. For the latest Android kernel, see Building Kernels.
Щодо Андроїда, то на блоги і офіційні ресурси підписаний від самої появи. Завжди був принцип: ядро з дровами, поверх набір бібліотек які позбавляють потреби колупатися в дровах, поверх набір серверів які юзають бібліотеки і тут же паралельно паше віртуальна машина (точніше потрібна кількість екземплярів), у віртуальних машинах (у кожного додатка свій екземпляр) пашуть додатки, які отримують доступ до серверів так само як програма на Java до БД MySQL (принцип, але для кожного сервера своя відмінність). Кому скільки який ресурсів визначає ядро. Висновок, ядро більше ніж драйвер. Якщо цікаво до чого дрова до ядра лінукса, то почитай про ядро лінукса:
Ядро Linux підтримує багатозадачність, віртуальну пам'ять, динамічні бібліотеки, відкладене завантаження, продуктивну систему управління пам'яттю і багато мережних протоколів.
На сьогоднішній день Linux — монолітне ядро з підтримкою завантажуваних модулів. Драйвери пристроїв і розширення ядра зазвичай запускаються на «кільці 0», з повним доступом до устаткування. На відміну від звичайних монолітних ядер, драйвери пристроїв легко збираються у вигляді модулів і завантажуються або вивантажуються під час роботи системи.
Якщо виникло питання, навіщо тоді бібліотеки, то вони потрібні щоб зробити універсальний API для серверів які працюють із залізом, тобто пишеш сервер і неїбеш мізки тим з яким залізом він пахатиме, тобто від якого модуля ядра залежатиме, у тебе є бібліотека яка вирішує всі проблеми в розбіжностях. Відповідно виробник заліза пише модуль для ядра, а той хто поєднає це залізо в пристрій пише бібліотеку для роботи із відповідними модулями ядра.
Тож не треба фігні писати, що весь андроїд паше у віртуальній машині, все простіше і побудовано на основі ОС лінукс, просто Гугле все упорядкував, зробив чітким і зрозумілим, одним словом позбувся деякого хаусу що виникає час від часу в лінукс через відсутність контролю. Ну і звісно адаптував під поставлену задачу, прибравши непотрібне на мобільних пристроях.
Простіше кажучи є програми-сервера (сервіси) і є віртуальна машина на якій програма що працює із сервісами так само, як з БД MySQL (сервером). Все це паше на лінуксі на якому навели порядок у структурі. До речі, такий приклад навели розробники перед випуском першого андроїда.
P.S. Я дивуюся як не вийшло у вас що додатки працють у віртуальній машині що працює на андроїді, а сам андроїд у іншій віртуальній машині, яка працює взагалі в паралельній реальності з якої веде червоточина до модулів ядра ядра лінукс, при тому за рахунок зсуву у часі між реальностями модуля працюють без решти частин ядра. Хоча ні, приблизно так у вас і вийшло. Бо ядро лінукс у вас лиш драйвер і розподілом ресурсів не займається. Жах..
P.P.S. Діаграми роблять для узагальненого пояснення, більш точні шукайте не в блогах, а у статтях і документації від розробників.
?