如何在同一设备上运行的 Android 应用程序之间传输文件？

Question

我正在编写一个与 RESTful 服务交互的 Android 应用程序。这个 Web 服务本质上是一个文件系统的前端，并提供元数据以及对文件的 CRUD 访问。我的应用程序检索元数据，并通过ContentProvider 将其公开给第 3 方应用程序。

我需要添加与我的应用程序在同一设备上运行的第 3 方应用程序的功能，通过向/从我的应用程序发出请求（而不是直接使用服务器）来 CRUD 实际文件。这意味着他们需要通过我的应用程序发送或接收文件的内容（通常是 XML 或图像）。

我想到了两种实现方法：

选项 1 - 使用 ContentProvider.openFile

这似乎是让第 3 方应用程序能够从我的ContentProvider 读取文件的明显选择。我认为当这些应用程序需要通过我的“ContentProvider”创建或更新文件时，它开始变得棘手。当他们完成后，我需要一个回调，以便知道何时将新的/更改的文件发送回服务器。不过，我相信我可以为此使用FileObserver。

选项 2 - 通过服务使用 Messenger

使用这种方法，我可以通过Messenger 在我的应用程序和客户端应用程序之间发送文件。这些文件必须通过Bundle 传递，所以我不确定传输它们的最佳格式是什么（File、FileDescriptor、字节数组，还有什么？？）。如果文件变大，我无法很好地处理这是否会导致问题。

选项 3 - 混合方法

1. 将外部存储上的文件夹用作投递箱
2. 通过Messenger/Service 传达 CRUD 请求和下拉框内容
3. 使用ContentProvider 存储请求的状态
4. 第三方应用通过ContentObserver 接收状态更新

总结

我认为使用ContentProvider 将是理想的解决方案，但API 似乎并不完全支持我的用例。我担心尝试走这条路可能会导致笨拙的实施。如果我使用Messenger 和Service 方法，我不确定通过Bundle 传输文件的最可靠方法。

混合方法看起来相当健壮，但实施起来最复杂。文件实际上并没有被传递，所以性能应该很好。但是，我担心这会过度构建解决方案。

在同一 Android 设备上运行的应用程序之间传输文件的最佳方法是什么？当然，我愿意接受我的问题中没有列出的其他选项。

Answer 1

内容提供商绝对是要走的路。如果您认为 google 几乎所有事情都使用这种方法，那么很明显这是预期的设计方法。

我不是在赞美他们的美德，但在盲人之地，独眼内容提供者为王。

更新

CommonsWare 书中有一个如何执行此操作的示例，请参阅提供的链接。

Source of Content Provider/Files

为内容提供者使用同步框架。只需维护一个请求列表，然后安排同步以下载这些文件。您也可以在网络 Tickles 等上执行此操作。您可以使用广播意图或 contentobserver 通知客户端文件已下载。

本质上，这可能类似于您的第三个选项，但重要的是它使用 Android 提供的工具，而不是滚动您自己的工具。

广告结尾

最好的起点是 android-sdk\samples\android-8\SampleSyncAdapter 中的 android SDK 示例，但请注意，有大量与联系人相关的东西掩盖了这些有趣的部分。我花了一段时间才发现我可以删除几乎所有的，除了同步适配器

Answer 2

http://developer.android.com/reference/android/os/ParcelFileDescriptor.html 可以在进程之间发送。我相信有一个微妙的地方，这些被明确列入黑名单，不允许被放入意图中。它们可以通过 AIDL 发送。 此外，请勿为此使用 sdcard。这只是自找麻烦。一张 sdcard 是世界可读的，所以任何人都可以看到它。此外，您并不总是有权写入 sdcard（它已被移除或放入 UMS）。

Answer 3

使用 SD 卡绝对是recommended 在 Android 上共享文件的方式。

但是，我会使用经过修改的混合解决方案，它在客户端使用 startActivityForResult() 和 onActivityResult()（文档here）来传达 CRUD 请求（并将 Uri 获取到SD 卡（如果需要））如果您不介意创建一个虚拟活动作为您的服务的前端。客户在完成文件后，可以再次致电startActivityForResult() 以提醒您的应用进行更改。

当然，这可以通过startService()/bindService() 来完成，但是它并没有为客户提供获取状态结果的简单方法，尤其是在您需要 IPC 时。

虽然内容提供者/解析者感觉是处理事情的正确方式，但我确实认为它更多是针对特定于提供/消费内容的单向请求。