從Android7.0開始瑰剃，一個(gè)應(yīng)用提供自身文件給其它應(yīng)用使用時(shí)，如果給出一個(gè)file://格式的URI的話奠衔，應(yīng)用會(huì)拋出FileUriExposedException济赎。這是由于谷歌認(rèn)為目標(biāo)app可能不具有文件權(quán)限，會(huì)造成潛在的問題约巷。所以讓這一行為快速失敗偎痛。詳見這里。這里討論兩種解決方式独郎。
1 FileProvider方式
這是谷歌官方推薦的解決方案踩麦。即使用FileProvider來生成一個(gè)content://格式的URI。具體實(shí)現(xiàn)方式如下：
manifest聲明
在manifest中聲明一個(gè)provider氓癌。name（即類名）為android.support.v4.content.FileProvider谓谦。
其中authorities可以自定義。為了避免和其它app沖突贪婉，最好帶上自己app的包名反粥。file_paths.xml中編寫該P(yáng)rovider對(duì)外提供文件的目錄。文件放置在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，分別對(duì)應(yīng)Context.getFilesDir()腰池，Context.getCacheDir()尾组，Environment.getExternalStorageDirectory()，Context.getExternalFilesDir()巩螃，Context.getExternalCacheDir()等幾個(gè)方法演怎。后來翻看源碼發(fā)現(xiàn)還有一個(gè)沒有寫進(jìn)文檔的匕争，但是也可以使用的element避乏，是root-path，直接對(duì)應(yīng)文件系統(tǒng)根目錄甘桑。不過既然沒有寫進(jìn)文檔中拍皮，其實(shí)還是有將來移除的可能的。使用的話需要注意一下風(fēng)險(xiǎn)跑杭。
3.在Java代碼當(dāng)中使用
以分享一個(gè)圖片為例：
File file = ...;? ? //要分享的圖片文件
Uri uri = FileProvider.getUriForFile(context, "com.mydomain.fileprovider", file);? ? //第二個(gè)參數(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);? ? //這一步很重要铆帽。給目標(biāo)應(yīng)用一個(gè)臨時(shí)的授權(quán)。
startActivity(intent);? ? //或者其它最終處理方式
2 VmPolicy方式
以上方法固然是推薦使用的德谅，正確的方法爹橱。但是我在實(shí)際開發(fā)中遇到這樣的問題。某些應(yīng)用（此處點(diǎn)名新浪微博）根本無法理解一個(gè)指向文件的content://格式的URI窄做。新浪微博接收到這類URI之后愧驱，無法加載圖片慰技，并會(huì)在點(diǎn)擊發(fā)送微博時(shí)崩潰。
另一方面组砚，新浪微博對(duì)權(quán)限管理的處理采取了一種比較流氓的方式吻商。它會(huì)在啟動(dòng)時(shí)申請(qǐng)文件讀寫權(quán)限，而如果拒絕該權(quán)限的話糟红，居然就直接退出了艾帐。我反正是不信什么需要文件權(quán)限來放緩存放數(shù)據(jù)的說辭。放緩存放數(shù)據(jù)有著一堆不需要權(quán)限的目錄可用盆偿。但是這樣一來柒爸，我們其實(shí)是不需要擔(dān)心傳遞一個(gè)file://格式URI過去而對(duì)方?jīng)]有權(quán)限的。
話說回來事扭，如何解決這一問題呢揍鸟？我在調(diào)研的時(shí)候觀察到嚴(yán)格模式的一個(gè)方法：StrictMode.VmPolicy.Builder.detectFileUriExposure()。顧名思義句旱，調(diào)用這個(gè)方法就會(huì)檢測(cè)FileUriExposure這件事阳藻。這個(gè)方法其實(shí)從API18就有了，是不是有可能在API24變成了默認(rèn)選項(xiàng)呢谈撒？
在Application.onCreate加入如下代碼腥泥，置入一個(gè)不設(shè)防的VmPolicy：
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.N) {
StrictMode.VmPolicy.Builderbuilder = new StrictMode.VmPolicy.Builder();StrictMode.setVmPolicy(builder.build());}
再用舊的方式直接把file://格式的URI發(fā)送出去。居然成功了啃匿，沒有再拋出FileUriExposedException蛔外。
3 小結(jié)
個(gè)人感覺第二個(gè)比較好用！
最終我采取的綜合方案是溯乒，先使用PackageManager.checkPermission檢測(cè)對(duì)方的app有沒有取得文件讀寫權(quán)限夹厌。如果有的話，給對(duì)方發(fā)送file://格式URI裆悄。如果沒有的話矛纹，給對(duì)方發(fā)送FileProvider生成的URI并臨時(shí)授權(quán)。
原本一個(gè)有標(biāo)準(zhǔn)解決方案的問題光稼，因?yàn)槟承?yīng)用不遵循規(guī)范而需要做更多的調(diào)研和workaround或南。實(shí)在是麻煩。希望可以幫助到遇到同樣問題的人艾君。
