[BUG] Memory leaks in OreoAutofillService

[msfjarvis]

Describe the bug

OreoAutofillService constantly leaks memory in the background.

To Reproduce
Steps to reproduce the behavior:

1. Enable Autofill
2. Launch a website to a login form and attempt to fill it in
3. Observe LeakCanary notification saying an object leaked.

Expected behavior

No memory leaks

Device information (please complete the following information):

• Device: Google Pixel 4a
• OS: Android 11
• App version: 2.0.0-SNAPSHOT

Additional context

Here's the leak trace:

┬───
│ GC Root: Global variable in native code
│
├─ android.service.autofill.AutofillService$1 instance
│    Leaking: UNKNOWN
│    Retaining 2.0 kB in 15 objects
│    Anonymous subclass of android.service.autofill.IAutoFillService$Stub
│    this$0 instance of dev.msfjarvis.aps.util.services.OreoAutofillService
│    ↓ AutofillService$1.this$0
│                        ~~~~~~
╰→ dev.msfjarvis.aps.util.services.OreoAutofillService instance
​     Leaking: YES (ObjectWatcher was watching this because dev.msfjarvis.aps.
​     util.services.OreoAutofillService received Service#onDestroy() callback)
​     Retaining 1.4 kB in 14 objects
​     key = 77ea4a3f-ebd3-4805-9296-0b99bbbcdc89
​     watchDurationMillis = 32544
​     retainedDurationMillis = 27506
​     mApplication instance of dev.msfjarvis.aps.Application
​     mBase instance of android.app.ContextImpl

METADATA

Build.VERSION.SDK_INT: 30
Build.MANUFACTURER: Google
LeakCanary version: 2.6
App process name: dev.msfjarvis.aps
Stats: LruCache[maxSize=3000,hits=2067,misses=72796,hitRate=2%]
RandomAccess[bytes=3515060,reads=72796,travel=29562220372,range=20995498,size=26
704589]
Heap dump reason: 1 retained objects, app is not visible
Analysis duration: 2463 ms

[fmeum]

This seems to be internal to the Autofill implementation and may even be working as intended: Even after the service has been destroyed, a reference to it is kept as it may need to be invoked again soon (there is only ever a single such service implementation after all). What do you think? If it turns out this is a repeatable leak, that could be an issue, but I don't know whether LeakCanary can track those across multiple lifecycles.

[msfjarvis]

This seems to be internal to the Autofill implementation and may even be working as intended: Even after the service has been destroyed, a reference to it is kept as it may need to be invoked again soon (there is only ever a single such service implementation after all). What do you think? If it turns out this is a repeatable leak, that could be an issue, but I don't know whether LeakCanary can track those across multiple lifecycles.

The leak has been triggered approximately 17 times for me in the last 6 hours so I'm not entirely sure if this is expected behaviour, but if it is then I'll work with the maintainer and get this marked as ignored.

[fmeum]

Turns out this is a general pattern of issues related to services: square/leakcanary#1906
Related AOSP issue: https://issuetracker.google.com/issues/167281719