我应该如何使用Android AccountManager？

Question

我在Android SDK中看到了AccountManager，它用于存储帐户信息。因此，我找不到任何关于其目的的一般性讨论。有谁知道有关AccountManager背后的意图以及它为您购买的内容的任何有用的讨论？对于哪种类型的账户适合的任何意见？这是您将用户的帐户信息用于一般Web服务的位置吗？

Answer 1

这个问题有点陈旧，但我认为它仍然有很好的兴趣。

AccountManager，SyncAdapter和ContentProvider一起使用。

• You cannot have a SyncAdapter without an Account in the AccountManager。
• You cannot have a SyncAdapterwithout a ContentProvider。

但你可以：

• 使用ContentProvider而不使用其他人。
• 在没有其他人的情况下使用AccountManager（但在Android 2.2 / Froyo API 8之前使用cannot use an AccountManager without a SyncAdapter）

使用AccountManager / SyncAdapter / ContentProvider：

• AccountManager为用户提供了一个中心点（设置＆gt;帐户）来定义他们的凭据
• Android决定何时可以通过SyncAdapter进行同步。这可以很好地优化电池（例如，当网络关闭时不进行同步）
• ContentProvider是跨应用程序共享数据的便捷方式 注意：有other methods of inter-process communication on Android。
• ContentProvider在后​​台线程中调度数据库访问 AsyncQueryHanlder有助于查询后台线程中的ContentProvider，防止应用程序无响应（ANR）错误，而不要求您明确处理线程。
• ContentProvider与ContentResolver的观察者联系：这意味着在内容发生变化时很容易通知视图

底线：如果您想要同步来自网络资源的数据，框架AccountManager / SyncAdapter / ContentProvider会有所帮助。 API 7还需要假/ Dumb implementations。

• 如果您只想存储数据，则应考虑simpler mechanism for data storage
• 如果您只需要获取唯一的资源，则可以使用AsyncTaskLoader
• 如果要异步加载图像，可以使用Square Picasso
等专用库
• 如果您只想在给定时间执行某些代码，可以考虑使用服务/警报
• 仅适用于API＆gt; = 7（这不再重要）

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

Answer 2

AccountManager类已与您的手机帐户集成。因此，如果您按照所有指南操作并使其正常工作，您会在“设置 - ＆gt;帐户和同步”菜单下看到您的帐户。从那里你可以自定义它们甚至删除它们。此外，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/：

  

拼图的第一部分是   称为帐户身份验证器，其中   定义用户帐户的方式   出现在“帐户＆amp;同步”   设置。实施帐户   Authenticator需要3件：a   返回子类的服务   AbstractAccountAuthenticator来自   onBind方法，一个提示活动   用户输入他们的凭证，   和一个描述你的如何的xml文件   帐户显示时应该看起来   用户。你还需要添加   android.permission.AUTHENTICATE_ACCOUNTS   允许你的   的AndroidManifest.xml。

Answer 4

AccountManager因以下原因而有用：

• 首先，在单个帐户类型下存储对应用功能具有不同访问级别的多个帐户名称。例如，在视频流应用中，可能有两个帐户名：一个帐户名称可以访问有限数量的视频，另一个帐户名称可以全月访问所有视频。这不是使用Accounts的主要原因，但是，因为您可以在应用中轻松管理它，而无需使用这种看似奇特的Accounts ...
• 使用Accounts的另一个好处是，每次用户请求授权功能时，都会使用用户名和密码取消传统授权，因为身份验证是在后台进行的，并且要求用户他们的密码仅在某些条件下，我稍后会知道。
• 在android中使用Accounts功能也无需定义自己的帐户类型。您可能会遇到使用Google帐户进行授权的应用，这样可以省去制作新帐户和记住用户凭据的麻烦。
• Accounts可以通过设置→帐户
单独添加
• 可以使用Accounts轻松管理跨平台用户授权。例如，客户端可以在他们的Android设备和PC中同时访问受保护的材料，而无需重复登录。
• 从安全角度来看，在对服务器的每个请求中使用相同的密码允许在非安全连接中进行可能的窃听。此处密码加密不足以防止密码被盗。
• 最后，在android中使用Accounts功能的一个重要原因是将依赖于Accounts的所有业务中涉及的双方分开，即所谓的身份验证者和资源所有者，而不会损害客户端（用户） ）的证书。这些条款似乎相当含糊，但在阅读以下段落之前不要放弃......

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

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

我已经在我的网站here. AccountManager {{1}}详细阐述了这一点及更多内容。