Android - правильный способ обмена открытыми файлами между приложениями - PullRequest
Новая
       45

Android - правильный способ обмена открытыми файлами между приложениями

0 голосов
/ 28 апреля 2018

выпуск

В мире Android Nougat + Google применяет content:// Uris вместо file:// Uris. Это имеет смысл для личных файлов приложений, но не для общесистемных или общедоступных. У меня есть приложение для управления файлами, которое, естественно, должно делиться файлами на телефоне пользователя с различными приложениями для просмотра. Эта ситуация не соответствует логическому обоснованию протокола content://, который заключается в том, чтобы временно предоставить доступ к файлам моего приложения другому приложению. Файл /sdcard/Downloads/kittens.png не является приватным для моего файлового менеджера, поэтому моему приложению кажется неправильным пометить kittens.png (открытый файл) как частный и, таким образом, предоставить доступ к приложению для просмотра через content://. В конце концов, файловый менеджер - это просто органайзер и удобная связь между файлами пользователя и их предпочтительными приложениями.

Поскольку протокол file:// жестко осуждается в эти дни, я попытался использовать протокол content:// со смешанными результатами. Некоторые приложения отвечают на content:// Uri и обрабатывают файл, а другие - нет. Однако каждое приложение для просмотра, которое я тестировал, правильно реагирует на протокол file:// и затем может обработать файл. Хорошим примером этого являются VLC и jetAudio, два моих любимых медиаплеера. VLC будет воспроизводить звук, переданный через content:// и file://, в то время как jetAudio воспроизводит только звук, переданный через file://.

Чтобы подвести итог проблемы

Мне нужно иметь возможность обмениваться практически всеми файлами на телефоне пользователя с независимо от того, какие неизвестные приложения для просмотра установлены, так же, как файловый менеджер должен уметь это делать. Некоторые приложения для просмотра (вероятно, более старые, не предназначенные для 24+) некорректно отображают файлы, совместно используемые через content:// - проблема, которая сделала бы мой файловый менеджер непригодным для использования. Другие приложения для управления файлами избегают этой проблемы, ориентируясь на более низкий SDK или снимая ограничение на file://, но я не уверен, является ли это хорошим вариантом, ориентированным на будущее. Какой правильный (надежный и надежный) способ решить эту проблему?

Мои текущие идеи

Обмен по содержимому
Вот как я пытался поделиться с content://, что не работает для некоторых приложений для просмотра, таких как jetAudio.

C # (я использую Xamarin) : 

Intent viewFile = new Intent(Intent.ActionView);
fileIntent.SetDataAndType(FileProvider.GetUriForFile(Application.Context, Application.Context.PackageName + ".provider", new Java.IO.File(fileFullpath)), fileMIME);
fileIntent.SetFlags(ActivityFlags.NewTask | ActivityFlags.GrantReadUriPermission | ActivityFlags.GrantWriteUriPermission);
...
StartActivity(viewFile);

В манифесте : 

<provider
    android:name="android.support.v4.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>

XML / provider_paths 

<paths xmlns:android="http://schemas.android.com/apk/res/android">
    <external-path name="external_files" path="."/>
</paths>


Обмен файлами
Я хочу, чтобы мой целевой SDK был равен 25. Поэтому я мог бы использовать StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder().build()); или что-то похожее для общего доступа к файлам file://. Это работает практически со всеми приложениями для просмотра, но это явно обходной путь, а не решение. Я хотел бы избежать этого, если это возможно, поскольку я не уверен, насколько дольше будет разрешен этот подход в будущих версиях Android.


Superuser Aid
Если есть утилита bash или собственный код, который может лучше решить эту проблему, я абсолютно открыт.

...