從Android 7.0開始碍论，一個應(yīng)用提供自身文件給其它應(yīng)用使用時谅猾，如果給出一個file://格式的URI的話，應(yīng)用會拋出FileUriExposedException鳍悠。這是由于谷歌認為目標app可能不具有文件權(quán)限税娜，會造成潛在的問題。所以讓這一行為快速失敗藏研。詳見這里敬矩。這里討論兩種解決方式。
1 FileProvider方式
這是谷歌官方推薦的解決方案遥倦。即使用FileProvider來生成一個content://格式的URI谤绳。具體實現(xiàn)方式如下：
- manifest聲明
在manifest中聲明一個provider占锯。name（即類名）為android.support.v4.content.FileProvider袒哥。
<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>
其中authorities可以自定義。為了避免和其它app沖突消略，最好帶上自己app的包名堡称。file_paths.xml中編寫該Provider對外提供文件的目錄。文件放置在res/xml/下艺演。
2.編寫file_paths.xml
文件格式如下：
<paths xmlns:android="http://schemas.android.com/apk/res/android">
<files-path name="my_images" path="images/"/>
...
</paths>
內(nèi)部的element可以是files-path却紧，cache-path，external-path胎撤，external-files-path晓殊，external-cache-path，分別對應(yīng)Context.getFilesDir()伤提，Context.getCacheDir()巫俺，Environment.getExternalStorageDirectory()，Context.getExternalFilesDir()肿男，Context.getExternalCacheDir()等幾個方法介汹。后來翻看源碼發(fā)現(xiàn)還有一個沒有寫進文檔的，但是也可以使用的element舶沛，是root-path嘹承，直接對應(yīng)文件系統(tǒng)根目錄。不過既然沒有寫進文檔中如庭，其實還是有將來移除的可能的叹卷。使用的話需要注意一下風險。
3.在Java代碼當中使用
以分享一個圖片為例：
File file = ...; //要分享的圖片文件
Uri uri = FileProvider.getUriForFile(context, "com.mydomain.fileprovider", file); //第二個參數(shù)是manifest中定義的`authorities`
Intent intent = new Intent(Intent.ACTION_SEND);
intent.setType("image/*");
intent.putExtra(Intent.EXTRA_TITLE, title);
intent.putExtra(Intent.EXTRA_TEXT, text);
intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION); //這一步很重要。給目標應(yīng)用一個臨時的授權(quán)骤竹。
startActivity(intent); //或者其它最終處理方式
2 VmPolicy方式
以上方法固然是推薦使用的餐胀，正確的方法。但是我在實際開發(fā)中遇到這樣的問題瘤载。某些應(yīng)用（此處點名新浪微博）根本無法理解一個指向文件的content://格式的URI否灾。新浪微博接收到這類URI之后，無法加載圖片鸣奔，并會在點擊發(fā)送微博時崩潰墨技。
另一方面，新浪微博對權(quán)限管理的處理采取了一種比較流氓的方式挎狸。它會在啟動時申請文件讀寫權(quán)限扣汪，而如果拒絕該權(quán)限的話，居然就直接退出了锨匆。我反正是不信什么需要文件權(quán)限來放緩存放數(shù)據(jù)的說辭崭别。放緩存放數(shù)據(jù)有著一堆不需要權(quán)限的目錄可用。但是這樣一來恐锣，我們其實是不需要擔心傳遞一個file://格式URI過去而對方?jīng)]有權(quán)限的茅主。
話說回來，如何解決這一問題呢土榴？我在調(diào)研的時候觀察到嚴格模式的一個方法：StrictMode.VmPolicy.Builder.detectFileUriExposure()诀姚。顧名思義，調(diào)用這個方法就會檢測FileUriExposure這件事玷禽。這個方法其實從API18就有了赫段，是不是有可能在API24變成了默認選項呢？
在Application.onCreate加入如下代碼矢赁，置入一個不設(shè)防的VmPolicy：
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.N) {
StrictMode.VmPolicy.Builder builder = new StrictMode.VmPolicy.Builder();
StrictMode.setVmPolicy(builder.build());
}
再用舊的方式直接把file://格式的URI發(fā)送出去糯笙。居然成功了，沒有再拋出FileUriExposedException撩银。
3 小結(jié)
最終我采取的綜合方案是给涕，先使用PackageManager.checkPermission檢測對方的app有沒有取得文件讀寫權(quán)限。如果有的話蜒蕾，給對方發(fā)送file://格式URI稠炬。如果沒有的話，給對方發(fā)送FileProvider生成的URI并臨時授權(quán)咪啡。
原本一個有標準解決方案的問題首启，因為某些應(yīng)用不遵循規(guī)范而需要做更多的調(diào)研和workaround。實在是麻煩撤摸。希望可以幫助到遇到同樣問題的人毅桃。
