1

FileProviderを実装しています。

プレーンContentProviderよりも優れている点は、セキュリティが優れていることです。

  • の代わりcontent:// Uriにファイル用のfile:/// Uri
  • コンテンツ URI により、一時的なアクセス許可を使用して読み取りおよび書き込みアクセスを許可できます

ポイントの 1 つは、クライアント アプリがデータにアクセスするための実際のファイル パスを認識してはならないということです。

ほとんどのクライアント アプリでは、実際のデータの読み取りを開始する前に、human-friendly name of fileおよび/またはを知ることが重要です。size of the fileこれらのアプリは、 query() メソッドFileProviderを介して名前/サイズを尋ねます。このメソッドは、paramでOpenableColumns ( , ) の 2 つのオプションのみを想定しています。projection_display_name_size

そして今問題。一部のクライアント アプリは_data、データへの実際のフル パスを取得することを期待して、プロジェクションに移行しています。しかし、実際のファイル パスを返すと、FileProviderセキュリティ上の理由から使用するという考え全体が壊れてしまいます。

私の質問は、「何か足りないものはありますか?」です。一部のクライアント アプリの記述が不十分なため、ファイル パスを取得できないためにクラッシュするのは彼らの問題なのでしょうか?

4

0 に答える 0