Android语言基础教程（204）Android预定义Content Provider范例之系统内置联系人的使用：潜入Android系统联系人数据库：Content Provider实战全揭秘

你的Android应用真的会“读通讯录”吗？不少开发者还在权限申请上折腾，却不知背后隐藏着一套强大的数据访问机制。

01. Content Provider：Android世界的“数据中介”

简单来说，Content Provider就像是Android系统中的数据大管家，它用一种标准化的方式管理着不同应用间的数据共享。

想象一下，如果没有这个管家，每个应用都想访问系统联系人时，都得自己想办法直接进入系统数据库——这简直是一场安全灾难。

Content Provider封装了数据存储的细节，并提供了一个统一的API接口供其他应用使用。无论是系统内置的联系人、照片、日历事件，还是我们自定义的数据，都可以通过Content Provider来暴露给其他应用。

Android系统早已经为常用数据类型创建了对应的Content Provider，比如我们最熟悉的联系人信息。当你在短信应用中选择联系人发送信息时，背后就是Content Provider在默默工作。

02. 联系人数据库：三层结构探秘

要使用Content Provider访问联系人数据，我们首先得了解它的数据库结构。Android联系人数据库采用了三层设计：

• Data层：最底层，每种独立的数据类型占一行。比如姓名、电话、邮箱都作为单独的数据行存储。
• RawContacts层：由多个Data行组合成一个完整的联系人信息。
• Contacts层：最高层，处理一些特殊情况（如合并本地和网络联系人）。

在实际开发中，我们主要关注前两层。联系人信息被分散在多个表中，其中最重要的两张表是：

• raw_contacts表：保存了所有创建过的联系人，每个联系人占一行。
• data表：保存了所有联系人的详细信息，每个字段占一行。

这种设计看似复杂，实则合理——它允许每个联系人有多个电话号码、多个邮箱地址，而不需要为每个可能的字段组合创建新的列。

03. 权限：进入联系人数据库的“钥匙”

在访问联系人数据前，我们必须先获得用户的许可。Android系统要求我们在AndroidManifest.xml文件中声明权限：

<uses-permission android:name="android.permission.READ_CONTACTS" />
<uses-permission android:name="android.permission.WRITE_CONTACTS" />

从Android 6.0（API级别23）开始，我们不仅要在清单文件中声明权限，还要在运行时请求权限。这意味着我们需要在代码中检查是否已获得授权，如果没有，就需要向用户弹出权限请求对话框。

切记：没有这些权限，你的应用连联系人数据的“门”都进不去。

04. 实战：一步步读取联系人信息

理论说够了，让我们来看一个完整的示例，演示如何查询并显示手机上的所有联系人。

第一步：定义布局文件

我们使用一个简单的ListView来展示联系人信息：

<LinearLayout xmlns:android="http://schemas.androi