從Android 7.0開始,一個應用提供自身文件給其它應用使用時,如果給出一個file://格式的URI的話,應用會拋出FileUriExposedException。這是由於谷歌認爲目標app可能不具有文件權限,會造成潛在的問題。所以讓這一行爲快速失敗。詳見這裏。這裏討論兩種解決方式。
1 FileProvider方式
這是谷歌官方推薦的解決方案https://github.com/honjane/fileProviderDemo。即使用FileProvider來生成一個content://格式的URI。具體實現方式如下:
manifest聲明
1、在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>
內部的element可以是files-path,cache-path,external-path,external-files-path,external-cache-path,分別對應Context.getFilesDir(),Context.getCacheDir(),Environment.getExternalStorageDirectory(),Context.getExternalFilesDir(),Context.getExternalCacheDir()等幾個方法。後來翻看源碼發現還有一個沒有寫進文檔的,但是也可以使用的element,是root-path,直接對應文件系統根目錄。不過既然沒有寫進文檔中,其實還是有將來移除的可能的。使用的話需要注意一下風險。
3.在Java代碼當中使用
以分享一個圖片爲例:
File file = ...; //要分享的圖片文件
Uri uri = FileProvider.getUriForFile(context, "com.mydomain.fileprovider", file); //第二個參數是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); //這一步很重要。給目標應用一個臨時的授權。
startActivity(intent); //或者其它最終處理方式
2 VmPolicy方式
以上方法固然是推薦使用的,正確的方法。但是我在實際開發中遇到這樣的問題。某些應用(此處點名新浪微博)根本無法理解一個指向文件的content://格式的URI。新浪微博接收到這類URI之後,無法加載圖片,並會在點擊發送微博時崩潰。
另一方面,新浪微博對權限管理的處理採取了一種比較流氓的方式。它會在啓動時申請文件讀寫權限,而如果拒絕該權限的話,居然就直接退出了。我反正是不信什麼需要文件權限來放緩存放數據的說辭。放緩存放數據有着一堆不需要權限的目錄可用。但是這樣一來,我們其實是不需要擔心傳遞一個file://格式URI過去而對方沒有權限的。
話說回來,如何解決這一問題呢?我在調研的時候觀察到嚴格模式的一個方法:StrictMode.VmPolicy.Builder.detectFileUriExposure()。顧名思義,調用這個方法就會檢測FileUriExposure這件事。這個方法其實從API18就有了,是不是有可能在API24變成了默認選項呢?
在Application.onCreate加入如下代碼,置入一個不設防的VmPolicy:
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.N) {
StrictMode.VmPolicy.Builder builder = new StrictMode.VmPolicy.Builder();
StrictMode.setVmPolicy(builder.build());
}
再用舊的方式直接把file://格式的URI發送出去。居然成功了,沒有再拋出FileUriExposedException。
小結
最終我採取的綜合方案是,先使用PackageManager.checkPermission檢測對方的app有沒有取得文件讀寫權限。如果有的話,給對方發送file://格式URI。如果沒有的話,給對方發送FileProvider生成的URI並臨時授權。
原本一個有標準解決方案的問題,因爲某些應用不遵循規範而需要做更多的調研和workaround。實在是麻煩。希望可以幫助到遇到同樣問題的人。