zoukankan      html  css  js  c++  java
  • 说说Android应用的persistent属性

    转载地址:http://my.oschina.net/youranhongcha/blog

    摘要 在Android系统中,有一种永久性应用。它们对应的AndroidManifest.xml文件里,会将persistent属性设为true。

     

    说说Android应用的persistent属性

    侯 亮

    1 启动persistent应用

        在Android系统中,有一种永久性应用。它们对应的AndroidManifest.xml文件里,会将persistent属性设为true,比如:

    1
    2
    3
    4
    <application android:name="PhoneApp"
    android:persistent="true"
    android:label="@string/dialerIconLabel"
    android:icon="@drawable/ic_launcher_phone">


        在系统启动之时,AMS的systemReady()会加载所有persistent为true的应用。

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    public void systemReady(final Runnable goingCallback)
    {
        . . . . . .
        . . . . . .
        try {
            List apps = AppGlobals.getPackageManager().
                            getPersistentApplications(STOCK_PM_FLAGS);
            if (apps != null)
            {
                int N = apps.size();
                int i;
                 
                for (i=0; i<N; i++)
                {
                    ApplicationInfo info = (ApplicationInfo)apps.get(i);
                    if (info != null &&
                            !info.packageName.equals("android"))
                    {
                        addAppLocked(info, false);
                    }
                }
            }
        }
        catch (RemoteException ex) {
            // pm is in same process, this will never happen.
        }

    其中的STOCK_PM_FLAGS的定义如下:

    1
    2
    // The flags that are set for all calls we make to the package manager.
    static final int STOCK_PM_FLAGS = PackageManager.GET_SHARED_LIBRARY_FILES;

    上面代码中的getPersistentApplications()函数的定义如下:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    public List<ApplicationInfo> getPersistentApplications(int flags)
    {
        final ArrayList<ApplicationInfo> finalList = new ArrayList<ApplicationInfo>();
     
     
        // reader
        synchronized (mPackages)
        {
            final Iterator<PackageParser.Package> i = mPackages.values().iterator();
            final int userId = UserId.getCallingUserId();
            while (i.hasNext())
            {
                final PackageParser.Package p = i.next();
                if (p.applicationInfo != null
                    && (p.applicationInfo.flags & ApplicationInfo.FLAG_PERSISTENT) != 0
                    && (!mSafeMode || isSystemApp(p)))
                {
                    PackageSetting ps = mSettings.mPackages.get(p.packageName);
                    finalList.add(PackageParser.generateApplicationInfo(p, flags,
                            ps != null ? ps.getStopped(userId) : false,
                            ps != null ? ps.getEnabled(userId) : COMPONENT_ENABLED_STATE_DEFAULT,
                            userId));
                }
            }
        }
     
        return finalList;
    }
         在PKMS中,有一个记录所有的程序包信息的哈希表(mPackages),每个表项中含有ApplicationInfo信息,该信息的flags(int型)数据中有一个专门的bit用于表示persistent。getPersistentApplications()函数会遍历这张表,找出所有persistent包,并返回ArrayList<ApplicationInfo>。

         从代码里可以看出,带persistent标志的系统应用(即flags中设置了FLAG_SYSTEM)是一定会被选上的,但如果不是系统应用的话,则要进一步判断当前是否处于“安全模式”,一旦处于安全模式,那么就算应用设置了persistent属性,也不会被选中。

         随后systemReady()开始遍历选中的ApplicationInfo,并对包名不为“android”的结点执行addAppLocked()。addAppLocked()的代码如下:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    final ProcessRecord addAppLocked(ApplicationInfo info, boolean isolated)
    {
        ProcessRecord app;
        if (!isolated) {
            app = getProcessRecordLocked(info.processName, info.uid);
        } else {
            app = null;
        }
     
        if (app == null) {
            app = newProcessRecordLocked(null, info, null, isolated);
            mProcessNames.put(info.processName, app.uid, app);
            if (isolated) {
                mIsolatedProcesses.put(app.uid, app);
            }
            updateLruProcessLocked(app, true, true);
        }
     
        // This package really, really can not be stopped.
        try {
            AppGlobals.getPackageManager().setPackageStoppedState(
                    info.packageName, false, UserId.getUserId(app.uid));
        } catch (RemoteException e) {
        } catch (IllegalArgumentException e) {
            Slog.w(TAG, "Failed trying to unstop package "
                    + info.packageName + ": " + e);
        }
     
        if ((info.flags&(ApplicationInfo.FLAG_SYSTEM|ApplicationInfo.FLAG_PERSISTENT))
                == (ApplicationInfo.FLAG_SYSTEM|ApplicationInfo.FLAG_PERSISTENT)) {
            app.persistent = true;
            app.maxAdj = ProcessList.PERSISTENT_PROC_ADJ;
        }
        if (app.thread == null && mPersistentStartingProcesses.indexOf(app) < 0) {
            mPersistentStartingProcesses.add(app);
            startProcessLocked(app, "added application", app.processName);
        }
     
        return app;
    }
        在AMS中,所谓的“add App”主要是指“添加一个与App进程对应的ProcessRecord节点”。当然,如果该节点已经添加过了,那么是不会重复添加的。在添加节点的动作完成以后,addAppLocked()还会检查App进程是否已经启动好了,如果尚未开始启动,此时就会调用startProcessLocked()启动这个进程。既然addAppLocked()试图确认App“正在正常运作”或者“将被正常启动”,那么其对应的package就不可能处于stopped状态,这就是上面代码调用setPackageStoppedState(...,false,...)的意思。

        现在,我们就清楚了,那些persistent属性为true的应用,基本上都是在系统启动伊始就启动起来的。

        因为启动进程的过程是异步的,所以我们需要一个缓冲列表(即上面代码中的mPersistentStartingProcesses列表)来记录那些“正处于启动状态,而又没有启动完毕的”ProcessRecord结点。一旦目标进程启动完毕后,目标进程会attach系统,于是走到AMS的attachApplicationLocked(),在这个函数里,会把目标进程对应的ProcessRecord结点从mPersistentStartingProcesses缓冲列表里删除。

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    private final boolean attachApplicationLocked(IApplicationThread thread, int pid) {
     
            // Find the application record that is being attached...  either via
            // the pid if we are running in multiple processes, or just pull the
            // next app record if we are emulating process with anonymous threads.
            ProcessRecord app;
             
            . . . . . .
            thread.asBinder().linkToDeath(adr, 0);
            . . . . . .
            thread.bindApplication(processName, appInfo, providers,
                        app.instrumentationClass, profileFile, profileFd, profileAutoStop,
                        app.instrumentationArguments, app.instrumentationWatcher, testMode,
                        enableOpenGlTrace, isRestrictedBackupMode || !normalMode,
                        app.persistent,
                        new Configuration(mConfiguration), app.compat,
                        getCommonServicesLocked(),
                        mCoreSettingsObserver.getCoreSettingsLocked());
            . . . . . .
            . . . . . .
            // Remove this record from the list of starting applications.
            mPersistentStartingProcesses.remove(app);
            . . . . . .

    2 如何保证应用的持久性(persistent)

        我们知道,persistent一词的意思是“持久”,那么persistent应用的意思又是什么呢?简单地说,这种应用会顽固地运行于系统之中,从系统一启动,一直到系统关机。

        为了保证这种持久性,persistent应用必须能够在异常出现时,自动重新启动。在Android里是这样实现的。每个ActivityThread中会有一个专门和AMS通信的binder实体——final ApplicationThread mAppThread。这个实体在AMS中对应的代理接口为IApplicationThread。

        当AMS执行到attachApplicationLocked()时,会针对目标用户进程的IApplicationThread接口,注册一个binder讣告监听器,一旦日后用户进程意外挂掉,AMS就能在第一时间感知到,并采取相应的措施。如果AMS发现意外挂掉的应用是persistent的,它会尝试重新启动这个应用。

        注册讣告监听器的代码如下:

    1
    2
    3
    AppDeathRecipient adr = new AppDeathRecipient(app, pid, thread);
    thread.asBinder().linkToDeath(adr, 0);
    app.deathRecipient = adr;

    其中的thread就是IApplicationThread代理。

        AppDeathRecipient的定义如下:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    private final class AppDeathRecipient implements IBinder.DeathRecipient
    {
        final ProcessRecord mApp;
        final int mPid;
        final IApplicationThread mAppThread;
     
        AppDeathRecipient(ProcessRecord app, int pid,
                IApplicationThread thread)
        {
            if (localLOGV)
                Slog.v(TAG, "New death recipient " + this
                       + " for thread " + thread.asBinder());
            mApp = app;
            mPid = pid;
            mAppThread = thread;
        }
     
        public void binderDied()
        {
            if (localLOGV)
                Slog.v(TAG, "Death received in " + this
                       + " for thread " + mAppThread.asBinder());
            synchronized(ActivityManagerService.this)
            {
                appDiedLocked(mApp, mPid, mAppThread);
            }
        }
    }

    当其监听的binder实体死亡时,系统会回调AppDeathRecipient的binderDied()。这个回调函数会辗转重启persistent应用,调用关系如下:

        一般情况下,当一个应用进程挂掉后,AMS当然会清理掉其对应的ProcessRecord,这就是cleanUpApplicationRecordLocked()的主要工作。然而,对于persistent应用,cleanUpApplicationRecordLocked()会尝试再次启动对应的应用进程。代码截选如下:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    private final void cleanUpApplicationRecordLocked(ProcessRecord app,
                                                      boolean restarting,
                                                      boolean allowRestart, int index)
    {
        . . . . . .
        . . . . . .
        if (!app.persistent || app.isolated)
        {
            . . . . . .
            mProcessNames.remove(app.processName, app.uid);
            mIsolatedProcesses.remove(app.uid);
            . . . . . .
        }
        else if (!app.removed)
        {
            if (mPersistentStartingProcesses.indexOf(app) < 0) {
                mPersistentStartingProcesses.add(app);
                restart = true;
            }
        }
        . . . . . .
        . . . . . .
        if (restart && !app.isolated)
        {
            mProcessNames.put(app.processName, app.uid, app);
            startProcessLocked(app, "restart", app.processName);
        }
        else if (app.pid > 0 && app.pid != MY_PID)
        {
            . . . . . .
        }
        . . . . . .
    }

        现在我们可以画一张关于“启动persistent应用”的示意图:

    3 补充知识点

    3.1 persistent应用可以在系统未准备好时启动

        在AMS中,有一个isAllowedWhileBooting()函数,其代码如下:

    1
    2
    3
    4
    boolean isAllowedWhileBooting(ApplicationInfo ai)
    {
        return (ai.flags & ApplicationInfo.FLAG_PERSISTENT) != 0;
    }


        从这个函数可以看到,将persistent属性设为true的应用,是允许在boot的过程中启动的。我们可以查看前文提到的startProcessLocked()函数:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    final ProcessRecord startProcessLocked(String processName,
                                           ApplicationInfo info, boolean knownToBeDead,
                                           int intentFlags,
                                           String hostingType, ComponentName hostingName,
                                           boolean allowWhileBooting,
                                           boolean isolated)
    {
        ProcessRecord app;
         
        if (!isolated)
        {
            app = getProcessRecordLocked(processName, info.uid);
        }
        else
        {
            // If this is an isolated process, it can't re-use an existing process.
            app = null;
        }
     
        . . . . . .
        . . . . . .
         
        if (!mProcessesReady
            && !isAllowedWhileBooting(info)
            && !allowWhileBooting) {
            if (!mProcessesOnHold.contains(app)) {
                mProcessesOnHold.add(app);
            }
            if (DEBUG_PROCESSES) Slog.v(TAG, "System not ready, putting on hold: " + app);
            return app;
        }
     
        startProcessLocked(app, hostingType, hostingNameStr);
        return (app.pid != 0) ? app : null;
    }

    其中的最后几句可以改写为以下更易理解的形式:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    if  (mProcessesReady || isAllowedWhileBooting(info) || allowWhileBooting)
    {
        startProcessLocked(app, hostingType, hostingNameStr);
        return (app.pid != 0) ? app : null;
    }
    else
    {
        . . . . . .
        return app;
    }

        也就是说,当系统已经处于以下几种情况时,多参数的startProcessLocked()会进一步调用另一个只有三个参数的startProcessLocked():
    1)系统已经处于ready状态;
    2)想要启动persistent应用;
    3)参数中明确指定可以在boot过程中启动应用。

        补充说一下,一般情况下,当AMS调用startProcessLocked()时,传入的allowWhileBooting参数都为false。比如说,当系统需要启动“某个content provider或者某个service或者某个特定activity”时,此时传给startProcessLocked()的allowWhileBooting参数是写死为false的。只有一种特殊情况下会在该参数中传入true,那就是当系统发出的广播intent中携带有Intent.FLAG_RECEIVER_BOOT_UPGRADE标记时,此时允许在系统未ready时,启动接受广播的目标进程。

    4 结束

        有关Android应用的persistent属性,我们就先说这么多。希望对大家有点儿帮助。

  • 相关阅读:
    delete
    js混淆代码还原-js反混淆:利用js进行赋值实现
    Microservice Trade-Offs
    tagged by: microservices 【martinfowler.com】
    Tackle Business Complexity in a Microservice with DDD and CQRS Patterns
    Why Can't I Access A Protected Member From A Derived Class
    tagged by: domain driven design 【martinfowler.com】
    Domain Driven Design
    Why Would I Ever Need to Use C# Nested Classes
    RabbitMQ compare with redis and MSMQ
  • 原文地址:https://www.cnblogs.com/senior-engineer/p/4968786.html
Copyright © 2011-2022 走看看