What should I use Android AccountManager for?

Solution 1:

This question is a bit old, but I think it is still of good interest.

AccountManager, SyncAdapter and ContentProvidergo together.

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

But you can:

• use the ContentProvider without the others.
• use the AccountManager without the others (but you cannot use an AccountManager without a SyncAdapter before Android 2.2 / Froyo API 8)

With AccountManager / SyncAdapter / ContentProvider:

• AccountManager gives users a central point (Settings > Accounts) to define their credentials
• Android decides when synchronization can be done via SyncAdapter. This can be good to optimize battery (no sync is done when network is down, for instance)
• ContentProvider is a convenient way to share data across applications Note: there are other methods of inter-process communication on Android.
• ContentProvider schedules the database access in a background thread The AsyncQueryHanlder helps to query the ContentProvider in a background thread, preventing Application Not Responsive (ANR) errors while not requiring you to explicitly handle threading.
• ContentProvider ties into ContentResolver's observer: this means it is easy to notify views when content is changed

Bottom line: the framework AccountManager / SyncAdapter / ContentProvider helps if you want to synchronize data from a web resource. Fake/Dumb implementations are required on API 7. Also

• If you only want to store data, you should consider a simpler mechanism for data storage
• If you only need to fetch an only resource, you can use an AsyncTaskLoader
• If you want to load images asynchronously, you can use specialized libraries like Square Picasso
• If you only want to execute some code at a given time, you can consider a Service / Alarm
• only available from API >= 7 (this doesn't matter anymore)

Finally, if you use a SyncAdapter, seriously consider Firebase Cloud Messaging (previously Google Cloud Messaging) aka "push notifications" to have fresher updates and optimized battery usage.

Solution 2:

The AccountManager class is integrated with your phone accounts. So if you follow all the guides and get it working correctly you'll see your accounts under the menu "Settings->accounts and sync". From there you can customize them or even delete them. Furthermore the accountManager has a cache of the authentication tickets for your accounts. This can be used also if you don't plan to synchronize your account (as far as I know).

If you don't want your accounts to appear under that menu you shouldn't use the AccountManager and store the accounts data elsewhere (maybe in the shared preferences) http://developer.android.com/guide/topics/data/data-storage.html

Solution 3:

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

The first piece of the puzzle is called an Account Authenticator, which defines how the user’s account will appear in the “Accounts & Sync” settings. Implementing an Account Authenticator requires 3 pieces: a service that returns a subclass of AbstractAccountAuthenticator from the onBind method, an activity to prompt the user to enter their credentials, and an xml file describing how your account should look when displayed to the user. You’ll also need to add the android.permission.AUTHENTICATE_ACCOUNTS permission to your AndroidManifest.xml.

Solution 4:

The AccountManager is good for the following reasons:

• First is to store multiple account names with different levels of access to the app’s features under a single account type. For example, in a video streaming app, one may have two account names: one with demo access to a limited number of videos and the other with full-month access to all videos. This is not the main reason for using Accounts, however, since you can easily manage that in your app without the need for this fancy-looking Accounts thing… .
• The other advantage of using Accounts is to get rid of the traditional authorization with username and password each time an authorized feature is requested by the user, because the authentication takes place in the background and the user is asked for their password only in certain condition, which I will get to it later.
• Using the Accounts feature in android also removes the need for defining one’s own account type. You have probably come across the apps using Google accounts for authorization, which saves the hassle of making a new account and remembering its credentials for the user.
• Accounts can be added independently through Settings → Accounts
• Cross-platform user authorization can be easily managed using Accounts. For example, the client can access protected material at the same time in their android device and PC without the need for recurrent logins.
• From the security point of view, using the same password in every request to the server allows for possible eavesdropping in non-secure connections. Password encryption is not sufficient here to prevent password theft.
• Finally, an important reason for using the Accounts feature in android is to separate the two parties involved in any business dependent on Accounts, so called authenticator and resource owner, without compromising the client (user)’s credentials. The terms may seem rather vague, but don’t give up until you read the following paragraph … 😉

Let me elaborate on the latter with an example of a video streaming app. Company A is the holder of a video streaming business in contract with Company B to provide its certain members with premium streaming services. Company B employs a username and password method for recognizing its user. For Company A to recognize the premium members of B, one way would be to get the list of them from B and utilize similar username/password matching mechanism. This way, the authenticator and resource owner are the same (Company A). Apart from the users obligation to remember a second password, it is very likely that they set the same password as their Company B’s profile for using the services from A. This is obviously not favorable.

To allay the above shortcomings, OAuth was introduced. As an open standard for authorization, in the example above, OAuth demands that the authorization be done by Company B (authenticator) by issuing some token called Access Token for the eligible users (third party) and then providing Company A (resource owner) with the token. So no token means no eligibility.

I have elaborated more on this and more on AccountManager on my website here.