有两个App需要共享数据，采用的是ContentProvider方案，在使用的过程中，发现在B应用关闭的时候，如果A想取B内的数据，大概率会失败。一直很奇怪，ContentProvider设计是就是为数据共享而生，相册，短信等系统服务，也是通过ContentProvider来完成数据共享的，为何自己实现的ContentProvider会出现访问不到数据的情况呢？
整个方案也很简单，B应用通过数据库存储数据并与ContentProvider建立关联，然后A应用通过指定的URI去访问B的数据，带着疑问去查了下ContentProvider相关代码，最终解开了谜底。
这里只分析A访问B数据的逻辑
如下：
ContentResolver contentResolver =context.getContentResolver();
Uri uri = Uri.parse(Constant.SERVER_URI + path);
Cursor cursor = contentResolver.query(uri, null, null, null, null);
首先拿到当前应用的ContentResolver，然后调用query方法去查询数据，代码其实很简单，既然拿不到数据，问题肯定出现在query方法上了，顺着思路，我们点开query方法，看下内部实现如何。
class ContextImpl extends Context {
public ContentResolver getContentResolver() {
return mContentResolver;
}
private ContextImpl(...) {
...
mContentResolver = new ApplicationContentResolver(this, mainThread, user);
}
}
Context中调用getContentResolver，经过层层调用来到ContextImpl类,返回值mContentResolver赋值是在ContextImpl对象创建过程完成赋值.
getContentResolver()方法返回的类型是android.app.ContextImpl.ApplicationContentResolver，这个类是抽象类android.content.ContentResolver的子类，resolver.query实际上是调用父类ContentResolver的query实现：
public final @Nullable Cursor query(final @RequiresPermission.Read @NonNull Uri uri,
@Nullable String[] projection, @Nullable String selection,
@Nullable String[] selectionArgs, @Nullable String sortOrder,
@Nullable CancellationSignal cancellationSignal) {
Preconditions.checkNotNull(uri, "uri");
IContentProvider unstableProvider = acquireUnstableProvider(uri);
if (unstableProvider == null) {
return null;
}
IContentProvider stableProvider = null;
Cursor qCursor = null;
try {
long startTime = SystemClock.uptimeMillis();
ICancellationSignal remoteCancellationSignal = null;
if (cancellationSignal != null) {
cancellationSignal.throwIfCanceled();
remoteCancellationSignal = unstableProvider.createCancellationSignal();
cancellationSignal.setRemote(remoteCancellationSignal);
}
try {
qCursor = unstableProvider.query(mPackageName, uri, projection,
selection, selectionArgs, sortOrder, remoteCancellationSignal);
} catch (DeadObjectException e) {
// The remote process has died... but we only hold an unstable
// reference though, so we might recover!!! Let's try!!!!
// This is exciting!!1!!1!!!!1
// 远程进程死亡，处理unstable provider死亡过程
unstableProviderDied(unstableProvider);
//unstable类型死亡后，再创建stable类型的provider
stableProvider = acquireProvider(uri);
if (stableProvider == null) {
return null;
}
//再次执行查询操作
qCursor = stableProvider.query(mPackageName, uri, projection,
selection, selectionArgs, sortOrder, remoteCancellationSignal);
}
......略去非关键代码
}
- 调用acquireUnstableProvider()，尝试获取unstable的ContentProvider;
然后执行query操作； - 当执行query过程抛出DeadObjectException，即代表ContentProvider所在进程死亡，则尝试获取stable的ContentProvider:
- 调用unstableProviderDied(), 清理刚创建的unstable的ContentProvider；
调用acquireProvider()，尝试获取stable的ContentProvider;
由于这两个acquire*都是抽象方法，我们可以直接看子类ApplicationContentResolver的实现：
@Override
protected IContentProvider acquireProvider(Context context, String auth) {
return mMainThread.acquireProvider(context,
ContentProvider.getAuthorityWithoutUserId(auth),
resolveUserIdFromAuthority(auth), true);
}
@Override
protected IContentProvider acquireExistingProvider(Context context, String auth) {
return mMainThread.acquireExistingProvider(context,
ContentProvider.getAuthorityWithoutUserId(auth),
resolveUserIdFromAuthority(auth), true);
}
可以看到这两个抽象方法最终都通过调用ActivityThread类的acquireProvider获取到IContentProvider，接下来我们看看到底是如何获取到ContentProvider的。
ContentProvider获取过程
ActivityThread类的acquireProvider方法如下，方法的最后一个参数stable代表着ContentProvider所在的进程是否存活，如果进程已死，可能需要在必要的时候唤起这个进程；
public final IContentProvider acquireProvider(
Context c, String auth, int userId, boolean stable) {
final IContentProvider provider = acquireExistingProvider(c, auth, userId, stable);
if (provider != null) {
return provider;
}
// There is a possible race here. Another thread may try to acquire
// the same provider at the same time. When this happens, we want to ensure
// that the first one wins.
// Note that we cannot hold the lock while acquiring and installing the
// provider since it might take a long time to run and it could also potentially
// be re-entrant in the case where the provider is in the same process.
IActivityManager.ContentProviderHolder holder = null;
try {
holder = ActivityManagerNative.getDefault().getContentProvider(
getApplicationThread(), auth, userId, stable);
} catch (RemoteException ex) {
throw ex.rethrowFromSystemServer();
}
if (holder == null) {
Slog.e(TAG, "Failed to find provider info for " + auth);
return null;
}
// Install provider will increment the reference count for us, and break
// any ties in the race.
holder = installProvider(c, holder, holder.info,
true /*noisy*/, holder.noReleaseNeeded, stable);
return holder.provider;
}
这个方法首先通过acquireExistingProvider尝试从本进程中获取ContentProvider，如果获取不到，那么再请求AMS获取对应ContentProvider,这里应该就是跨进程访问数据了，也就符合我们当前遇到的问题，A如果需要访问B，需要通过AMS获取对应ContentProvider，如果手机厂商做了深度定制，禁止应用关联，此时是无法通过AMS拿到holder对象，从而无法完成我们后续的增删改查。
ok，到此，我们基本了解为何无法访问到B共享的数据了。这种属于ROM做的定制，想要跨越这道坎，有点以卵击石的感觉，既然这条路走不通，尝试下别的方法吧。
考虑到Activity这个特殊的组件，应该不会被标记为关联启动吧，虽然不知道手机厂商做了什么，我可以试一试啊。方案大概这样，在B应用声明一个透明的activity，然后exported设置为true，当A无法读取B共享的ContentProvider数据并且B进程死亡的前提下，A通过Activity跳转调起B，B进程启动之后，对应的ContentProvider也起来了，这样的话，应该就可以正常访问B的数据了。话不多说，直接试吧
Intent intent = new Intent();
ComponentName comp = new ComponentName("com.swt.setting", "com.swt.setting.VirtualActivity");
intent.setComponent(comp);
intent.setAction("android.intent.action.MAIN");
intent.putExtra("flag", "flag");
intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
context.startActivity(intent);
完美，B成功被启动，并且A可以正常访问B的数据了。。。
