Android: альтернатива устаревшему Context.MODE_WORLD_READABLE?
Отсюда Я знаю способ написать файл и быть доступным для другого приложения и другого намерения, но теперь, когда Context.MODE_WORLD_READABLE устарел, как я могу безопасно выполнить это?
FileOutputStream out = myActivity.openFileOutput(fileTo, Context.MODE_WORLD_READABLE);
Ладно больше информации:
Я использую это:
intent = new Intent(Intent.ACTION_VIEW);
intent.setDataAndType(uri, "video/*");
И uri будет тем, который я напишу в SD-карте. И видео появится из приложения, так что проблема в том, что если это сейчас не разрешено, как я могу написать файл и просмотреть его.
Ответы
Ответ 1
И uri будет тем, который я напишу в SD-карте.
Это уже MODE_WORLD_WRITABLE
по умолчанию. Также обратите внимание, что код, который вы указали (openFileOutput()
), не записывается во внешнее хранилище (что вы неправильно вызываете "sdcard" ). openFileOutput()
предназначен для внутреннего хранения.
И видео появится из приложения, так что проблема в том, что если это сейчас не разрешено, как я могу написать файл и просмотреть его.
Если вы действительно пишете файл во внешнем хранилище, просто используйте Uri
, указывающий на этот файл.
Если вы пишете файл во внутреннюю память, создайте ContentProvider
для обслуживания этого файла и используйте Uri
, указывающий на это ContentProvider
. Вот пример приложения с ContentProvider
, который извлекает PDF файл из assets/
при первом запуске, затем обслуживает этот файл через openFile()
, поэтому он может быть просмотрен программой просмотра PDF.
Ответ 2
Сохраните видео в своей внутренней памяти, используя:
openFileOutput("test.mp4", "MODE_PRIVATE");
Затем сделайте следующее:
String path = context.getFilesDir().getAbsolutePath() + "/test.mp4"; // path to the root of internal memory.
File f = new File(path);
f.setReadable(true, false);
Intent playIntent ....
playIntent.setType("video/*");
playIntent.setData(Uri.fromFile(f));
Удачи.
Ответ 3
Кажется, что документы в нем понятны.
Эта константа была устарела в уровне API 17.
Создание общедоступных файлов очень опасно и может вызвать дыры безопасности в приложениях. Это сильно обескураживает; вместо, приложения должны использовать более формальный механизм взаимодействия, например ContentProvider, BroadcastReceiver и Service. Нет гарантирует, что этот режим доступа останется в файле, например, когда он проходит резервное копирование и восстановление. Режим создания файла: разрешить все другие приложения имеют доступ для чтения к созданному файлу.