This class provides access to a centralized registry of the user's online accounts. The user enters credentials (username and password) once per account, granting applications access to online resources with "one-click" approval.

Different online services have different ways of handling accounts and authentication, so the account manager uses pluggable authenticator modules for different account types. Authenticators (which may be written by third parties) handle the actual details of validating account credentials and storing account information. For example, Google, Facebook, and Microsoft Exchange each have their own authenticator.

Many servers support some notion of an authentication token, which can be used to authenticate a request to the server without sending the user's actual password. (Auth tokens are normally created with a separate request which does include the user's credentials.) AccountManager can generate auth tokens for applications, so the application doesn't need to handle passwords directly. Auth tokens are normally reusable and cached by AccountManager, but must be refreshed periodically. It's the responsibility of applications to invalidate auth tokens when they stop working so the AccountManager knows it needs to regenerate them.

Applications accessing a server normally go through these steps:

• Get an instance of AccountManager using AccountManager.Get(Android.Content.Context).
• List the available accounts using AccountManager.GetAccountsByType(string) or AccountManager.getAccountsByTypeAndFeatures(java.lang.String, java.lang.String[], android.accounts.AccountManagerCallback<android.accounts.Account[]>, android.os.Handler). Normally applications will only be interested in accounts with one particular type, which identifies the authenticator. Account features are used to identify particular account subtypes and capabilities. Both the account type and features are authenticator-specific strings, and must be known by the application in coordination with its preferred authenticators.
• Select one or more of the available accounts, possibly by asking the user for their preference. If no suitable accounts are available, AccountManager.addAccount(java.lang.String, java.lang.String, java.lang.String[], android.os.Bundle, android.app.Activity, android.accounts.AccountManagerCallback<android.os.Bundle>, android.os.Handler) may be called to prompt the user to create an account of the appropriate type.
• Important: If the application is using a previously remembered account selection, it must make sure the account is still in the list of accounts returned by AccountManager.GetAccountsByType(string). Requesting an auth token for an account no longer on the device results in an undefined failure.
• Request an auth token for the selected account(s) using one of the AccountManager.getAuthToken(android.accounts.Account, java.lang.String, android.os.Bundle, android.app.Activity, android.accounts.AccountManagerCallback<android.os.Bundle>, android.os.Handler) methods or related helpers. Refer to the description of each method for exact usage and error handling details.
• Make the request using the auth token. The form of the auth token, the format of the request, and the protocol used are all specific to the service you are accessing. The application may use whatever network and protocol libraries are useful.
• Important: If the request fails with an authentication error, it could be that a cached auth token is stale and no longer honored by the server. The application must call AccountManager.InvalidateAuthToken(string, System.String) to remove the token from the cache, otherwise requests will continue failing! After invalidating the auth token, immediately go back to the "Request an auth token" step above. If the process fails the second time, then it can be treated as a "genuine" authentication failure and the user notified or other appropriate actions taken.

Some AccountManager methods may need to interact with the user to prompt for credentials, present options, or ask the user to add an account. The caller may choose whether to allow AccountManager to directly launch the necessary user interface and wait for the user, or to return an Intent which the caller may use to launch the interface, or (in some cases) to install a notification which the user can select at any time to launch the interface. To have AccountManager launch the interface directly, the caller must supply the current foreground Android.App.Activity context.

Many AccountManager methods take Android.Accounts.IAccountManagerCallback and Android.OS.Handler as parameters. These methods return immediately and run asynchronously. If a callback is provided then IAccountManagerCallback.run(android.accounts.AccountManagerFuture<V>) will be invoked on the Handler's thread when the request completes, successfully or not. The result is retrieved by calling IAccountManagerFuture.Result on the Android.Accounts.IAccountManagerFuture returned by the method (and also passed to the callback). This method waits for the operation to complete (if necessary) and either returns the result or throws an exception if an error occurred during the operation. To make the request synchronously, call IAccountManagerFuture.Result immediately on receiving the future from the method; no callback need be supplied.

Requests which may block, including IAccountManagerFuture.Result, must never be called on the application's main event thread. These operations throw Java.Lang.IllegalStateException if they are used on the main thread.

[Android Documentation]