page.title=<provider> @jd:body
<provider android:authorities="list" android:enabled=["true" | "false"] android:exported=["true" | "false"] android:grantUriPermissions=["true" | "false"] android:icon="drawable resource" android:initOrder="integer" android:label="string resource" android:multiprocess=["true" | "false"] android:name="string" android:permission="string" android:process="string" android:readPermission="string" android:syncable=["true" | "false"] android:writePermission="string" > . . . </provider>
<application>
<meta-data>
<grant-uri-permission>
The Android system identifies content providers by the authority part
of a {@code content:} URI. For example, suppose that the following URI
is passed to {@link android.content.ContentResolver#query
ContentResolver.query()}
:
{@code content://com.example.project.healthcareprovider/nurses/rn}
The {@code content:} scheme identifies the data as belonging to a content provider and the authority ({@code com.example.project.healthcareprovider}) identifies the particular provider. The authority therefore must be unique. Typically, as in this example, it's the fully qualified name of a ContentProvider subclass. The path part of a URI may be used by a content provider to identify particular data subsets, but those paths are not declared in the manifest.
For information on using and developing content providers, see a separate document, Content Providers.
There is no default. At least one authority must be specified.
The <application>
element has its own
enabled
attribute that applies to all
application components, including content providers. The
<application>
and {@code <provider>}
attributes must both be "{@code true}" (as they both
are by default) for the content provider to be enabled. If either is
"{@code false}", the provider is disabled; it cannot be instantiated.
You can export a content provider but still limit access to it with the
permission
attribute.
readPermission
,
writePermission
, and
permission
attributes
—
"{@code true}" if permission can be granted, and "{@code false}" if not.
If "{@code true}", permission can be granted to any of the content
provider's data. If "{@code false}", permission can be granted only
to the data subsets listed in
<grant-uri-permission>
subelements,
if any. The default value is "{@code false}".
Granting permission is a way of giving an application component one-time access to data protected by a permission. For example, when an e-mail message contains an attachment, the mail application may call upon the appropriate viewer to open it, even though the viewer doesn't have general permission to look at all the content provider's data.
In such cases, permission is granted by
{@link android.content.Intent#FLAG_GRANT_READ_URI_PERMISSION}
and {@link android.content.Intent#FLAG_GRANT_WRITE_URI_PERMISSION}
flags in the Intent object that activates the component. For example, the
mail application might put {@code FLAG_GRANT_READ_URI_PERMISSION} in the
Intent passed to {@code Context.startActivity()}. The permission is specific
to the URI in the Intent.
If you enable this feature, either by setting this attribute to "{@code true}"
or by defining <grant-uri-permission>
subelements, you must call
{@link android.content.Context#revokeUriPermission
Context.revokeUriPermission()}
when a covered URI is deleted from
the provider.
See also the <grant-uri-permission>
element.
<application>
element's icon
attribute).<application>
element's
label
attribute).
The label should be set as a reference to a string resource, so that it can be localized like other strings in the user interface. However, as a convenience while you're developing the application, it can also be set as a raw string.
Normally, a content provider is instantiated in the process of the application that defined it. However, if this flag is set to "{@code true}", the system can create an instance in every process where there's a client that wants to interact with it, thus avoiding the overhead of interprocess communication.
<manifest>
element.
There is no default. The name must be specified.
readPermission
and
writePermission
attributes take precedence
over this one. If the readPermission
attribute is also set, it controls access for querying the content provider.
And if the writePermission
attribute is set,
it controls access for modifying the provider's data.
For more information on permissions, see the Permissions section in the introduction and a separate document, Security and Permissions.
<application>
element's
process
attribute can set a different
default for all components. But each component can override the default
with its own {@code process} attribute, allowing you to spread your
application across multiple processes.
If the name assigned to this attribute begins with a colon (':'), a new process, private to the application, is created when it's needed and the activity runs in that process. If the process name begins with a lowercase character, the activity will run in a global process of that name, provided that it has permission to do so. This allows components in different applications to share a process, reducing resource usage.
permission
and
writePermission
attributes.permission
and
readPermission
attributes.