FileProvider 是 Android N 系統提供的保障 app 間文件 (File) 傳輸安全的一個新特性。當我們的應用需要分享私有文件時（典型場景就是調用相機拍照），我們需要適配此特性，否則將會在 Android 7.0 以上系統觸發安全機制（StrictMode），導致閃退。
FileProvider 是 ContentProvider 的子類，實現了 query() 和 delete() 方法，并使 insert() 和 update() 方法直接拋出異常。同時，新增了一個 public static 方法，getUriFromFile(File file),來讓我們在應用中獲取用于分享此 file 的 uri。FileProvider 類中還有一些用于解析文件路徑的內部類和私有方法，此處不展開分析。
工作過程
Uri 是什么
Uri 類是 Android 對 Java 提供的 URI 類的一個擴展。簡單來講，Uri 對象是對一個資源文件（圖片、音頻等）的一個標識符（Identifier），通過這個對象，應用可以準確的找到對應的資源文件。Uri 主要分為三部分：scheme, authority 和 path。一個常見的 uri 示例如下："content://com.mydomain.fileprovider/image.jpg"，也就是 "{scheme}://{authority}/{path}"
應用根據文件獲取 uri
拿我們使用相機為自己的應用提供照片為例，我們需要向啟動相機的 intent 中加入存儲相片的文件的 uri 信息，以供相機應用存儲照片時使用。
在 7.0 以前的系統版本中，我們可以直接調用 Uri.fromFile(file) 來獲取 file 的 uri，這個 uri 以 “file:///” 為首，且無時效性限制，接受到此 uri 的應用可以對它進行保存后，隨時獲取此 file。
而在 7.0 以后的系統版本中，我們只能通過前文提到的，FileProvider.getUriFromFile(file) 來提供一個以 “content://” 為首的 uri。這個 uri 有一定的時效性，其生命周期伴隨著 intent 關聯的組件（可以是 Activity，也可以是 Service）的生命周期結束而結束，所以很大程度上保障了開發者的應用私有文件的安全。
接收到 uri 的應用，通過 uri 獲取具體文件
為此我特意找到了 5.1 和 7.0 系統的 Camera 源碼，準備寫一寫兩個系統對接受到的 Uri 處理方式的不同，然后發現...
兩個系統的處理方式一毛一樣！都是 getContentResolver().openOutputStream(mSaveUri),然后對這個輸出流寫數據。
心有不甘的我又打開了 ContentReslover 的源碼，發現真正區別的代碼是在這里：
** ①“file" 開頭的uri，直接用 new File(uri.getPath()) 獲取對應文件 **
** ②“content" 開頭的uri，先找到對應的 Provider （這里就是 FileProvider），再調用unstableProvider.openAssetFile(mPackageName, uri, mode, remoteCancellationSignal) 獲取對應文件**
適配教程
在 AndroidManifest 中定義 FileProvider
定義 FileProvider 的過程其實和定義 ContentProvider 的過程相差無幾，只不過系統已經為我們構建好了 FileProvider 的具體代碼，我們只需要在 AndroidManifest.xml 中來定義他們。
直接上代碼：
<manifest>
...
<application>
...
<provider
android:name="android.support.v4.content.FileProvider"
android:authorities="com.mydomain.fileprovider"
android:exported="false"
android:grantUriPermissions="true">
<meta-data
android:name="android.support.FILE_PROVIDER_PATHS"
android:resource="@xml/file_paths"/>
</provider>
...
</application>
</manifest>
其中，需要自定義的有 android:authorities,用于標識屬于你的應用的 FileProvider；還有 meta-data 標簽內需要指定一個路徑配置文件，android:resource。關于路徑配置文件的相關定義在下節會給出。
在 xml 文件夾下定義路徑配置文件
路徑配置文件限制了 FileProvider 可以獲取到你的應有私有目錄下具體的子文件夾，比如說你的應用目錄下有 imgs 和 docs 兩個子文件夾，而你只希望向外分享圖片，則可以將下面的 path 屬性值設置為 path="imgs"。
一般我們在 res 文件夾下新建一個 xml 文件夾，然后新建一個 file_paths.xml 文件（文件夾名+文件名=上面 Mainfest 中定義的 meta-data 標簽 的 resource 屬性）。然后 file_paths.xml 中寫入：
<?xml version="1.0" encoding="utf-8"?>
<paths>
<external-path name="my_images" path=""/>
<!-- 以下為各類標簽匯總
<files-path name="name" path="path" />
<cache-path name="name" path="path"/>
<external-path name="name" path="path"/>
<external-files-path name="name" path="path"/>
<external-cache-path name="name" path="path"/>
-->
</paths>
其中，name 屬性值用于組成最后生成的 uri 的一部分，所以這個屬性可以任意定制。
而前面的標簽名的不同則決定了文件夾位置的不同。
"files_path" 對應 Context.getFilesDir() 的路徑，物理路徑為：data/data/<application package>/files。
"cache-path" 對應 Context.getCacheDir()，物理路徑為：/data/data/<application package>/cache。
"external-path"對應 Environment.getExternalStorageDirectory()。
"external-files-path" 對應Context.getExternalFilesDir(String)、Context.getExternalFilesDir(null)。
而 "external-cache-path" 對應的是 Context.getExternalCacheDir()。
path 屬性就是第一段所提到的，當你的文件夾下有多個子文件夾，你只希望提供某一個文件夾的時候，可以在屬性中填入相應的文件夾名。為空時，FileProvider 則可以為應用文件夾下的所有文件生成 uri。
獲取 uri 并分享
當配置文件都完成了之后我們便可以方便的獲取 uri了，具體代碼如下：
File file = new File(Context.getFilesDir(), "default_image.jpg");
Uri contentUri = FileProvider.getUriForFile(getContext(), "com.mydomain.fileprovider", file);
這時候，你就可以獲取到一個值為："content://com.mydomain.fileprovider/my_images/default_image.jpg" 的 uri了，其中 “com.mydomain.fileprovider/” 后的 "my_images" 就是前面路徑配置文件中 name 屬性指定的。再將 uri 傳入 intent，設置臨時權限，適配完成。
Intent intent = new Intent();
intent.setAction(MediaStore.ACTION_IMAGE_CAPTURE);
intent.putExtra(MediaStore.EXTRA_OUTPUT, contentUri);
intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK | Intent.FLAG_GRANT_READ_URI_PERMISSION
| Intent.FLAG_GRANT_WRITE_URI_PERMISSION);
startActivityForResult(intent, requestCode);
當然，這只是對應 7.0 以上系統的代碼截選，對應 7.0 以下系統的代碼中，我們直接調用 Uri.fromFile(file) 獲取 uri 即可。
總結
FileProvider 這個類其實在 Android 5.1 就已經加入到了 sdk 中，Android 7.0 開始強制開發者使用，可以看出，谷歌有意進一步提升安卓系統的安全性。在查閱資料的過程中，看到有評論“通過反射關閉 StrictMode 從而防止閃退”的“黑科技”（哭笑），從我個人使用的感覺上，適配這個新特性，并沒有繁瑣的操作，也沒有性能的影響。作為一個還沒入行的開發者，還是希望大家可以支持谷歌建設更好的生態，而不是自砸飯碗吧。
