Develop Reference

Is particular bookmark a content provider?

I know that browser is content provider but i want to know, is bookmark (which support to browser) is also a content provider.

Be aware in android 6 global bookmarks are removed.
In general, any app can implement its own bookmarks and share it as content provider.
You may ask - but how do clients find provider? Well, it’s required to know the URIs of a provider to access it. The recommendation is to publish public constants for the URIs and document them to other developers.

When is a Custom Content Provider called for?

I have seen custom content providers for sqLite in apps, but thats about it. When should a Custom Content provider be built?

EboMike in this question says:
Other apps will be able to access your data.
You can wrap and abstract a lot of the query logic in your content provider, and limit access.
You will be able to lean on the system to allow for things like managed queries.
Remember that you can control user interacts with your data,for example you can prevent user from modifying data or you can force system to open data with explicit App and so on.

How many content provider we can implement in one app?

I've read Android dev guide and notice that we can implement different classes for the content provider. So,
There are many content providers or just one content provider in one Android app?
How to properly implement different content provider classes like that?
Here is what I read from the dev guide:
You implement a provider as one or more classes in an Android
application
http://developer.android.com/guide/topics/providers/content-provider-creating.html

You can implement as many as you want, as you can see from the documentation here. To register a content provider, you need to add its corresponding <provider> tag in the Android Manifest.
In most cases, however, you won't need multiple content providers. One is usually enough, as it can handle multiple tables. You should only really need more than one if you want your app to provide public access to 2+ separate data entities.

You can use (provide as well as use) as many content providers per app as you need. They need different content URIs, of course.
In addition to the uses outlined in the document (your link) you can use content providers for other purposes as accessing data storage. The content URI can have parameters, so you can use a content provider similarly to a web service.

You can create as many content providers as you want. But do you need them al?
What content provider classes do you want to implement? If you read the page very good you should have seen that it contains links to two pages:
http://developer.android.com/guide/topics/providers/content-provider-basics.html - Content Provider Basics
http://developer.android.com/guide/topics/providers/content-provider-creating.html#ContentProvider - Implementing the ContentProvider Class
I suggest you first read those pages. Google is giving some more information about Content Providers, tutorials and examples:
http://android10.org/index.php/articlesdatastorage/252-content-providers-using-and-creating-them
http://thinkandroid.wordpress.com/2010/01/13/writing-your-own-contentprovider/
http://www.vogella.com/articles/AndroidSQLite/article.html
http://about-android.blogspot.com/2010/04/content-provider-example-1.html

There is no rule as such that you have to implement only one content provider per application. If your project demands, then you can do so.
If you want to implement multiple content providers in your application package, then make sure that authorities part of each content provider is unique, to route the incoming data requests to each content providers properly.
But having too many content providers can really confuse you and not required.
The only scenario that I see to have multiple content providers is, if you are having multiple databases in your application and you want to share all those databases with outside applications. Where you can use separate content provider for each database to share it with outside world.
Hope it helps.

Using content provider to fetch emails

I need to fetch and list the received emails in my own layout listview.
Is this possible through Content Provider?

There are no documented and supported content providers for "received emails". "Email" is not really a part of the operating system (though there are a few lingering references to it from back in the 2006-2007 timeframe when there was no clear distinction between the OS, apps, and the SDK). There are probably hundreds of email clients, only a few of which might have such content providers, and probably no standards between them.
You will find some blog posts and other answers here on StackOverflow that point you to a Gmail content provider. This is an example of an undocumented and unsupported content provider. It was also just closed off by Google.
You are welcome to write your own email client, store your own emails, and display them as you see fit, though.

Can multiple ContentProvider's serve the same URI?

When querying a ContentProvider on Android, one specifies the ContentProvider of interest by providing the "content URI" for that ContentProvider. What happens when multiple ContentProvider's serve that same URI, either intentionally? or maliciously?
When trying to open a pic on my phone, I've seen it prompt with apps that can "handle" the image. Will the same kind of thing happen here?

Multiple ContentProviders can't do this. The first application that registers a content provider using the element in its manifest has control over the URI pattern. I'm pretty sure that you'll get an installation error if you try to add another provider that uses the same URI pattern. Android keeps track of providers and URIs.
When you see a prompt with multiple apps for handling a file or situation, that's because the apps have specified an with a child that includes
android.intent.category.CATEGORY_ALTERNATIVE or android.intent-category.CATEGORY_SELECTED_ALTERNATVE. In essence, the app or apps are declaring themselves to be alternatives to the action specified in the child. This allows the user to have multiple choices for handling a type of data.
It makes sense to provide alternatives: a user might want to edit a picture, share it via Twitter, or e-mail it.
Note that two content providers can do the same thing, but they can't use the same URI. An app has to make a conscious choice of which one to use, or provide some mechanism of choosing between the two.