IssueTracker

（1） Steps to reproduce the problem：
Write a demo to create a new item in ChooseAccountActivity and just "return null" in the addAccount method in the class which implenments AbstractAccountAuthenticator.(I have wrote one and the github link: https://github.com/TCGOGOGO/AccountDemo) Install the Apk and go to Settings -> Accounts -> Add account,you will see the listItem "Test" which we add. Press it you will enter an empty interface and do this repeatedly.

（2） What happened：
Below is the meminfo i got use "adb shell dumpsys meminfo com.android.settings" when i was firstly in "Add accound interface"
 Objects
               Views:      488         ViewRootImpl:        3
         AppContexts:        6           Activities:        4
              Assets:        5        AssetManagers:        5
       Local Binders:       54        Proxy Binders:       45
       Parcel memory:        6         Parcel count:       25
    Death Recipients:        6      OpenSSL Sockets:        0
and After 15 times Test pressed i got
 Objects
               Views:      488         ViewRootImpl:        3
         AppContexts:        6           Activities:        19
              Assets:        5        AssetManagers:        5
       Local Binders:       54        Proxy Binders:       45
       Parcel memory:        6         Parcel count:       25
    Death Recipients:        6      OpenSSL Sockets:        0
I wait for 20 minutes and the result remained unchanged, so i geuss a memory leak occurred. Fortunately, the conjecture is confirmed by leakcanary, below is the memory leak infomation
[VALID]simple ref:
* GC ROOT android.accounts.AccountManager$AmsTask$Response.this$1
* references android.accounts.AccountManager$13.mCallback (anonymous subclass of android.accounts.AccountManager$AmsTask)
* references com.android.settings.accounts.AddAccountSettings$1.this$0 (anonymous implementation of android.accounts.AccountManagerCallback)
* leaks com.android.settings.accounts.AddAccountSettings instance

（3）Root cause：
firstly, I will give the call stack when press a listitem to add an account:
addAccount (AddAccountSettings) -> addAccountAsUser (AccountManager$AmsTask) ->  addAccountAsUser (AccountManagerService$Session)
-> addAccount (AbstractAccountAuthenticator$Transport) -> addAccount(the class we implements AbstractAccountAuthenticator) ->  response.onResult (AbstractAccountAuthenticator$Transport) -> onResult (AccountManagerService$Session) -> onResult (AccountManager$AmsTask$Response) -> run (AddAccountSettings$Callback).
We pass a callback parameter when we call addAccountAsUser in AccountManager, the callback is a reference of an non static anonymous inner class, so if its finsh(in finally) have no choice to execute, the callback will always hold the outer class's(AddAccountSettings) reference which leads to a memory leak. In AbstractAccountAuthenticator’s addAccount we can find that the response.onResult only be called when the result isn't null. the result is the return value of addAccount we implement. In other words, if we just return null in the addAccount we implement, the response.onResult will never be called, as well as the finsh in AddAccountSettings

（4）Solution：
Remove the Judgement "if (result != null)", that's will be ok because we will check it in onResult (AccountManagerService$Session) below are relative code:
if (result == null) {
    if (Log.isLoggable(TAG, Log.VERBOSE)) {
        Log.v(TAG, getClass().getSimpleName()
            + " calling onError() on response " + response);
    }
    response.onError(AccountManager.ERROR_CODE_INVALID_RESPONSE,
        "null bundle returned");
}
when we execute response.onError，the FutureTask's setException will be called and we will catch an AuthenticatorException in AddAccountSettings and finsh in finally. The memory leak will be solved easily in this way. Actually, this issue will only happen when the third-part Application do not follow the standard development criteria Android has offered, and i think this change will improve the system robustness to some extend.