從Android 7.0開始，一個應用提供自身檔案給其它應用使用時，如果給出一個file://格式的URI的話，應用會丟擲FileUriExposedException。這是由於谷歌認為目標app可能不具有檔案許可權，會造成潛在的問題。所以讓這一行為快速失敗。詳見這裡。這裡討論兩種解決方式。

1 FileProvider方式

這是谷歌官方推薦的解決方案。即使用FileProvider來生成一個content://格式的URI。具體實現方式如下：

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>

內部的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。

3 小結
個人感覺第二個比較好用！
最終我採取的綜合方案是，先使用PackageManager.checkPermission檢測對方的app有沒有取得檔案讀寫許可權。如果有的話，給對方傳送file://格式URI。如果沒有的話，給對方傳送FileProvider生成的URI並臨時授權。
原本一個有標準解決方案的問題，因為某些應用不遵循規範而需要做更多的調研和workaround。實在是麻煩。希望可以幫助到遇到同樣問題的人。