O provedor de conteúdo gerencia o acesso a um repositório central de dados. Implementa-se um provedor como uma ou mais classes em um aplicativo do Android, em conjunto com elementos no arquivo de manifesto. Uma das classes implementa uma subclasse {@link android.content.ContentProvider}, que é a interface entre o provedor e outros aplicativos. Embora provedores de conteúdo se destinem a disponibilizar dados a outros aplicativos, naturalmente é possível ter atividades no aplicativo que permitam ao usuário consultar e modificar os dados gerenciados pelo provedor.
O restante deste tópico é uma lista básica de etapas para a criação de um provedor de conteúdo e uma lista de APIs para usar.
Antes de começar a criar um provedor, faça o seguinte:
Não é necessário um provedor para usar um banco de dados SQLite se o uso for inteiramente dentro do próprio aplicativo.
A seguir, siga estas etapas para criar seu provedor:
Os provedores de conteúdo são a interface para dados salvos em um formato estruturado. Antes de criar a interface, é preciso decidir como armazenar os dados. É possível armazená-los da forma que quiser e, em seguida, projetar a interface para ler e gravar os dados conforme o necessário.
Essas são algumas das tecnologias de armazenamento de dados disponíveis no Android:
Lembre-se de que não é necessário usar nenhum banco de dados para implementar o repositório. Um provedor aparece externamente como um conjunto de tabelas, semelhante a um banco de dados relacional, mas isso não é um requisito para a implementação interna do provedor.
A seguir há algumas dicas para projetar a estrutura de dados do seu provedor:
_ID.
Pode-se usar um BLOB para implementar uma tabela independente de esquema. Nesse tipo de tabela, define-se uma coluna de chave principal, uma coluna de tipo MIME e uma ou mais colunas genéricas como BLOB. O significado dos dados nas colunas BLOB é indicado pelo valor na coluna de tipo MIME. Isso permite o armazenamento de diferentes tipos de linha na mesma tabela. A tabela de "dados" {@link android.provider.ContactsContract.Data} do Provedor de contatos é um exemplo de uma tabela independente de esquema.
URI de conteúdo é uma URI que identifica dados em um provedor. URIs de conteúdo contêm o nome simbólico de todo o provedor (sua autoridade) e um nome que aponta para uma tabela ou arquivo (um caminho). Parte do ID opcional aponta para uma linha individual em uma tabela. Cada método de acesso aos dados {@link android.content.ContentProvider} de tem uma URI de conteúdo como um argumento. Isso permite determinar a tabela, a linha ou o arquivo a acessar.
Os conceitos básicos de URIs de conteúdo são escritos no tópico Preceitos do provedor de conteúdo.
Os provedores normalmente têm uma única autoridade, que serve como seu nome interno do Android. Para
evitar conflitos com outros provedores, deve-se usar a propriedade de domínio da internet (ao contrário)
como a base da autoridade do provedor. Em virtude de esta recomendação ser verdadeira para nomes
de pacote do Android, é possível definir a autoridade do provedor como uma extensão do nome
do pacote que contém o provedor. Por exemplo: se o nome do pacote do Android for
com.example.<appname>, deve-se atribuir ao provedor
a autoridade com.example.<appname>.provider.
Desenvolvedores normalmente criam URIs de conteúdo a partir da autoridade anexando caminhos que apontam para
tabelas individuais. Por exemplo: se você tiver duas tabelas (tabela1 e
tabela2), combine a autoridade do exemplo anterior para produzir
as URIs de conteúdo
com.example.<appname>.provider/table1 e
com.example.<appname>.provider/table2. Caminhos não
se limitam a um único segmento e não precisa ter uma tabela para cada nível do caminho.
Por convenção, provedores fornecem acesso a uma linha exclusiva em uma tabela aceitando uma URI de conteúdo
com um valor de ID para a linha no fim da URI. Também por convenção, provedores combinam
o valor do ID com a coluna _ID da tabela e realizam o acesso solicitado
na linha correspondente.
Essa convenção facilita a padronização comum do projeto para aplicativos que acessam um provedor. O aplicativo
realiza uma consulta no provedor e exibe o {@link android.database.Cursor}
resultante em uma {@link android.widget.ListView} usando um {@link android.widget.CursorAdapter}.
A definição de {@link android.widget.CursorAdapter} requer que uma das colunas
no {@link android.database.Cursor} seja _ID
Em seguida, o usuário seleciona uma das linhas exibidas na IU para visualizar ou modificar
os dados. O aplicativo tem a linha correspondente do {@link android.database.Cursor} apoiando
a {@link android.widget.ListView}, obtém o valor _ID para essa linha, anexa-o
à URI de conteúdo e envia a solicitação de acesso ao provedor. O provedor, então, pode realizar
a consulta ou modificação na exata linha que o usuário selecionou.
Para ajudar a escolher que ação tomar para uma URI de conteúdo recebida, a API do provedor contém
a classe de conveniência {@link android.content.UriMatcher}, que mapeia "padrões" de URI de conteúdo
como valores de número inteiro. É possível usar os valores de número inteiro em uma declaração switch que
escolha a ação desejada para a URI de conteúdo ou URIs que atendam ao padrão determinado.
Um padrão de URI de conteúdo corresponde a URIs de conteúdo que usam caracteres especiais:
*: Corresponde a uma string de qualquer caractere válido de qualquer comprimento.
#: Corresponde a uma string de caracteres numéricos de qualquer comprimento.
Como um exemplo de projeto e codificação da identificação de URIs de conteúdo, considere um provedor
com a autoridade com.example.app.provider que reconheça as URIs de conteúdo
que apontam para tabelas:
content://com.example.app.provider/table1: Uma tabela chamada table1.
content://com.example.app.provider/table2/dataset1: Uma tabela chamada
dataset1.
content://com.example.app.provider/table2/dataset2: Uma tabela chamada
dataset1.
content://com.example.app.provider/table3: Uma tabela chamada table3.
O provedor também reconhece essas URIs de conteúdo se elas tiverem um ID de linha anexado, como
content://com.example.app.provider/table3/1 para a linha identificada por
1 em table3.
Os seguintes padrões de URI de conteúdo seriam possíveis:
content://com.example.app.provider/*
content://com.example.app.provider/table2/*:
dataset1
e dataset2, mas não a URIs de conteúdo de table1
nem table3.
content://com.example.app.provider/table3/#: Corresponde a uma URI de conteúdo
para linhas exclusivas em table3, como
content://com.example.app.provider/table3/6 da linha identificada por
6.
O fragmento de código a seguir mostra como funcionam os métodos em {@link android.content.UriMatcher}.
Esse código identifica URIs para toda uma tabela, diferentemente das URIs
para uma linha exclusiva, usando o padrão de URI de conteúdo
content://<authority>/<path> para tabelas e
content://<authority>/<path>/<id> para linhas exclusivas.
O método {@link android.content.UriMatcher#addURI(String, String, int) addURI()} mapeia
uma autoridade e um caminho como um valor de número inteiro. O método {@link android.content.UriMatcher#match(Uri)
match()} retorna o valor de número inteiro para a URI. Uma declaração switch
escolhe entre consultar a tabela inteira e consultar um único registro:
public class ExampleProvider extends ContentProvider {
...
// Creates a UriMatcher object.
private static final UriMatcher sUriMatcher;
...
/*
* The calls to addURI() go here, for all of the content URI patterns that the provider
* should recognize. For this snippet, only the calls for table 3 are shown.
*/
...
/*
* Sets the integer value for multiple rows in table 3 to 1. Notice that no wildcard is used
* in the path
*/
sUriMatcher.addURI("com.example.app.provider", "table3", 1);
/*
* Sets the code for a single row to 2. In this case, the "#" wildcard is
* used. "content://com.example.app.provider/table3/3" matches, but
* "content://com.example.app.provider/table3 doesn't.
*/
sUriMatcher.addURI("com.example.app.provider", "table3/#", 2);
...
// Implements ContentProvider.query()
public Cursor query(
Uri uri,
String[] projection,
String selection,
String[] selectionArgs,
String sortOrder) {
...
/*
* Choose the table to query and a sort order based on the code returned for the incoming
* URI. Here, too, only the statements for table 3 are shown.
*/
switch (sUriMatcher.match(uri)) {
// If the incoming URI was for all of table3
case 1:
if (TextUtils.isEmpty(sortOrder)) sortOrder = "_ID ASC";
break;
// If the incoming URI was for a single row
case 2:
/*
* Because this URI was for a single row, the _ID value part is
* present. Get the last path segment from the URI; this is the _ID value.
* Then, append the value to the WHERE clause for the query
*/
selection = selection + "_ID = " uri.getLastPathSegment();
break;
default:
...
// If the URI is not recognized, you should do some error handling here.
}
// call the code to actually do the query
}
Outra classe, {@link android.content.ContentUris}, fornece métodos convenientes para trabalhar
com a parte id das URIs de conteúdo. As classes {@link android.net.Uri}
e {@link android.net.Uri.Builder} contêm métodos convenientes para analisar objetos
{@link android.net.Uri} existentes e criar novos.
A instância {@link android.content.ContentProvider} gerencia o acesso a um conjunto de dados estruturado lidando com solicitações de outros aplicativos. Todas as formas de acesso ocasionalmente chamam {@link android.content.ContentResolver} que, em seguida, chama um método concreto de {@link android.content.ContentProvider} para obter acesso.
A classe abstrata {@link android.content.ContentProvider} define seis métodos abstratos que devem ser implementados como parte das subclasses concretas. Todos esses métodos, exceto {@link android.content.ContentProvider#onCreate() onCreate()}, são chamados por um aplicativo cliente que está tentando acessar seu provedor de conteúdo:
Observe que esses métodos têm a mesma assinatura dos métodos {@link android.content.ContentResolver} de mesmo nome.
A implementação desses métodos deve levar em conta o seguinte:
O método {@link android.content.ContentProvider#query(Uri, String[], String, String[], String)
ContentProvider.query()} precisa retornar um objeto {@link android.database.Cursor} ou, se
falhar, gerar uma {@link java.lang.Exception}. Se você estiver usando um banco de dados SQLite
como armazenamento de dados, pode simplesmente retornar o {@link android.database.Cursor} retornado
por um dos métodos query() da classe {@link android.database.sqlite.SQLiteDatabase}.
Se a consulta não corresponder a nenhuma linha, deve-se retornar uma instância {@link android.database.Cursor}
cujo método {@link android.database.Cursor#getCount()} retorne 0.
Deve-se retornar null somente se ocorrer um erro interno durante o processo de consulta.
Se você não estiver usando um banco de dados SQLite como modo de armazenamento de dados, use uma das subclasses concretas de {@link android.database.Cursor}. Por exemplo, a classe {@link android.database.MatrixCursor} implementa um cursor em que cada linha é uma matriz de {@link java.lang.Object}. Com essa classe, use {@link android.database.MatrixCursor#addRow(Object[]) addRow()} para adicionar uma nova linha.
Lembre-se de que o sistema Android deve ser capaz de se comunicar com {@link java.lang.Exception} entre limites de processo. O Android pode fazer isso para as exceções a seguir, que podem ser úteis para tratar de erros de consulta:
O método {@link android.content.ContentProvider#insert(Uri, ContentValues) insert()} adiciona uma nova linha à tabela apropriada usando os valores no argumento {@link android.content.ContentValues}. Se um nome de coluna não estiver no argumento {@link android.content.ContentValues}, talvez seja necessário fornecer um valor padrão para ele tanto no código do provedor quanto no esquema do banco de dados.
Esse método deve retornar a URI de conteúdo da nova linha. Para construir isso, anexe o valor _ID
da nova linha (ou outra chave principal) à URI de conteúdo da tabela usando
{@link android.content.ContentUris#withAppendedId(Uri, long) withAppendedId()}.
O método {@link android.content.ContentProvider#delete(Uri, String, String[]) delete()} não precisa excluir linhas fisicamente do armazenamento de dados. Se você estiver usando um adaptador de sincronização com o provedor, considere marcar uma linha excluída com um sinalizador "excluir" em vez de removê-la totalmente. O adaptador de sincronização pode verificar se há linhas excluídas e removê-las do servidor antes de excluí-las do provedor.
O método {@link android.content.ContentProvider#update(Uri, ContentValues, String, String[])
update()} usa o mesmo argumento {@link android.content.ContentValues} usado por
{@link android.content.ContentProvider#insert(Uri, ContentValues) insert()}, e os
mesmos argumentos selection e selectionArgs usados por
{@link android.content.ContentProvider#delete(Uri, String, String[]) delete()} e
{@link android.content.ContentProvider#query(Uri, String[], String, String[], String)
ContentProvider.query()}. Isso deve permitir a reutilização do código entre esses métodos.
O sistema Android chama {@link android.content.ContentProvider#onCreate() onCreate()} quando inicia o provedor. Nesse método, devem-se realizar apenas tarefas de inicialização de execução rápida e adiar a criação do banco de dados e o carregamento dos dados até que o provedor receba efetivamente uma solicitação de acesso aos dados. Se houver tarefas longas em {@link android.content.ContentProvider#onCreate() onCreate()}, a inicialização do provedor ficará lenta. Consequentemente, isso diminuirá a rapidez da resposta do provedor a outros aplicativos.
Por exemplo: se você estiver usando um banco de dados SQLite, é possível criar um novo objeto {@link android.database.sqlite.SQLiteOpenHelper} em {@link android.content.ContentProvider#onCreate() ContentProvider.onCreate()} e, em seguida, criar as tabelas SQL na primeira vez em que o banco de dados for aberto. Para facilitar isso, a primeira vez que chamar {@link android.database.sqlite.SQLiteOpenHelper#getWritableDatabase getWritableDatabase()}, ele automaticamente chamará o método {@link android.database.sqlite.SQLiteOpenHelper#onCreate(SQLiteDatabase) SQLiteOpenHelper.onCreate()}
Os dois fragmentos a seguir demonstram a interação entre {@link android.content.ContentProvider#onCreate() ContentProvider.onCreate()} e {@link android.database.sqlite.SQLiteOpenHelper#onCreate(SQLiteDatabase) SQLiteOpenHelper.onCreate()}. O primeiro fragmento é a implementação de {@link android.content.ContentProvider#onCreate() ContentProvider.onCreate()}.
public class ExampleProvider extends ContentProvider
/*
* Defines a handle to the database helper object. The MainDatabaseHelper class is defined
* in a following snippet.
*/
private MainDatabaseHelper mOpenHelper;
// Defines the database name
private static final String DBNAME = "mydb";
// Holds the database object
private SQLiteDatabase db;
public boolean onCreate() {
/*
* Creates a new helper object. This method always returns quickly.
* Notice that the database itself isn't created or opened
* until SQLiteOpenHelper.getWritableDatabase is called
*/
mOpenHelper = new MainDatabaseHelper(
getContext(), // the application context
DBNAME, // the name of the database)
null, // uses the default SQLite cursor
1 // the version number
);
return true;
}
...
// Implements the provider's insert method
public Cursor insert(Uri uri, ContentValues values) {
// Insert code here to determine which table to open, handle error-checking, and so forth
...
/*
* Gets a writeable database. This will trigger its creation if it doesn't already exist.
*
*/
db = mOpenHelper.getWritableDatabase();
}
}
O próximo fragmento é a implementação de {@link android.database.sqlite.SQLiteOpenHelper#onCreate(SQLiteDatabase) SQLiteOpenHelper.onCreate()}, inclusive uma classe auxiliar:
...
// A string that defines the SQL statement for creating a table
private static final String SQL_CREATE_MAIN = "CREATE TABLE " +
"main " + // Table's name
"(" + // The columns in the table
" _ID INTEGER PRIMARY KEY, " +
" WORD TEXT"
" FREQUENCY INTEGER " +
" LOCALE TEXT )";
...
/**
* Helper class that actually creates and manages the provider's underlying data repository.
*/
protected static final class MainDatabaseHelper extends SQLiteOpenHelper {
/*
* Instantiates an open helper for the provider's SQLite data repository
* Do not do database creation and upgrade here.
*/
MainDatabaseHelper(Context context) {
super(context, DBNAME, null, 1);
}
/*
* Creates the data repository. This is called when the provider attempts to open the
* repository and SQLite reports that it doesn't exist.
*/
public void onCreate(SQLiteDatabase db) {
// Creates the main table
db.execSQL(SQL_CREATE_MAIN);
}
}
A classe {@link android.content.ContentProvider} tem dois métodos para retornar tipos MIME:
O método {@link android.content.ContentProvider#getType(Uri) getType()} retorna uma {@link java.lang.String} em formato MIME que descreve o tipo de dados retornado pelo argumento da URI de conteúdo. O argumento {@link android.net.Uri} pode ser um padrão em vez de uma URI específica; nesse caso, deve-se retornar o tipo de dados associado a URIs de conteúdo que correspondam ao padrão.
Para tipos de dados comuns como texto, HTML ou JPEG, {@link android.content.ContentProvider#getType(Uri) getType()} deve retornar o tipo MIME padrão daqueles dados. Há uma lista completa desse tipos de padrão no site de Tipos de mídia MIME IANA.
Para obter URIs de conteúdo que apontam para uma linha ou linhas de dados de tabela, {@link android.content.ContentProvider#getType(Uri) getType()} deve retornar um tipo MIME no formato MIME específico do fornecedor do Android:
vnd
android.cursor.item/
android.cursor.dir/
vnd.<name>.<type>
Fornecem-se <name> e o <type>.
O valor <name> deve ser globalmente exclusivo
e o <type> deve ser exclusivo para o padrão de URI
correspondente. Uma boa escolha para <name> é o nome da empresa
ou alguma parte do nome do pacote do Android do seu aplicativo. Uma boa escolha para
<type> é uma string que identifique a tabela associada
à URI.
Por exemplo: se a autoridade de um provedor
for com.example.app.provider e ele expuser uma tabela chamada
table1, o tipo MIME de diversas linhas em table1 será:
vnd.android.cursor.dir/vnd.com.example.provider.table1
Para uma única linha de table1, o tipo MIME será:
vnd.android.cursor.item/vnd.com.example.provider.table1
Se o provedor oferecer arquivos, implemente {@link android.content.ContentProvider#getStreamTypes(Uri, String) getStreamTypes()}. O método retorna uma matriz {@link java.lang.String} de tipos MIME para os arquivos que o provedor pode retornar de uma dada URI de conteúdo. É preciso filtrar os tipos MIME oferecidos pelo argumento do filtro de tipo MIME para retornar somente os tipos MIME que o cliente quer tratar.
Por exemplo: considere um provedor que ofereça imagens de foto como arquivos em formatos .jpg,
.gif e .png.
Se um aplicativo chama {@link android.content.ContentResolver#getStreamTypes(Uri, String)
ContentResolver.getStreamTypes()} com a string de filtro image/* (algo que
seja uma "imagem"),
o método {@link android.content.ContentProvider#getStreamTypes(Uri, String)
ContentProvider.getStreamTypes()} deve retornar a matriz:
{ "image/jpeg", "image/png", "image/gif"}
Se o aplicativo estiver interessado apenas em arquivos .jpg, ele pode chamar
{@link android.content.ContentResolver#getStreamTypes(Uri, String)
ContentResolver.getStreamTypes()} com a string de filtro *\/jpeg
e {@link android.content.ContentProvider#getStreamTypes(Uri, String)
ContentProvider.getStreamTypes()} deve retornar:
{"image/jpeg"}
Se o provedor não oferecer nenhum tipo MIME solicitado na string de filtro,
{@link android.content.ContentProvider#getStreamTypes(Uri, String) getStreamTypes()}
deve retornar null.
Uma classe de contrato é uma classe public final que contém definições de constantes para
os nomes de coluna das URIs, dos tipos MIME e de outros metadados que pertencem ao provedor. A classe
estabelece um contrato entre o provedor e outros aplicativos, garantindo que o provedor
possa ser corretamente acessado mesmo se houver mudanças nos valores atuais de URIs, nomes de coluna
etc.
As classes de contrato também ajudam os desenvolvedores porque normalmente suas constantes têm nomes mnemônicos e, por isso, os desenvolvedores têm menos chance de usar valores incorretos para nomes de coluna ou URIs. Já que é uma classe, ela pode conter documentação Javadoc. Ambientes de desenvolvimento integrados, como o Eclipse, podem preencher automaticamente os nomes de constantes da classe de contrato e exibir Javadoc para as constantes.
Os desenvolvedores não podem acessar o arquivo de classe da classe de contrato do aplicativo, mas podem
compilá-lo estaticamente no aplicativo a partir de um arquivo .jar que você fornece.
A classe {@link android.provider.ContactsContract} e classes aninhadas são exemplos de classes de contrato.
Permissões e acesso, para todos os aspectos do sistema Android, são descritos detalhadamente no tópico Permissões e segurança. O tópico Armazenamento de dados também descreve segurança e permissões em vigor para diversos tipos de armazenamento. Em resumo, os pontos importantes são:
Se você deseja usar permissões do provedor de conteúdo para controlar o acesso aos dados, deve armazená-los em arquivos internos, bancos de dados SQLite ou em "nuvem" (por exemplo, em um servidor remoto) e mantê-los privados em relação ao aplicativo.
Todos os aplicativos podem ler ou gravar no provedor, mesmo que os dados em questão
sejam privados porque, por padrão, o provedor não tem permissões definidas. Para mudar isso,
defina permissões do provedor no arquivo de manifesto por meio de atributos ou elementos
filho do elemento
<provider>. É possível definir permissões que se apliquem a todo o provedor,
a determinadas tabelas, a registros específicos ou a todos os três.
As permissões são definidas para o provedor com um ou mais
elementos
<permission> no arquivo de manifesto. Para tornar
a permissão exclusiva para o provedor, use escopo de estilo Java para
o atributo
android:name. Por exemplo: nomeie a permissão de leitura
com.example.app.provider.permission.READ_PROVIDER.
A lista a seguir descreve o escopo de permissões do provedor, começando com as permissões que se aplicam a todo o provedor e seguindo para as mais específicas. Permissões mais específicas têm precedência sobre as de escopo maior:
android:permission
do elemento
<provider>.
android:readPermission
e
android:writePermission
do elemento
<provider>. Elas têm precedência sobre a permissão exigida
por
android:permission.
<path-permission>
do elemento
<provider>. Para cada URI de conteúdo, pode-se especificar
uma permissão de leitura/gravação, uma permissão de leitura, uma permissão de gravação ou as três. As permissões
de leitura e gravação têm precedência sobre a permissão de leitura/gravação. Além disso,
permissões no nível do caminho têm precedência sobre permissões no nível do provedor.
Considere as permissões necessárias para implementar um provedor e um aplicativo de e-mail ao permitir um aplicativo visualizador de imagens externas para exibir anexos de fotos do provedor. Para conceder o acesso necessário ao visualizador de imagens sem as permissões exigidas, configure permissões temporárias das URIs de conteúdo de fotos. Projete o aplicativo de e-mail para que, quando o usuário quiser exibir uma foto, o aplicativo envie uma intenção com a URI de conteúdo da foto e sinalizadores de permissão para o visualizador de imagens. O visualizador de imagens poderá, então, consultar o provedor de e-mail para recuperar a foto mesmo que ele não tenha a permissão normal de leitura para o provedor.
Para ativar permissões temporárias, defina
o atributo
android:grantUriPermissions
do elemento
<provider> ou adicione um ou mais
elementos filhos
<grant-uri-permission>
ao elemento
<provider>. Se forem usadas permissões temporárias, será necessário chamar
{@link android.content.Context#revokeUriPermission(Uri, int)
Context.revokeUriPermission()} sempre que remover suporte a URI de conteúdo do
provedor, e a URI de conteúdo será associada a uma permissão temporária.
O valor do atributo determina o nível de acessibilidade do provedor.
Se o atributo estiver definido como true, o sistema concederá permissão
temporária a todo o provedor, sobrepondo todas as outras permissões exigidas
pelas permissões no nível do provedor ou no nível do caminho.
Se esse sinalizador estiver definido como false, será necessário adicionar
elementos filhos
<grant-uri-permission>
ao elemento
<provider>. Cada elemento filho especifica a URI ou URIs
de conteúdo para as quais o acesso temporário é concedido.
Para delegar o acesso temporário a um aplicativo, a intenção deve conter os sinalizadores {@link android.content.Intent#FLAG_GRANT_READ_URI_PERMISSION}, {@link android.content.Intent#FLAG_GRANT_WRITE_URI_PERMISSION} ou ambos. Eles são definidos com o método {@link android.content.Intent#setFlags(int) setFlags()}.
Se o atributo
android:grantUriPermissions não estiver presente, presume-se que ele seja
false.
Como os componentes {@link android.app.Activity} e {@link android.app.Service},
a subclasse de {@link android.content.ContentProvider}
deve ser definida no arquivo de manifesto do aplicativo
pelo elemento
<provider>. O sistema Android obtém as seguintes informações
do elemento:
android:name
)
android:grantUriPermssions: Sinalizador de permissão temporária.
android:permission: Permissão única de leitura/gravação por todo o provedor.
android:readPermission: Permissão de leitura por todo o provedor.
android:writePermission: Permissão de gravação por todo o provedor.
As permissões e os atributos correspondentes são abordados com mais detalhes na seção Implementação de permissões do Provedor de conteúdo.
android:enabled: sinalizador que permite ao sistema iniciar o provedor.
android:exported: sinalizador que permite a outros aplicativos usarem esse provedor.
android:initOrder: a ordem em que esse provedor deve ser iniciado,
relativa a outros provedores no mesmo processo.
android:multiProcess: sinalizador que permite ao sistema iniciar o provedor
no mesmo processo que o cliente chama.
android:process: o nome do processo em que o provedor deve
ser executado.
android:syncable: sinalizador que indica que os dados do provedor devem ser
sincronizados com os dados em um servidor.
os atributos estão totalmente documentados no tópico do guia de desenvolvimento
do elemento
<provider>.
android:icon: um recurso desenhável contendo um ícone para o provedor.
O ícone aparece próximo ao rótulo do provedor na lista de aplicativos
em Configurações > Aplicativos > Todos.
android:label: um rótulo informacional que descreve o provedor,
seus dados ou ambos. O rótulo aparece na lista de aplicativos
em Configurações > Aplicativos > Todos.
Os atributos estão totalmente documentados no tópico do guia de desenvolvimento
do elemento
<provider>.
Os aplicativos podem acessar um provedor de conteúdo indiretamente com uma {@link android.content.Intent}. O aplicativo não chama nenhum método de {@link android.content.ContentResolver} nem de {@link android.content.ContentProvider}. Em vez disso, ele envia uma intenção que inicia uma atividade, que, em geral, é parte do aplicativo do próprio provedor. A atividade de destino é responsável pela recuperação e exibição dos dados na IU. Conforme a ação na intenção, a atividade de destino também pode levar o usuário a realizar modificações nos dados do provedor. Uma intenção também pode conter dados "extras" que a atividade de destino exibe na IU; o usuário terá, então, a opção de alterar esses dados antes de usá-los para modificar os dados no provedor.
Pode ser necessário usar acesso de intenções para ajudar a garantir a integridade deles. O provedor pode depender de ter dados inseridos, atualizados e excluídos de acordo com a lógica de negócio rigorosamente definida. Se for o caso, a permissão para que outros aplicativos modifiquem os dados diretamente pode levar à invalidação dos dados. Se você deseja que os desenvolvedores usem o acesso via intenções, certifique-se de documentá-lo minuciosamente. Explique por que o acesso via intenções pela IU do aplicativo é melhor do que tentar modificar os dados com códigos.
O tratamento das intenções recebidas com a intenção de modificar os dados do provedor não é diferente de tratar de outras intenções. Para saber mais sobre o uso de intenções, leia o tópico Intenções e filtros de intenções.