Creating a custom account type create a custom account type

So far we 've talked about accessing Google APIs, which use accounts and users defined by Google. if you have your own online service, though, it won't have Google accounts or users, so what do you do? It turns out to be relatively straightforward to install
New account types on a user's device. This lesson explains how to create a custom account type that works the same way as the built-in accounts do.

Http://blog.csdn.net/sergeycao

Implement your custom account code

The first thing you'll need is a way to get credentials from the user. this may be as simple as a dialog box that asks for a name and a password. or it may be a more exotic procedure like a one-time password or a biometric scan. either way, it's your responsibility
To implement the code that:

1. Collects credentials from the user
2. Authenticates the credentials with the server
3. Stores the credentials on the device

Typically all three of these requirements can be handled by one activity. We'll call this the authenticator activity.

Because they need to interact withAccountManagerSystem, Authenticator activities have certain requirements that normal activities don't. To make it easy to get things right, the android framework supplies a base class,AccountAuthenticatorActivity,
Which you can extend to create your own authm authenticator.

How you address the first two requirements of an authenticator activity, credential collection and authentication, is completely up to you. (if there were only one way to do it, there 'd be no need for "Custom" account types, after all .) the third requirement
Has a canonical, and rather simple, implementation:

final Account account = new Account(mUsername, your_account_type);mAccountManager.addAccountExplicitly(account, mPassword, null);

Be smart about security!

It's important to understand thatAccountManagerIs not an encryption service or a keychain. It stores account credentials just as you pass them, inPlain text. On most devices, this isn't a particle concern,
Because it stores them in a database that is only accessible to root. But on a rooted device, the credentials wocould be readable by anyoneadbAccess to the device.

With this in mind, you shouldn't pass the user's actual passwordAccountManager.addAccountExplicitly(). Instead, you shocould store a cryptographically secure token that wocould be of limited use to an attacker. If your user credentials
Are protecting something valuable, you shoshould carefully consider doing something similar.

Remember:When it comes to security code, follow the "MythBusters" rule: Don't try this at home! Consult a security professional before implementing any custom account code.

Now that the security disclaimers are out of the way, it's time to get back to work. you 've already implemented the meat of your custom account code; what's left is plumbing.

Extend extends actaccountauthenticator

In order forAccountManagerTo work with your custom account code, you need a class that implements the interfaces thatAccountManagerExpects. This class is
Authenticator class.

The easiest way to create an authenticator class is to extendAbstractAccountAuthenticatorAnd implement its abstract methods. If you 've worked through the previous lessons, the abstract methodsAbstractAccountAuthenticator
Shocould look familiar: They're the opposite side of the methods you called in the previous lesson to get account information and authorization tokens.

Implementing an authenticator class properly requires a number of separate pieces of code. First,AbstractAccountAuthenticatorHas seven abstract methods that you must override. Second, you need to add anintent Filter
For"android.accounts.AccountAuthenticator"To your application manifest (shown in the next section). Finally, you must supply two XML resources that define, among other things, the name of your custom account type and the icon that the system
Will display next to accounts of this type.

You can find a step-by-step guide to implementing a successful authenticator class and the XML files inAbstractAccountAuthenticatorDocumentation. There's also a sample implementation in thesamplesyncadapter
Sample app.

As you read through the samplesyncadapter code, you'll notice that several of the Methods return an intent in a bundle. this is the same intent that will be used to launch your custom authenticator activity. if your authenticator activity needs any special
Initialization parameters, you can attach them to the intent usingIntent.putExtra().

Create an authenticator Service

Now that you have an authenticator class, you need a place for it to live. account authenticators need to be available to multiple applications and work in the background, so naturally they're required to run insideService.
We'll call this the authenticator service.

Your authenticator service can be very simple. All it needs to do is create an instance of your authenticator class inonCreate()And call
getIBinder()InonBind().

Samplesyncadapter contains a good example of an authenticator service.

Don't forget to add<service>Tag to your manifest file and add an intent filter for the accountauthenticator intent and declare the account authenticator:

<service ...>   <intent-filter>      <action android:name="android.accounts.AccountAuthenticator" />   </intent-filter>   <meta-data android:name="android.accounts.AccountAuthenticator"             android:resource="@xml/authenticator" /></service>

Distribute your service

You're done! The system now recognizes your account type, right alongside all the big name account types like "google" and "Adjust ate." You can useAccounts & SyncSettings page to add an account, and apps that ask for accounts of your
Custom type will be able to enumerate and authenticate just as they wocould with any other account type.

Of course, all of this assumes that your account service is actually installed on the device. if only one app will ever access the service, then this isn't a big deal-just bundle the service in the app. but if you want your account service to be used
More than one app, things get trickier. You don't want to bundle the service with all of your apps and have multiple copies of it taking up space on your user's device.

One solution is to place the service in one small, special-purpose APK. when an app wishes to use your custom account type, it can check the device to see if your custom account service is available. if not, it can direct the user to Google Play to download
The service. This may seem like a great deal of trouble at first, but compared with the alternative of re-entering credentials for every app that uses your custom account, it's refreshingly easy.