Android persistent属性研究

この間telephonyを研究していたとき、frameworkの下でtelephonyの初期化(PhoneFactory.javaのmakeDefaultPhones関数)の呼び出しは発見されなかった.その結果、グローバル検索の結果、アプリケーションPhoneApp(packages/apps/iPhone)で呼び出されたことがわかりました.しかし、アプリケーションPhoneAppはBroadcastに起動されていないし、他のサービスに呼び出されていないので、AndroidはどのようにPhoneAppを起動するのか、属性android:persistentを発見しました.
AndroidManifestでxml定義では、アプリケーションにはandroid:persistentという属性があり、文字通りアプリケーションは持続可能、すなわち常駐的なアプリケーションであると理解される.実はandroid:persistentで修飾されたアプリケーションがシステム起動後にAMで起動されるという理解です.
AMまずPM(PackageManagerService)でAndroid:persistentが設定されているアプリケーションを検索

public void systemReady(final Runnable goingCallback) {  
            if (mFactoryTest != SystemServer.FACTORY_TEST_LOW_LEVEL) {  
                try {  
                    List apps = AppGlobals.getPackageManager().  
                        getPersistentApplications(STOCK_PM_FLAGS);  
                    if (apps != null) {  
                        int N = apps.size();  
                        int i;  
                        for (i=0; i

Android:persistentによって修飾されたアプリケーションがこの時点で実行されていない場合、AMはstartProcessLockedを呼び出してappを起動し、startProcessLockedについては説明しないが、別の文章「How to start a new process for Android?」で詳しく紹介されています.
appの起動プロセスは、appが存在するpackageに対応するプロセスを起動することである.

final ProcessRecord addAppLocked(ApplicationInfo info) {  
        ProcessRecord app = getProcessRecordLocked(info.processName, info.uid);  
        if (app == null) {  
            app = newProcessRecordLocked(null, info, null);  
            mProcessNames.put(info.processName, info.uid, app);  
            updateLruProcessLocked(app, true, true);  
        }  
        if ((info.flags&(ApplicationInfo.FLAG_SYSTEM|ApplicationInfo.FLAG_PERSISTENT))  
                == (ApplicationInfo.FLAG_SYSTEM|ApplicationInfo.FLAG_PERSISTENT)) {  
            app.persistent = true;  
            app.maxAdj = CORE_SERVER_ADJ;  
        }  
        if (app.thread == null && mPersistentStartingProcesses.indexOf(app) < 0) {  
            mPersistentStartingProcesses.add(app);  
            startProcessLocked(app, "added application", app.processName);  
        }  
        return app;  
    }  

面ではappが存在するpackageに対応するプロセスの起動が完了した後、appがどのようにcreateされたかを紹介します.
記事『How to start a new process for Android?』からでは、zygoteは新しいプロセスを作成する際にmainThread androidを起動することがわかります.app.Activity Threadなので、Activity Threadのmain関数からappのcreateプロセスを解析します.
mainでは次の操作があります.
thread.attach(false);  
attachプロセス中、Activity Threadは対応するアプリケーションattachをAMに渡し、AMに渡して管理します.ここでは変数に注意する必要があります
final ApplicationThread mAppThread = new ApplicationThread();  
mAppThreadはApplicationThreadオブジェクトであり、mAppThreadは現在のプロセスマスタースレッドのコアと見なすことができ、このプロセスと他のプロセス(主にAM)との間の通信を処理するとともに、attachApplicationによってmAppThreadのエージェントBinderをAMに渡す.

private final void attach(boolean system) {  
        sThreadLocal.set(this);  
        mSystemThread = system;  
        if (!system) {  
            ViewRoot.addFirstDrawHandler(new Runnable() {  
                public void run() {  
                    ensureJitEnabled();  
                }  
            });  
            Android.ddm.DdmHandleAppName.setAppName("");  
            RuntimeInit.setApplicationObject(mAppThread.asBinder());  
            IActivityManager mgr = ActivityManagerNative.getDefault();  
            try {  
                mgr.attachApplication(mAppThread);  
            } catch (RemoteException ex) {  
            }  
        }  
    }  

上のattachコードでは、IPC呼び出しAMのattachApplicationプロセスに沿ってさらに下を見ます.
この過程で、AMはIPC通信呼び出しmAppThreadのbindApplicationを呼び出す.

private final boolean attachApplicationLocked(IApplicationThread thread,  
            int pid) {  
      
            thread.bindApplication(processName, app.instrumentationInfo != null  
                    ? app.instrumentationInfo : app.info, providers,  
                    app.instrumentationClass, app.instrumentationProfileFile,  
                    app.instrumentationArguments, app.instrumentationWatcher, testMode,   
                    isRestrictedBackupMode || !normalMode,  
                    mConfiguration, getCommonServicesLocked());  
            updateLruProcessLocked(app, false, true);  
            app.lastRequestedGc = app.lastLowMemory = SystemClock.uptimeMillis();  
}  

mAppThreadのbindApplicationは、Activity Thread自身がメンテナンスしているhandlerにメッセージメカニズムを介してBIND_を送信するAPPLICATIONメッセージ.Activity Thread自身がメンテナンスしているhandler対メッセージBIND_を見てみましょう.APPLICATIONの処理は最終的にhandleBindApplication関数に呼び出されます
handleBindApplication関数には
mInstrumentation.callApplicationOnCreate(app);
私たちは最終的に大きな周りを回った後、appのonCreate関数を呼び出してこのアプリケーションを起動しました.