ContentResolver如何找到对应的ContentProvider？
这是一个深奥的魔法问题。 我知道对 ContentResolver 方法的调用需要特定于 ContentProvider 的 URI，但是 android 实际上如何进行关联？
我猜测涉及与 AndroidManifest.xml 中 ContentProvider 提供的权限匹配的任何 URI。 请求是否发送给每个包含该权限的提供商？ 如果我尝试创建其权限以另一个权限为前缀的提供者，这会是一个问题吗？
有没有办法查看ContentProvider是否正在运行？我想也许 getType() 方法上的虚拟响应会表明活跃度。
This is a deep magic question.
I understand that a call to a ContentResolver method takes a URI specific to the ContentProvider, but how does android actually make the association?
I am guessing that any URI matching the authority provided with the ContentProvider in the AndroidManifest.xml is involved.
Is the request sent to every provider containing that authority?
If I try to create providers whose authority prefixes another authority will that be a problem?
Is there a way to see if the ContentProvider is running? I'm thinking maybe a dummy response on the getType() method would indicate liveness.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
ContentResolver类维护从内容权限到ContentProvider类的映射。该映射的数据来自各种已安装应用程序的 AndroidManifest.xml 文件的只有一个 ContentProvider 会匹配，因为 contentAuthorities（内容的“域名”部分：类型 uri）要求是唯一的。他们没有等级之分。将它们视为必须完全匹配的唯一字符串。它们看起来具有层次结构的原因是为了提供一种保证唯一性的简单方法，类似于确保 Java 包名称唯一的方式。
根据标签文档的“描述：”部分：
至于当您创建一个具有与另一个相同的 contentAuthority 的提供程序时会发生什么......好吧，东西坏了。具体来说，它将拒绝安装第二个软件包，并表示：
所以......不要这样做。
无法查看 ContentProvider 是否正在运行。它由 ContentResolver 根据需要自动启动和停止。当您开始向特定 contentAuthority 发出请求时，关联的提供程序（如果尚未运行）将会启动。一旦它闲置一段时间后，它会被 ContentResolver 自动停止，并且看起来可能暂时不需要它。
Class
ContentResolvermaintains a mapping from Content Authorities toContentProviderclasses. The data for that mapping comes from the<provider>elements of the various installed applications' AndroidManifest.xml files. ContentResolver uses this mapping to identify which Provider class is the right one to use for a given URI that comes in. Think of ContentResolver as being sort of like DNS. It figures out which server (provider) is the right one to answer your query.Only one ContentProvider will match, because contentAuthorities (the "domain name" part of the content: type uri) are required to be unique. They are not hierarchical. Treat them as a unique string which must exactly match. The reason they look hierarchical is to allow an easy way of guaranteeing uniqueness, akin to the way Java package names are ensured to be unique.
Per the 'Description:" section for the tag documentation:
As for what happens when you make a provider with a contentAuthority that's identical to another one... Well, stuff breaks. Specifically, it will refuse to install whichever package goes on second, saying:
So.... Don't do that.
There is no way to see if the ContentProvider is running. It is started and stopped automatically by ContentResolver as needed. When you start making requests for a specific contentAuthority, the associated provider will be started if it isn't already running. It will be stopped automatically by ContentResolver, some time later once it has sat idle and it looks like it might not be needed for a while.