Android Version

Android 14 and Android 15: the leak still exists on latest master / main of AOSP.

Root cause

• AccountManager$AmsTask$Response is a binder stub (extends IAccountManagerResponse.Stub) and as such it will often be retained long after the associated AmsTask and activity are destroyed, as by design stubs are retained until the other side gets GCed.
• AccountManager$AmsTask$Response has a strong this$1 reference to AccountManager$11
• AccountManager$11 is an anonymous subclass of AccountManager$AmsTask which has a mActivity reference to a destroyed activity.

How to fix

Make AccountManager$AmsTask$Response a static inner class with an explicit nullable reference to AccountManager$AmsTask.

Leak Trace

 ┬───
 │ GC Root: Global variable in native code
 │
 ├─ android.accounts.AccountManager$AmsTask$Response instance
 │    Retaining 6,2 MB in 17823 objects
 │    ↓ AccountManager$AmsTask$Response.this$1
 │                                      ~~~~~~
 ├─ android.accounts.AccountManager$11 instance
 │    Retaining 6,2 MB in 17822 objects
 │    Anonymous subclass of android.accounts.AccountManager$AmsTask
 │    ↓ AccountManager$AmsTask.mActivity
 │                             ~~~~~~~~~
 ╰→ com.example.MyActivity instance
 ​     Leaking: YES (Activity#mDestroyed is true)
 ​     Retaining 6,2 MB in 17806 objects

This leak is hard to reproduce systematically as one needs to have the other process hold its GC. Still, it's very real, it's easy to fix, and looks like it has existed since the introduction of AccountManager in 2009.