第007天：跨APP共享数据技术

        在上一章中我们学了 Android数据持久化的技术，包括文件存储、SharedPreferences存储以 及数据库存储。不知道你有没有发现，使用这些持久化技术所保存的数据都只能在当前应用程序中 访问。虽然文件和 SharedPreferences 存储中提供了 MODE_WORLD_READABLE 和MODE_ WORLD_WRITEABLE这两种操作模式，用于供给其他的应用程序访问当前应用的数据，但这两 种模式在Android4.2版本中都已被废弃了。为什么呢？因为Android官方已经不再推荐使用这种方式来实现跨程序数据共享的功能，而是应该使用更加安全可靠的内容提供器技术。

        可能你会有些疑惑，为什么要将我们程序中的数据共享给其他程序呢？当然，这个是要视情况而定的，比如说账号和密码这样的隐私数据显然是不能共享给其他程序的，不过一些可以让其他程序进行二次开发的基础性数据，我们还是可以选择将其共享的。例如系统的电话簿程序，它的数据库中保存了很多的联系人信息，如果这些数据都不允许第三方的程序进行访问的话，恐怕很多应用的功能都要大打折扣了。除了电话簿之外，还有短信、媒体库等程序都实现了跨程序数据共享的功能，而使用的技术当然就是内容提供器了，下面我们就来对这一技术进行深入的探讨。

7.1内容提供器简介

        内容提供器(Content Provider)主要用于在不同的应用程序之间实现数据共享的功能，它提供了一套完整的机制，允许一个程序访问另一个程序中的数据，同时还能保证被访数据的安全性。 目前，使用内容提供器是Android实现跨程序共享数据的标准方式。

        不同于文件存储和SharedPreferences存储中的两种全局可读写操作模式，内容提供器可以选择只对哪一部分数据进行共享，从而保证我们程序中的隐私数据不会有泄漏的风险。

        不过在正式开始学习内容提供器之前，我们需要先掌握另外一个非常重要的知识—— Android运行时权限，因为待会的内容提供器示例中会使用到运行时权限的功能。当然不光是内容提供器，以后我们的开发过程中也会经常使用到运行时权限，因此你必须能够牢牢掌握它才行。

7.2运行时权限

        Android的权限机制并不是什么新鲜事物，从系统的第一个版本开始就已经存在了。但其实之前Android的权限机制在保护用户安全和隐私等方面起到的作用比较有限，尤其是一些大家都离不开的常用软件，非常容易“店大欺客”。为此，Android开发团队在Android 6.0系统中引用了运行时权限这个功能，从而更好地保护了用户的安全和隐私，那么本节我们就来详细学习一下这个6.0系统中引入的新特性。

7.2.1 Android权限机制详解

        首先来回顾一下过去Android的权限机制是什么样的。我们在第5章写BroadcastTest项目的时候第一次接触了 Android权限相关的内容，当时为了要访问系统的网络状态以及监听开机广播, 于是在AndroidManifest.xml文件中添加了这样两句权限声明：

<manifest xmlns:android="http://schemas.android.com/apk/res/android"     
    package="com.example.broadcasttest">
    <uses-permission android:name="android.permission.ACCESSNETWORKSTATE" /> <uses-        
    permission 
    android:name="android.permission.RECEIVE BOOT COMPLETED" />

</manifest>

        因为访问系统的网络状态以及监听开机广播涉及了用户设备的安全性，因此必须在 AndroidManifest.xml中加入权限声明，否则我们的程序就会崩溃。

        那么现在问题来了，加入了这两句权限声明后，对于用户来说到底有什么影响呢？为什么这 样就可以保护用户设备的安全性了呢？

        其实用户主要在以下两个方面得到了保护，一方面，如果用户在低于6.0系统的设备上安装该程序，会在安装界面给出如图7.1所示的提醒。这样用户就可以清楚地知晓该程序一共申请了哪些权限，从而决定是否要安装这个程序。

        另一方面，用户可以随时在应用程序管理界面查看任意一个程序的权限申请情况，如图7.2 所示。这样该程序申请的所有权限就尽收眼底，什么都瞒不过用户的眼睛，以此保证应用程序不会出现各种滥用权限的情况。

        这种权限机制的设计思路其实非常简单，就是用户如果认可你所申请的权限，那么就会安装 你的程序，如果不认可你所申请的权限，那么拒绝安装就可以了。但是理想是美好的，现实却很残酷，因为很多我们所离不开的常用软件普遍存在着滥用权限的情况，不管到底用不用得到，反正先把权限申请了再说。比如说微信所申请的权限列表如图 7.3所示。

        这只是微信所申请的一半左右的权限，因为权限太多一屏截不下来。其中有一些权限我并不 认可，比如微信为什么要读取我手机的短信和彩信？但是我不认可又能怎样，难道我拒绝安装微 信？没错，这种例子比比皆是，当一些软件已经让我们产生依赖的时候就会容易“店大欺客”, 反正这个权限我就是要了，你自己看着办吧!

        Android开发团队当然也意识到了这个问题，于是在6.0系统中加入了运行时权限功能。也就是说，用户不需要在安装软件的时候一次性授权所有申请的权限，而是可以在软件的使用过程中再对某一项权限申请进行授权。比如说一款相机应用在运行时申请了地理位置定位权限，就算我拒绝了这个权限，但是我应该仍然可以使用这个应用的其他功能，而不是像之前那样直接无法安装它。

        当然，并不是所有权限都需要在运行时申请，对于用户来说，不停地授权也很烦琐。Android 现在将所有的权限归成了两类，一类是普通权限，一类是危险权限。普通权限指的是那些不会直 接威胁到用户的安全和隐私的权限，对于这部分权限申请，系统会自动帮我们进行授权，而不需 要用户再去手动操作了，比如在BroadcastTest项目中申请的两个权限就是普通权限。危险权限则 表示那些可能会触及用户隐私，或者对设备安全性造成影响的权限，如获取设备联系人信息、定 位设备的地理位置等，对于这部分权限申请，必须要由用户手动点击授权才可以，否则程序就无 法使用相应的功能。

        但是Android中有一共有上百种权限，我们怎么从中区分哪些是普通权限，哪些是危险权限呢？其实并没有那么难，因为危险权限总共就那么几个，除了危险权限之外，剩余的就都是普通 权限了。下表列出了 Android中所有的危险权限，一共是9组24个权限。

 

        这张表格你看起来可能并不会那么轻松，因为里面的权限全都是你没使用过的。不过没有关 系，你并不需要了解表格中每个权限的作用，只要把它当成一个参照表来查看就行了。每当要使 用一个权限时，可以先到这张表中来查一下，如果是属于这张表中的权限，那么就需要进行运行 时权限处理，如果不在这张表中，那么只需要在AndroidManifest.xml文件中添加一下权限声明就 可以了。

        另外注意一下，表格中每个危险权限都属于一个权限组，我们在进行运行时权限处理时使用 的是权限名，但是用户一旦同意授权了，那么该权限所对应的权限组中所有的其他权限也会同时 被授权。访http://developer.android.com/reference/android/Manifest.permission.html 可以查看 Android 系统中完整的权限列表。好了，关于Android权限机制的内容就讲这么多，理论知识你已经了解得非常充足了。接下 来我们就学习一下到底如何在程序运行的时候申请权限。

7.2.2在程序运行时申请权限

        首先新建一个RuntimePermissionTest项目，我们就在这个项目的基础上来学习运行时权限的 使用方法。在开始动手之前还需要考虑一下到底要申请什么权限，其实刚才表中列出的所有权限 都是可以申请的，这里简单起见我们就使用CALL_PHONE这个权限来作为本小节中的示例吧。

        CALL_PHONE这个权限是编写拨打电话功能的时候需要声明的，因为拨打电话会涉及用户手 机的资费问题，因而被列为了危险权限。在Android 6.0系统出现之前，拨打电话功能的实现其 实非常简单,修改activity main.xml布局文件，如下所示：

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"         
    android:layout_width="match_parent" 
    android:layout_height="match_parent">

    <Button
    android:id=”@+id/make_call"
    android:layout_width="match_parent"
    android:layout_height="wrap_content" 
    android:text="Make Call" 
    />
</LinearLayout>

        我们在布局文件中只是定义了一个按钮，当点击按钮时就去触发拨打电话的逻辑。接着修改 MainActivity中的代码，如下所示：

public class MainActivity extends AppCompatActivity {
    @Override
    protected void onCreate(Bundle savedlnstanceState) {
        super.onCreate(savedlnstanceState); setContentView(R.layout.activitymain); 
        Button makeCall = (Button) findViewById(R.id.makecall);             
        makeCall.setOnClickListener(new View.OnClickListener() { 
            @Override 
            public void onClick(View v) {
            try {
        Intent intent = new Intent(Intent.ACTIONCALL);             
        intent.setData(Uri.parse("tel:10086")); startActivity(intent);
} 
    catch (SecurityException e) {
    e.printStackTrace();
)
}

        可以看到，在按钮的点击事件中，我们构建了一个隐式Intent , Intent的action指定为Intent. ACTI0N_ CALL,这是一个系统内置的打电话的动作，然后在data部分指定了协议是tel, 号码是10086o其实这部分代码我们在2.3.3小节中就已经见过了，只不过当时指定的action是Intent. ACTI0N_DIAL,表示打开拨号界面,这个是不需要声明权限的，而Intent. ACTI0N_ CALL 则可以直接拨打电话，因此必须声明权限。另外为了防止程序崩溃，我们将所有操作都放在了异常捕获代码块当中。

那么接下来修改AndroidManifest.xml文件，在其中声明如下权限：

<manifest xmlns:android="http://schemas.android.com/apk/res/android"             
    package="com.example.runtimepermissiontest">
    <uses-permission android: name=>l
    android.permission. CALL_PHONE** />

    <application
        android:allowBackup="true"
        android:icon="@mipmap/ic_launcher"
        android:label="@string/app name"
        android:supportsRtl="true"
        android: theme="(astyle/AppTheme">
        </application>
</manifest>

        这样我们就将拨打电话的功能成功实现了，并且在低于Android 6.0系统的手机上都是可以 正常运行的，但是如果我们在6.0或者更高版本系统的手机上运行，点击Make Call按钮就没有 任何效果，这时观察logcat中的打印日志，你会看到如图7.4所示的错误信息。

         错误信息中提醒我们“PermissionDenial”，可以看出，是由于权限被禁止所导致的，因为6.0 及以上系统在使用危险权限时都必须进行运行时权限处理。

        那么下面我们就来尝试修复这个问题，修改MainActivity中的代码，如下所示：

public class MainActivity extends AppCompatActivity {
    protected void onCreate(Bundle savedlnstanceState) {
    super.onCreate(savedlnstanceState); setContentView(R.layout.activitymain); Button         
    makeCall = (Button) findViewById(R.id.makecall); makeCall.setOnClickListener(new         
    View.OnClickListenerf) { (aOverride public void onClick(View v) (
    if (ContextCompat.checkSelfPermission(MainActivity.this, Manifest,         
        permission.CALL_PHONE) != PackageManager.PERMISSION__GRANTED) {         
         ActivityCompat.requestPermissions(MainActivity.thisf new
             String!]{ Manifest.permission.CALL_PHONE }, 1);
        } else { caU();
    }
)
        })；
}
private void call() {
        try {
            Intent intent = new Intent(Intent.ACTION_CALL);
                intent. setData(Uri. parse ("tel: 10686**)); sta rtActivity(intent);
        } catch (SecurityException e) {
            e.printStackT race();
        }
    }
    ©Override
public void onRequestPermissionsResult(int requestcode, String[] permissions, int[]                 grantResults) { switch (requestcode) {
    case 1:
        if (grantResults.length > G && grantResults[6] == PackageManager.             
        PERMISSION__GRANTED) {
        caU(); } else {
        Toast.makeText(this, "You denied the permission", Toast.LENGTH_ SHORT).show();	"
        } break;
        default:
        }
    }
}

        上面的代码将运行时权限的完整流程都覆盖了，下面我们来具体解析一下。说白了，运行时 权限的核心就是在程序运行过程中由用户授权我们去执行某些危险操作，程序是不可以擅自做主 去执行这些危险操作的。因此，第一步就是要先判断用户是不是已经给过我们授权了，借助的是 ContextCompat. checkSelfPermission ()方法。checkSelfPermission()方法接收两个参数， 第一个参数是Context,这个没什么好说的，第二个参数是具体的权限名，比如打电话的权限名
就是Manifest.permission.CALL PHONE,然后我们使用方法的返回值和PackageManager. PERMISSION_GRANTED做比较，相等就说明用户已经授权，不等就表示用户没有授权。

        如果已经授权的话就简单了，直接去执行拨打电话的逻辑操作就可以了，这里我们把拨打电 话的逻辑封装到了 call()方法当中。如果没有授权的话，则需要调用ActivityCompat. requestpermissions ()方法来向用户申请授权，requestpermissions ()方法接收3个参数， 第一个参数要求是Activity的实例，第二个参数是一个String数组，我们把要申请的权限名放 在数组中即可，第三个参数是请求码，只要是唯一值就可以了，这里传入了 1。

        调用完了 requestpermissions()方法之后，系统会弹出一个权限申请的对话框，然后用户 可以选择同意或拒绝我们的权限申请，不论是哪种结果，最终都会回调到onRequest- PermissionsResult ()方法中，而授权的结果则会封装在grantResults参数当中。这里我们 只需要判断一下最后的授权结果，如果用户同意的话就调用call()方法来拨打电话，如果用户 拒绝的话我们只能放弃操作，并且弹出一条失败提示。

        现在重新运行一下程序，并点击Make Call按钮，效果如图7.5所示。

        由于用户还没有授权过我们拨打电话权限，因此第一次运行会弹出这样一个权限申请的对话 框，用户可以选择同意或者拒绝，比如说这里点击了 DENY,结果如图7.6所示。

         由于用户没有同意授权，我们只能弹出一个操作失败的提示。下面我们再次点击Make Call 按钮，仍然会弹出权限申请的对话框，这次点击ALLOW，结果如图7.7所示。

         可以看到，这次我们就成功进入到拨打电话界面了，并且由于用户已经完成了授权操作，之 后再点击Make Call按钮就不会再弹出权限申请对话框了，而是可以直接拨打电话。那可能你会 担心，万一以后我又后悔了怎么办？没有关系，用户随时都可以将授予程序的危险权限进行关闭， 进入 Settings Apps —> RuntimePermissionTest —> Permissions,界面如图 7.8 所示。

        在这里我们就可以对任何授予过的危险权限进行关闭了。

        好了，关于运行时权限的内容就讲到这里，现在你已经有能力处理Android±各种关于权限 的问题了，下面我们就来进入本章的正题一一内容提供器。

7.3访问其他程序中的数据

        内容提供器的用法一般有两种，一种是使用现有的内容提供器来读取和操作相应程序中的数 据，另一种是创建自己的内容提供器给我们程序的数据提供外部访问接口。那么接下来我们就一 个一个开始学习吧，首先从使用现有的内容提供器开始。

        如果一个应用程序通过内容提供器对其数据提供了外部访问接口，那么任何其他的应用程序 就都可以对这部分数据进行访问。Android系统中自带的电话簿、短信、媒体库等程序都提供了 类似的访问接口，这就使得第三方应用程序可以充分地利用这部分数据来实现更好的功能。下面 我们就来看一看，内容提供器到底是如何使用的。

7.3.1 ContentResolver 的基本用法

        对于每一个应用程序来说，如果想要访问内容提供器中共享的数据，就一定要借助Content- Resolver 类，可以通过Context中的getContentResolver()方法获取到该类的实例。Content- Resolver 中提供了一系列的方法用于对数据进行CRUD操作，其中insertO方法用于添加数据， updateO方法用于更新数据，delete。方法用于删除数据，query()方法用于查询数据。有没有似曾相识的感觉？没错，SQLiteDatabase中也是使用这几个方法来进行CRUD操作的，只不过它们在方法参数上稍微有一些区别。

        不同于SQLiteDatabase, ContentResolver中的增删改查方法都是不接收表名参数的，而是使用一个Uri参数代替，这个参数被称为内容URI。内容URI给内容提供器中的数据建立了唯一 标识符，它主要由两部分组成：authority和patho authority是用于对不同的应用程序做区分的， 一般为了避免冲突，都会采用程序包名的方式来进行命名。比如某个程序的包名是com.example. app,那么该程序对应的authority就可以命名为com.example.app. providero path则是用于对同一 应用程序中不同的表做区分的，通常都会添加到authority的后面。比如某个程序的数据库里存在 两张表：table 1和table2,这时就可以将path分别命名为/table 1和/table2,然后把authority和path 进行组合，内容 URI 就变成了 com.example.app.provider/table 1 和 com.example.app.provider/table2o 不过，目前还很难辨认出这两个字符串就是两个内容URI,我们还需要在字符串的头部加上协议 声明。因此，内容URI最标准的格式写法如下：

content://com.example.app.provider/tablel content://com.example.app.provider/table2

        有没有发现，内容URI可以非常清楚地表达出我们想要访问哪个程序中哪张表里的数据。 也正是因此，ContentResolver