怎么会由一个应用程序创建的线程被视为从应用的ContentProvider的不同的应用程序？ [英] How would a thread created by an app be considered a different app from the app's ContentProvider?

问题描述

我有一个应用程序，当由 ContentObserver 更改了的ContentProvider ，试图查询的通知在后台线程提供商。这将导致一个 SecurityException异常抛出：

I have an app that, when notified by a ContentObserver of a change to a ContentProvider, attempts to query the provider on a background thread. This causes an SecurityException to be thrown:

8-10 15:54:29.577    3057-3200/com.xxxx.mobile.android.xxx W/Binder﹕ Caught a RuntimeException from the binder stub implementation.
  java.lang.SecurityException: Permission Denial: reading com.xxx.mobile.android.mdk.model.customer.ContentProvider uri content://com.xxx.mobile.android.consumer.xxx/vehicle from pid=0, uid=1000 requires the provider be exported, or grantUriPermission()
at android.content.ContentProvider.enforceReadPermissionInner(ContentProvider.java:539)
           at android.content.ContentProvider$Transport.enforceReadPermission(ContentProvider.java:452)
           at android.content.ContentProvider$Transport.query(ContentProvider.java:205)
           at android.content.ContentResolver.query(ContentResolver.java:478)
           at android.content.ContentResolver.query(ContentResolver.java:422)

怎么会由一个应用程序创建的线程与应用程序的ContentProvider的不同的UID结束了？

How would a thread created by an app end up with a different UID from the app's ContentProvider?

通过将异常断点 android.content.ContentProvider 我看到 UserHandle.isSameApp（UID，mMyUid）是假和 UserHandle.isSameUser（UID，mMyUid）是真正。我也看到，供应商UID是10087。

By placing an exception breakpoint in android.content.ContentProvider I see that UserHandle.isSameApp(uid, mMyUid) is false and UserHandle.isSameUser(uid, mMyUid) is true. I also see that the providers UID is 10087.

推荐答案

我得到了同样的问题，而试图用我的系统中的回调ContentProvider的交互（ LeScanCallback ）。问题是，回调的线程是由Android系统拥有的，而不是我的应用程序，即使code是在我的应用程序。

I got the same problem while trying to interact with my ContentProvider in a system callback (LeScanCallback). The problem is that the callback thread is owned by the Android system, and not by my app, even if the code is in my app.

试图互动与我的ContentProvider成功地解决了这个问题之前，传递从回调的工作，我的应用程序的线程之一。

Passing the work from the callback to one of my app threads before trying to interact with my ContentProvider solved the problem successfully.

要减少线程的创建和回收利用样板（需要频繁的回调以减少开销），我用 AndroidAnnotation的 @Background 标注我的委托方法。

To reduce boilerplate for thread creation and recycling (needed for frequent callbacks to reduce overhead), I used AndroidAnnotation's @Background annotation on my delegate method.

这篇关于怎么会由一个应用程序创建的线程被视为从应用的ContentProvider的不同的应用程序？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！