Android = Linux Kernel + C/C++ Runtime Framework + Davik Virtual Machine + Java Runtime Framework + Java SDK。下面我們再以APK的開發、編譯、安裝和執行來說明這些層次之間的關係。

首先，我們是在PC上使用Android SDK提供的介面來開發APK，用的Java語言。開發完成之後，使用Java編譯器將原始碼編譯成Java位元組碼，也就是帶.class字尾的檔案。接下來這些.class再被Android SDK提供的dx工具轉化成Dex位元組碼，最後打包在APK裡面的classes.dex檔案中。

接著，APK檔案在手機上安裝時，Java Runtime Framework裡面的PacakgeManagerService就會對該APK檔案進行解析，並且通過Socket IPC通知C/C++ Runtime Framework裡面的installd守護程序對APK裡面的classes.dex檔案進行優化，得到另外一個classes.odex檔案。

APK安裝完成之後，就可以運行了。我們以APK從桌面Launcher啟動的過程為例說明它的執行過程。當我們從Launcher點選應用圖示的時候，Launcher向Java Runtime Framework裡面的ActivityManagerService傳送一個啟動應用的請求。ActivityManagerService又通過Socket IPC向C/C++ Runtime Framework裡面的zygote守護程序請求建立一個應用程式程序。這個應用程式程序包含有一個Dalvik虛擬機器。應用程式程序建立並且啟動起來之後，就會通過它裡面的Dalvik虛擬機器載入前面提到的classes.odex檔案。這樣我們的應用程式就執行起來了。

APK的執行過程是依賴於Dalvik虛擬機器的。我們可以將它看成是將classes.odex裡面的位元組碼解釋成本地機器指令執行。例如，我們在APK裡面通過FileInputStream或者FileOutputStream開啟一個檔案的時候，Dalvik虛擬機器就會找到C/C++ Runtime Framework裡面的C庫bionic提供的系統介面open，並且通過它來開啟指定的檔案。

我們再以應用程式介面的繪製和渲染過程來詳細說明各個層次的關係。首先是應用程式通過SDK提供的UI類向Java Runtime Framework裡面的WindowManagerService申請分配一塊圖形緩衝區。WindowManagerService又是通過Binder IPC向C/C++ Runtime Framework裡面的SurfaceFlinger申請分配圖形緩衝區的。圖形緩衝區實際上不是由SurfaceFlinger分配的，而是由顯示系統分配的，可能在視訊記憶體裡面，也有可能在GPU裡面。這時候SurfaceFlinger就要通過HAL層次Gralloc模組向Kernel裡面的顯示卡或者GPU驅動申請分配真正的圖形緩衝區。HAL層可以看作是執行在C/C++ Runtime Framework中。

應用程式得通過上述方式得到繪製UI所需要的圖形緩衝區之後，就開始繪製自己的UI了。假設應用程式使用的是硬體繪製方式，也就是通過C/C++ Runtime Framework裡面的OpenGL來繪製。這時候SDK的UI類的與繪製相關的函式呼叫通過Dalvik虛擬機器都轉化成了C/C++ Runtime Framework裡面的OpenGL操作。

應用程式UI繪製完成之後，結果就儲存上述的圖形緩衝區中。這時候如果要將該圖形緩衝區渲染到手機螢幕上，那麼還需要通過Binder IPC將該圖形緩衝區傳送給C/C++ Runtime Framework裡面的SurfaceFlinger。SurfaceFlinger通過使用OpenGL或者HWComposer將所有請求要渲染到手機螢幕上的圖形緩衝區合成之後，得到一個主圖形緩衝區。最後這個圖形緩衝區又會被SurfaceFlinger提交給Kernel的顯示卡驅動，並且在手機螢幕上進行顯示。

上面描述的就是Android系統各個層次的呼叫關係。總的來說，應用程式執行在Dalvik虛擬機器上，並且通過SDK使用Java Runtime Framework裡面的服務，而Java Runtime Framework裡面的服務又通過C/C++ Runtime Framework裡面的服務來實現自己的功能，最後C/C++ Runtime Framework裡面的服務又會在需要的時候請求Kernel裡面的模組或者驅動來為自己服務。