APK安装流程详解16——Android包管理总结

APK安装流程系列文章整体内容如下:
  • 1、设计思想
  • 2、PackageManagerService的抽象理解
  • 3、PackageManagerService里面的数据结构
  • 4、PackageManagerService的三大流程
  • 5、PackageManagerService的体系结构

一、设计思想

如果你是Android 系统中的架构师,让你设计一个Android的安装系统中的PackageManagerService,你会怎么设计? 既然要设计,咱们要首先弄清几个问题,我希望大家看下面的问题的时候,多想两个问题:1、如果让你设计,你怎么设计。这个"类"存在意义是什么?

  • 1、为什么关机的时候手机是砖头,而开机后,所有APP都可以运行了,这是为什么?
  • 2、Android系统是通过什么手段来加载已经安装到手机上应用的?
  • 3、既然是加载,按照科学的架构设计,是不是应该存在一个管理者,来全局管理,那个这个类是什么?
  • 4、在安装一个APK的时候,APK是"死的",Android系统是怎么把它变成一个"活的"APP,他是怎么加载到内存中去的

那我们就来依次来看下这几个问题

1、为什么关机的时候手机是砖头,而开机后,所有APP都可以运行了,它是怎么加载的?

  • 首先明确一点,手机关机以后,就是一个冰冷的砖头,只能用来"砸核桃",那开机后,你点击桌面上的任何一个图片,都能开启一个APP,这说明在开机过程中,系统把已经安装好的APP加载到内存中,这到底是怎么做的?所以我们反推断,在安卓系统中肯定存在这么一块区域,用于存放已经安装的APP的信息,在开机的时候,通过系统扫描,这块区域,把对应的内容加载到内存中去。
  • 其次,通过上面的分析,我们知道了在Android系统中存在这样一块区域,在开机的的时候,加载这块区域的信息,从而实现加载在内存中去。那么我们继续反推断,那这块区域的信息,是怎么来的?应该在安装这个APK的时候,把这个APK的信息写入到该区域的。这样就可以实现了在安卓系统一次安装后,在删除APK文件后,还可以运行APP了

其实上面的解答是基本上所有操作的系统的安装思路,大家可以想一下在Windows下是不是也是如此。

上面说的Android区域其实就是:“/data目录”下的system目录,这个目录用来保存很多系统文件。主要工作是创建了5个位于目录/data/system的File对象,分别是:

  • packages.xml:记录了系统中所有安装的应用信息,包括基本信息、签名和权限
  • pakcages-back.xml:packages.xml文件
  • pakcages-stoped.xml:记录系统中被强制停止的运行的应用信息。系统在强制停止某个应用的时候,会将应用的信息记录在该文件中。
  • pakcages-stoped-backup.xml:pakcages-stoped.xml文件的备份
  • 保存普通应用的数据目录和uid等信息

这个5个文件中pakcages-back.xml和pakcages-stoped-backup.xml是备份文件。当Android对文件packages.xml和pakcages-stoped.xml写之前,会先把它们备份,如果写文件成功了,再把备份文件删除。如果写的时候,系统出问题了,重启后在需要读取这两个文件时,如果发现备份文件存在,会使用备份文件的内容,因为源文件可能已经损坏了。其中packages.xmlPackageManagerServcie启动时,需要用到的文件。
我把我的Nexus 6P手机Root后,在/data/system 截屏如下:

/data/system目录.png

我把packages.xml导出来,文件内容太大,我就直接截屏了,内容如下:


截屏1.png
截屏2.png

图片看不清,可以看下面的缩减版

<?xml version='1.0' encoding='utf-8' standalone='yes' ?>
<packages>
    <version sdkVersion="23" databaseVersion="3" fingerprint="google/angler/angler:6.0.1/MTC20L/3230295:user/release-keys" />
    <version volumeUuid="primary_physical" sdkVersion="23" databaseVersion="23" fingerprint="google/angler/angler:6.0.1/MTC19T/2741993:user/release-keys" />
    <permission-trees>
        <item name="com.google.android.googleapps.permission.GOOGLE_AUTH" package="com.google.android.gsf" />
    </permission-trees>
    <permissions>
        <item name="android.permission.REAL_GET_TASKS" package="android" protection="18" />
        <item name="android.permission.REMOTE_AUDIO_PLAYBACK" package="android" protection="2" />
     .....
        <item name="com.android.voicemail.permission.ADD_VOICEMAIL" package="android" protection="1" />
    </permissions>
    <package name="com.google.android.youtube" codePath="/system/app/YouTube" nativeLibraryPath="/system/app/YouTube/lib" primaryCpuAbi="arm64-v8a" publicFlags="945307205" privateFlags="0" ft="11e9134c000" it="11e9134c000" ut="11e9134c000" version="107560144" userId="10075">
        <sigs count="1">
            <cert index="0" key="30820252308201bb02044934987e300d06092a864886f70d01010405003070310b3009060355040613025553310b3009060355040813024341311630140603550407130d4d6f756e7461696e205669657731143012060355040a130b476f6f676c652c20496e6331143012060355040b130b476f6f676c652c20496e633110300e06035504031307556e6b6e6f776e301e170d3038313230323032303735385a170d3336303431393032303735385a3070310b3009060355040613025553310b3009060355040813024341311630140603550407130d4d6f756e7461696e205669657731143012060355040a130b476f6f676c652c20496e6331143012060355040b130b476f6f676c652c20496e633110300e06035504031307556e6b6e6f776e30819f300d06092a864886f70d010101050003818d00308189028181009f48031990f9b14726384e0453d18f8c0bbf8dc77b2504a4b1207c4c6c44babc00adc6610fa6b6ab2da80e33f2eef16b26a3f6b85b9afaca909ffbbeb3f4c94f7e8122a798e0eba75ced3dd229fa7365f41516415aa9c1617dd583ce19bae8a0bbd885fc17a9b4bd2640805121aadb9377deb40013381418882ec52282fc580d0203010001300d06092a864886f70d0101040500038181004086669ed631da4384ddd061d226e073b98cc4b99df8b5e4be9e3cbe97501e83df1c6fa959c0ce605c4fd2ac6d1c84cede20476cbab19be8f2203aff7717ad652d8fcc890708d1216da84457592649e0e9d3c4bb4cf58da19db1d4fc41bcb9584f64e65f410d0529fd5b68838c141d0a9bd1db1191cb2a0df790ea0cb12db3a4" />
        </sigs>
        <perms>
            <item name="com.google.android.c2dm.permission.RECEIVE" granted="true" flags="0" />
            <item name="android.permission.USE_CREDENTIALS" granted="true" flags="0" />
            <item name="com.google.android.providers.gsf.permission.READ_GSERVICES" granted="true" flags="0" />
            <item name="com.google.android.youtube.permission.C2D_MESSAGE" granted="true" flags="0" />
            <item name="android.permission.MANAGE_ACCOUNTS" granted="true" flags="0" />
            <item name="android.permission.NFC" granted="true" flags="0" />
            <item name="android.permission.CHANGE_NETWORK_STATE" granted="true" flags="0" />
            <item name="android.permission.RECEIVE_BOOT_COMPLETED" granted="true" flags="0" />
            <item name="com.google.android.gms.permission.AD_ID_NOTIFICATION" granted="true" flags="0" />
            <item name="android.permission.INTERNET" granted="true" flags="0" />
            <item name="android.permission.ACCESS_NETWORK_STATE" granted="true" flags="0" />
            <item name="android.permission.VIBRATE" granted="true" flags="0" />
            <item name="android.permission.ACCESS_WIFI_STATE" granted="true" flags="0" />
            <item name="android.permission.WAKE_LOCK" granted="true" flags="0" />
        </perms>
        <proper-signing-keyset identifier="11" />
        <domain-verification packageName="com.google.android.youtube" status="0">
            <domain name="youtu.be" />
            <domain name="m.youtube.com" />
            <domain name="youtube.com" />
            <domain name="www.youtube.com" />
        </domain-verification>
    </package>

上面是我手机packages.xml的一个片段。我们看下里面的"youtube"应用。通过标签<package>记录了一个应用的基本信息,签名和声明的权限。

(1)<package>表示包信息,下面我们就来解释下标签<package>中的属性
  • name表示应用的包名
  • codePath表示的是apk文件的路径
  • nativeLibraryPath表示应用的native库的存储路径
  • flags是指应用的属性,如FLAG_SYSTEM、FLAG_PERSISTENT等
  • it表示应用安装的时间
  • ut表示应用最后一次修改的时间
  • version表示应用的版本号
  • userId表示所属于的id
(2)<sign>表示应用的签名,下面我们就来解释下 标签<sign>中的属性
  • count表示标签中包含有多少个证书
  • cert表示具体的证书的值
(3)<perms>表示应用声明使用的权限,每一个子标签代表一项权限

通过上面的内容,我们知道Android系统通过packages.xml文件来存储应用信息的,所以我们举一反三,新安装的APK,肯定是把新安装的APK相关信息写入这个packages.xml文件中,那么怎么把这个xml文件,映射到内存中的? 那我们就来看第二个问题

2、Android系统是通过什么手段来加载已经安装到手机上应用的

上面提到了,应用的信息都存储在packages.xml中的<package>标签里面,那我们是怎么加载到内存中去的?大家平时是存储数据库的时候都是怎么做的?对的,一般都是一个实体类对应数据库中的一个表;其中每一个对象对应的是数据库中的一条数据。同理,Android系统也是这样设计的,<package>标签里面记录的包信息其实是一一对应的PackageSetting类。

PackageSetting类的继承关系.png

PackageSetting继承了PackageSettingBase类,PackageSettingBase类继承自GrantedPremisson类。应用的基本信息保存在PackageSettingBase类的成员变量中,声明的权限保存在GrantedPremissions类,签名则保存在SharedUserSetting类的成员变量signatures中。标签<package>所标识的应用PackageSetting对象都保存在Setting的mPackages中,定义如下:

// com.android.server.pm.Settings.java

    final HashMap<String, PackageSetting> mPackages =
            new HashMap<String, PackageSetting>();

在packages.xml中除了标签<package>,还有<updated-package>、<cleaning-package>和<renamed-package> 这三种标签。

  • <updated-package> 标签表示升级包覆盖的系统应用,对应的是PackageSetting,在Settings里面同样用mPackages 变量表示
  • <cleaning-package> 标签用来记录那些已经删除,但是数据目录还暂时保留的应用的信息。对应的是PackageCleanItem。在Settings里面用mPackagesToBeCleaned变量表示
  • <renamed-package> 标签用来记录系统中改名的应用。它的记录信息都插入到mSettings的mRenamedPackages对象中。

其中mPackagesToBeCleaned和mRenamedPackages在mSettings.java的定义如下:

// com.android.server.pm.Settings.java

    // Packages that have been uninstalled and still need their external
    // storage data deleted.
    final ArrayList<PackageCleanItem> mPackagesToBeCleaned = new ArrayList<PackageCleanItem>();
    
    // Packages that have been renamed since they were first installed.
    // Keys are the new names of the packages, values are the original
    // names.  The packages appear everwhere else under their original
    // names.
    final HashMap<String, String> mRenamedPackages = new HashMap<String, String>();

上面用大量的文笔说Settings,那么它是什么东西?下面就让我继续来看下一个问题

3、既然是加载,按照科学的架构设计,是不是应该存在一个管理者,来全局管理,那个这个类是什么?

这个类就是Settings

Settings是Android的包的全局管理者,用于协助PackageManagerService保存所有的安装包信息,同时用于存储系统执行过程中的一些设置,PackageManagerService和Settings之间的类图关系如下:

PackageManagerService和Settings的关系.png

大图地址1

Settings里面有3个重要的成员变量:mShareUsers,mPackages,mSharedUsers 。如下:

    final ArrayMap<String, SharedUserSetting> mSharedUsers =
            new ArrayMap<String, SharedUserSetting>();
    final ArrayMap<String, PackageSetting> mPackages =
            new ArrayMap<String, PackageSetting>();
  final ArraySet<String, SharedUserSetting> mSharedUsers =
            new ArraySet<String, SharedUserSetting>();
  • mShareUsers是一个以String类型的name为"key",ShareUserSetting对象为"value"的ArrayMap。
  • mPackages是一个以String类型的name为"key",PackageSetting对象为"value"的ArrayMap。
  • mSharedUsers 是一个以String类型的name(比如"android.uid.system")为"key",以SharedUserSetting 对象为"value"的HashMap

其中ShareUserSetting类继承自GrantedPermissions ,内部包含一个ArraySet类型的packages ,这个packages保存了声明相同的shareUserId的Package的权限设置信息(PackageSetting )通过上面的问题,我们知道PackageSetting继承自PackageSettingBase,同时PackageSetting中保存着package的多种信息。

如下图:


PackageSetting.png

上面提到了一个概念是SharedUserSetting,那么ShareUserSetting的作用什么是什么?那我们就来看下:

SharedUserSetting用来描述具有相同的sharedUserId的应用信息,它的成员变量packages保存了所有具有相同sharedUserId的应用信息引用。这些应用的签名时相同的,所有只需要在成员变量signatures中保存一份。通过这个对象,Android运行时很容易检索到某个应用拥有相同的sharedUserId的其他应用。其中应用的签名保存在ShardUserSetting类的成员变量signatures中。

我们在看系统应用的AndroidManifest.xml中会发现

<manifest 
    xmlns:android="http://schemas.android.com/apk/res/android" 
    xmlns:androidprv="http://schemas.android.com/apk/prv/res/android" 
    package="com.android.settings" coreApp="true"
    android:sharedUserId="android.uid.system" 
    android:versionCode="1" 
    android:versionName="1.0" >
 </manifest>

shareUserId与UID相关,作用是:

  • 1、两个或多个APK或者进程声明了同一种sharedUserId的APK可以共享批次的数据,并且可以在运行在同一进程中(相当于进程是系统的用户,某些进程可以归为同一用户使用,相当于Linux系统中的GroupId)
  • 2、通过声明特定的sharedUserId,该APK所在的进程将被赋予指定的
      2.通过声明特定的sharedUserId,该APK所在的进程将被赋予指定的UID,将被赋予该UID特定的权限。

在Settings中和用户有关的还有两个重要变量,即mUserIds 和mOtherUserIds

    private final ArrayList<Object> mUserIds = new ArrayList<Object>();
    private final SparseArray<Object> mOtherUserIds =
            new SparseArray<Object>();

他们都是以UID为索引,得到对应的ShardUserSetting对象。更多的关于Android系统中关于"用户"的信息,在后面"用户模块"再单独讲解

4、在安装一个APK的时候,APK是"死的",Android系统是怎么把它变成一个"活的"APP,他是怎么加载到内存中去的

这里就不得不提一下PackageParser这个类,这个类负责在APK文件安装的时候,解析AndroidManifest。

在Android中,Settings提供可持续化的包信息管理,PackageSetting是一个存储单元,表示一个pkg信息。我们在解析APK安装包的时候,会用到PackageParser,在PackageParser里面有一个字段是PackageParse.Package。这个PackageParse.Package其实是对应的上面packages.xml里面的<package>标签。同时PackageParse.Package也可以理解为pkg信息在内存中的一个实时信息,关机后变消失,重启后重新生成,所以PackageParse.Package中的信息一致保证最新。PackageParse.Packag、Settings和PackageSetting三者的关系如下:

关系.png

Settings中保存了一个包名和PackagesSetting的映射表,PackageParse.Package中的mExtras引用指向了对应的PackageSetting实例,而PackageParse中保存了一个PackageParse.Package列表

PackageParse.png

从上到下,介绍如下:
1:PackageParser.Package对应一个apk完整的原始数据
2:PackageSetting包含一个PackageParser对象实例,说明它也对应一个apk包的数据,不同的是,它还包括apk相关配置数据,比如apk内部哪些component是被disable等。
3:Settings包含了PackageSetting对象列表,也就是说它包含了系统所有apk数据,还有就是PackageParser,顾名思义,负责APK数据解析
4:PackageManagerService是全局的包管理器

5、补充一点:

Settings里面的主要关联关系如下图:


主要关联关系.png

二、PackageManagerService的抽象理解

上面说了很多,我们再上升一个高度,PackageManagerService到底应该怎么去理解它?

每一个组织结构,都有一套自己的管理机制,比如任何一家公司,都会存在下面三个元素:管理者(经理)、被管理者(员工)、管理机制(公司的规章制度及KPI考核等)。同理在Android的系统的世界里面,也有一家公司叫"包管理"。如果要研究Android的包管理机制,同样可以从以下几个角度来思考?

  • 管理者是谁,他的职责是什么?
  • 被管理者是谁,他的职责是什么?
  • 管理机制是什么,它是如何运转的?

所谓包,其实就是一种文件的格式,比如APK包,JAR包等,在Android中存活着很多包,所有的应用程序都是APK包,很多构成Android运行环境的都是JAR包,还有一些以so为后缀的库文件,包管理者很重要的一个职责就是识别不同的包,统一维护这些包的信息。当有一个包进入(安装)或者离开(卸载)Android世界,都需要向包管理者申报,其他管理部分要获取包的具体信息,也都需要向包管理者申请。

如同一家公司是由人与人协作工作的,不同包之间也需要进行协作。既然有协作,自然就有协作的规范,一个包可以干什么,不可以干什么,都需要有一个明确的范围界定,这就是包管理中的权限设计。涉及到的内容非常广泛,Android的权限管理、SELinux,都是包管理中权限设计的组成部分。同理Android的世界就像一个井然有序的一家公司,既有包管理部门,也有其他各种管理部门,比如电源管理部门,窗口管理部门等等。大家不仅各司其职,而且也有来往。比如在APK安装到Activity的显示,看着很简单的过程,其实却需要大量的管理部门参与进来,不断地进行数据解析、封装、传递、呈现,其内部机制十分复杂。

现在大家想一下上面三个问题的答案,我详细大部分人的前两个答案是一致的,管理者是PackageManagerService,被管理是各种"包",最后一个答案是各有千秋,这里是没有标准答案的,希望大家能自己找到自己的答案。

三、PackageManagerService里面的数据结构

PackageManagerService涉及的数据结构非常多,在分析源码时,很容易陷入各种数据结构之间的关系,难以自拔,以至于看不到包管理的全貌。我在这里简单的总结了一下各个数据结构的职能如下:

  • PackageManangerService :包管理的核心服务
  • com.android.server.pm.Settings :所有包的管理信息
    • com.android.server.pm.PackageSetting :单一包的信息
    • com.android.server.pm.BasePermission :系统中已有的权限
    • com.android.server.pm.PermissionState :授权状态

—————————————分隔符—————————————

  • PackageParser:包解析器
    • PackageParser.Package :解析得到的包信息
    • PackageParser.Component :组件的基类,其子类对应到AndroidManifest.xml中定义的不同组件
      • PackageParser.Activity 对应AndroidManifest.xml中定义<Activity>和<Receiver>标签
      • PackageParser.Service :对应AndroidManifest.xml中定义<Service/>标签
      • PackageParser.Provider :对应AndroidManifest.xml中定义<Provider/> 标签
      • PackageParser.Instrumentation :对应AndroidManifest.xml中定义<Instrumentation/> 标签
      • PackageParser.Permission :对应AndroidManifest.xml中定义<permission/> 标签
      • PackageParser.PermissionGroup :对应AndroidManifest.xml中定义<permission-group/> 标签
    • PackageLite :轻量的包信息
    • ApkLite :轻量级的APK信息
    • IntentInfo :组件所定义的<intent-filter/>信息,保存了每个<intent-filter/>节点的信息,是基类,它的子类是ActivityIntentInfo、ServiceIntentInfo和ProviderIntentInfo
      • ActivityIntentInfo :保存<activity/>和<Receiver/>节点下的<intent-filter/>节点
      • ServiceIntentInfo :保存<service/>节点下的<intent-filter/>节点
      • ProviderIntentInfo:保存<provider/> 节点下的<intent-filter/>节点
PackageParser的数据结构.png

—————————————分隔符—————————————

  • PackageInfo :跨进程传递的包数据,包解析时生成
    • PackageItemInfo :一个应用包内所有组件项和通用信息的基类。提供最基本的属性集,如:label、icon、meta-data等。
      • ApplicationInfo:代表一个特定应用的基本信息,对应AndroidManifest里面的<application>
      • InstrumentationInfo:用作进行instrumentation的测试的片段,对应AndroidManifest里面的<instrumentation>
      • PermissionInfo:代表一个特定的权限,对应AndroidManifest里面的<permission/>
      • PermissionGroupInfo :一个特定的权限组,对应AndroidManifest里面的<permission-group/>
      • ComponentInfo:代表一个应用内组件(如activityInfo、serviceInfo、ProviderInfo)通用信息的基类。一般不会直接使用该类,它设计为了不同应用的组件共享统一的定义。
        • ActivityInfo :对应AndroidManifest.xml里面的注册的<activity/>标签和<receiver/>标签。代表一个Activity或者receiver
        • ServiceInfo :对应AndroidManifest.xml里面的注册的<service/>标签。代表一个service
        • ProviderInfo :对应AndroidManifest.xml里面的注册的<service/>标签。代表一个Provider
  • Intent:根据特定的条件找到匹配的组件
  • IntentFilter :Intent过滤器
    • ResolveInfo
    • IntentResolver :Intent解析器,其子类用于不同组件的Intent解析
      保存了所有<activity/>或者<receiver/>节点信息。(Activity或者BroadcastReceiver信息就是用该自定义类保存的)
      • ActivityIntentResolver :保存所有<activity/>和<receiver/>节点信息。(Activity或者BroadcastReceiver信息就是用该自定义类保存的)
        保存了所有<service/>节点信息。(Service信息就是用该自定义类保存的)。
      • ServiceIntentResolver :保存了所有<service /> 节点信息。(Service信息就是用该自定义类保存的)
      • ProviderIntentReslover:保存了所有 <provider /> 节点信息
  • PackageHandler :包管理的消息处理器
    • HandlerParams :消息的数据载体
      • InstallParams : 用于APK的安装
      • MeasureParams:用于查询某个已安装的APK占据存储空间的大小(例如在设置程序中得到某个APK的缓存文件大小)
      • MoveParams :用于已安装APK的位置移动
    • InstallArgs :APK的安装参数
      • FileInstallArgs :针对是安装在内部存储的APK
      • AsecInstallArgs :针对安装在SD卡上的APK
      • MoveInfoArgs : 移动APK
        这么庞大的数据结构,其各个数据结构的类图如下:

数据结构.png

大图地址3

四、PackageManagerService的三大过程组

如果大家想对Android系统有一个大致的了解,就必须要要了解PackageManagerService的三大流程

  • 1、包扫描的过程组:
    即Android将一个APK文件的静态信息转化为可以管理的数据结构
  • 2、包安装的过程组:
    即包管理接纳一个新成员的体现。
  • 3、包查询的过程组:
    即Intent的定义和解析是包查询的核心,通过包查询服务可以获取到一个包的信息

下面我们来一一进行简单的介绍

(一)、包扫描过程组——即开机扫描过程

1、为什么要进行包扫描?

扫描目录的目的:

扫描Android系统的几个目标文件中的APK,从而建立合适的数据结构以及管理诸如Package信息、四大组件、授权信息等各种信息。抽象的地看,PackageManagerService像一个工厂,它解析实际的物理文件(APK文件),以及生成符合自己要求的产品。比如PackageManagerService将解析APK包中的AndroidManifest.xml,并根据其中声明的Activity标签来创建与此对应的对象,并保存到PackageParser.Package类型的变量中,然后通过PackageManagerService的scanPackageDirtyLI()方法将解析后的组件数据统计到PackageManagerService的本地变量中,用于管理查询调用,当系统中任意某个APK的package发生改变时,如卸载,升级等操作都会更新package的统计数据到PackageManagerService,PackageManagerService正式基于拥有系统中所有的Package的信息才能胜任"包管理"这个管理者的角色。PackageManagerService的工作流程相对简单,复杂的是其中用于保存各种信息的数据结构和它们的关联关系,以及对应影响结果的策略控制(比如系统应用和普通应用)

2、包扫描过程组的不同理解

如果把包扫描过程组看成一件事,那么这件事就是:

调用PackageManagerService类的静态方法main()方法来获取PackageManagerService对象

如果把包扫描过程组看成两件事,那么这两件事就是

1、创建PackageManagerService对象
2、将PackageManagerService向ServiceManager注册,即加入SMS,方便后续其他进程或者app通过ServiceManager获得PackageManagerService服务。

如果把包扫描过程组看成三件事,那么这三件事是:

1、先读取保存在packages.xml中记录的系统关机前记录所有安装的APP信息, 将其保存在PackageManagerServiced中mSettings中的mPackages中。
2、扫描指定的若干目录中的app,并把信息记录在PackageManagerServiced的mPackages中。
3、最后上面的两者进行对比,看是否有升级的APP,然后进行相关处理,最后写入package.xml中

当然换一个角度,以扫描角度来看,也可以把包扫描分解成另外三个阶段:

  • 扫描目标文件夹之前的准备工作
  • 扫描目标文件夹
  • 扫描目标文件夹之后的工作

如果把包扫描过程组看成四件事,那么这四件事是:

1、读取响应的配置文件
2、优化APK和Jar包
3、扫描系统中所有安装的应用
4、把扫描出的所有应用信息进行保存

如果把包扫描过程组划分的更细,则我将其分为6大步骤

  • 1、变量初始化,包括mSettings,mInstaller,mPackageDexOptimizer等等
  • 2、读取配置文件
  • 3、扫描系统Package,包含Dex优化
  • 4、保存扫描信息
  • 5、扫描非系统应用
  • 6、更新数据

如果把包扫描过程组划分的更细,则我将其分为9大步
第一步:创建Settings对象,并调用其addSharedUserLPw()方法,保存ShareUserSetting信息
第二步:创建Installer对象,用于Native进程installd交互
第三步:创建ThreadHandler线程,并以其Looper为参数创建PackageHandler对象,用于程序的安装和卸载
第四步:根据Installer对象和/data/user文件对象创建UserManager对象,用于多用户管理
第五步:调用readPermissions()方法,从/system/etc/permissions目录下的XML文件读取权限信息
第六步:调用Settings对象的readLPw()方法解析/data/system目录下的文件:
第七步:扫描/system/frameworks目录以及BOOTCLASSPATHplatform.xml定义的系统目录下的jar和APK文件是否需要dex优化,如果需要则调用Installer.dexopt()方法来发送消息给installd让它优化;如果任意一个文件执行了dex优化操作,删除/data/dalvik-cache目录下的缓存文件
第八步:创建AppDirObserver对象监听/system/frameworks、/system/app、/vendor/app(厂商定制)、/data/app、/data/app-private5个目录,并调用scanDirLI()方法扫描其中的APK文件:
第九步:汇总上面扫描XML和APK得到的信息,并写入文件;

3、如果把包扫描过程组划分为"方法级"的流程,如下图:

开机扫描流程.png

大图地址3

4、温馨提醒

  • 在packages.xml中<package>标签记录的APP的安装信息。有独立uid的APP,后面再反序列化的时候,会映射为PackageSetting对象,保存在mSettings的mPackages中;有sharedUid的APP,后面反序列化的时候,会映射为PendingPackage对象,保存在mSettings的mPendingPackages中。
  • 对于<share-user>标签记录的的share uid信息,封装为SharedUserSetting对象,保存到mSettings里面的mSharedUser中,在此过程中遇到的uid和 shared uid都保存在mUserIds中,并让每个uid指向与之关联的PackageSetting对象,或者SharedUserSetting对象

5、小结

  • PackageManagerService是伴随着系统进程启动而启动的,最终会构造一个PackageManagerService对象,此后,PackageManagerService将成为Android世界的包管理者,对外提供包的增、删、改、查的操作
  • 在PackageManagerService的启动过程中,最重要的是对所有静态APK文件进行扫描,生成一个在内存中的数据结构Package,PackageManagerService实际上就是维护这所有在内存中的数据结构。已有的包的历史信息会写入磁石,PackageManagerService的Settings专门来管理写入磁盘的包信息。
  • 所有包的信息扫描完成后,需要对应用进行授权,这是Android权限管理的一部分。随着 Android版本的升级,授权机制略有区别,总体框架是:每个APK都可以声明权限,并为权限设定保护级别,其他APK需要使用这些权限的时候,需要先申请,再由系统判定是否进行授权。

(二)、包安装的过程组——即安装一个新的APK

安装一个APK的其大致流程如下:


大致流程.png

通常,安装一个APK 通常分为以下4种方式

  • 安装系统应用
  • 网络下载应用安装
  • ADB工具安装
  • 第三方应用安装

下面我们就依次介绍下

1、 安装系统应用

系统的应用的安装主要在PackageManagerService的main方法里面进行操作的

其顺序如下:
第一步:PackageManagerService.main()初始化注册
第二步:建立Java层的installer与C层的intalld的socket联接
第三步:建立PackageHandler消息循环
第四步:调用成员变量mSettings的readLPw()方法恢复上一次的安装信息
第五步:.jar文件的detopt优化
第六步:scanDirLI函数扫描特定目录的APK文件解析
第七步:updatePermissionsLPw()函数分配权限
第八步:调用mSettings.writeLPr()保存安装信息

2、 网络下载应用安装

其顺序如下:
第一步:调用PackageManagerService的installPackage方法
第二步:上面的方法调用installPackageWithVerfication(),进行权限校验,发送INIT_COPY的msg
第三步:进入PackageManagerService的doHandleMessage方法的INIT_COPY分支
第四步:成功绑定了com.android.defcontainer.DefaultContainerService服务,进入MCS_BOUND分支
第五步:里面调用PackageManagerService中内部抽象类HandlerParams的子类InstallParams的startCopy方法。
第六步:抽象类的HandlerParams的startCopy方法调用了HandlerParams子类的handleStartCopy和handlerReturnCode两个方法
第七步:handlesStartCopy方法调用了InstallArgs的子类copyApk,它负责将下载的APK文件copy到/data/app
第八步:handleReturnCode调用handleReturnCode方法
第九步:调用PackageManagerService服务的installPackageLI(PackageParser.Package, int, int, UserHandle, String, String,PackageInstalledInfo)方法进行APK扫描。
第十步:上面的方法判断是否APP应安装,调用installNewPackageLI或replacePackageLI方法
第十一步:调用updateSettingsLI方法进行更新PackageManagerService的Settings
第十二步:发送what值为POST_INSTALL的Message给PackageHandler进行处理
第十三步:发送what值为MCS_UNBIND的Message给PackageHandler,进而调用PackageHandler.disconnectService()中断连接

3、 ADB工具安装

Android Debug Bridge (adb)是SDK自带的管理设备的工具,通过ADB命令的方式也可以为手机或者模拟器安装应用,其入口函数为pm.java

Android Debug Bridge (adb) 是SDK自带的管理设备的工具,通过ADB命令行的方式也可以为手机或模拟器安装应用,其入口函数源文件为pm.java

其顺序如下:
第一步:pm.java的runInstall()方法
第二步:参数不对会调用showUsage方法,弹出使用说明
第三步:正常情况runInstall会调用mPm变量的installPackageWithVerification方法
第四步:由于pm.java中的变量mPm是PackageManagerService的实例,所以实际上是调用PackageManagerService的installPackageWithVerfication()方法
第五步:进入PackageManagerService的doHandleMessage方法的INIT_COPY分支
第六步:成功绑定了com.android.defcontainer.DefaultContainerService服务,进入MCS_BOUND分支
第七步:里面调用PackageManagerService中内部抽象类HandlerParams的子类InstallParams的startCopy方法。
第八步:抽象类的HandlerParams的startCopy方法调用了HandlerParams子类的handleStartCopy和handlerReturnCode两个方法
第九步:handlesStartCopy方法调用了InstallArgs的子类copyApk,它负责将下载的APK文件copy到/data/app
第十步:handleReturnCode调用handleReturnCode方法
第十一步:调用PackageManagerService服务的installPackageLI(PackageParser.Package, int, int, UserHandle, String, String,PackageInstalledInfo)方法进行APK扫描。
第十二步:上面的方法判断是否APP应安装,调用installNewPackageLI或replacePackageLI方法
第十三步:调用updateSettingsLI方法进行更新PackageManagerService的Settings
第十四步:发送what值为POST_INSTALL的Message给PackageHandler进行处理
第十五步:发送what值为MCS_UNBIND的Message给PackageHandler,进而调用PackageHandler.disconnectService()中断连接

ADB安装.png
4、 第三方应用安装

第一步:调用PackageInstallerActivity的onCreate方法初始化安装界面
第二步:初始化界面以后调用initiateInstall方法
第三步:上面的方法调用startInstallConfirm方法,弹出确认和取消安装的按钮
第四步:点击确认按钮,打开新的activity:InstallAppProgress
第五步:InstallAppProgress类初始化带有进度条的界面之后,调用PackageManager的installPackage方法
第六步:PackageManager是PackageManagerService实例,所以就是调用PackageManagerService的installPackage方法
第七步:调用PackageManagerService的installPackage方法
第八步:上面的方法调用installPackageWithVerfication(),进行权限校验,发送INIT_COPY的msg
第九步:进入PackageManagerService的doHandleMessage方法的INIT_COPY分支
第十步:成功绑定了com.android.defcontainer.DefaultContainerService服务,进入MCS_BOUND分支
第十一步:里面调用PackageManagerService中内部抽象类HandlerParams的子类InstallParams的startCopy方法。
第十二步:抽象类的HandlerParams的startCopy方法调用了HandlerParams子类的handleStartCopy和handlerReturnCode两个方法
第十三步:handlesStartCopy方法调用了InstallArgs的子类copyApk,它负责将下载的APK文件copy到/data/app
第十四步:handleReturnCode调用handleReturnCode方法
第十五步:调用PackageManagerService服务的installPackageLI(PackageParser.Package, int, int, UserHandle, String, String,PackageInstalledInfo)方法进行APK扫描。
第十六步:上面的方法判断是否APP应安装,调用installNewPackageLI或replacePackageLI方法
第十七步:调用updateSettingsLI方法进行更新PackageManagerService的Settings
第十八步:发送what值为POST_INSTALL的Message给PackageHandler进行处理
第十九步:发送what值为MCS_UNBIND的Message给PackageHandler,进而调用PackageHandler.disconnectService()中断连接

流程.png

点击放大查看高清无码大图

小结:

  • 1、安装和卸载都是通过PackageManager,实质上是实现了PackageManagerService来完成具体的操作,所有细节和逻辑均可以在PackageManagerService中跟踪查看。
  • 2、所有安装方式殊途同归,最终就是回到PackageManagerService中,然后调用底层本地代码的installd来完成的。
  • 3、APK的安装过程主要分为以下几步:
    - 拷贝到apk文件到指定目录
    - 解压缩apk,拷贝文件,创建应用的数据目录
    - 解析apk的AndroidManifest.xml文件
    - 向Launcher应用申请添加创建快捷方式

(三)、包查询的过程组——即解析Intent并找到其配备的组件

1、包管理是以什么样的形式对外提供服务那?

在写应用程序时,我们通常会利用应用自身的上下文环境Context来获取包管理服务,如下:

// 获取一个PackageManager的对象实例
PackageManager pm = context.getPackageManager();
// 通过PackageManager对象获取指定包名的包信息
PackageInfo pi = pm.getPackageInfo("com.android.contacts", 0);

这么一段简单的代码,其实蕴含很多的深意

  • 1、上面已经讲解过了PackageManagerService和其管理的各种数据结构,都是运行在系统进程之中。在应用进程中获取的PackageManager对象,只是PackageManagerService在应用进程中的一个代理,不同的应用进程都有不同的代理,意味着不同应用进程中的PackageManager是不同的,但是管理者PackageManagerService有且只有一个
  • 2、运行在应用进程中的PackageManager要与运行在系统进程中的PackageManagerService进行通信,通信手段是Android中最常见的Binder机制。因此会有一个IPackageManager.aidl文件,用于描两者通信的接口。另外,应用进程中的PackageInfo对象。PackageInfo其实就是由系统进程传递到应用进程的对象
IPackageManager.png

PackageManagerService作为包管理的最核心组成部分,伴随着系统的启动而创建,并一直运行系统进程中。当应用程序需要获取包管理服务时,会生成一个PackageManager对PackageManagerService进行通信。在包解析时就会生成包信息,即XXInfo这一类数据结构,PackageManagerService将这些数据传递给需要的应用进程。

管理者对内设计了复杂的管理机制,对外封装了简单的使用接口。这种设计在Android中大量出现,比如ActivityManagerService、WindowManagerService、PowerManagerService等,基本所有的系统服务都遵循这种设计规范。对于应用程序而言,不需关心管理者的实现原理,只需要理解接口的使用场景

Android在全局定义了IPackageManager,接口,描述了包管理者对外提供的功能,运行在系统进程中的PackageManagerService实现了IPackageManager接口,作为包管理的服务端,客户端通过IPackageManager接口请求包服务。为了方便客户端进行包服务,Android做了多层的封装。应用进程作为客户端,通过PackageManager便可使用包服务,客户端实际存在的对象是ApplicationPackageManager,它封装了IPackageManager的所有接口。在应用进程来看,客户端和服务端的概念是模糊的,明确的只有运行环境的概念,即Context。包服务就存在于应用进程的运行环境中,需要时直接拿出来使用即可。

“运行环境(Context)”是Android的设计哲学之一,Android有意弱化进程,强化运行环境,这是面向应用开发者的设计。运行环境是什么并不是一个很好回到的问题。可以将其类比为我们的工作环境,当我们需要办公设备时,只需要向管理部门申请,并不需要关心办公设备如何采购,办公设备对一般的工作人员而言,就像是工作环境中天然存在的东西。

2、包管理的具体服务形式——Intent的解析:

在Android中,使用Intent来表达意图,最终会有一个响应者。当系统产生一个Intent后,如何找到它的响应者?这需要对Intent进行解析。作为所有包信息管理者的中枢,PackageManagerService自然有义务承担解析Intent的责任。要解析Intent,就需要了解Intent的结构,标识了一个Intent身份的信息由两部分构成:

  • 主要信息:主要信息Action和Data。Action用于表明Intent所要执行的操作,譬如ACTION_VIEW,ACTION_EDIT;Data用于表明执行操作的数据,譬如联系人数据,数据是以URI来表达的。再举两个Action和Data成对出现的例子:
    - ACTION_VIEW:content://contacts/people/1 :标识查看联系人数据库中,ID为1的联系人信息
    - ACTION_DIAL:tel:119 :表达拨打电话给119
    上面两个例子的URI并不一样,完整的URI格式为scheme://host:port/path
  • 次要信息:除了主要标记的信息,Intent还可以附加很多额外的信息,比如Category,Type,Componten和Extra:
    - Category:标识Intent的类别,譬如CATEGROY_LAUNCHER标识对属于左面的图标这一类的对象执行操作
    - Type:标识Intent所有操作的数据类型,就是MIMEType,譬如要操作PNG图片,那Type就可以设置为png
    - Component:标识Intent要操作的对象
    - Extra:标识Intent所传递的数据
    上述这些数据都实现了Parcelable接口。

之所以Intent信息的主次之分,是因为解析Intent的规则需要有一个依据,主要信息是最能表达意图的,而次要信息则是解析规则的一个补充。这就像大家在做自我介绍的时候,总是先说姓名、籍贯这些主要的信息,再额外补充爱好、特长这些次要信息,这样一来在和其他人交朋友的时候,其他人就可以先根据籍贯、姓名锁定我。如果我们只介绍爱好、特长,那么别人锁定的范围就比较广,因为有相同爱好或者特长的人比较多。

Intent身份信息,其实就是Android的一种设计语言,譬如"打电话给119",只需要发出Action为ACTION_DIAL,URI为“tel:119”的Intent即可,剩下的就交给Android系统去理解这个意图。任何组件只要按照规则发生,都会被Android系统正确的理解。

而根据Intent的方式不同,可以将Intent分为两类:

  • 显示(Explicit):明确指明需要谁来响应Intent。这一类Intent的解析过程比较简单
  • 隐式(Implicit):有系统找出合适的目标来响应Intent。这一类Intent的解析过程比较复杂,由于目标明确,所以需要经过层层筛选才能找到最合适的响应者。

之所以Intent有显式和隐式之分,是因为解析Intent的方式不同,如果我指定要和某某交朋友,那么发出的这一类请求,就是显式Intent;如果没有指定交朋友的对象,只是说找到跟我爱好相同的人,那发出的这一类请求,就是隐式的Intent。对待这两种Intent显然有不同的解析方式。

如果和"运行环境Context"一样,Intent也是面向应用程序设计,同样是弱化了了进程的概念。应用程序只需表明"我想要什么",不需要关心索要的东西在什么地方,如何找到索要的东西。Intent是Android通信的手段之一,可以承载要传递的信息,至于信息怎么从发起进程传递到目标进程,应用程序可以毫不关心。

Intent最后一个响应者是一个Android组件,Android组件都可以定义IntentFilter,前面说了包解析器的时候,说到了每一个Component类中都有一个IntentInfo对象的数组,而IntentInfo则是IntentFilter的子类。既然一个Android组件可以定义多个IntentFilter,那么Intent想要匹配到最终的组件,则需要通过组件所定义的所有IntentFilter:

IntentFilter.png

多个IntentFilter之间是"或"的关系,哪怕其他所有IntentFilter都匹配失败,只要有一个IntentFilter通过,最终Intent还是找到了可以响应的组件。

每一个IntentFilter就像是一个定义了白名单规则的过滤器,只有满足白名单的要求才会放行。Intent的过滤规则,其实就是针对Intent的身份信息的匹配规则,当Intent的身份信息与IntentFilter所规定的要求匹配上,则允许通过;否则,Intent就被过滤掉了。IntentFilter的过滤规则包含以下三个方面:

  • Action:每个IntentFilter可以定义零个或多个<action标签>,如果Intent想要通过这个IntentFilter,则Intent所辖的Action需要匹配其中至少一个。
  • Category:每一个IntentFilter可以定义零个或者多个<category>标签,如果Intent想要通过这个IntentFilter,则Intent所辖的Categroy必须是IntentFilter所定义的Category的子集,才能通过IntentFileter。譬如Intent设置了两个Category:CATEGORY_LAUNCHER和CATEGORY_MAIN,只有那些至少定义了两项Category的IntentFilter,才会放行该Intent。启动Activity时,会为Intent设置默认的Category,即CATEGORY_DEFAULT。目标Activity需要添加一个category伪CATEGORY_DEFAULT的IntentFilter来匹配这一类隐式的Intent。
  • Data:每一个IntentFilter可以定义零个或多个<data>,数据可以通过类型(MIMEType)和位置(URI)来描述,如果Intent想要通过这个IntentFilter,则Intent所辖的Data需要匹配其中至少一个。

在了解Intent的身份信息和IntentFilter的规则定义之后,就可以介绍Intent解析的过程了,PackageManagerService有四大组件的Intent解析器,分别是ActivityIntentResolver用于解析发往Activity或Broadcast的Intent,ServiceIntentResolver用于解析发往Service的Intent,ProviderIntentResolver用于解析发往Provider的Intent,系统每收到一个Intent的解析请求时,就会使用对应的解析器,他们都是IntentResolver的子类。

IntentResolver的职能就是解析Intent,它包含了所有IntentFilter,同时有一个重要的成员函数queryIntent(),接受Intent作为参数,返回查询结构:一个ResolveInfo对象的数据。因为可能有多个组件来响应一个Intent,所以返回结果是一个数组。可想而知,该函数就是针对输入的Intent,按照前面所述的过滤规则,逐个与IntentFilter进行匹配,直到找到最终的响应者,便加入返回结果的列表。

  • ResolveInfo是最终的Intent解析结果的数据结构,并不复杂,就是各类组件信息的一个包装。需要注意的是,其中的组件信息ActivityInfo、ProviderInfo、ServiceInfo只有一个不为空,这样就可以区分不同组件的解析结果。
  • 解析"显式"的Intent,如果Intent中有设置Component,则说明已经显式的指明由谁来响应Intent。根据Component可以获取到对应的 ActivityInfo,再封装成ResolveInfo便可以作为结果返回了。
  • 解析"隐式"的Intent,该处逻辑比较复杂,后面讲解Activity的启动流程时再详细讲解。

3、小结

  • 包管理对外提供服务的形式基于Bidner机制,服务端是运行在系统进程中的PackageManagerService,包查询服务是使用范围很广的一类服务,很多其他服务都需要用到包信息,都是通过PackageManagerService获取的。
  • 包查询服务的核心是Intent解析,PackageManagerService中实现了不同组件的解析器。针对一个输入的Intent,解析得到可以响应的组件。Android为此设计了IntentFilter机制,定义了Intent匹配规则,最终解析实现在IntentResolver.queryIntent()函数中

五、PackageManagerService的体系结构

image.png

大图地址

六、总结

本片文章主要讲解了包管理的三个大的过程:包扫描过程、包查询过程、包安装过程,其中重点的是包安装的过程。我们再来复习一下:

APK的安装流程如下:

复制APK安装包到/data/app目录下,解压缩并扫描安装包,向资源管理器注入APK资源,解析AndroidManifest文件,并在/data/data目录下创建对应的应用数据目录,然后针对Dalvik/ART环境优化dex文件,保存到dalvik-cache目录,将AndroidManifest文件解析出的组件、权限注册到PackageManagerService并发送广播

具体流程如下:

├── PMS.installPackage()
    └── PMS.installPackageAsUser()
         |传递 InstallParams 参数
        PackageHandler.doHandleMessage().INIT_COPY
         |
        PackageHandler.doHandleMessage().MCS_BOUND
         ├── HandlerParams.startCopy()
         │    ├── InstallParams.handleStartCopy()
         │    │    └──InstallArgs.copyApk()
         │    └── InstallParams.handleReturnCode()
         │         └── PMS.processPendingInstall()
         │              ├── InstallArgs.doPreInstall()
         │              ├── PMS.installPackageLI()
         │              │    ├── PackageParser.parsePackage()
         │              │    ├── PackageParser.collectCertificates()
         │              │    ├── PackageParser.collectManifestDigest()
         │              │    ├── PackageDexOptimizer.performDexOpt()
         │              │    ├── InstallArgs.doRename()
         │              │    │    └── InstallArgs.getNextCodePath()
         │              │    ├── replacePackageLI()
         │              │    │    ├── shouldCheckUpgradeKeySetLP()
         │              │    │    ├── compareSignatures()
         │              │    │    ├── replaceSystemPackageLI()
         │              │    │    │    ├── killApplication()
         │              │    │    │    ├── removePackageLI()
         │              │    │    │    ├── Settings.disableSystemPackageLPw()
         │              │    │    │    ├── createInstallArgsForExisting()
         │              │    │    │    ├── deleteCodeCacheDirsLI()
         │              │    │    │    ├── scanPackageLI()
         │              │    │    │    └── updateSettingsLI()
         │              │    │    └── replaceNonSystemPackageLI()
         │              │    │         ├── deletePackageLI()
         │              │    │         ├── deleteCodeCacheDirsLI()
         │              │    │         ├── scanPackageLI()
         │              │    │         └── updateSettingsLI()
         │              │    └── installNewPackageLI()
         │              │         ├── scanPackageLI()
         │              │         └── updateSettingsLI()
         │              ├── InstallArgs.doPostInstall()
         │              ├── BackupManager.restoreAtInstall()
         │              └── sendMessage(POST_INSTALL)
         │                   |
         │                  PackageHandler.doHandleMessage().POST_INSTALL
         │                   ├── grantRequestedRuntimePermissions()
         │                   ├── sendPackageBroadcast()
         │                   └── IPackageInstallObserver.onPackageInstalled()
         └── PackageHandler.doHandleMessage().MCS_UNBIND
              └── PackageHandler.disconnectService()

至此,整个APK安装流程详解全部说完,谢谢!

官人[飞吻],你都把臣妾从头看到尾了,喜欢就点个赞呗(眉眼)!!!!