Account Manager Overview

This class provides access to a centralized registry of users' online accounts. The credentials, including the user name and password, are entered once for each account, and the apps are authorized to access online resources through one-click authentication. Different services have different ways of handling Account authentication, and Account Manager uses a plug-in authenticator module for different Account types. An authenticator (which is written by a third-party organization) handles the actual content of verifying account authentication information. And save the account information. Google, Facebook, and Microsoft, for example, each have their own authenticators.Copy the code

Many services support some concepts about a single authorization token (auth token), which is often used to authenticate authorization requests to services that do not contain a real password. Auth Tokens are often created on separate requests that contain user authentication information (username and password). AccountManager can generate an authentication token (Auth token) for an application, so that the application no longer needs to deal with passwords directly. Autho Tokens are often reusable and cached by the AccountManager, but must be refreshed periodically. When stopped, the application invalidates the Auth tokens so that the Auth tokens know to regenerate them. Applications typically access services through the following steps:

  • Get an instance of AuccountManager using the get(Context) method.
  • List of the available account, use the getAccountsByType (String) or getAccountsByTypeAndFeatures (String, String [], AccountManagerCallback, Handler). General applications are interested in a specific type of account, which is the identity of the authenticator. Account features are used to identify the subtypes and capabilities of a particular account. These two are the authenticator specification strings and must be known to the application about the preferred authenticator to coordinate them.
  • Select one or more accounts available and ask users about their preferences if possible. If no matching account is available, addAccount(String, String, String[], Bundle, Activity, AccountManagerCallback, Handler) will be called, Prompts the user to create an account of the appropriate type
  • Important: If the application is using pre-remembered account options, it must ensure that the account still exists in a list of accounts that are returned by getAccountsByType(String). Requesting an authentication mark for an account no longer results in “an undefined failure” in device results.
  • Build 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. Applications can use any network and protocol library.
  • Important: If the request fails with an “authorization error”, it is possible that the cached Auth token has expired and is no longer trusted by the server. The application must call invalidateAuthToken(String, String) to remove the Auth token cache, and the request will continue to fail! After invalidating the Auth token, immediately return to the request an Auth Token step above. If the second exit fails, it is treated as a bona fide authentication failure and the user is notified or other appropriate action is taken.

Some AccountManager methods may need to interact with the user, prompting for authentication information, presenting options, or asking the user to add an account. The caller can choose whether to allow the AccountManager to directly launch the necessary user interface and wait for the user, or to return an intent that the caller can launch the interface. Or in some cases, install a notification, which the user can choose to boot the interface. For the AccountManager to launch the interface directly, the caller must provide the current front-end Activity Context.

 

Many AccountManager methods take AccountManagerCallback and Handler as parameters. These methods return immediately and start asynchronously. If a callback is provided, then run(AccountManagerFuture) will be invoked on the Handler’s thread. The result is retrieved via the getResult() method of the “return value” AccountManagerFuture (which can also be retrieved via the callback method). This method waits for the operation to complete (if needed) and either returns the result or throws an exception if an error occurs during the operation. To make the request execute synchronously, the method simply calls getResult() as soon as it receives the future, without needing to provide a callback.

 

Requests can block, including getResult(), and must never be called on the main thread. If used on the main thread, those operations will throw an IllegalStateException.

  

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Common methods of AccountManager

 

Set password for the specified account mAccountManager. SetPassword (account, mPassword);

 

Adding an Account to the Account Center Final Account Account = new Account(mUsername, Constants.ACCOUNT_TYPE); mAccountManager.addAccountExplicitly(account, mPassword, null);

 

Get authToken final String authToken = mAccountManager. BlockingGetAuthToken (account, the AUTHTOKEN_TYPE, NOTIFY_AUTH_FAILURE);

 

Access to user data String markerString = mAccountManager. GetUserData (account, SYNC_MARKER_KEY);

 

Summary of AbstractAccountAuthenticator

This is an abstract base class for creating account managers. In order to be an authenticator, a class must inherit the class, provide an implementation of an abstract method, and write a service that, when called by ACTION_AUTHENTICATOR_INTENT as an intent for an action, In the service’s onBind (Android.Content.Intent) method implementation, the result of getIBinder() is returned directly. In the Androidmanifest.xml file, the service must specify the intent filter and metadata tag below.


<intent-filter>

<action android:name=”android.accounts.AccountAuthenticator” />

</intent-filter>

<meta-data android:name=”android.accounts.AccountAuthenticator”

android:resource=”@xml/authenticator” />

 

Translator note: ACTION_AUTHENTICATOR_INTENT is actually a constant, is equal to the string android. Accounts. AccountAuthenticator, is actually and the intent filter on the filter action are the same.

In the XML description above, the Android :resource attribute must point to a resource file, like the following:

< account – the authenticator XMLNS: android = “schemas.android.com/apk/res/and…” android:accountType=”typeOfAuthenticator” android:icon=”@drawable/icon” android:smallIcon=”@drawable/miniIcon” android:label=”@string/label” android:accountPreferences=”@xml/account_preferences” />

Replace the values pointed to by the icon and label attributes with your own resources. The Android :accountType attribute must be a string that uniquely identifies your authenticator and is identical to the string specified by the user using the AccountManager call, as well as to your Account Type. A user of Android: Icon is in the “Account and Sync” Settings page, and a user of Android :smallIcon is in the TAB panel of the Contacts app.

Android: accountPreferences attribute points to a preferences screen set of XML configuration files (PreferenceScreen XML), it contains a list of PreferenceScreen, can be nested hierarchy. It can be called to manage the authenticator. The following is an example:

The < PreferenceScreen XMLNS: android = “schemas.android.com/apk/res/and…” >

 

A standard implementation pattern for some abstract methods looks like this:

  • * If the parameters provided to the authenticator are sufficient and complete satisfaction is reached, it will do so and a Bundle containing the result is returned.
  • * If the authenticator needs to collect information from the user to be satisfied, an intent is created to open the “Activity that prompts the user for information” and complete the request. The intent must return a Bundle containing the specified key named KEY_INTENT. When finished, the activity needs to return the result of the final modifier. This intent should use KEY_ACCOUNT_MANAGER_RESPONSE to contain AccountAuthenticatorResponse key instructions. The activity must end by calling onResult(Bundle) or onError(int, String).
  • If the authenticator cannot process the request synchronously and returns a result. Then when the request completes, it can choose to return NULL and use AccountManagerResponse to send the result.

Subsequent descriptions of each abstract authenticator method will not describe possible asynchronous native request processing, but instead will describe input parameters and expected results.

When writing an activity to satisfy those requests, one way to do that is to pass an AccountManagerResponse and return the result via the response when the activity is shut down (or in any other case the activity’s author thinks is the right time to respond). AccountAuthenticatorActivity to handle these, so when writing activity to deal with these requests, we can go to inherit the extend it.

 

 

 

 

AccountAuthenticatorActivity overview

This is an abstract to implement the activity base class, are often used to help abstract the certifier (AbstractAccountAuthenticator) concrete implementation (implement). If the abstract certifier AbstractAccountAuthenticator need to use an activity to capture the request, this is it allows an activity to AccountAuthenticatorActivity inheritance. Abstract certifier AbstractAccountAuthenticator transfer response to the intent of the method is as follows:

  intent.putExtra(KEY_ACCOUNT_AUTHENTICATOR_RESPONSE, response);
Copy the code

This activity sets (specify) results, the results (result) is passed to the response through setAccountAuthenticatorResult (android. OS. Bundle) method. When the activity ends, the result is sent as the result of the request. If this is never set or set to null, the error ERROR_CODE_CANCELED is called on the response.

 

The account authenticator calls the activity with an intent, passing the following parameters:

intent.putExtra(KEY_ACCOUNT_AUTHENTICATOR_RESPONSE, response); Pass a account authenticator response to this activity, as a parameter, and this activity will deal with the specific implementation, after processing, using setAccountAuthenticatorResult (android. OS. Bundle) to set up the processing results.Copy the code

AccountManagerFuture overview

An AccountManagerFuture represents the result of an asynchronous AccountManager call. It provides methods for determining whether a calculation is complete, waiting for the calculation to complete, and getting the result. When the operation is complete, the block (if needed) knows that the result is ready, and the result can only be obtained using the GET method. A cancel operation is handled by the Cancel method. Additional methods are provided to determine whether the task was completed properly or cancelled. Once an operation has been completed, it cannot be cancelled. If you use the class in a way that doesn’t provide a useful result for cancelable intent, you can declare something like Future
and returns NULL as the result of the related task.