android - 我应该使用 Android AccountManager 做什么？

Question

我在 Android SDK 中看到过 AccountManager，它用于存储帐户信息。因此，我找不到任何关于它的用途的一般性讨论。有没有人知道关于 AccountManager 背后的意图是什么以及它给你带来了什么有用的讨论？关于这适合什么类型的账户有什么意见吗？这会是您将用户帐户信息用于一般 Web 服务的地方吗？

Answer 1

这个问题有点老了，但我认为它仍然很有趣。

AccountManager，SyncAdapter一起ContentProvider去。

• SyncAdapterAccountAccountManager你不能在.
• 你不能SyncAdapter没有 aContentProvider。

但是你可以：

• 在ContentProvider没有其他人的情况下使用。
• 在AccountManager没有其他人的情况下使用（但您不能AccountManagerSyncAdapter在 Android 2.2 / Froyo API 8 之前使用没有 a的情况）

与AccountManager/ SyncAdapter/ ContentProvider：

• AccountManager为用户提供一个中心点（设置 > 帐户）来定义他们的凭据
• Android 决定何时可以通过SyncAdapter. 这可以很好地优化电池（例如，当网络关闭时不同步）
• ContentProvider是跨应用程序共享数据的便捷方式 注意：Android 上还有其他进程间通信方法。
• ContentProvider在后台线程中安排数据库访问这AsyncQueryHanlder有助于在后台线程中查询ContentProvider，防止应用程序无响应 (ANR) 错误，同时不需要您显式处理线程。
• ContentProvider与ContentResolver观察者联系：这意味着当内容改变时很容易通知视图

底线：如果您想从 Web 资源同步数据，该框架AccountManager//会有所帮助。API 7 需要Fake/ Dumb 实现。此外SyncAdapterContentProvider

• 如果你只想存储数据，你应该考虑更简单的数据存储机制
• 如果您只需要获取唯一资源，则可以使用AsyncTaskLoader
• 如果要异步加载图像，可以使用Square Picasso等专用库
• 如果你只想在给定时间执行一些代码，你可以考虑一个服务/警报
• 仅适用于 API >= 7（这不再重要）

最后，如果您使用SyncAdapter，请认真考虑Firebase Cloud Messaging（以前称为 Google Cloud Messaging），即“推送通知”，以获得更新的更新和优化的电池使用。

Answer 2

AccountManager 类与您的电话帐户集成在一起。因此，如果您遵循所有指南并使其正常工作，您将在“设置->帐户和同步”菜单下看到您的帐户。从那里您可以自定义它们甚至删除它们。此外，accountManager 缓存了您帐户的身份验证票证。如果您不打算同步您的帐户（据我所知），这也可以使用。

如果您不希望您的帐户出现在该菜单下，则不应使用 AccountManager 并将帐户数据存储在其他位置（可能在共享首选项中）http://developer.android.com/guide/topics/data/data -storage.html

Answer 3

来自http://www.c99.org/2010/01/23/writing-an-android-sync-provider-part-1/：

第一个难题称为帐户验证器，它定义了用户帐户在“帐户和同步”设置中的显示方式。实现一个 Account Authenticator 需要 3 个部分：一个从 onBind 方法返回 AbstractAccountAuthenticator 子类的服务，一个提示用户输入其凭据的活动，以及一个描述您的帐户在向用户显示时的外观的 xml 文件。您还需要将 android.permission.AUTHENTICATE_ACCOUNTS 权限添加到您的 AndroidManifest.xml。

Answer 4

这AccountManager很好，原因如下：

• 首先是在单个帐户类型下存储多个具有不同级别的应用程序功能访问权限的帐户名称。例如，在视频流应用程序中，一个可能有两个帐户名称：一个具有对有限数量视频的演示访问权限，另一个具有对所有视频的全月访问权限。Accounts然而，这不是使用Accounts.
• 使用的另一个优点Accounts是摆脱了每次用户请求授权功能时使用用户名和密码进行的传统授权，因为身份验证在后台进行，并且仅在特定条件下要求用户输入密码，这我稍后会谈到它。
• 在 android 中使用该Accounts功能也无需定义自己的帐户类型。您可能遇到过使用 Google 帐户进行授权的应用程序，这样就省去了创建新帐户和为用户记住其凭据的麻烦。
• Accounts可以通过设置→账户独立添加
• 跨平台用户授权可以使用Accounts. 例如，客户端可以在他们的安卓设备和 PC 中同时访问受保护的资料，而无需重复登录。
• 从安全的角度来看，在对服务器的每个请求中使用相同的密码允许在非安全连接中进行窃听。此处的密码加密不足以防止密码被盗。
• 最后，在 android 中使用该功能的一个重要原因是在不损害客户端（用户）的凭据的情况下，Accounts将涉及任何业务依赖的两方分开Accounts，即所谓的身份验证器和资源所有者。这些术语可能看起来相当模糊，但在阅读以下段落之前不要放弃……

让我以视频流应用程序为例详细说明后者。A 公司是一家视频流媒体业务的持有人，与 B 公司签订合同，为其某些成员提供优质流媒体服务。B公司采用用户名和密码方法来识别其用户。为了让 A 公司识别 B 的高级成员，一种方法是从 B 获取他们的列表并使用类似的用户名/密码匹配机制。这样，验证者和资源所有者是相同的（公司 A）。除了用户有义务记住第二个密码外，他们很可能设置了与 B 公司的个人资料相同的密码来使用 A 的服务。这显然是不利的。

为了缓解上述缺点，引入了 OAuth。作为授权的开放标准，在上面的示例中，OAuth 要求 B 公司（身份验证者）通过为符合条件的用户（第三方）颁发一些名为 Access Token 的令牌，然后向 A 公司（资源所有者）提供令牌。所以没有代币就意味着没有资格。

AccountManager我已经在我的网站上详细阐述了这一点和更多内容。