Android应用程序组件Content Provider的启动过程源代码分析

时间：2022-03-21 14:39:56

文章转载至CSDN社区罗升阳的安卓之旅，原文地址：http://blog.csdn.net/luoshengyang/article/details/6963418

通过前面的学习，我们知道在Android系统中，Content Provider可以为不同的应用程序访问相同的数据提供统一的入口。Content Provider一般是运行在独立的进程中的，每一个Content Provider在系统中只有一个实例存在，其它应用程序首先要找到这个实例，然后才能访问它的数据。那么，系统中的Content Provider实例是由谁来负责启动的呢？本文将回答这个问题。

Content Provider和应用程序组件Activity、Service一样，需要在AndroidManifest.xml文件中配置之后才能使用。系统在安 装包含Content Provider的应用程序的时候，会把这些Content Provider的描述信息保存起来，其中最重要的就是Content Provider的Authority信息，Android应用程序的安装过程具体可以参考Android应用程序安装过程源代码分析一 文。注意，安装应用程序的时候，并不会把相应的Content Provider加载到内存中来，系统采取的是懒加载的机制，等到第一次要使用这个Content Provider的时候，系统才会把它加载到内存中来，下次再要使用这个Content Provider的时候，就可以直接返回了。

本文以前面一篇文章Android应用程序组件Content Provider应用实例中的例子来详细分析Content Provider的启动过程。在Android应用程序组件Content Provider应用实例这 篇文章介绍的应用程序Article中，第一次使用ArticlesProvider这个Content Provider的地方是ArticlesAdapter类的getArticleCount函数，因为MainActivity要在ListView中 显示文章信息列表时， 首先要知道ArticlesProvider中的文章信息的数量。从ArticlesAdapter类的getArticleCount函数调用开始，一 直到ArticlesProvider类的onCreate函数被调用，就是ArticlesProvider的完整启动过程，下面我们就先看看这个过程 的序列图，然后再详细分析每一个步骤：

Android应用程序组件Content Provider的启动过程源代码分析

Step 1. ArticlesAdapter.getArticleCount

这个函数定义在前面一篇文章Android应用程序组件Content Provider应用实例介绍的应用程序Artilce源代码工程目录下，在文件为packages/experimental/Article/src/shy/luo/article/ArticlesAdapter.java中：

  1. public class ArticlesAdapter {
  2. ......
  3. private ContentResolver resolver = null;
  4. public ArticlesAdapter(Context context) {
  5. resolver = context.getContentResolver();
  6. }
  7. ......
  8. public int getArticleCount() {
  9. int count = 0;
  10. try {
  11. IContentProvider provider = resolver.acquireProvider(Articles.CONTENT_URI);
  12. Bundle bundle = provider.call(Articles.METHOD_GET_ITEM_COUNT, null, null);
  13. count = bundle.getInt(Articles.KEY_ITEM_COUNT, 0);
  14. } catch(RemoteException e) {
  15. e.printStackTrace();
  16. }
  17. return count;
  18. }
  19. ......
  20. }

这个函数通过应用程序上下文的ContentResolver接口resolver的acquireProvider函数来获得与 Articles.CONTENT_URI对应的Content Provider对象的IContentProvider接口。常量Articles.CONTENT_URI是在应用程序 ArticlesProvider中定义的，它的值为“content://shy.luo.providers.articles/item”，对应的 Content Provider就是ArticlesProvider了。

Step 2. ContentResolver.acqireProvider

这个函数定义在frameworks/base/core/java/android/content/ContentResolver.java文件中：

  1. public abstract class ContentResolver {
  2. ......
  3. public final IContentProvider acquireProvider(Uri uri) {
  4. if (!SCHEME_CONTENT.equals(uri.getScheme())) {
  5. return null;
  6. }
  7. String auth = uri.getAuthority();
  8. if (auth != null) {
  9. return acquireProvider(mContext, uri.getAuthority());
  10. }
  11. return null;
  12. }
  13. ......
  14. }

函数首先验证参数uri的scheme是否正确，即是否是以content://开头，然后取出它的authority部分，最后调用另外一个成员函数
acquireProvider执行获取ContentProvider接口的操作。在我们这个情景中，参数uri的authority的内容便是
“shy.luo.providers.articles”了。

从ContentResolver类的定义我们可以看出，它是一个抽象类，两个参数版本的acquireProvider函数是由它的子类来实现的。回
到Step
1中，这个ContentResolver接口是通过应用程序上下文Context对象的getContentResolver函数来获得的，而应用程序
上下文Context是由ContextImpl类来实现的，它定义在frameworks/base/core/java/android/app
/ContextImpl.java文件中：

  1. class ContextImpl extends Context {
  2. ......
  3. private ApplicationContentResolver mContentResolver;
  4. ......
  5. final void init(LoadedApk packageInfo,
  6. IBinder activityToken, ActivityThread mainThread,
  7. Resources container) {
  8. ......
  9. mContentResolver = new ApplicationContentResolver(this, mainThread);
  10. ......
  11. }
  12. ......
  13. @Override
  14. public ContentResolver getContentResolver() {
  15. return mContentResolver;
  16. }
  17. ......
  18. }

ContextImpl类的init函数是在应用程序启动的时候调用的，具体可以参考Android应用程序启动过程源代码分析一文中的Step 34。

因此，在上面的ContentResolver类的acquireProvider函数里面接下来要调用的ApplicationContentResolver类的acquireProvider函数。

Step 3. ApplicationContentResolve.acquireProvider

这个函数定义在frameworks/base/core/java/android/app/ContextImpl.java文件中：

  1. class ContextImpl extends Context {
  2. ......
  3. private static final class ApplicationContentResolver extends ContentResolver {
  4. ......
  5. @Override
  6. protected IContentProvider acquireProvider(Context context, String name) {
  7. return mMainThread.acquireProvider(context, name);
  8. }
  9. ......
  10. private final ActivityThread mMainThread;
  11. }
  12. ......
  13. }

它调用ActivityThread类的acquireProvider函数进一步执行获取Content Provider接口的操作。

Step 4. ActivityThread.acquireProvider

这个函数定义在frameworks/base/core/java/android/app/ActivityThread.java文件中：

  1. public final class ActivityThread {
  2. ......
  3. public final IContentProvider acquireProvider(Context c, String name) {
  4. IContentProvider provider = getProvider(c, name);
  5. if(provider == null)
  6. return null;
  7. ......
  8. return provider;
  9. }
  10. ......
  11. }

它又是调用了另外一个成员函数getProvider来进一步执行获取Content Provider接口的操作。

Step 5. ActivityThread.getProvider

这个函数定义在frameworks/base/core/java/android/app/ActivityThread.java文件中：

  1. public final class ActivityThread {
  2. ......
  3. private final IContentProvider getExistingProvider(Context context, String name) {
  4. synchronized(mProviderMap) {
  5. final ProviderClientRecord pr = mProviderMap.get(name);
  6. if (pr != null) {
  7. return pr.mProvider;
  8. }
  9. return null;
  10. }
  11. }
  12. ......
  13. private final IContentProvider getProvider(Context context, String name) {
  14. IContentProvider existing = getExistingProvider(context, name);
  15. if (existing != null) {
  16. return existing;
  17. }
  18. IActivityManager.ContentProviderHolder holder = null;
  19. try {
  20. holder = ActivityManagerNative.getDefault().getContentProvider(
  21. getApplicationThread(), name);
  22. } catch (RemoteException ex) {
  23. }
  24. IContentProvider prov = installProvider(context, holder.provider,
  25. holder.info, true);
  26. ......
  27. return prov;
  28. }
  29. ......
  30. }

这个函数首先会通过getExistingProvider函数来检查本地是否已经存在这个要获取的ContentProvider接口，如果存在，就直
接返回了。本地已经存在的ContextProvider接口保存在ActivityThread类的mProviderMap成员变量中，以
ContentProvider对应的URI的authority为键值保存。在我们这个情景中，因为是第一次调用ArticlesProvider接
口，因此，这时候通过getExistingProvider函数得到的IContentProvider接口为null，于是下面就会调用
ActivityManagerService服务的getContentProvider接口来获取一个ContentProviderHolder对
象holder，这个对象就包含了我们所要获取的ArticlesProvider接口，在将这个接口返回给调用者之后，还会调用
installProvider函数来把这个接口保存在本地中，以便下次要使用这个ContentProvider接口时，直接就可以通过
getExistingProvider函数获取了。

我们先进入到ActivityManagerService服务的getContentProvider函数中看看它是如何获取我们所需要的ArticlesProvider接口的，然后再返回来看看installProvider函数的实现。

Step 6. ActivityManagerService.getContentProvider

这个函数定义在frameworks/base/services/java/com/android/server/am/ActivityManagerService.java文件中：

  1. public final class ActivityManagerService extends ActivityManagerNative
  2. implements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback {
  3. ......
  4. public final ContentProviderHolder getContentProvider(
  5. IApplicationThread caller, String name) {
  6. ......
  7. return getContentProviderImpl(caller, name);
  8. }
  9. ......
  10. }

它调用getContentProviderImpl函数来进一步执行操作。

Step 7. ActivityManagerService.getContentProviderImpl

这个函数定义在frameworks/base/services/java/com/android/server/am/ActivityManagerService.java文件中：

  1. public final class ActivityManagerService extends ActivityManagerNative
  2. implements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback {
  3. ......
  4. private final ContentProviderHolder getContentProviderImpl(
  5. IApplicationThread caller, String name) {
  6. ContentProviderRecord cpr;
  7. ProviderInfo cpi = null;
  8. synchronized(this) {
  9. ProcessRecord r = null;
  10. if (caller != null) {
  11. r = getRecordForAppLocked(caller);
  12. ......
  13. }
  14. // First check if this content provider has been published...
  15. cpr = mProvidersByName.get(name);
  16. if (cpr != null) {
  17. ......
  18. } else {
  19. try {
  20. cpi = AppGlobals.getPackageManager().
  21. resolveContentProvider(name,
  22. STOCK_PM_FLAGS | PackageManager.GET_URI_PERMISSION_PATTERNS);
  23. } catch (RemoteException ex) {
  24. }
  25. ......
  26. }
  27. cpr = mProvidersByClass.get(cpi.name);
  28. final boolean firstClass = cpr == null;
  29. if (firstClass) {
  30. try {
  31. ApplicationInfo ai =
  32. AppGlobals.getPackageManager().
  33. getApplicationInfo(
  34. cpi.applicationInfo.packageName,
  35. STOCK_PM_FLAGS);
  36. ......
  37. cpr = new ContentProviderRecord(cpi, ai);
  38. } catch (RemoteException ex) {
  39. // pm is in same process, this will never happen.
  40. }
  41. }
  42. if (r != null && cpr.canRunHere(r)) {
  43. // If this is a multiprocess provider, then just return its
  44. // info and allow the caller to instantiate it.  Only do
  45. // this if the provider is the same user as the caller's
  46. // process, or can run as root (so can be in any process).
  47. return cpr;
  48. }
  49. ......
  50. // This is single process, and our app is now connecting to it.
  51. // See if we are already in the process of launching this
  52. // provider.
  53. final int N = mLaunchingProviders.size();
  54. int i;
  55. for (i=0; i<N; i++) {
  56. if (mLaunchingProviders.get(i) == cpr) {
  57. break;
  58. }
  59. }
  60. // If the provider is not already being launched, then get it
  61. // started.
  62. if (i >= N) {
  63. final long origId = Binder.clearCallingIdentity();
  64. ProcessRecord proc = startProcessLocked(cpi.processName,
  65. cpr.appInfo, false, 0, "content provider",
  66. new ComponentName(cpi.applicationInfo.packageName,
  67. cpi.name), false);
  68. ......
  69. mLaunchingProviders.add(cpr);
  70. ......
  71. }
  72. // Make sure the provider is published (the same provider class
  73. // may be published under multiple names).
  74. if (firstClass) {
  75. mProvidersByClass.put(cpi.name, cpr);
  76. }
  77. cpr.launchingApp = proc;
  78. mProvidersByName.put(name, cpr);
  79. ......
  80. }
  81. // Wait for the provider to be published...
  82. synchronized (cpr) {
  83. while (cpr.provider == null) {
  84. ......
  85. try {
  86. cpr.wait();
  87. } catch (InterruptedException ex) {
  88. }
  89. }
  90. }
  91. return cpr;
  92. }
  93. ......
  94. }

这个函数比较长，我们一步一步地分析。
        函数首先是获取调用者的进程记录块信息：

  1. ProcessRecord r = null;
  2. if (caller != null) {
  3. r = getRecordForAppLocked(caller);
  4. ......
  5. }

在我们这个情景中，要获取的就是应用程序Article的进程记录块信息了，后面会用到。

在ActivityManagerService中，有两个成员变量是用来保存系统中的Content
Provider信息的，一个是mProvidersByName，一个是mProvidersByClass，前者是以Content
Provider的authoriry值为键值来保存的，后者是以Content Provider的类名为键值来保存的。一个Content
Provider可以有多个authority，而只有一个类来和它对应，因此，这里要用两个Map来保存，这里为了方便根据不同条件来快速查找而设计
的。下面的代码就是用来检查要获取的Content Provider是否已经加存在的了：

  1. // First check if this content provider has been published...
  2. cpr = mProvidersByName.get(name);
  3. if (cpr != null) {
  4. ......
  5. } else {
  6. try {
  7. cpi = AppGlobals.getPackageManager().
  8. resolveContentProvider(name,
  9. STOCK_PM_FLAGS | PackageManager.GET_URI_PERMISSION_PATTERNS);
  10. } catch (RemoteException ex) {
  11. }
  12. ......
  13. }
  14. cpr = mProvidersByClass.get(cpi.name);
  15. final boolean firstClass = cpr == null;
  16. if (firstClass) {
  17. try {
  18. ApplicationInfo ai =
  19. AppGlobals.getPackageManager().
  20. getApplicationInfo(
  21. cpi.applicationInfo.packageName,
  22. STOCK_PM_FLAGS);
  23. ......
  24. cpr = new ContentProviderRecord(cpi, ai);
  25. } catch (RemoteException ex) {
  26. // pm is in same process, this will never happen.
  27. }
  28. }

在我们这个情景中，由于是第一次调用ArticlesProvider接口，因此，在mProvidersByName和
mProvidersByClass两个Map中都不存在ArticlesProvider的相关信息，因此，这里会通过
AppGlobals.getPackageManager函数来获得PackageManagerService服务接口，然后分别通过它的
resolveContentProvider和getApplicationInfo函数来分别获取ArticlesProvider应用程序的相关信
息，分别保存在cpi和cpr这两个本地变量中。这些信息都是在安装应用程序的过程中保存下来的，具体可以参考Android应用程序安装过程源代码分析一文。

接下去这个代码判断当前要获取的Content Provider是否允许在客户进程中加载，即查看一个这个Content
Provider否配置了multiprocess属性为true，如果允许在客户进程中加载，就直接返回了这个Content
Provider的信息了：

  1. if (r != null && cpr.canRunHere(r)) {
  2. // If this is a multiprocess provider, then just return its
  3. // info and allow the caller to instantiate it.  Only do
  4. // this if the provider is the same user as the caller's
  5. // process, or can run as root (so can be in any process).
  6. return cpr;
  7. }

在我们这个情景中，要获取的ArticlesProvider设置了要在独立的进程中运行，因此，继续往下执行：

  1. // This is single process, and our app is now connecting to it.
  2. // See if we are already in the process of launching this
  3. // provider.
  4. final int N = mLaunchingProviders.size();
  5. int i;
  6. for (i=0; i<N; i++) {
  7. if (mLaunchingProviders.get(i) == cpr) {
  8. break;
  9. }
  10. }

系统中所有正在加载的Content
Provider都保存在mLaunchingProviders成员变量中。在加载相应的Content
Provider之前，首先要判断一下它是可否正在被其它应用程序加载，如果是的话，就不用重复加载了。在我们这个情景中，没有其它应用程序也正在加载
ArticlesProvider这个Content Provider，继续往前执行：

  1. // If the provider is not already being launched, then get it
  2. // started.
  3. if (i >= N) {
  4. final long origId = Binder.clearCallingIdentity();
  5. ProcessRecord proc = startProcessLocked(cpi.processName,
  6. cpr.appInfo, false, 0, "content provider",
  7. new ComponentName(cpi.applicationInfo.packageName,
  8. cpi.name), false);
  9. ......
  10. mLaunchingProviders.add(cpr);
  11. ......
  12. }

这里的条件i >= N为true，就表明没有其它应用程序正在加载这个Content
Provider，因此，就要调用startProcessLocked函数来启动一个新的进程来加载这个Content
Provider对应的类了，然后把这个正在加载的信息增加到mLaunchingProviders中去。我们先接着分析这个函数，然后再来看在新进程
中加载Content Provider的过程，继续往下执行：

  1. // Make sure the provider is published (the same provider class
  2. // may be published under multiple names).
  3. if (firstClass) {
  4. mProvidersByClass.put(cpi.name, cpr);
  5. }
  6. cpr.launchingApp = proc;
  7. mProvidersByName.put(name, cpr);

这段代码把这个Content Provider的信息分别保存到mProvidersByName和mProviderByCalss两个Map中去，以方便后续查询。

因为我们需要获取的Content
Provider是在新的进程中加载的，而getContentProviderImpl这个函数是在系统进程中执行的，它必须要等到要获取的
Content
Provider是在新的进程中加载完成后才能返回，这样就涉及到进程同步的问题了。这里使用的同步方法是不断地去检查变量cpr的provider域是
否被设置了。当要获取的Content
Provider在新的进程加载完成之后，它会通过Binder进程间通信机制调用到系统进程中，把这个cpr变量的provider域设置为已经加载好
的Content
Provider接口，这时候，函数getContentProviderImpl就可以返回了。下面的代码就是用来等待要获取的Content
Provider是在新的进程中加载完成的：

  1. // Wait for the provider to be published...
  2. synchronized (cpr) {
  3. while (cpr.provider == null) {
  4. ......
  5. try {
  6. cpr.wait();
  7. } catch (InterruptedException ex) {
  8. }
  9. }
  10. }

下面我们再分析在新进程中加载ArticlesProvider这个Content Provider的过程。

Step 8. ActivityManagerService.startProcessLocked

Step 9. Process.start

Step 10. ActivityThread.main

Step 11. ActivityThread.attach

Step 12. ActivityManagerService.attachApplication

这五步是标准的Android应用程序启动步骤，具体可以参考Android应用程序启动过程源代码分析一文中的Step 23到Step 27，或者Android系统在新进程中启动自定义服务过程（startService）的原理分析一文中的Step 4到Step 9，这里就不再详细描述了。

Step 13. ActivityManagerService.attachApplicationLocked

这个函数定义在frameworks/base/services/java/com/android/server/am/ActivityManagerService.java文件中：

  1. public final class ActivityManagerService extends ActivityManagerNative
  2. implements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback {
  3. ......
  4. private final boolean attachApplicationLocked(IApplicationThread thread,
  5. int pid) {
  6. // Find the application record that is being attached...  either via
  7. // the pid if we are running in multiple processes, or just pull the
  8. // next app record if we are emulating process with anonymous threads.
  9. ProcessRecord app;
  10. if (pid != MY_PID && pid >= 0) {
  11. synchronized (mPidsSelfLocked) {
  12. app = mPidsSelfLocked.get(pid);
  13. }
  14. } else if (mStartingProcesses.size() > 0) {
  15. ......
  16. } else {
  17. ......
  18. }
  19. ......
  20. app.thread = thread;
  21. app.curAdj = app.setAdj = -100;
  22. app.curSchedGroup = Process.THREAD_GROUP_DEFAULT;
  23. app.setSchedGroup = Process.THREAD_GROUP_BG_NONINTERACTIVE;
  24. app.forcingToForeground = null;
  25. app.foregroundServices = false;
  26. app.debugging = false;
  27. ......
  28. boolean normalMode = mProcessesReady || isAllowedWhileBooting(app.info);
  29. List providers = normalMode ? generateApplicationProvidersLocked(app) : null;
  30. try {
  31. ......
  32. thread.bindApplication(processName, app.instrumentationInfo != null
  33. ? app.instrumentationInfo : app.info, providers,
  34. app.instrumentationClass, app.instrumentationProfileFile,
  35. app.instrumentationArguments, app.instrumentationWatcher, testMode,
  36. isRestrictedBackupMode || !normalMode,
  37. mConfiguration, getCommonServicesLocked());
  38. ......
  39. } catch (Exception e) {
  40. ......
  41. }
  42. ......
  43. return true;
  44. }
  45. ......
  46. private final List generateApplicationProvidersLocked(ProcessRecord app) {
  47. List providers = null;
  48. try {
  49. providers = AppGlobals.getPackageManager().
  50. queryContentProviders(app.processName, app.info.uid,
  51. STOCK_PM_FLAGS | PackageManager.GET_URI_PERMISSION_PATTERNS);
  52. } catch (RemoteException ex) {
  53. }
  54. if (providers != null) {
  55. final int N = providers.size();
  56. for (int i=0; i<N; i++) {
  57. ProviderInfo cpi =
  58. (ProviderInfo)providers.get(i);
  59. ContentProviderRecord cpr = mProvidersByClass.get(cpi.name);
  60. if (cpr == null) {
  61. cpr = new ContentProviderRecord(cpi, app.info);
  62. mProvidersByClass.put(cpi.name, cpr);
  63. }
  64. app.pubProviders.put(cpi.name, cpr);
  65. app.addPackage(cpi.applicationInfo.packageName);
  66. ensurePackageDexOpt(cpi.applicationInfo.packageName);
  67. }
  68. }
  69. return providers;
  70. }
  71. ......
  72. }

这个函数首先是根据传进来的进程ID找到相应的进程记录块，注意，这个进程ID是应用程序ArticlesProvider的ID，然后对这个进程记录
块做一些初倾始化的工作。再接下来通过调用generateApplicationProvidersLocked获得需要在这个过程中加载的
Content Provider列表，在我们这个情景中，就只有ArticlesProvider这个Content
Provider了。最后调用从参数传进来的IApplicationThread对象thread的bindApplication函数来执行一些应用
程序初始化工作。从Android应用程序启动过程源代码分析一
文中我们知道，在Android系统中，每一个应用程序进程都加载了一个ActivityThread实例，在这个ActivityThread实例里
面，有一个成员变量mAppThread，它是一个Binder对象，类型为ApplicationThread，实现了
IApplicationThread接口，它是专门用来和ActivityManagerService服务进行通信的。因此，调用下面语句：

  1. thread.bindApplication(processName, app.instrumentationInfo != null
  2. ? app.instrumentationInfo : app.info, providers,
  3. app.instrumentationClass, app.instrumentationProfileFile,
  4. app.instrumentationArguments, app.instrumentationWatcher, testMode,
  5. isRestrictedBackupMode || !normalMode,
  6. mConfiguration, getCommonServicesLocked());

就会进入到应用程序ArticlesProvider进程中的ApplicationThread对象的bindApplication函数中去。在我们这个情景场，这个函数调用中最重要的参数便是第三个参数providers了，它是我们要处理的对象。

Step 14. ApplicationThread.bindApplication

这个函数定义在frameworks/base/core/java/android/app/ActivityThread.java文件中：

  1. public final class ActivityThread {
  2. ......
  3. private final class ApplicationThread extends ApplicationThreadNative {
  4. ......
  5. public final void bindApplication(String processName,
  6. ApplicationInfo appInfo, List<ProviderInfo> providers,
  7. ComponentName instrumentationName, String profileFile,
  8. Bundle instrumentationArgs, IInstrumentationWatcher instrumentationWatcher,
  9. int debugMode, boolean isRestrictedBackupMode, Configuration config,
  10. Map<String, IBinder> services) {
  11. if (services != null) {
  12. // Setup the service cache in the ServiceManager
  13. ServiceManager.initServiceCache(services);
  14. }
  15. AppBindData data = new AppBindData();
  16. data.processName = processName;
  17. data.appInfo = appInfo;
  18. data.providers = providers;
  19. data.instrumentationName = instrumentationName;
  20. data.profileFile = profileFile;
  21. data.instrumentationArgs = instrumentationArgs;
  22. data.instrumentationWatcher = instrumentationWatcher;
  23. data.debugMode = debugMode;
  24. data.restrictedBackupMode = isRestrictedBackupMode;
  25. data.config = config;
  26. queueOrSendMessage(H.BIND_APPLICATION, data);
  27. }
  28. ......
  29. }
  30. ......
  31. }

这个函数把相关的信息都封装成一个AppBindData对象，然后以一个消息的形式发送到主线程的消息队列中去等等待处理。这个消息最终是是在ActivityThread类的handleBindApplication函数中进行处理的。

Step 15. ActivityThread.handleBindApplication

这个函数定义在frameworks/base/core/java/android/app/ActivityThread.java文件中：

  1. public final class ActivityThread {
  2. ......
  3. private final void handleBindApplication(AppBindData data) {
  4. ......
  5. List<ProviderInfo> providers = data.providers;
  6. if (providers != null) {
  7. installContentProviders(app, providers);
  8. ......
  9. }
  10. ......
  11. }
  12. ......
  13. }

这个函数的内容比较多，我们忽略了其它无关的部分，只关注和Content Provider有关的逻辑，这里主要就是调用installContentProviders函数来在本地安装Content Providers信息。

Step 16. ActivityThread.installContentProviders

这个函数定义在frameworks/base/core/java/android/app/ActivityThread.java文件中：

  1. public final class ActivityThread {
  2. ......
  3. private final void installContentProviders(
  4. Context context, List<ProviderInfo> providers) {
  5. final ArrayList<IActivityManager.ContentProviderHolder> results =
  6. new ArrayList<IActivityManager.ContentProviderHolder>();
  7. Iterator<ProviderInfo> i = providers.iterator();
  8. while (i.hasNext()) {
  9. ProviderInfo cpi = i.next();
  10. StringBuilder buf = new StringBuilder(128);
  11. buf.append("Pub ");
  12. buf.append(cpi.authority);
  13. buf.append(": ");
  14. buf.append(cpi.name);
  15. Log.i(TAG, buf.toString());
  16. IContentProvider cp = installProvider(context, null, cpi, false);
  17. if (cp != null) {
  18. IActivityManager.ContentProviderHolder cph =
  19. new IActivityManager.ContentProviderHolder(cpi);
  20. cph.provider = cp;
  21. results.add(cph);
  22. // Don't ever unload this provider from the process.
  23. synchronized(mProviderMap) {
  24. mProviderRefCountMap.put(cp.asBinder(), new ProviderRefCount(10000));
  25. }
  26. }
  27. }
  28. try {
  29. ActivityManagerNative.getDefault().publishContentProviders(
  30. getApplicationThread(), results);
  31. } catch (RemoteException ex) {
  32. }
  33. }
  34. ......
  35. }

这个函数主要是做了两件事情，一是调用installProvider来在本地安装每一个Content
Proivder的信息，并且为每一个Content
Provider创建一个ContentProviderHolder对象来保存相关的信息。ContentProviderHolder对象是一个
Binder对象，是用来把Content Provider的信息传递给ActivityManagerService服务的。当这些Content
Provider都处理好了以后，还要调用ActivityManagerService服务的publishContentProviders函数来通
知ActivityManagerService服务，这个进程中所要加载的Content
Provider，都已经准备完毕了，而ActivityManagerService服务的publishContentProviders函数的作用
就是用来唤醒在前面Step
7等待的线程的了。我们先来看installProvider的实现，然后再来看ActivityManagerService服务的
publishContentProviders函数的实现。

Step 17. ActivityThread.installProvider

这个函数定义在frameworks/base/core/java/android/app/ActivityThread.java文件中：

  1. public final class ActivityThread {
  2. ......
  3. private final IContentProvider installProvider(Context context,
  4. IContentProvider provider, ProviderInfo info, boolean noisy) {
  5. ContentProvider localProvider = null;
  6. if (provider == null) {
  7. ......
  8. Context c = null;
  9. ApplicationInfo ai = info.applicationInfo;
  10. if (context.getPackageName().equals(ai.packageName)) {
  11. c = context;
  12. } else if (mInitialApplication != null &&
  13. mInitialApplication.getPackageName().equals(ai.packageName)) {
  14. c = mInitialApplication;
  15. } else {
  16. try {
  17. c = context.createPackageContext(ai.packageName,
  18. Context.CONTEXT_INCLUDE_CODE);
  19. } catch (PackageManager.NameNotFoundException e) {
  20. }
  21. }
  22. ......
  23. try {
  24. final java.lang.ClassLoader cl = c.getClassLoader();
  25. localProvider = (ContentProvider)cl.
  26. loadClass(info.name).newInstance();
  27. provider = localProvider.getIContentProvider();
  28. ......
  29. // XXX Need to create the correct context for this provider.
  30. localProvider.attachInfo(c, info);
  31. } catch (java.lang.Exception e) {
  32. ......
  33. }
  34. } else if (localLOGV) {
  35. ......
  36. }
  37. synchronized (mProviderMap) {
  38. // Cache the pointer for the remote provider.
  39. String names[] = PATTERN_SEMICOLON.split(info.authority);
  40. for (int i=0; i<names.length; i++) {
  41. ProviderClientRecord pr = new ProviderClientRecord(names[i], provider,
  42. localProvider);
  43. try {
  44. provider.asBinder().linkToDeath(pr, 0);
  45. mProviderMap.put(names[i], pr);
  46. } catch (RemoteException e) {
  47. return null;
  48. }
  49. }
  50. if (localProvider != null) {
  51. mLocalProviders.put(provider.asBinder(),
  52. new ProviderClientRecord(null, provider, localProvider));
  53. }
  54. }
  55. return provider;
  56. }
  57. ......
  58. }

这个函数的作用主要就是在应用程序进程中把相应的Content
Provider类加载进来了，在我们这个种情景中，就是要在ArticlesProvider这个应用程序中把ArticlesProvider这个
Content Provider类加载到内存中来了：

  1. final java.lang.ClassLoader cl = c.getClassLoader();
  2. localProvider = (ContentProvider)cl.
  3. loadClass(info.name).newInstance();

接着通过调用localProvider的getIContentProvider函数来获得一个Binder对象，这个Binder对象返回给
installContentProviders函数之后，就会传到ActivityManagerService中去，后续其它应用程序就是通过获得这
个Binder对象来和相应的Content
Provider进行通信的了。我们先看一下这个函数的实现，然后再回到installProvider函数中继续分析。

Step 18. ContentProvider.getIContentProvider

这个函数定义在frameworks/base/core/java/android/content/ContentProvider.java文件中：

  1. public abstract class ContentProvider implements ComponentCallbacks {
  2. ......
  3. private Transport mTransport = new Transport();
  4. ......
  5. class Transport extends ContentProviderNative {
  6. ......
  7. }
  8. public IContentProvider getIContentProvider() {
  9. return mTransport;
  10. }
  11. ......
  12. }

从这里我们可以看出，ContentProvider类和Transport类的关系就类似于ActivityThread和
ApplicationThread的关系，其它应用程序不是直接调用ContentProvider接口来访问它的数据，而是通过调用它的内部对象
mTransport来间接调用ContentProvider的接口，这一点我们在下一篇文章中分析调用Content
Provider接口来获取共享数据时将会看到。
        回到前面的installProvider函数中，它接下来调用下面接口来初始化刚刚加载好的Content Provider：

  1. // XXX Need to create the correct context for this provider.
  2. localProvider.attachInfo(c, info);

同样，我们先进入到ContentProvider类的attachInfo函数去看看它的实现，然后再回到installProvider函数来。

Step 19. ContentProvider.attachInfo

这个函数定义在frameworks/base/core/java/android/content/ContentProvider.java文件中：

  1. public abstract class ContentProvider implements ComponentCallbacks {
  2. ......
  3. public void attachInfo(Context context, ProviderInfo info) {
  4. /*
  5. * Only allow it to be set once, so after the content service gives
  6. * this to us clients can't change it.
  7. */
  8. if (mContext == null) {
  9. mContext = context;
  10. mMyUid = Process.myUid();
  11. if (info != null) {
  12. setReadPermission(info.readPermission);
  13. setWritePermission(info.writePermission);
  14. setPathPermissions(info.pathPermissions);
  15. mExported = info.exported;
  16. }
  17. ContentProvider.this.onCreate();
  18. }
  19. }
  20. ......
  21. }

这个函数很简单，主要就是根据这个Content
Provider的信息info来设置相应的读写权限，然后调用它的子类的onCreate函数来让子类执行一些初始化的工作。在我们这个情景中，这个子
类就是ArticlesProvide应用程序中的ArticlesProvider类了。

Step 20. ArticlesProvider.onCreate

这个函数定义在前面一篇文章Android应用程序组件Content Provider应用实例介
绍的应用程序ArtilcesProvider源代码工程目录下，在文件为packages/experimental
/ArticlesProvider/src/shy/luo/providers/articles/ArticlesProvider.java中：

  1. public class ArticlesProvider extends ContentProvider {
  2. ......
  3. @Override
  4. public boolean onCreate() {
  5. Context context = getContext();
  6. resolver = context.getContentResolver();
  7. dbHelper = new DBHelper(context, DB_NAME, null, DB_VERSION);
  8. return true;
  9. }
  10. ......
  11. }

这个函数主要执行一些简单的工作，例如，获得应用程序上下文的ContentResolver接口和创建数据库操作辅助对象，具体可以参考前面一篇文章Android应用程序组件Content Provider应用实例。

回到前面Step 17中的installProvider函数中，它接下来就是把这些在本地中加载的Content Provider信息保存下来了，以方便后面查询和使用：

  1. synchronized (mProviderMap) {
  2. // Cache the pointer for the remote provider.
  3. String names[] = PATTERN_SEMICOLON.split(info.authority);
  4. for (int i=0; i<names.length; i++) {
  5. ProviderClientRecord pr = new ProviderClientRecord(names[i], provider,
  6. localProvider);
  7. try {
  8. provider.asBinder().linkToDeath(pr, 0);
  9. mProviderMap.put(names[i], pr);
  10. } catch (RemoteException e) {
  11. return null;
  12. }
  13. }
  14. if (localProvider != null) {
  15. mLocalProviders.put(provider.asBinder(),
  16. new ProviderClientRecord(null, provider, localProvider));
  17. }
  18. }

和ActivityMangerService类似，在ActivityThread中，以Content
Provider的authority为键值来把这个Content
Provider的信息保存在mProviderMap成员变量中，因为一个Content
Provider可以对应多个authority，因此这里用一个for循环来处理，同时又以这个Content
Provider对应的Binder对象provider来键值来把这个Content
Provider的信息保存在mLocalProviders成员变量中，表明这是一个在本地加载的Content Provider。

函数installProvider执行完成以后，返回到Step 16中的instalContentProviders函数中，执行下面语句：

  1. try {
  2. ActivityManagerNative.getDefault().publishContentProviders(
  3. getApplicationThread(), results);
  4. } catch (RemoteException ex) {
  5. }

前面已经提到，这个函数调用的作用就是通知ActivityMangerService，需要在这个进程中加载的Content Provider已经完加载完成了，参数results就包含了这些已经加载好的Content Provider接口。

Step 21. ActivityMangerService.publishContentProviders

这个函数定义在frameworks/base/services/java/com/android/server/am/ActivityManagerService.java文件中：

  1. public final class ActivityManagerService extends ActivityManagerNative
  2. implements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback {
  3. ......
  4. public final void publishContentProviders(IApplicationThread caller,
  5. List<ContentProviderHolder> providers) {
  6. ......
  7. synchronized(this) {
  8. final ProcessRecord r = getRecordForAppLocked(caller);
  9. ......
  10. final int N = providers.size();
  11. for (int i=0; i<N; i++) {
  12. ContentProviderHolder src = providers.get(i);
  13. if (src == null || src.info == null || src.provider == null) {
  14. continue;
  15. }
  16. ContentProviderRecord dst = r.pubProviders.get(src.info.name);
  17. if (dst != null) {
  18. mProvidersByClass.put(dst.info.name, dst);
  19. String names[] = dst.info.authority.split(";");
  20. for (int j = 0; j < names.length; j++) {
  21. mProvidersByName.put(names[j], dst);
  22. }
  23. int NL = mLaunchingProviders.size();
  24. int j;
  25. for (j=0; j<NL; j++) {
  26. if (mLaunchingProviders.get(j) == dst) {
  27. mLaunchingProviders.remove(j);
  28. j--;
  29. NL--;
  30. }
  31. }
  32. synchronized (dst) {
  33. dst.provider = src.provider;
  34. dst.app = r;
  35. dst.notifyAll();
  36. }
  37. ......
  38. }
  39. }
  40. }
  41. }
  42. ......
  43. }

在我们这个情景中，只有一个Content Provider，因此，这里的N等待1。在中间的for循环里面，最重要的是下面这个语句：

  1. ContentProviderRecord dst = r.pubProviders.get(src.info.name);

从这里得到的ContentProviderRecord对象dst，就是在前面Step
7中创建的ContentProviderRecord对象cpr了。在for循环中，首先是把这个Content
Provider信息保存好在mProvidersByClass和mProvidersByName中：

  1. mProvidersByClass.put(dst.info.name, dst);
  2. String names[] = dst.info.authority.split(";");
  3. for (int j = 0; j < names.length; j++) {
  4. mProvidersByName.put(names[j], dst);
  5. }

前面已经说过，这两个Map中，一个是以类名为键值保存Content Provider信息，一个是以authority为键值保存Content Provider信息。

因为这个Content Provider已经加载好了，因此，把它从mLaunchingProviders列表中删除：

  1. int NL = mLaunchingProviders.size();
  2. int j;
  3. for (j=0; j<NL; j++) {
  4. if (mLaunchingProviders.get(j) == dst) {
  5. mLaunchingProviders.remove(j);
  6. j--;
  7. NL--;
  8. }
  9. }

最后，设置这个ContentProviderRecord对象dst的provider域为从参数传进来的Content Provider远程接口：

  1. synchronized (dst) {
  2. dst.provider = src.provider;
  3. dst.app = r;
  4. dst.notifyAll();
  5. }

执行了dst.notiryAll语句后，在Step 7中等待要获取的Content
Provider接口加载完毕的线程就被唤醒了。唤醒之后，它检查本地ContentProviderRecord变量cpr的provider域不为
null，于是就返回了。它最终返回到Step 5中的ActivityThread类的getProvider函数中，继续往下执行：

  1. IContentProvider prov = installProvider(context, holder.provider,
  2. holder.info, true);

注意，这里是在Article应用程序中进程中执行installProvider函数的，而前面的Step 17的installProvider函数是在ArticlesProvider应用程序进程中执行的。

Step 22. ActivityThread.installProvider

这个函数定义在frameworks/base/core/java/android/app/ActivityThread.java文件中：

  1. public final class ActivityThread {
  2. ......
  3. private final IContentProvider installProvider(Context context,
  4. IContentProvider provider, ProviderInfo info, boolean noisy) {
  5. ......
  6. if (provider == null) {
  7. ......
  8. } else if (localLOGV) {
  9. ......
  10. }
  11. synchronized (mProviderMap) {
  12. // Cache the pointer for the remote provider.
  13. String names[] = PATTERN_SEMICOLON.split(info.authority);
  14. for (int i=0; i<names.length; i++) {
  15. ProviderClientRecord pr = new ProviderClientRecord(names[i], provider,
  16. localProvider);
  17. try {
  18. provider.asBinder().linkToDeath(pr, 0);
  19. mProviderMap.put(names[i], pr);
  20. } catch (RemoteException e) {
  21. return null;
  22. }
  23. }
  24. ......
  25. }
  26. return provider;
  27. }
  28. ......
  29. }

同样是执行installProvider函数，与Step
17不同，这里传进来的参数provider是不为null的，因此，它不需要执行在本地加载Content
Provider的工作，只需要把从ActivityMangerService中获得的Content
Provider接口保存在成员变量mProviderMap中就可以了。

这样，获取与"shy.luo.providers.artilces"这个uri对应的Content
Provider（shy.luo.providers.articles.ArticlesProvider）就完成了，它同时也是启动Content
Provider的完整过程。第三方应用程序获得了这个Content
Provider的接口之后，就可以访问它里面的共享数据了。在下面一篇文章中，我们将重点分析Android应用程序组件Content
Provider在不同进程中传输数据的过程，即Content Provider在不同应用程序*享数据的原理，敬请关注。

老罗的新浪微博：http://weibo.com/shengyangluo，欢迎关注！

相关文章