Xamarin的。安卓

注意:路径xml/provider_paths.xml (.axml)无法解析，即使在将xml文件夹放在资源下(也许它可以放在像Values这样的现有位置，但没有尝试)，所以我采用了这个方法，目前它是有效的。测试表明，每次应用程序运行时只需要调用它一次(这是有意义的，因为它改变了主机VM的操作状态)。

注意:xml需要大写，所以Resources/ xml /provider_paths.xml

Java.Lang.ClassLoader cl = _this.Context.ClassLoader;
Java.Lang.Class strictMode = cl.LoadClass("android.os.StrictMode");                
System.IntPtr ptrStrictMode = JNIEnv.FindClass("android/os/StrictMode");
var method = JNIEnv.GetStaticMethodID(ptrStrictMode, "disableDeathOnFileUriExposure", "()V");                
JNIEnv.CallStaticVoidMethod(strictMode.Handle, method);

如果你的targetSdkVersion >= 24，那么我们必须使用FileProvider类来访问特定的文件或文件夹，以使其他应用程序可以访问它们。我们创建自己的类继承FileProvider，以确保我们的FileProvider不会与此处所述导入依赖项中声明的FileProviders冲突。

用content:// URI替换file:// URI的步骤:

在AndroidManifest.xml的<application>标签下添加FileProvider <provider>标签。为android:authorities属性指定唯一的权限以避免冲突，导入的依赖项可能指定${applicationId}。提供者和其他常用的授权。

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    ...
    <application
        ...
        <provider
            android:name="androidx.core.content.FileProvider"
            android:authorities="${applicationId}.provider"
            android:exported="false"
            android:grantUriPermissions="true">
            <meta-data
                android:name="android.support.FILE_PROVIDER_PATHS"
                android:resource="@xml/provider_paths" />
        </provider>
    </application>
</manifest>

然后在res/xml文件夹中创建provider_paths.xml文件。如果一个文件夹还不存在，可能需要创建它。该文件的内容如下所示。它描述了我们希望以external_files的名称共享根文件夹(path=".")的外部存储的访问权限。

<?xml version="1.0" encoding="utf-8"?>
<paths>
    <external-path name="external_files" path="."/>
</paths>

最后一步是更改下面的代码行 Uri photoURI = Uri. fromfile (createImageFile()); 来 Uri photoURI = FileProvider。getUriForFile(context, context. getapplicationcontext (). getpackagename() +”。提供者”,createImageFile ()); 编辑:如果你想让系统打开你的文件，你可能需要添加以下代码行: intent.addFlags (Intent.FLAG_GRANT_READ_URI_PERMISSION);

请参考这里解释的完整代码和解决方案。

我的答案是“乌里”。解析文件路径为字符串，而不是使用Uri.fromFile()。

String storage = Environment.getExternalStorageDirectory().toString() + "/test.txt";
File file = new File(storage);
Uri uri;
if (Build.VERSION.SDK_INT < 24) {
    uri = Uri.fromFile(file);
} else {
    uri = Uri.parse(file.getPath()); // My work-around for SDKs up to 29.
}
Intent viewFile = new Intent(Intent.ACTION_VIEW);
viewFile.setDataAndType(uri, "text/plain");
startActivity(viewFile);

似乎fromFile()使用了一个文件指针，当内存地址暴露给所有应用程序时，我认为这可能是不安全的。但是文件路径字符串不会伤害任何人，所以它不会抛出FileUriExposedException异常。

测试API等级9至29!在另一个应用程序中成功打开文本文件进行编辑。不需要FileProvider，也不需要Android支持库。这将不能在API级别30(Android 11)或更新版本上正常工作，因为getExternalStorageDirectory()已弃用。

我刚刚做了以下如果android版本> 24

File fl = new File(url);
    Uri uri = Uri.fromFile(fl);
    Intent intent = new Intent(Intent.ACTION_VIEW);
    if (android.os.Build.VERSION.SDK_INT>=24)
    {
        Context context = getApplicationContext();
        uri = FileProvider.getUriForFile(
                context,
                context.getApplicationContext()
                        .getPackageName() + ".provider", fl);
        intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION);
    }
    intent.setDataAndType(uri, mimetype);
    intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
    startActivity(intent);

点击这个链接，然后https://medium.com/@ali.muzaffar/what-is-android-os- fileuriexposedexceptionand what-you-can-do-about-it 70b9eb17c6d0#.54odzsnk4

我花了几乎一天的时间试图弄清楚为什么我得到了这个异常。经过大量的斗争，这个配置工作得很完美(Kotlin):

AndroidManifest.xml

<provider
  android:name="androidx.core.content.FileProvider"
  android:authorities="com.lomza.moviesroom.fileprovider"
  android:exported="false"
  android:grantUriPermissions="true">
  <meta-data
    android:name="android.support.FILE_PROVIDER_PATHS"
    android:resource="@xml/file_paths" />
</provider>

file_paths.xml

<?xml version="1.0" encoding="utf-8"?>
<paths>
  <files-path name="movies_csv_files" path="."/>
</paths>

目的本身

fun goToFileIntent(context: Context, file: File): Intent {
    val intent = Intent(Intent.ACTION_VIEW)
    val contentUri = FileProvider.getUriForFile(context, "${context.packageName}.fileprovider", file)
    val mimeType = context.contentResolver.getType(contentUri)
    intent.setDataAndType(contentUri, mimeType)
    intent.flags = Intent.FLAG_GRANT_READ_URI_PERMISSION or Intent.FLAG_GRANT_WRITE_URI_PERMISSION

    return intent
}

我在这里解释整个过程。

如果你的应用程序目标API 24+，你仍然想要/需要使用file:// intents，你可以使用hack方法禁用运行时检查:

if(Build.VERSION.SDK_INT>=24){
   try{
      Method m = StrictMode.class.getMethod("disableDeathOnFileUriExposure");
      m.invoke(null);
   }catch(Exception e){
      e.printStackTrace();
   }
}

StrictMode方法。disableDeathOnFileUriExposure被隐藏并记录为:

/**
* Used by lame internal apps that haven't done the hard work to get
* themselves off file:// Uris yet.
*/

问题是我的应用程序不是蹩脚的，而是不想被使用内容://意图所削弱，这是许多应用程序无法理解的。例如，以content:// scheme打开mp3文件，提供的应用程序比打开相同的over file:// scheme时少得多。我不想为谷歌的设计缺陷买单，限制我的应用程序的功能。

谷歌希望开发者使用内容方案，但系统并没有为此做好准备，多年来应用程序都是使用文件而不是“内容”，文件可以编辑和保存，而通过内容方案提供的文件则不能(可以吗?)