文章轉自：http://piziyuyu.blog.163.com/blog/static/96323832201110144851181/

下面各個步驟都已經分析清楚，加步驟的話就在每個階段的開始和接受加上廣播的推送即可。

APK是Android Package的縮寫，即Android安裝包。APK是類似Symbian Sis或Sisx的檔案格式。通過將APK檔案直接傳到Android模擬器或Android手機中執行即可安裝。

一、Android應用安裝有如下四種方式

1.系統應用安裝――開機時完成，沒有安裝介面

2.網路下載應用安裝――通過market應用完成，沒有安裝介面

3.ADB工具安裝――沒有安裝介面。

4.第三方應用安裝――通過SD卡里的APK檔案安裝，有安裝介面

二、應用安裝的流程及路徑
應用安裝涉及到如下幾個目錄：

system/app 系統自帶的應用程式，無法刪除
data/app 使用者程式安裝的目錄，有刪除許可權。安裝時把apk檔案複製到此目錄
data/data 存放應用程式的資料
data/dalvik-cache 將apk中的dex檔案安裝到dalvik-cache目錄下(dex檔案是dalvik虛擬機器的可執行檔案,其大小約為原始apk檔案大小的四分之一)

在這個文件中主要介紹的是第三方應用安裝的完整過程

—安裝SD卡里的APK檔案。

呼叫安裝介面完成安裝

pm.installPackage(mPackageURI,observer, installFlags);

看到這裡，我有一個疑問:

PackageManager.java中的installPackage的原型如下：

public abstract void installPackage(

Uri packageURI, IPackageInstallObserver observer, int flags,

String installerPackageName);

然後看到所有Packageanager.java裡面的方法基本都是抽象的，經過不斷尋找，終於在檔案

ContextImpl.java（/framework/bash/core/java/android/app/ContextImpl.java）中找到了實現的位置首先通過getPackageManager()獲取到包管理器的控制代碼，然後再呼叫它裡邊的installPackage進行安裝。

public PackageManager getPackageManager() {

if (mPackageManager != null) {

return mPackageManager;

}

IPackageManager pm = ActivityThread.getPackageManager();

if (pm != null) {

// Doesn't matter if we make more than one instance.

return (mPackageManager=newApplicationPackageManager(this,pm));

}

return null;

}

ApplicationPackageManager繼承了PackageManager，該類實現了所有的抽象方法

public void installPackage(Uri packageURI, IPackageInstallObserver observer, int flags,

String installerPackageName) {

try {

mPM.installPackage(packageURI,observer,flags,installerPackageName);

} catch (RemoteException e) {

// Should never happen!

}

}

這樣就呼叫了PackageManagerService.java（/framework/base/services/java/com/android/server/PackageManagerService.java）中的installPackage裡面。

public void installPackage(

final Uri packageURI, final IPackageInstallObserver observer, final int flags,

final String installerPackageName) {

mContext.enforceCallingOrSelfPermission(

android.Manifest.permission.INSTALL_PACKAGES, null);

Message msg = mHandler.obtainMessage(INIT_COPY);

msg.obj = new InstallParams(packageURI, observer, flags,

installerPackageName);

mHandler.sendMessage(msg);

}

通過sendMessage將訊息傳送給PackageHandler中的handleMessage(Message msg)接收。

if (!mBound) {

// If this is the only one pending we might

// have to bind to the service again.

if (!connectToService()) {

Slog.e(TAG, "Failed to bind to media container service");

params.serviceError();

return;

} else {

// Once we bind to the service, the first

// pending request will be processed.

mPendingInstalls.add(idx,params);

}

} else {

mPendingInstalls.add(idx,params);

// Already bound to the service. Just make

// sure we trigger off processing the first request.

if (idx == 0) {

mHandler.sendEmptyMessage(MCS_BOUND);

}

}

分析INIT_COPY裡面的邏輯程式碼，可以知道首先檢查是否已經和IMediaContainerService服務繫結，如果沒有則與該服務嘗試連線，負責將接收到的安裝包新增到mPendingInstalls變數裡邊，但是mPendingInstalls這裡邊的請求在什麼時候被處理掉的呢？

public void onServiceConnected(ComponentName name, IBinder service) {

if (DEBUG_SD_INSTALL) Log.i(TAG, "onServiceConnected");

IMediaContainerService imcs =

IMediaContainerService.Stub.asInterface(service);

mHandler.sendMessage(mHandler.obtainMessage(MCS_BOUND,imcs));

}

原來在第一次繫結該服務成功後就傳送了MCS_BOUND訊息，呼叫到HandlerParams的startCopy方法準備安裝

else if (mPendingInstalls.size() > 0) {

HandlerParams params = mPendingInstalls.get(0);

if (params != null) {

params.startCopy();

}

}

接下來在該方法中呼叫mHandler.sendEmptyMessage(MCS_UNBIND)，PackageHandler接收到MSC_UNBIND 訊息以後會進入以下邏輯塊

if (mPendingInstalls.size() == 0) {

if (mBound) {

disconnectService();

}

} else {

// There are more pending requests in queue.

// Just post MCS_BOUND message to trigger processing

// of next pending install.

mHandler.sendEmptyMessage(MCS_BOUND);

}

如果mPendingInstalls還有未處理的請求繼續重複上述步驟，否則斷開與IMediaContainerService建立的服務。

抽象類HandlerParams中實現了方法startCopy()，而handleStartCopy()和handleReturnCode()兩個方法的實現則是在HandlerParams的子類InstallParams裡邊。

final void startCopy() {

try {

if (DEBUG_SD_INSTALL) Log.i(TAG, "startCopy");

retry++;

if (retry > MAX_RETRIES) {

Slog.w(TAG, "Failed to invoke remote methods on default container service. Giving up");

mHandler.sendEmptyMessage(MCS_GIVE_UP);

handleServiceError();

return;

} else {

handleStartCopy();

if (DEBUG_SD_INSTALL) Log.i(TAG, "Posting install MCS_UNBIND");

mHandler.sendEmptyMessage(MCS_UNBIND);

}

} catch (RemoteException e) {

if (DEBUG_SD_INSTALL) Log.i(TAG, "Posting install MCS_RECONNECT");

mHandler.sendEmptyMessage(MCS_RECONNECT);

}

handleReturnCode();

}

在InstallParams裡邊handleStartCopy()主要實現的功能是獲取安裝位置資訊以及複製apk到指定位置。

if (ret == PackageManager.INSTALL_SUCCEEDED) {

// Create copy only if we are not in an erroneous state.

// Remote call to initiate copy using temporary file

ret=mArgs.copyApk(mContainerService,true);

}

抽象類InstallArgs中的copyApk負責複製APK檔案，具體實現在子類FileInstallArgs和SdInstallArgs裡面。

下面我們看一下FileInstallArgs中實現該方法的關鍵部分

if (imcs.copyResource(packageURI,out)) {

ret = PackageManager.INSTALL_SUCCEEDED;

}

通過IMediaContainerService服務將APK複製到指定目錄(data/app/vmdl26489.tmp)

SdInstallArgs中該方法實現的原理差不多，就不再贅述。

我們再回到InstallParams裡面的handleReturnCode()中來，該方法呼叫processPendingInstall方法處理安裝。

@Override

void handleReturnCode() {

processPendingInstall(mArgs,mRet);

}

private void processPendingInstall(final InstallArgs args, final int currentStatus) {

// Queue up an async operation since the package installation may take a little while.

mHandler.post(new Runnable() {

public void run() {

/** 省略若干**/

if (res.returnCode == PackageManager.INSTALL_SUCCEEDED) {

args.doPreInstall(res.returnCode);

synchronized (mInstallLock) {

installPackageLI(args,true,res);

}

args.doPostInstall(res.returnCode);

}

/** 省略若干**/

if (!doRestore) {

// No restore possible, or the Backup Manager was mysteriously not

// available -- just fire the post-install work request directly.

if (DEBUG_INSTALL) Log.v(TAG, "No restore - queue post-install for " + token);

Messagemsg=mHandler.obtainMessage(POST_INSTALL,token,0);

mHandler.sendMessage(msg);

}

}

});

}

方法processPendingInstall中關鍵的操作已經用紅色標出，主要的安裝流程都在這個方法裡面。安裝過程放在一個執行緒裡面，因為安裝需要一定的時間（這裡有個問題，Handler中有一個MessageQueue處理所有的Message佇列，那麼通過post進來一個Runnable，這個Runnable是在什麼時候處理的？）。處理流程是預安裝-安裝-安裝收尾-傳送POST_INSTALL訊息

預安裝：下面這個doPreInstall的實現是來自InstallArgs的直接子類SdInstallArgs，所做的工作是檢查當前安裝包的狀態以及確保SDCARD的掛載，並返回狀態資訊。從中我們可以看出來預安裝功能就是在安裝前確保安裝環境的可靠。

int doPreInstall(int status) {

if (status != PackageManager.INSTALL_SUCCEEDED) {

// Destroy container

PackageHelper.destroySdDir(cid);

} else {

boolean mounted = PackageHelper.isContainerMounted(cid);

if (!mounted) {

cachePath = PackageHelper.mountSdDir(cid, getEncryptKey(), Process.SYSTEM_UID);

if (cachePath == null) {

return PackageManager.INSTALL_FAILED_CONTAINER_ERROR;

}

}

}

return status;

}

安裝：對mHistallLock加了鎖，表明同時只能有一個安裝包進行安裝，installPackageLI稍候介紹。

相關推薦