SharedUserId 访问 SharedPreferences

Posted 2023-02-23

【中文标题】SharedUserId 访问 SharedPreferences

【英文标题】：SharedUserId access SharedPreferences

【发布时间】：2012-03-22 02:17:37

【问题描述】：

我有两个应用程序，包名如下：

com.blah.a com.blah.b

他们得到了 sharedUserId “com.blah.shared”。在我设备中的 /data/data 处，他们都有一个包含数据的文件夹，其中包含 shared_prefs 文件夹和名为的默认 SharedPreferences 文件：

com.blah.a_preferences.xml com.blah.b_preferences.xml

我知道具有相同 sharedUserId 的两个应用可以访问彼此的文件。 如何从应用 b 读取应用 a 的 SharedPreferences？

我找到了一个解决方案，但它既不能很好地工作（如果应用程序 a 更新了偏好，应用程序 b 仍会读取旧值）也不是好的代码（可能会引发异常）。

try 
    Context c = context.createPackageContext("com.blah.a", 
        Context.CONTEXT_IGNORE_SECURITY))

    aPrefs = PreferenceManager.getDefaultSharedPreferences(c);
 catch (NameNotFoundException e) 

感谢您的帮助！

【参考方案1】：

通常，您不需要这样做，sharedUserId 对于生产应用程序来说是个坏主意。无论如何，这是执行此操作的代码，但您无需指定IGNORE_SECURITY。如果您的应用程序具有相同的 UID，它们应该能够读取彼此的（私有）文件。至于异常，只有包不存在才会抛出异常。您可以检查它是否存在，并且仅在代码存在时才执行代码（即，安装了另一个应用程序）。可能有一些缓存，因此您应该在每次需要时加载首选项。

【讨论】：

好的，谢谢您的回答。我会尝试用这种方法让它工作。为什么 sharedUserId 对于生产应用程序来说不是一个好主意？

我测试了更多。即使我在阅读之前直接加载首选项，它也不会更新。因为该方法不可靠，所以我会将值保存到我的 ContentProvider 中的单行表中。现在仍然想知道为什么 sharedUserId 是个坏主意...

ContentProvider 听起来不错，您可以对要公开的数据进行细粒度控制。至于 sharedUserId，显然它最初仅用于系统应用程序。引用：'它会对你的应用程序产生很多你可能不喜欢的微妙影响——从具有相同共享用户 ID 的所有应用程序被批处理在一起以考虑电池使用，到当你的进程之一被终止时使用共享用户 ID 的应用程序已更新。'

您的应用是否已经发布？如果是这样，您可能需要小心并进行彻底的测试。如果添加或移除sharedUserId，应用的UID会发生变化，无法读取自己的数据。可能还有其他问题。

它们仍在开发中，所以没问题。不过谢谢你的提醒:)