AndroidAccountsAPI

#Implementing Android Accounts API into K-9 Mail

(Android ≥ 2.0)

http://developer.android.com/reference/android/accounts/AccountManager.html

Has a client/server model:

• the client code is making requests to the AccountManager API (not directly to the server) to:
  • retrieve existing accounts (GET_ACCOUNTS) - directly implemented by Android
  • ask for accounts creation/deletion (MANAGE_ACCOUNTS) - forwarded to the server
  • ask for credentials update (MANAGE_ACCOUNT) - forwarded to the server
  • retrieve authentication tokens (USE_CREDENTIALS) - forwarded to the server
  • update vendor specific data for an account (MANAGE_ACCOUNTS) - forwarded to the server
• the server (authenticator) code is invoked by Android internals (not directly by client code) and:
  • is the one actually adding/removing accounts and reading/saving the associated data (AUTHENTICATE_ACCOUNTS):
    • password
    • tokens
    • vendor specific data
    • all the above data are saved by Android internals (using the AccountManager API) to an unspecified storage
  • should validate any data before saving them - vendor specific
  • can directly serve the client request if possible (synchronous mode)
  • can launch a threaded long running task, provided that proper threading is made to return the response (asynchnous mode) - can be any user input, a network connection, etc.
  • can invalidate the client request

This client/server model allows asynchronous operations for almost every operations exposed to the client. It's up to the server to choose how to serve the client request: if user interaction is required (most probably because the client request didn't include needed parameters), async mode has to be implemented. That means the client has to manage asynchronous response: proper threading is required.

This client/server model allows to have several apps using a single shared authenticator, provided they meet some requirements (same application vendor). Google apps work that way.

K-9 implementation:

Pros:

• Remove credentials from store URI (currently implemented in various ways, depending of the protocol)
• Better security - the application doesn't manage the actual storing of credentials data. Allow to safely export K-9 settings without having to filter out credentials data.
• Seamless integration with the Android way to control which account is synchronized (apps using that: Gmail, Calendar, Reader, Twitter, LinkedIn, etc.)

Cons:

• Android thinks it can now use our Account to store contacts
• Not compatible with 1.x (an abstraction would be needed)
• Need to implement it for each type inbound and outbound connection (IMAP, POP3, WebDav, SMTP)
• An authenticator should be able to directly validate the credentials before saving them (need minimal connection capabilities and possibly a proper UI to define some server settings like encryption)
• Authenticator user interaction should be carefully threaded as Android enforce usage of a dedicated thread (as opposed to the UI thread) for some methods (should we first fix existing StrictMode issues?)
• K-9 accounts need to be kept synchronized with Android accounts
• Android accounts don't have a separate identifier: they are identified by their name which is also the label shown to the user. This means we can't directly use K-9 UUIDs to ensure proper mapping. Also, if we use K-9 account description to match the Android account label, we have to enforce the uniqueness of these description in K-9.

However there should be a dirty way to ease implementation: bypassing the client/server model and directly implementing the server code into existing code but that breaks the architecture of the Android account API but that doesn't remove much complexity (and some POC code was already done for the client/server model).