Presentation is loading. Please wait.

Presentation is loading. Please wait.

Android Linux Kernel.

Similar presentations


Presentation on theme: "Android Linux Kernel."— Presentation transcript:

1 Android Linux Kernel

2 序論 眾所皆知Android的核心是採用Linux kernel,但對於兩者之間細部的關係並非所有開發人員都熟知,本課程將針對Android核心進行剖析,介紹Android與Linux 之間的關係,以及Android系統在Linux系統上之擴充的部分功能和驅動程式,詳細分析這些驅動程式的架構與思維,希望藉由該課程幫助學員們深入了解Android核心的相關知識,以供後續進行Android核心開發與Android系統移植所需。

3 單元介紹 本單元一將介紹Android Linux Kernel,將說明Android作業系統與Linux kernel之間的關係,Android作業系統所使用的Linux kernel是怎樣的Kernel而Android作業系統又擴增了哪些自己特有的功能及驅動。在有基礎知識之後本課程將搭配實作課程「Android kernel移植」讓大家了解如何將一個 kernel進行功能選擇、編譯最後產生移植用的映像檔。以下就開始教授大家Android linux kernel的知識。

4 基礎知識 具備良好的C基礎。 良好的硬體基礎。 對Linux kernel原始程式初步了解。 多工程式設計能力。
在修習本單元前,學生們最好具備以下四點能力,可方便理解本單元所教授的內容。 Android Linux kernel 開發人員需具備C程式開發能力,且須能靈活應用C語言的結構體、指標、巨集等基本語言結構。由於Linux 所使用的是GNU C編譯器,所以也須對GUN C語言有所了解。 Android Linux kernel 開發人員須有良好的硬體基礎,要知道一般性硬體觀念(DMA、IRQ、I/O port),雖不必具備設計電路能力,但須對晶片手冊上的周邊設備有所認識,例如:SRAM、Flash、UART、USB等。 Android Linux kernel 開發人員須對Linux kernel原始程式有初步的了解,一些重要的資料結構、系統呼叫、命令、函數等都須了解。 因驅動程式內會使用大量的自旋鎖、互斥鎖、訊號量等,所以裝置驅動程式開發人員需具有多功程式設計能力。

5 目次 Part I Android Linux kernel核心機制與結構 Reference
Chapter 1 Android與Linux kernel的來龍去脈 Chapter 2 Android 專用驅動程式 Chapter 3 Android 使用的裝置驅動程式 Reference 由於本單元專於介紹Andrlid linux kernel,所以分類的章節並不多,主要以Linux kernel為中心點來講解Android 與Linux kernel的關係及其所擴增的驅動和功能。 以下將以三個章節:Android與Linux kernel的來龍去脈、Android專用驅動程式、Android使用的裝置驅動程式,來解說。

6 Part I Android Linux kernel核心機制與結構

7 Chapter 1 Android與Linux kernel的來龍去脈
1.4 Android Kernel 版本 1.5 Android 的Linux Kernel 本章節將分為四個小節來解說Android與Linux kernel的來龍去脈,分別為: 1.1 為何使用Linux kernel、1.2 Android 系統並非Linux 系統、1.3 Android系統架構、1.4 Android kernel版本、1.5 Android 的Linux kernel。

8 1.1 為何使用Linux Kernel 使用標準Linux 2.6 Kernel 具有強大的記憶體管理機制 具有完善處理行程管理機制
支援共享函式庫 基於權限的安全模式 具有標準的驅動程式模型 開放原始碼專案 Android作業系統是基於Linux kernel 2.6版本開發的一個作業系統,但並非所有的Android作業系統都是採用Linux kernel 2.6版,這邊會說採用這個版本主要是因為當初在開發Android作業系統時,Linux kernel的版本中屬2.6版為最新最穩定的版本,所以就從2.6版本開始使用,後來Android作業系統在進行版本更新時,也採用了更新版本的Linux kernel。 Linux kernel它具有幾個優點,分別是:記憶體管理機制、行程管理機制、共享函式庫、基於權限的安全模式、標準的驅動程式模型,最重要的它是採開放原始碼的授權。

9 1.1.1 具有強大的記憶體管理機制 Buddy System Slab Allocator
DMA (Direct memory access, 16MB以下)。 Normal (16MB~896MB)。 HighMem (896以上)。 Slab Allocator SLOB Allocator(Simple List Of Blocks Allocator)。 SLUB Allocator。 slabinfo buddyinfo proc/ / Linux 之所以會穩定,有一部分則歸功於它有著優良的記憶體管理機制。Linux的記憶體管理機制,主要由兩個部分所組成,分別是:Buddy System與Slab Allocator。 如一般的 Operating System Design,Linux Kernel 一樣是以 Page 為記憶體管理的單位,因此設計了一層針對 page(或稱分頁)的管理機制,該機制在 Linux Kernel 裡被稱為『Buddy System (buddy allocator,簡稱 buddy)』,buddy 是 Kernel 最底層的記憶體管理機制,日後所有的記憶體配置,最後都要經過 buddy 才能取得或釋放記憶體。 關於Buddy System的相關資料可以在根目錄( / )內 proc資料夾中的「buddyinfo」檔案內查看,該檔案是以 page 為單位,紀錄目前記憶體使用的狀況。 在檔案內會列出三種 zone,分別是DMA、Normal、HighMem,這三種分類是以Physical Memory 位置的範圍來區分。 但由於Buddy System的機制相當抽象且基礎,對於驅動開發來講非常不好用,因此Linux kernel就在Buddy之上,設計了一個智慧型的機制─Slab Allocator。 Slab 算是 Kernel 裡最早的一種演算法,事實上,除了 Slab 之外,Linux Kernel 已經實作出數種演算法,以優化記憶體的配置機制。前面提到,Kernel 的底層是以 page 為記憶體配置的單位,因此,哪怕只是需要 1 Byte 的空間,都會佔用一個 page,所以良好的 Slab 演算法,才能盡可能避免記憶體浪費和破碎的問題。截至目前為止,Linux Kernel 所支援的演算法,除 Slab 外另有:SLOB Allocator和SLUB Allocator。 此外,雖演算法不同,習慣上,在 Linux Kernel 裡還是統稱為『Slab Allocator』,沿用舊有的稱呼以表示該層級的記憶體管理機制。 如果要知道目前系統上有哪些 cache 正在使用,可查看根目錄( / )內 proc資料夾中的 slabinfo檔案,或是透過指令工具 「slabtop」來查看。

10 1.1.2 具有完善的行程處理機制 Stopped signal signal Runnig State termination
creation Ready Executing Zombie scheduling Android的程序圖跟一般的有所差別,其中的Interruptible是等待 signal 或 event來進行再次啟動,但Uninterruptible是不處理任何 signal,因為它主要是等待硬體的event。 signal or event event Uninterruptible Interruptible

11 1.1.3 共享函式庫V.S.靜態函式庫 共享函式庫 靜態函式庫 與Windows比較 在執行檔中留下記號,以便程式執行時連結。
所需記憶體及磁碟位較少。 名稱為:libname.so.x.y.z (x.y.z為版本序號)。 缺點速度太慢 靜態函式庫 由鍊結器(linker)自動找出所需模組,實際拷貝至執行檔中。 所需記憶體及磁碟容量較多。 名稱為:libname.a 與Windows比較 Windows:無法修改該軟體的原始程式碼,必須求助發行廠商 Linux:幾乎提供原始碼,使用者可以自行修改成符合個人的需求 建立程式的最後一個步驟便是進行連結,也就是把所有分散的小程式連結組合起來。 靜態程式庫是由連接器自動去尋找需要連接的模組並將其拷貝至執行檔中,但會造成所需較大量的記憶體及磁碟位置;而共享程式庫則是會在執行檔內留下一個記號,指明當程式執行時必須載入做好記號的程式庫,如此一來便可讓直行檔變得更小更精簡。在Linux中預設是採用共享程式庫,但若無法找到共享程式庫時便會採用靜態程式庫。

12 1.2 Android 系統並非Linux系統 修改及優化後的Linux kernel 沒有原生視窗系統 不支援glibc
不同一般市售Ubuntu、Fedora的Linux作業系統。 沒有原生視窗系統 不支援glibc 使用bionic C取代gun libc 未包含一整套的標準Linux kernel 除修正了部分Bug外,還增加部分功能 基於ARM架構的Goldfish平台、Yaffs2及Flash檔案系統…等。 擁有自己專屬的驅動程式 雖然Android系統採用的是Linux kernel,但他並不屬於Linux作業系統的一種,Android既沒有原生視窗系統也不支援glibc,且不包含標準的Linux 使用程序,甚至對Linux部分功能及驅動進行修改及擁有自己專屬的驅動程式。 原生視窗系統:所謂的原生視窗就是指GNU/Linux上的X Window系統,或是Mac OS X的Quartz。每種作業系統都有各自的視窗系統,而Android所用的視窗系統並非GNU/Linux的X Window系統。 不支援glibc:Android系統最初設定用於可攜式的嵌入式設備上,基於效率問題,Google便自行開發一套Bionic Libc來代替GNU/Linux的glibc。 未包含一整套的標準Linux kernel:雖然Android系統是採用Linux kernel,但並不是完全使用,Android修正了Linux kernel的部分BUG,還自行增加了一些功能。 擁有專屬驅動:Android系統除了修改部分Linux kernel外,還自行開發了一些裝置驅動程式,這些裝置驅動程式便是Android所專屬的驅動程式。

13 1.3 Android 系統架構 整個Android系統架構依此圖可分為兩個部分,Layer4和3是屬於應用程式的部分,而Layer2和1則是屬於系統部分。Android Linux kernel便是位於系統部分中的Layer1層,在這層除了原本的Linux kernel外還有Android對Linux kernel修改的部分及自己專屬的裝置驅動程式。後需將針對Layer1進行詳細說明,而其它階層將由後續單元三做詳細解說,在此便不多加敘述。

14 1.4 Android Kernel 版本 Android Version Linux Kernel Version
Android 1.5 , Cupcake Based on Linux Kernel Android 1.6, Donut Based on Linux Kernel Android 2.0/2.1/2.2, Eclair Android 2.2/ 2.2.1, Froyo Based on Linux Kernel Android 2.3, Gingerbread Based on Linux Kernel Android 3.0.1/3.1/3.2, Honeycomb Based on Linux Kernel Android 4.0, Ice Cream Sandwich Based on Linux kernel 3.0.1 Android 5.0, Jelly Bean No specify Android 6.0, Key Lime Pie(2013年發佈) Linux kernel最初版本是由Linus Torvalds開發,之後經過網路上許多高手共同參與開發,目前Linux kernel的版本已經到了2.6。而Android系統所採用的Linux kernel也是使用2.6.X版本的,但隨著Android系統版本不同,所需的Linux kernel版本也有所不同,在進行移植Android系統時便需要依照相對應的Linux kernel來移植,以下表格是Android系統與Linux kernel版本的對照表。

15 1.5 Android 的Linux Kernel Android 的Linux Kernel 可分為 標準Linux Kernel
Android Kernel Space 標準 Linux Kernel Android 專用驅動程式 Android 所使用的裝置驅動程式 在Android系統架構圖中所提到的Linux kernel總共分為:標準Linux kernel、Android專用驅動程式及Android所使用的裝置驅動程式。這邊標準的Linux kernel便是由官方所公布的原生Linux kernel,而Android專用驅動程式及Android所使用的裝置驅動程式便是由Google所開發給Android系統使用的驅動程式,其中包括了一些修改、優化部分原生Linux kernel及專門給Android系統使用的驅動程式。後續將對Android專用驅動程式及Android所使用的裝置驅動程式做詳細介紹。

16 練習 基於哪六個特點,讓Android作業系統採用Linux kernel為自己的核心?
為什麼Android作業系統採用Linux kernel,但它又不是Linux作業系統的一種? Android作業系統的Linux kernel部分,可細分為哪三個部份? 1. 具有強大的記憶體管理機制、具有完善處理行程管理機制、支援共享函式庫、基於權限的安全模式、具有標準的驅動程式模型、開放原始碼專案。 2. 雖然Android系統採用的是Linux kernel,但他並不屬於Linux作業系統的一種,Android既沒有原生視窗系統也不支援glibc,且不包含標準的Linux 使用程序,甚至對Linux部分功能及驅動進行修改及擁有自己專屬的驅動程式。 3. Linux kernel、Android 專用驅動程式、Android 所使用的裝置驅動程式。

17 Chapter 2 Android 專用驅動程式

18 2.1 Android 專用驅動程式 Android Binder Android電源管理 Low Memory Killer Ashmem
Android Logger Android Alarm Android PMEM ADB Gadget 驅動程式 Android RAM Console Android timed driver Yaffs2 檔案系統 Android雖然使用Linux系統的 kernel,但不是把整個Kernel都照搬過來,除了修正了Linux部分的BUG之外,Android還增加了不少自己專屬的驅動程式,以下11項便是Android所開發出來專屬的驅動程式,在後面會陸續介紹各個驅動程式的功用。

19 2.1.1 Android Binder(1/3) 同時為Android的兩種機制
IPC(Inter-Process Communication) 機制。 RPC(Remote Procedure Call)機制。 Android 的 IPC(Inter-Process Communication) 機制 使行程間相互通訊的機制 Android 整個系統運作依賴於Binder驅動 Android 同時為Java環境和C / C++ 環境提供Binder機制 在Linux系統中,是以處理行程為單位來進行資料的配置和管哩,基於保護目的,一個處理行程不能夠直接存取另一個處理程序的資源,也就是說處理行程之間是不知道其他行程的存在。但在一個複雜的應用程式中,通常會使用多個相關的處理行程來完成同一個任務,因此行程之間需要能夠相互溝通,來共用資源和資訊,因此作業系統必須提供一個機制讓程序以行程之間能夠相互溝通,這種機制稱為 IPC (Inter-Process Communication),在Linux中常見的IPC為:具名管道(named pipc)、訊息佇列(message queue)、信號(signal)、共用記憶體(share memory)等,但在Android系統中並無這些IPC機制,Android有著自己開發的專屬IPC機制─Binder。 Binder不僅是Android系統中完善的IPC機制,同時也是Android系統的RPC機制。當透過Binder來取得本機處理行程的服務時,Binder可視為一個本機的「物件」,若是要去取得遠端處理行程的服務時即可視為一種「參照」。

20 2.1.1.1 IPC(Inter-Process Communication)
行程間通訊(Inter-Process Communication, IPC) 兩個或以上的行程、執行緒之間的通訊 使用優點: 資訊共享 提升運行速度 分離私有權 模組化 行程間通訊,Inter-Process Communication縮寫是IPC,他是作業系統中為了讓兩個以上的行程或執行緒可以相互溝通、使用資源的一種技術,但IPC這項技術並非只有Android作業系統才擁有,事實上在還沒有Android作業系統之前我們一般常用的Windows及Linux作業系統均有此機制。採用IPC將會有幾項優點:資訊共享、提昇運行速度、分離私有權、模組化。而詳細的解說將在後續單元七「IPC」將有更完整的介紹,在此先知道此機制的作用即可。

21 2.1.1.2 RPC(Remote Procedure Call)
遠端行程呼叫(Remote Procedure Call, RPC) 使兩台電腦間的行程可互相溝通 Client與Server的架構方式 允許不同Client存取Server 介面描述語言(Interface Description Language, IDL) 遠端行程呼叫,Remote Procedure Call簡稱RPC,它具有與IPC相同的功能,不同的是他是為了提供兩台電腦之間的行程溝通的一種機制,主要是採用Client-Server架構,簡單來講就是,由各個Client對Server提出要求,而Server便會依其要求將相對應的結果回傳至Client端,而這之間的傳送協定便是RPC,且RPC並不拘泥於同一種作業系統之間,及使Client與Server所使用的作業系統不同一樣可以進行溝通傳送,為了可以達到跨平台效果,大部分的RPC都採用介面描述語言來溝通。所為的介面描述語言便是用來描述軟體介面的一種計算機語言,他提供一種中立的方法來產生軟體介面,讓不同平台上的對象和程式語言可以相互溝通,譬如:Java與C語言之間的溝通。

22 2.1.1 Android Binder(2/3) Binder 主要提供下列功能: 多個行程間的溝通及設定彼此間傳的方式
透過共享記憶體(Share memory)的來提高效能 處理行程要求所配置的個別處理行程執行緒池 執行緒池:需要時,在執行緒池找可用的執行緒,如找不到可建立新的執行緒,執行緒使用後會留在執行緒池,提供重複使用 針對系統中的物件導入引用計數和跨處理行程的物件參照映射 物件參照:指令參照到物件時,不參照程式設計的樣子使用 處理行程間的同步呼叫

23 2.1.1 Android Binder(3/3) Binder 主要實作Linux Binder 驅動實作而成
基於OpenBinder 實作 Android 系統皆依賴Binder 驅動程式 Binder 通訊基於 Client / Server 架構 處理行程須建立Ibinder 介面 由Server Manager 管理系統中的各項服務 Service Manager 檔案路徑: Frameworks/base/cmds/servicemanager/ OpenBinder簡稱OB,它是Linux中的IPC名稱,Android作業系統中的Biner便是以他為基底來改良實作自己的IPC。Binder是採用Client-Server架構,行程之間需要建立Ibinder介面以便透過此介面來進行溝通傳輸。

24 2.1.1.3 Android Binder 原理 Binder 驅動程式原理和實作
Binder 採用 AIDL ( Android Interface Definition Language, Android介面定義語言 ) 描述處理行程間的介面 具體實作為字元裝置(Character device),裝置節點: /dev/binder 實作程式主要檔案: Android 層 binder libs/ include/ base/ frameworks/ Kernel 層 Kernel層的binder 檔案主要為Android Binder 驅動程式的實作。 Android 層的binder 檔案: frameworks/base/include/binder/ :Binder 驅動在user space 的封裝介面 framework/base/libs/binder/ : Binder 驅動在 User Space 的封裝實作 Android 主要透過 open_binder 開啟Linux 設備節點 /dev/binder,並透過 ioctrl 建立通訊框架 要注意的是不同Kernel Source Code版本檔案路徑略有不同。 binder.h binder.c staging/ driver/

25 2.1.1.4 Binder 系統架構 Java Binder Client / Server 原生Binder
IBinder Binder BpBinder Binder 核心函式庫 Binder的系統架構可以看成是一個Server和Client的關係架構,舉例來說,在Android中,每個Activity和Service都是獨立的處理程序,而Activity要和Service進行通訊就是一種跨處理程序的通訊,這時候就需要透過Binder機制來協助,我們可以把Activity看成是一個Client端,而Service看成Server端,兩者之間的資料交換均是透過Binder來寫入/讀取資料。 整個Binder機制還包含了:Service Manager、Server、Client、服務代理。 Service Manager:負責管理Android系統中所有的服務,當Client與Server進行通訊時,首先須透過Service Manager來查詢和取得所需要的互動服務,且每個服務均須向Service Manager註冊自己,以便提供服務給Client進行查詢、使用。 Server:這裡所說的服務便是Server端,通常是Android的系統服務,透過Service Manager可進行查詢和取得某個server。 Client:這裡所指的Client是Android系統上的應用程式,它可以要求Server中的服務,例如:Activity。 服務代理:所指的是Client端應用程式所產生的Service proxy,也是Binder機制中的核心模組。 在Binder最底層的Binder驅動程式這層,它是屬於Linux的Kernel層,是用來實作Binder的設備驅動程式,主要負責組織Binder的服務節點,呼叫Binder相關的處理程序,完成實際的Binder傳輸等。 Binder Adapter這層則是對Binder驅動程式進行封裝,來操控Binder驅動程式,使應用程式不用直接接觸Binder驅動程式,該階層主要實作的有三樣東西,分別是:IPCThreadState.cpp、ProcessState.cpp及Parcel.cpp檔案中的部分內容。 Binder的核心函式庫是Binder的框架的核心實作,須實作:Ibinder、Binder(server端)及BpBinder(Client端)。 而最上面的Client端/Server端則分成兩類型,分別是Java及C++兩種實作方式,提供應用程式使用。 IPCThreadState.cpp ProcessState.cpp Parcel.cpp Binder Adapter Binder 驅動程式

26 2.1.1.5 Android Binder工作原理與機制
Client Server 監聽請求 處理請求 回應 發出請求 1. Client 端取得Server 端的代理物件 2. Client 端透過呼叫服務代理物件向伺服器端發送請求 3. 代理物件將Client 端的請求透過Binder 驅動程式發送至Server端處理程序 4. Server端處理Client端的請求,並透過Binder 驅動程式傳回處理結果給Client端的服務代理物件 5.Client端收到Server端的傳回結果 回應

27 2.1.2 Android電源管理(1/3) Android 電源管理(Power Management, PM)機制實作,主要包含三個部份: kernel/power/ 該目錄主要實作系統電源管理框架 arch/arm ( mips or powerpc ) / mach-xxx ( Ex: mach-goldfish )/pm.c 實作特定處理器的電源管理 drivers/power/ 該目錄主要實作設備電源管理的基礎管理框架 為驅動程式提供電源管理介面 其它設備驅動程式皆依賴此框架 在日常生活中我們常聽到的省電就是屬於電源管理的範圍之一,良好的電源管理可以達到節能、延長電池壽命、降低輻射、降溫、延長設備使用壽命等要點。 而所謂的電源管理其實就是實作低功耗。電子產品中的處理器通常都具有多種低功耗狀態,當系統閒置的時候就會依照需求,讓處理器進入低功耗狀態。但單憑處理器是無法實作整個系統的低功耗,需要借助外部設備一起來實作。在硬體提供的低功耗機制基礎上需要作業系統、驅動程式以及上層的應用軟體一起配合來發揮硬體的低功耗潛能,才能完整實作整個系統的低功耗。換句話說整個電源管理其實是個系統工程,從底層的硬體設備開始往上至驅動程式、核心框架、應用程式都要做系統化的考慮,才能實作電源管理的最佳化。

28 2.1.2 Android電源管理(2/3) Android 電源管理機制主要基於Linux Kernel 標準電源管理框架並進行修改
Early suspend ( 早期暫停 ) 讓某些設備進入低功耗狀態 如:LCD 降底亮度或滅掉 Suspend ( 暫停 ) 除電源管理以外的其它模組和CPU 不工作 讓記憶體保持自我更新 ( self – refresh ) Hibernation ( 休眠 ) 將所有記憶體映像寫入磁碟,而後系統關機 重新啟動後恢復至關機之前的狀態

29 2.1.2 Android電源管理(3/3) 主要在Kernel下修改下列檔案: 新增檔案:
include/linux/android_power.h:定義電源管理API drivers/android/power.c:電源管理API 實作 修改檔案: drivers/input/evdev.c :修改Android電源處理方式 fs/inotify_user.c:修改Android電源處理方式 kernel/power/process.c:修改Android電源處理方式

30 2.1.2.1 Android電源管理狀態圖 touch or keyboard user activity event
or full wake lock acquired AWAKE all wake up sources touch or keyboard user activity event timeout or Power key pressed 系統正常開機後進入到AWAKE的狀態,背光會從最低速度亮慢慢調節到使用者設定的亮度,系統螢幕定時關機(設置 - >聲音和顯示>顯示設置 - >螢幕超時時間)開始計時,在計時時間到之前,如果有任何的activity事件發生,如觸摸點擊,按下鍵盤等事件,則將會重置系統關閉螢幕的時間,系統會保持在AWAKE狀態。如果有應用程序,在這段時間內申請了Full wake lock,那麼系統也將保持在清醒狀態,除非使用者按下電源鍵。在醒著的狀態下如果電池電量低或者什麼用交流供電屏幕定時關機時間到:並且選中保持屏幕插頭插入選項,背光時會被強制調節到:暗淡的狀態。 如果屏幕定時關機時間到:並且沒有Full wake lock或者使用者觸動電源鍵,那麼系統狀態將被切換到NOTIFICATION,並且調用所有已經註冊的g_early_suspend_handlers函數,通常會把LCD和背光驅動註冊成early suspend類型,如有需要也可以把別的驅動註冊成early suspend,這樣就會在第一階段被關閉。接下來系統會判斷是否有partial wake lock acquired,如果有則等待其釋放,在等待的過程中如果有使用者activity的事件發生,系統則馬上回到AWAKE狀態,如果沒有partial wake lock acquired,則系統會馬上調用函數pm_suspend關閉其它相關驅動,讓CPU的有限公司進入休眠狀態。 系統在Sleep狀態時如果檢測到:任何一個Wakeup source,則處理器會從休眠狀態被喚醒,並且調用相關驅動的 resume函數,接下來馬上調用前期註冊的early suspend 驅動的resume 函數,最後更新系統狀態回到AWAKE的狀態。 SLEEP NOTIFICATION all partial wake locks released

31 2.1.2.2 Android電源管理架構 PowerManager PowerManager Service
ACTION_SCREEN_ON ActivityManagerService Settings Observer STAY_ON_WHILE_PLUGGED_IN SCREEN_OFF_TIMEOUT ACTION_SCREEN_OFF PhoneWindowManager iBinder PowerManager PowerManager Service Keyguard Update Monitor Android Fromework REBOOT_ACTION ACTION_BATTERY_CHANGED WatchDog Power Shutdown Thread Battery Service Android的電源管理架構是屬於比較簡單的,主要就是透過「鎖」和「定時器」來切換系統狀態,使系統的功耗降到最低,整個系統的電源管理如此架構。 整個架構從下到上分成了,硬體、Linux kernel層的驅動,及最上層的Android fromework與應用程式, 在最上層中間的PowerManager Service與Power是屬於Android Fromework層,PowerManager Service是電源管理的核心,負責處理各應用程式的要求並依要求對實體電源進行控管,而Power則是負責提供接口以JNI的方式與底層Linux驅動進行溝通。REBOOT_ACTION後會啟動WatchDog,在系統死當後重新啟動系統,讓系統回到工作狀態,雖然他無法預防死當但可重新啟動,這項模組是直接透過Power與Linux kernel層的電源驅動溝通,PowerManager模組是透過Android 的IPC機制-Binder來與Power Manager Service溝通,並進行電源的控管,電池服務會依照定時器來進行改變,有改變時會依照改變的狀態來決定是要通知系統進行自動鎖定按鍵及更新畫面狀態,或是告知PowerManager Service進行相對應的動作。 JNI JNI Linux kernel Android_so_Power Com_android_server_BatteryService Hardware Power

32 2.1.3 Low Memory Killer(1/2) 低記憶體管理(Low Memory Killer, LMK)
類似Linux Kernel 中的OOM ( out of memork killer, 記憶體不足 ) 功能 Android 自行設計新的機制實作Linux OOM 功能 提供當記憶體不足時結束處理程序的功能 User Space 設定記憶體臨界值,透過此臨界值來判定是否執行結束行程 OOM功能:當記憶體不夠時,將會試圖選擇一個處理程序並Kill 掉

33 2.1.3 Low Memory Killer(2/2) Lower Memory Killer 機制 主要判斷條件: 主要檔案:
於User Space 指定一組記憶體臨界值 每個處理程序會有一個oom_adj (Out of Memory Adjust )值,當處理程序的oom_adj 值與臨界值在同一範圍時,該處理程序將被Kill 掉 oom_adj 值越小,處理行程的優先順序越高 如:當minfree 小於數值A 時,kill 掉oom_adj 大於數值B的處理程序 主要判斷條件: oom_adj值越大,該處理程序會越優先被Kill 佔用實體記憶體越多的處理程序越優先被Kill 主要檔案: drivers/staging/android/lowmemorykiller.c

34 OOM介紹 重要性,由task_struct->signal_struct->oom_adj决定,Android將行程分成以下幾類,按照重要性依次降低的排序,行程越重要,被kill的可能性越低 名稱 oom_adj 解釋 FOREGROUD_APP 前端行程,可以理解為正在使用的程式 VISIBLE_APP 1 用户可見的行程 SECONDARY_SERVER 2 後端服務,比如会在後臺運行的服務 HOME_APP 4 HOME,就是主頁面 HIDDEN_APP 7 被隐藏的行程 CONTENT_PROVIDER 14 内容的提供者 EMPTY_APP 15  空行程,既不提供服務,也不提供内容

35 2.1.4 Ashmem(1/2) Ashmem(匿名共享記憶體),全名Anonymous Shared Memory
主要是Android 記憶體配置與共享機制 取代傳統Linux記憶體配置機制: malloc、anonymouse/named mmap. 設備節點:/dev/ashmem 原始檔案位置: include/linux/ashmem.h kernel/mm/ashmem.c

36 2.1.4 Ashmem(2/2) 透過Linux Kernel 驅動,提供記憶體回收演算法機制輔助Linux Kernel 進行記憶體回收
記憶體配置流程 開啟 /dev/ashmem 檔案 使用 ioctl 函式設定名稱與大小…等 呼叫 Nmap 將Ashmem 所配置的空間映射至處理行程空間 Ioctl函式全名是input/output control,顧名思義就是用來控制I/O讀寫管理的函式,在進行記憶體配置時透過這個函式來設定所要配置的名稱及大小,而Nmap則是用來偵測目前運行的服務類型、作業系統與設備等,是一種評估網路系統安全的軟體之一 ,在透過ioctl設定好名稱及大小後便透過這個軟體來將要配置的空間映射至處理行程空間內。

37 2.1.5 Android Logger 具有三個設備節點: Android 輕量級的記錄設備,用以取得Android 系統記錄
/dev/log/main :主要 Log /dev/log/event:事件 Log /dev/log/radio:Modem 部份的 Log Android 輕量級的記錄設備,用以取得Android 系統記錄 原始檔案位置 kernel/include/linux/logger.h kernel/driver/misc.logger.c 主要提供User Space 層Log支援 此驅動程式主要作為log 工具使用 Log 驅動程式在User Space封裝為liblog system/core/logcat/ Android User Space 層可透過“logcat ”可執行程式呼叫Logger 驅動程式,取出系統log 資訊 可執行程式:在Linux 上具有”可被執行”的屬性

38 2.1.6 Android Alarm(1/2) 設備節點 為User Space 提供時鐘介面 提供計時器功能,用來將裝置從睡眠狀態中喚醒
/dev/alarm 為User Space 提供時鐘介面 提供計時器功能,用來將裝置從睡眠狀態中喚醒 須使用Linux Kernel 中的RTC (Real Time Clock ) 功能 原始碼檔案位置: drivers/rtc/alarm.c 須使用kernel 中的RTC ,但Android alarm和具體的RTC驅動程式 沒有直接的關係。

39 2.1.6 Android Alarm(2/2) Alarm 主要包含五種類型:
ANDROID_ALARM_RTC_WAKEUP、ANDROID_ALARM_ELAPSED_REALTIME_WAKEUP 觸發時需要喚醒設備 ANDROID_ALARM_RTC 指定時間觸發alarm ANDROID_ALARM_ELAPSED_REALTIME 指設備啟動後經過的時間達到總時間後觸發alarm ANDROID_ALARM_SYSTEMTIME 系統時間 ANDROID_ALARM_TYPE_COUNT Alarm 類型的計數 找資料詳細講五種類型

40 2.1.7 Android PMEM 實體記憶體(Physical Memory, PMEM)驅動程式,用於提供連續的記憶體空間
提供User Space 連續記憶體空間以供特殊設備使用 如: DSP (Digital Signal Processing/Processor 數位信號處理 )、GPU、VPU Android PMEM 主要功能: 讓GPU或VPU 緩衝區共享CPU 核心 用於Android Server Stack System server stack 不會受到標準Linux Kernel 記憶體管理機制的限制,讓DSP、GPU、VPU可順利工作 原始碼檔案位置: drivers/android/pmem.c Include/linux/android_pmem.h DSP晶片只能運作於大塊的連續記憶體區塊上,因此Android 設計 Android PMEM 來處理記憶體空間問題 VPU(Video Processing Unit) Android PMEM驅動程式主要為了實現應用程式與核心層之間共享大塊連續實體記憶體而研發出來的記憶體配置機制

41 2.1.8 ADB Gadget 驅動程式 基於標準Linux USB gadget 驅動程式框架的設備驅動程式
使用此驅動程式,可讓Android 設備作為一個USB設備,提供ADB (Android Debug Bridge) 介面 當Android打開 /dev/android_adb_enable 設備時,即表示可讓Android設備啟動ADB 功能 ADB 功能主要透過讀寫 /dev/android_adb ADB Gadget 包含adb 除錯功能與大量存放區(Mass Storage)功能 普通的Gadget 驅動只實現一個功能,如 usb隨身碟、 usb 網卡…等。但由於智慧型手機或PDA 此種複合式設備就可提供許多複合的功能 每個硬體只能選定一個來做為USB Gadget 功能。 Mass Storage :主要就是讓設備能夠做為儲存設備來使用

42 2.1.9 Android RAM Console Android 提供輔助除錯的核心機制
提供kernel 事件訊息。 透過使用一塊記憶體建構一個虛擬的console 設備 當 Linux Kernel 呼叫 printk 時,除錯資訊將寫入至 RAM Consle 設備中 於User Space 層的介面是/proc 檔案系統 在proc 中的名稱為 lat_kmsg 檔案

43 Android timed driver Android Time Gpio (全名)主要基於 Timed Output 驅動程式框架 對設備提供計時控制功能 如:支援vibrator 和 LED 設備(提供圖片) Timed Output 驅動程式 定時發出一個Output 原始碼檔案位置: drivers/staging/android/timed_gpio.c drivers/staging/android/timed_gpio.h drivers/staging/android/timed_output.c drivers/staging/android/timed_output.h

44 2.1.11 Yaffs2 檔案系統(1/3) 全名:Yet Another Flash File System, 2nd edition
Aleph1(←公司名稱)的工程師開發適合用於NAND Flash 檔案系統 YAFFS2 最小儲存單位可支援到 2K per page,更適合用於大容量的NAND Flash 提供Linux Kernel 高效能存取NAND Flash 介面 原始碼檔案位置: fs/yaffs2/

45 2.1.11 Yaffs2 檔案系統(2/3) Flash Memory 主要分為兩種:
NOR Flash Memory 與 NAND Flash Memory NAND Flash Memory 具有較快的Erase Time、Small Size 及成本低廉的優勢,更適合用於Embedded System 一般的Block Device 上所使用的檔案系統須透過 FTL (Flash Translation Layer) 轉換後才可用於Flash 的操作 如:NTFS、FAT32、ext2、ext3…等 專用於Flash 的檔案系統無須經過FTL轉換 如:JFFS(Journaling Flash File System)、JFFS2、Yaffs、Yaffs2 NOR Flash Memory 與 NAND Flash Memory

46 2.1.11 Yaffs2 檔案系統(3/3) 使用者程式 ( User Process )
虛擬檔案系統(Virtual Filesystem Switch, VFS ) FAT32 NTFS EXT2 JFFS YAFFS2 FTL ( Flash Translation Layer ) Flash Memory ( NOR Flash, NAND Flash )

47 練習 Android作業系統中的IPC功用為何?與其相同功能的RPC又有何差別?
1. 行程間通訊,Inter-Process Communication縮寫是IPC,他是作業系統中為了讓兩個以上的行程或執行緒可以相互溝通、使用資源的一種技術,但IPC這項技術並非只有Android作業系統才擁有,事實上在還沒有Android作業系統之前我們一般常用的Windows及Linux作業系統均有此機制。採用IPC將會有幾項優點:資訊共享、提昇運行速度、分離私有權、模組化。而詳細的解說將在後續單元七「IPC」將有更完整的介紹,在此先知道此機制的作用即可。IPC與RPC最大的差別在於,IPC是讓同一部電腦中的行程或執行緒進行溝通傳輸資料,而RPC則是讓不同電腦中不同平台內的行程或執行緒進行溝通傳輸的協定。 2. Early suspend( 早期暫停 ),讓某些設備進入低功耗狀態,如:LCD 降底亮度或滅掉;Suspend( 暫停 ),除電源管理以外的其它模組和CPU 不工作,讓記憶體保持自我更新 ( self – refresh );Hibernation ( 休眠 ),將所有記憶體映像寫入磁碟,而後系統關機,重新啟動後恢復至關機之前的狀態。 3.

48 Chapter 3 Android使用的裝置驅動程式
3.1 Framebuffer 顯示驅動 3.2 Event 輸入裝置驅動 3.3 V4L2相機-視訊驅動 3.4 音訊驅動程式 3.5 MTD驅動 3.6 藍牙驅動 3.7 WLAN驅動

49 3.1 Framebuffer 顯示驅動(1/3) Linux 抽象出Framebuffer 供使用者模式中的處理行程實作直接寫入螢幕
將螢幕LCD(矩陣) 嵌入式系統中 的SoC (System on Chip )處理器,Framebuffer 通常作為LCD 控制器(如果找不到好的解釋就砍掉) Android 的Framebuffer 設備節點位置 /dev/graphics/ 目錄底下 Android 採用 Double Framebuffer 在記憶體中分配二倍LCD大小的畫面 用於畫面的滑動、pre-draw 機制…等效能上的考量

50 3.1 Framebuffer 顯示驅動(2/3) 工作原理: Framebuffer 將顯示卡硬體結構抽象為一組資料結構
使用者不必關注實體顯示記憶體的位置、換頁機制…等細節,便於使用者的開發 每個系統可擁有多個顯示設備 如:/dev/fb0、 /dev/fb1 …等。 Buf0 Buf1圖層解說,舉MHP例子來講解

51 3.1 Framebuffer 顯示驅動(3/3) 檔案操作介面 字元設備驅動程式 ( /dev/fbX )
透過 ioctl 和 mmap 進行操作 字元設備驅動程式 ( /dev/fbX ) 呼叫Framebuffer驅動程式 Framebuffer 驅動程式(fbmem.c) 呼叫Framebuffer 具體實作 下2是 .h檔 是一些介面方法 下3 是.c檔 去把下2的東西實作出來 具體的Framebuffer 驅動程式 (struct fb_info) 對硬體設備進行實際操作 硬體設備

52 3.2 Event 輸入裝置驅動(1/5) Linux 事件輸入驅動程式都整合於Input 子系統中
如:按鍵、觸控螢幕、鍵盤,滑鼠 Android Input 設備驅動程式主要包含: 搖桿 ( Joystick ) 滑鼠 ( Mouse ) 事件設備 ( Event ) Android 的虛擬鍵盤也是經由Event 機制進行實作

53 3.2 Event 輸入裝置驅動(2/5) Input 系統主要由三個部分組成:
輸入子系統核心層 ( Input Core ) 驅動程式層 ( Drivers ) 事件處理層 ( Event Handler ) Input 系統透過分層方式將輸入設備的輸入過程獨立成兩部分: 驅動程式→輸入子系統核心層 輸入子系統核心層 → 事件處理層 事件的觸發流程: 三個組成部分由下頁圖講解 Device InputCore Event Handler Userspace

54 3.2 Event 輸入裝置驅動(3/5) 事件處理層 ( Event Hanlder ) 驅動程式層 Keyboard Handler
輸入子系統 核心層 ( Input Core ) Keyboard Handler 主控台 子系統 USB Mouse Handler 使用者空間 (/dev/input/mouseX ) ( /dev/input/mice )) PS/2 每個驅動所發出的事件,都有相對應的Handler 進行處理 當USB有事件發生後,就會向核心層發送訊息要求處理,然後核心層便會依照訊息內容到事件處理層找相對應的Hander進行處理,之後反映製硬體或其他系統上。 每項附上詳解 Joystick Handler 使用者空間 ( /dev/input/jsX) Serial Event Handler 使用者空間 (/dev/input/eventX)

55 3.2 Event 輸入裝置驅動(4/5) Input 驅動程式為字元設備,主設備編號13 Input 驅動程式主要檔案
滑鼠驅動:/dev/input/mouseX 搖桿驅動:/dev/input/jsX Input 驅動程式主要檔案 kernel/include/linux/input.h : Input driver head file kernel/drivers/input/input.c : Input driver core file kernel/drivers/input/event.c : Event 機制 kernel/drivers/input/joydev.c : joyststick driver kernel/drivers/input/mousedev.c : mouse driver Event 設備於檔案系統中的設備節點 /dev/input/eventX 各個具體設備則位於misc、touchscreen、keyboard 目錄中 Major nomber minor number 附上解說

56 字元設備驅動程式 ( /dev/input/ )
3.2 Event 輸入裝置驅動(5/5) 檔案操作介面 字元設備驅動程式 ( /dev/input/ ) 向系統輸入事件 Input 核心驅動程式 ( input.c ) 滑鼠 搖桿 Event 對應匹配的Handler 具體的Event 驅動程式 硬體設備

57 3.3 V4L2相機 – 視訊驅動(1/3) 全名:Video For Linux Two Linux 下的視訊擷取設備驅動程式
提供統一介面的API 管理Linux 下所有視訊擷取設備,方便使用者開發 由於VFL 在支援上有些許不足,重新開發而成V4L2 不相容於 V4L V4L2 成為Linux 2.6標準介面 包含:Video , DVB (Digital Video Broadcasting), FM

58 3.3 V4L2相機 – 視訊驅動(2/3) 主要介面: 視訊捕捉介面 從硬體設備 ( 如:攝影機、電視調諧器 )捕捉視訊資料並輸入到軟體
視訊輸出介面 將應用程式的視訊資料透過設備進行輸出 如:輸出電視訊號到電視機 視訊Overlay 介面 透過使用硬體將視訊資料直接輸出到顯示設備上,視訊資料完全不經過CPU 處理 VBI (vertical blank interval )介面 利用視訊影像畫面之間的時段 ( time slot ) 來發送圖文資料 收音介面 提供接收收音機音訊資料的介面 vertical blanking interval (VBI) :我們通常收看的電視圖像是由電子槍發射的電子串高速轟擊顯像管上的螢光物質而產生的,電子串按從左至右,從上至下的方式掃描整個螢幕,因為速度十分快,所以我們的眼睛感覺不到,當電子槍的掃描位置從左上角達到右下角時,必須由右下角回到左上角,開始下一次掃描,從右下角回到左上角所花費的時間就是垂直回掃期,這一段時間對於設備來說是一個浪費,因此人們想了辦法來利用這一段時間,電視臺可以利用這一時間發送一些不可顯示資訊,如果您使用過電傳視訊您就會立刻明白,為什麼電傳視訊卡要接收電視信號,電視卡可以解讀這一資訊,而電視不能,這種資訊就是利用垂直回掃期發送的,電視卡通過RS-232埠將接收到的不可顯示資訊傳送給電腦,由電腦加以處理,這就是電傳視訊的原理,也就是說,電視臺利用垂直回掃期發送一些不可顯示的資訊,而電傳視訊卡將這種資訊接收下來,經過解碼發送到電腦內由電腦處理。 這種資訊傳送稱為VBI資訊傳送,對於這種資訊的傳送的一個開放的國際標準,稱為北美基本圖文說明(North American Basic Teletext Specification,NABTS),它用於歐洲,南美和遠東地區,其他的標準還有WST,Gemstar和Nielsen。

59 字元設備驅動程式 ( /dev/video)
3.3 V4L2相機 – 視訊驅動(3/3) 檔案操作介面 ( ioctl/ mmap … ) 字元設備驅動程式 ( /dev/video) V4L2驅動程式 具體的V4L2 驅動程式 硬體設備

60 3.4 音訊驅動程式 Linux 音訊驅動程式技術主要有兩種: 主要提供多數音效卡統一的程式設計介面
OSS ( Open Sound System ) ALSA ( Advanced Linux Sound Architecture ) 主要提供多數音效卡統一的程式設計介面 Linux 上最早出現的音效卡驅動程式 Linux Kernel 模組中,一部分由Linux Kernel Souce 免費發佈,另一部份由4Front Technologies 公司提供二進位 ( Binary ) 檔案 完全開放原始碼的驅動程式 由志願者維護的自由專案 特點: 支援多種音效卡設備 模組化的Linux Kernel 驅動程式 支援SMP(Symmetric Multi-Processor)和 Multi-thread 提供應用程式開發程式庫 相容OSS 應用程式

61 3.4.1 OSS音訊驅動(1/2) OSS主要包含下列設備檔案: /dev/sndstat 唯讀檔案,主要作用限於回報音效卡目前狀態
/dev/dsp Digital Signal Processor, DSP,數位訊號處理器 用於數位取樣(sampling)和數位錄音(recording)的設備檔 向該設備進行寫入資料即代表啟動D/A轉換進行聲音播放 向該設備進行讀取資料即代表啟動A/D轉換進行聲音錄製 /dev/audio 與/dev/dsp 類似,主要用以相容於SunOS的音效設備 /dev/mixer 混音器,主要作用是將多個訊號組合或疊加,用於控制音量大小 混音器電路通常由輸入混音器(input mixer)與輸出混音器(output mixer)組合而成 /dev/sequencer 主要提供MIDI匯流排上的樂器進行控制

62 3.4.1 OSS音訊驅動(2/2) 檔案操作介面 ( ioctl / read, write )
字元設備驅動程式(/dev/dsp … ) OSS驅動程式 ( sound_core.c ) 具體的OSS驅動程式 音訊設備

63 3.4.2 ALSA音訊驅動(1/2) ALSA系統主要由7個子項目所組成: ALSA核心提供 User Space 層的介面如下:
驅動程式套件:alsa-driver 開發套件:alsa-libs 開發套件外掛:alsa-libplugins 設定管理工具套件: alsa-utils 聲音相關處理工具套件:alsa-tools 特殊音訊韌體支援套件:alsa-firmware OSS介面相容模擬層工具:alsa-oss ALSA核心提供 User Space 層的介面如下: 資訊介面( information Interface) :/dev/asound 控制介面(Control Interface):/dev/snd/control1CX 混音器介面(Mixer Interface):/dev/snd/mixerCXDX PCM 介面(PCM Interface):/dev/snd/pcmCXDX Raw MIDI 介面(Raw MIDI Interface):/dev/snd/midiCXDX 合成器介面(Sequencer Interface):/dev/snd/seq 計時器介面(Timer Interface):/dev/snd/timer Pulse Code Modulation, PCM

64 3.4.2 ALSA音訊驅動(2/2) ALSA 工具 ALSA 程式庫 檔案操作介面 ( ioctl / write, read )
字元設備驅動程式 ALSA核心驅動程式(控制設備、資料設備) 具體的ALSA 驅動程式 硬體設備 ALSA 程式庫 ALSA 工具

65 3.5 MTD驅動(1/4) 記憶體技術設備(Memory Technology Device, MTD)
Linux 專為嵌入式環境所開發的新型驅動程式,基於快閃記憶體(Flash )設備 具有更好的支援、管理與基於磁區的Erase 、Read和Write 操作介面 Linux 下採用的檔案系統控制階層: 記憶體檔案控制區塊:JFFS、JFFS2、Block device、Character device MTD晶片驅動程式:對Flash 晶片進行存取控制 控制階層:記憶體檔案控制區塊:如針對flash ,採用jffs2 檔案系統。底層驅動程式主要完成檔案系統對 Flash 晶片的存取控制:如讀取、寫入、擦除的操作 虛擬檔案系統 ( VFS ) 記憶體檔案控制區塊 MTD 晶片驅動程式 硬體設備

66 3.5 MTD驅動(2/4) MTD 驅動程式介面分為兩種模組 使用者模組:提供User Space 直接使用的介面 原始字元存取
原始區塊存取 FTL ( Flash Transition Layer) ,快閃記憶體階層轉換 JFS ( Journaled File System ),日誌式檔案系統 硬體模組: 提供記憶體設備的實體存取 不直接使用,而是透過使用者模組來存取 提供讀取(Read)、寫入(Write)、擦除(Erase)的操作 JFS:日誌式檔案系統,在flash 上直接提供檔案系統而不是模擬區塊設備

67 3.5 MTD驅動(3/4) MTD驅動程式架構: 包含字元設備 ( MTD_CHAR)和區塊設備(MTD_BLOCK) MTD_CHAR:
提供Flash 的原始字元存取 檔案設備節點:/dev/mtd0、/dev/mtd1 …等 MTD_BLOCK: 將Flash 設計為可在上面建立檔案系統的一般區塊設備(如IDE磁碟) 檔案設備節點:/dev/mtdblock0、/dev/mtdblock1…等 原始檔案程式: kernel/include/linux/mtd/mtd.h kernel/driver/mtd/mtdcore.c kernel/driver/mtd/mtdchar.c kernel/driver/mtd/mtdblock.c

68 3.5 MTD驅動(4/4) MTD 字元設備操作 MTD 區塊設備操作 檔案系統 MTD 字元設備
MTD 區塊設備 ( mtdblock.c ) MTD 原始設備 ( mtdcore.c ) Flash 驅動程式 硬體設備

69 3.6 藍牙驅動(1/3) Android 藍牙協定使用BlueZ實作GAP、SDP、RFCOMM規範的支援,並獲得SIG認證
Android Framework 使用D-Bus IPC 與BlueZ的User Space 程式進行互動以避免GPL授權 BlueZ的底層協定實作在Kernel 程式碼中,不屬於User Space D-BUS: 可視為在 Kernel 層以上的一種軟體BUS,設計的目的在於讓各種軟體可以彼此溝通 除 User mode applications 可以相互溝通外,Kernel 也可以透過 Kernel Event Layer 來存取 D-Bus 間接與 Application 來溝通 為三種架構的行程間通訊(IPC)系統: 函式庫libdbus: 提供給各個應用程式叫用,使應用程式間具有通信與資料交換能力 基於libdbus 的 Bus Daemon : 管理多個應用程式間的通訊,每個應用程式都與 Bus Daemon 連接,並由Bus Daemon 管理訊息的分派 基於特定應用程式框架的Wrapper庫: 包含.ibdbus-glib,libdbus-qt…等。 SIG: 藍牙技術聯盟(Bluetooth SIG)認證 D-BUS 是一種 'message bus',未來將取代傳統 IPC 的使用 D-BUS是一個設計標的為應用程式間通訊的訊息匯流排系統。它是個3層架構的行程間通訊(IPC)系統,包括: 函式庫libdbus,用於兩個應用程式呼叫聯繫和互動訊息。 一個基於libdbus構造的訊息,匯流排守護行程可同時與多個應用程式相連,並能把來自一個應用程式的訊息路由到0或者多個其他程式。 一系列基於特定應用程式框架的Wrapper庫。

70 3.6 藍牙驅動(2/3) Android d Headset 、Handsfree … 等Profile 的實作位於 Java Framework 中,並透過JNI 操作這些socket 底層協定: HCI ( Host Control Interface): 主機控制介面,可完成與藍牙硬體的互動 SDP( Service Discovery Protocol):服務搜尋協定,可存取其它服務的基礎協定 RFCOMM:類似於port 的通訊協定,為上層服務的實作提供簡單且方便移植的傳輸介面 L2CAP:邏輯鏈路控制與調協協定,是RFCOMM、SDP 協定的基礎 SCO:同步資料交換協定,為語音等需要同步資料傳輸的服務提供支援,而不須經過HCI

71 3.6 藍牙驅動(3/3) Headset/Handsfree 藍牙Setting APP 電話相關 Application
Linux Kernel Libraries (User Space ) Application Framework 藍牙驅動 藍牙協定層 BlueZ (GPL) BlueZ配接層 藍牙Setting APP Headset/Handsfree 電話相關 Android.bluetooth套件 D-BUS Sco, Rfcomm Socket HCI SIG認為藍牙裝置有4個最基本的Profile: General Access Profile(GAP) Service Discovery Application Profile(SDAP) Serial Port Profile(SPP) General Object Exchange Profile(GOEP) RFCOMM ,提供Bluetooth 上的序列模擬,使序列應用程式( 如:minicom ) 和協定( 如p2p 協定) 可以不加更改地在Bluetooth 上執行

72 3.7 WLAN驅動(1/2) Android Wifi 系統(由下而上) 包含以下內容: Wpa_supplicant
Linux Kernrel 的標準WiFi 驅動程式和協定 Wpa_supplicant 可執行程式 ( WPA 應用程式證認Client ) WiFi HAL ( wpa_supplicant 配接層 ) WiFi JNI 介面 WiFi Java Framework WiFi 相關的應用程式 Wpa_supplicant wpa_supplicant 是WPA 應用程式認證Client 端,負責完成認證的相關登錄、加密工作 wpa_suplicant 為一開放原始碼專案,可被移植至許多嵌入式系統上 專案原始碼在Android 中的目錄:external/wpa_supplicant 編譯後主要產生動態函式庫 libwpa_client.so 與 wpa_supplicant 可執行程式

73 Setting、WifiSwitcher 應用程式
3.7 WLAN驅動(2/2) Linux Kernel Libraries (User Space ) Application Framework Android WiFI 套件 WiFi JNI WPA 配接層 WiFi Kernel 驅動程式 Setting、WifiSwitcher 應用程式 wpa_supplicant

74 練習 Android作業系統的裝置驅動程式主要有哪七個? Android作業系統中的音訊驅動程式可分為哪兩種?
Android作業系統中的Event 輸入裝置驅動的Input是由哪三個部份組成?而其輸入過程又為何? 1. Android作業系統中主要的裝置驅動程式可分為:Framebuffer 顯示驅動、Event 輸入裝置驅動、V4L2相機-視訊驅動、音訊驅動程式、MTD驅動、藍牙驅動、WLAN驅動。 2. Android作業系統中的音訊驅動程式可分為OSS ( Open Sound System )及ALSA ( Advanced Linux Sound Architecture )這兩種, 3. Event輸入裝置驅動是由:輸入子系統核心層 ( Input Core )、驅動程式層 ( Drivers )及事件處理層 ( Event Handler )三個部份所組成,而其輸入過程可分為兩個階段:Input 系統透過分層方式將輸入設備的輸入過程獨立成兩部分:第一個階段是,驅動程式→輸入子系統核心層、第二個階段是,輸入子系統核心層 → 事件處理層。

75 Reference 楊豐盛,Android技術內幕-探索Android 原核原理與系統開發,初版,臺北市:碁峰資訊,2011.10


Download ppt "Android Linux Kernel."

Similar presentations


Ads by Google