1、PackageManagerService 文件瀏覽器雙擊adb install/push *.apk APK installationshell installAndroid market packageinstaller.apk SD卡安裝building in system img一 、APK安裝方式 .PackageManagerServicescanPackageLI()二、PackageManagerService啟動過程 PackageManagerService.main()PackageManagerService m = new PackageManagerService(

2、);ServiceManager.addService(package, m);解析/system/etc/permissions/下的xml文件建立PackageHandler消息循環(huán)對jar進行dexopt優(yōu)化啟動AppDirObserver監(jiān)測幾個目錄的add/removed事件ScanDirLI對幾個目錄下的apk逐個解析建立installer與installd的socket聯(lián)接解析/data/system/packages.xml文件二、PackageManagerService綜述包管理服務是在系統(tǒng)啟動階段由systemserver啟動的一個java層服務，用來管理/system/

3、framework，/system/app，/data/app，/data/app-private目錄下的apk文件，所做的工作主要是：1.建立java層的installer與c層的installd的socket聯(lián)接，使得在上層的install,remove,dexopt等功能最終由installd在底層實現(xiàn)2.建立PackageHandler消息循環(huán)，用于處理外部的apk安裝請求消息，如adb install,packageinstaller安裝apk時會發(fā)送消息3.解析/system/etc/permission下xml文件(framework/base/data/etc/)，包括plat

4、form.xml和系統(tǒng)支持的各種硬件模塊的feature.主要工作：(1)建立底層user ids和group ids 同上層permissions之間的映射；可以指定一個權限與幾個組ID對應。當一個APK被授予這個權限時，它也同時屬于這幾個組。(2)給一些底層用戶分配權限，如給shell授予各種permission權限；把一個權限賦予一個UID，當進程使用這個UID運行時，就具備了這個權限。(3) library,系統(tǒng)增加的一些應用需要link的擴展jar庫；(4) feature,系統(tǒng)每增加一個硬件，都要添加相應的feature.將解析結果放入mSystemPermissions,mSha

5、redLibraries,mSettings.mPermissions,mAvailableFeatures等幾個集合中供系統(tǒng)查詢和權限配置使用。 4.檢查/data/system/packages.xml是否存在，這個文件是在解析apk時由writeLP()創(chuàng)建的，里面記錄了系統(tǒng)的permissions，以及每個apk的name,codePath,flags,ts,version,uesrid等信息，這些信息主要通過apk的AndroidManifest.xml解析獲取，解析完apk后將更新信息寫入這個文件并保存到flash，下次開機直接從里面讀取相關信息添加到內存相關列表中。當有apk升級

6、，安裝或刪除時會更新這個文件。5.檢查BootClassPath，mSharedLibraries及/system/framework下的jar是否需要dexopt，需要的則通過dexopt進行優(yōu)化6.啟動AppDirObserver線程監(jiān)測/system/framework,/system/app,/data/app,/data/app-private目錄的事件,主要監(jiān)聽add和remove事件。對于目錄監(jiān)聽底層通過inotify機制實現(xiàn)，inotify 是一種文件系統(tǒng)的變化通知機制，如文件增加、刪除等事件可以立刻讓用戶態(tài)得知,它為用戶態(tài)監(jiān)視文件系統(tǒng)的變化提供了強大的支持。當有add eve

7、nt時調用scanPackageLI(File , int , int)處理；當有remove event時調用removePackageLI()處理;7.對于以上幾個目錄下的apk逐個解析，主要是解析每個apk的AndroidMa-nifest.xml文件，處理asset/res等資源文件，建立起每個apk的配置結構信息，并將每個apk的配置信息添加到全局列表進行管理。調用installer.install()進行安裝工作,檢查apk里的dex文件是否需要再優(yōu)化,如果需要優(yōu)化則通過輔助工具dexopt進行優(yōu)化處理；將解析出的componet添加到pkg的對應列表里；對apk進行簽名和證書校驗

8、,進行完整性驗證。8.將解析的每個apk的信息保存到packages.xml和packages.list文件里，packages.list記錄了如下數(shù)據(jù)：pkgName，userId，debugFlag，dataPath（包的數(shù)據(jù)路徑）三、主要功能的詳細分析1.installer VS installdPackageManagerServicecallinstaller classmethodsinit.rc launchInstalld daemon functionsstruct cmdinfo cmds = install, 3, do_install , dexopt, 3, do_d

9、exopt , movedex, 2, do_move_dex , rmdex, 1, do_rm_dex , rename, 2, do_rename , freecache,1, do_free_cache , movefiles, 0, do_movefiles , .;installdexoptmovedexrmdexrenamefreecachemovefiles .installdexoptmovedexrmdexrenamefreecachemovefiles .Commands.cSocketconnectSocketcommand層層2.dalvik vm & dex

10、opt2.1 dalvik vm主要特征主要特征專有的專有的dex文件文件一個應用中會定義很多類，編譯完成后即會有很多相應的CLASS文件，CLASS文件間會有不少冗余的信息；而 DEX 文件格式會把所有的 CLASS 文件內容整合到一個文件中。這樣，除了減少整體的文件尺寸，I/O操作，也提高了類的查找速度。 原來每個類文件中的常量池，在DEX 文件中由一個常量池來管理。 Jar to Dex Conversion一個應用，一個進程，一個虛擬機實例一個應用，一個進程，一個虛擬機實例每一個Android應用都運行在一個 Dalvik虛擬機實例里，而每一個虛擬機實例都是一個獨立的進程空間。虛擬機的

11、線程機制，內存分配和管理，Mutex等等都是依賴底層操作系統(tǒng)實現(xiàn)的。所有 Android 應用的線程都對應一個 Linux 線程，虛擬機因而可以更多的依賴操作系統(tǒng)的線程調度和管理機制。不同的應用在不同的進程空間里運行，加之對不同來源的應用都使用不同的Linux用戶來運行，可以最大程度的保護應用的安全和獨立運行。 基于寄存器基于寄存器相對于基于堆棧的虛擬機實現(xiàn)，基于寄存器的虛擬機實現(xiàn)雖然在硬件通用性上要差一些，但是它在代碼的執(zhí)行效率上卻更勝一籌。在基于寄存器的虛擬機里，可以更為有效的減少冗余指令的分發(fā)和減少內存的讀寫訪問。 2.2 dexopt如果我們想要求運行時的性能有進一步提高，就仍然需要對

12、DEX文件進行進一步優(yōu)化。優(yōu)化DEX會產生一個可以快速載入執(zhí)行的classes.dex文件，會進行包括byte-swapping,structure realigning與basic structure checks,更新ODEX header ,為了確保產生ODEX流程的正確性,Android提供了一個dexopt工具,用來做為虛擬機的輔助工具,可以在系統(tǒng)啟動時,透過Dalvik虛擬機對載入的DEX文件執(zhí)行佳化操作。 優(yōu)化發(fā)生的時機有兩個： 對于預置應用，可以在系統(tǒng)編譯后，生成優(yōu)化文件，以ODEX 結尾。這樣在發(fā)布時除APK 文件（不包含 DEX）以外，還有一個相應的 ODEX 文件； 對于

13、非預置應用，包含在 APK 文件里的 DEX 文件會在運行時通過dexopt進行優(yōu)化，優(yōu)化后的文件將被保存在緩存中(data/dalvik-cache)。 ODEX文件結構圖3. permissions & security3.1 android安全機制概述 Android是一個權限分離的系統(tǒng) ，這是利用Linux已有的權限管理機制，通過為每一個Application分配不同的uid和gid, 從而使得不同的Application之間的私有數(shù)據(jù)和訪問(native以及java層通過這種sandbox機制)達到隔離的目的 。與此同時,Android還在此基礎上進行擴展，提供了permis

14、sion機制，它主要是用來對Application可以執(zhí)行的某些具體操作進行權限細分和訪問控制，同時提供了per-URI permission機制，用來提供對某些特定的數(shù)據(jù)塊進行訪問。 Application 級別通過user ID和group Id實現(xiàn)安全控制；component級別通過permission來限制對于某一組件的訪問；在data級別通過基于permission的per URI進行安全控制。 3.2 uid gid gids Android 的權限分離的基礎是建立在 Linux 已有的 uid 、 gid 、 gids 基礎上的 。UID :Android 在 安裝一個應用程序，

15、就會為 它 分配一個 uid 。其中普通 Android 應用程序的 uid 是從 10000 開始分配 （Process.FIRST_APPLICATION_UID ）， 10000 以下是系統(tǒng)進程的 uid 。GID :對 于普通應用程序來說， gid 等于 uid 。由于每個應用程序的 uid 和 gid 都不相同， 因此不管是 native 層還是 java 層都能夠達到保護私有數(shù)據(jù)的作用 。GIDS : gids 是由框架在 Application 安裝過程中生成，與 Application 申請的具體權限相關。 如果 Application 申請的相應的 permission 被

16、granted ，而且中有對應的 gids ， 那么這個Application 的 gids 中將包含這個gids 。3.3 permission 一個權限主要包含三個方面的信息：權限的名稱；屬于的權限組；保護級別。一個權限組是指把權限按照功能分成的不同的集合。每一個權限組包含若干具體權限，例如在COST_MONEY組中包含 android.permission.SEND_SMS ,android.permission.CALL_PHONE 等和費用相關的權限。 每個權限通過protectionLevel來標識保護級別:normal,dangerous,signature,signatureo

17、rsystem.不同的保護級別代表了程序要使用此權限時的認證方式。 的權限只要申請了就可以使用；的權限在安裝時需要用戶確認才可以使用； 當請求某個權限的應用與已經申請了這個權限的應用具有相同的證書簽名，系統(tǒng)就會授予其相應的權限.只有在系統(tǒng)鏡像里或具有相同證書簽名的packages才會被授予的權限 Package的權限信息主要通過在AndroidManifest.xml中通過一些標簽來指定。如 標簽， 標簽 等標簽。如果 package 需要申請使用某個權限，那么需要使用 標簽來指定。3.4 共享UID和簽名 安裝在設備中的每一個Android包文件都會被分配到一個屬于自己的統(tǒng)一的Linux用戶

18、ID，并且為它創(chuàng)建一個沙箱，以防止影響其他應用程序。不同user id 的應用之間數(shù)據(jù)是不能訪問的；platform.xml中的shared-user標簽代表共享UID，通過Shared User id，擁有同一個User id的多個APK可以配置成運行在同一個進程中，具有共享UID的不同應用直接可以數(shù)據(jù)互訪。一般把共同實現(xiàn)一系列相似功能的apk配置成共享UID。 對于一個apk來說，要實現(xiàn)共享uid必須做如下幾步： 1.在AndroidManifest.xml中增加android:sharedUserId屬性 2.在Android.mk中增加LOCAL_CERTIFICATE定義android:sharedUserIdLOCAL_CERTIFICATEandroid.uid.systemplatformandroid.uid.sharedsharedandroid.mediamediaandroid.uid.log？android.uid.phoneplatformandroid:shareUserId與LOCAL_CERTIFICATE對應關系兩者的關系如果沒有正確對應，在apk安裝時會報錯，提示證書不連續(xù)：Failure INSTALL_PARSE_FAILED_INCONSISTENT_CERTIFI