请考虑以下情形。一家公司发布了许多应用。他们希望在所有这些应用程序之间共享一些数据。这些应用程序中的任何一个都可以创建或读取这些数据，就像通用数据库一样所以公司决定创建一个实现此目的的android库。我搜索了几天，我的分析如下。
SharedPreferences-不推荐使用，不推荐使用。它也没有达到目的。所有其他应用程序需要知道创建数据的应用程序的包名称以创建PackageContext。在这里这是不切实际的，因为任何应用程序都可以创建/更新/读取数据，并且不可能说谁是谁。
ContentProviders - 这对我不起作用。 ContentProviders必须存在于每个应用程序中。设备中不能有2个具有相同名称的内容提供商。除此之外，ContentProviders基本上是指一个应用程序使用Content_Uri创建数据和其他应用程序订阅它。
网络连接 - 我们不希望在任何服务器中存储数据。
外部存储 - 这是剩下的唯一选择。我应该这样做吗？
有趣的是，数据也必须受到保护，这在任何存储选项中都是不受支持的。
注意：对于iOS，我们使用钥匙串来实现相同的功能
答案 0 :(得分：2)
答案 1 :(得分：1)
了解Android上的问题
具有讽刺意味的是，由于iOS上强烈的沙盒，有一种简单的方法可以实现这一点（App Groups）提供了需要共享数据的应用程序都是由同一个开发人员完成的。可能因为Android在安全方面更灵活，这实际上最终成为一个更难的问题。迄今为止，Android团队认为不适合提供一种方便安全的方式来专门共享此类数据，因为这是一种安全性较低的解决方法。
也就是说，有很多方法可以在不涉及云的情况下在应用程序之间共享数据。
<强> SharedPreferences
原始问题指出不推荐使用SharedPreferences。据我所知，这不是真的，但是不推荐使用MODE_WORLD_READABLE和MODE_WORLD_WRITABLE上下文，这使得这种方法将来不会起作用。尽管如此，该模式已被弃用了一段时间 - 自Android 4.2（2012）以来。在当前的Android文档中没有任何威胁表明他们实际上正在逐步淘汰它（有时候，弃用仅仅意味着＆＃34;这不是一个好主意＆＃34;不是＆＃34;这是将被删除＆＃34;）。我怀疑在设置级别缺少更安全的操作系统级直接替代应用程序数据共享可能是在过去5年中将其保留在弃用状态的原因。
文件访问
我所知道的在Android上的应用程序之间实现数据共享的最简单和最常见的方法是简单地请求设备上的文件访问，并在外部存储上为此数据创建共享位置。 （不要被＆＃34;外部存储＆＃34;指定混淆 - 这就是Android如何引用共享数据。它不一定是指SD卡。）你给文件一个唯一的名称，您将它存储在您的应用程序知道在哪里寻找它的地方。获得该路径的最佳方式是： Environment.getExternalStoragePublicDirectory（Environment.DIRECTORY_DOCUMENTS）
这个问题的明显问题是安全性。虽然不被操作系统弃用，但它引入了与Android文档列出的相同问题，因为它弃用了MODE_WORLD_ * - 它本身就是不安全的，并在您的应用程序中开辟了潜在的漏洞利用。
如果您的应用程序没有处理任何敏感数据，那么这对您（可能对您的用户而言）并不重要。如果您计划从这些文件中读取数据，则应确保在解析之前为该数据提供最大程度的验证。检查文件大小，验证格式等。
创建自己的服务
您始终可以创建服务或IntentService。 （两者之间存在细微差别，但IntentService是Service的一个子类，在Service线程中运行而Service中断主线程.InntService也实现了Intent支持，它提供了Android上最直接的应用程序通信。）
此服务有自己的私有存储，对其具有完全的读/写访问权限，但没有别的。然后，该服务提供一个接口，用于从其他应用程序接收Intent，并将结果（作为Intents）返回给这些应用程序。这是一种非常友好的方式来实现应用程序间数据，同时最大化数据隐私和数据的安全性。如果外围应用程序主要需要从中央应用程序请求非常基本的信息，这是您的入门级选项。
实施BroadcastReceiver
同样的行是BroadcastReceiver类。根据您打算在应用程序之间共享的数据类型，以及这些应用程序对您的特定方法的熟悉程度，这是另一种可能性。同样，您将在一个应用程序的私有存储下管理共享数据。通信由Intents完成，因此它与IntentService类似 - 除了应用程序可以通过发布系统范围的事件（即，他们不需要与您的应用程序或服务明确通信）与BroadcastReceiver通信 - 他们正在向世界喊出一条信息，并希望得到答案。）
创建ContentProvider
原帖似乎误解了ContentProvider是什么以及它是如何工作的。您必须将此类项目视为云解决方案 - 即使它是您设备的本地项目。每个应用程序都不需要ContentProvider - 它们都需要与ContentProvider通信，ContentProvider维护，更新和返回数据。
这可能是最多＆＃34; Android-y＆＃34;该特定用例的解决方案，提供最大的可扩展性。您实现了一个处理数据存储并响应其他应用程序的独立进程。然而，这是一个更加进化的解决方案 - 因此可能更具挑战性。如果您需要真正的数据库服务，而不是相当简单的请求/响应类型服务，ContentProvider似乎是最佳选择。
答案 2 :(得分：0)
是。对于所有应用程序，可能在外部存储中使用相同的路径是最好的方法。可以使用代码的公共部分来了解数据库是否存在，从而打开或创建新数据库。为了安全起见，我建议在连接到数据库时始终使用“用户”和“密码”，但如果您认为这还不够，我建议您看一下：http://www.hwaci.com/sw/sqlite/see.html