====================================
HEAP ANALYSIS RESULT
====================================
1 APPLICATION LEAKS
References underlined with "~~~" are likely causes.
Learn more at https://squ.re/leaks.
1349 bytes retained by leaking objects
Signature: fbba65ae31efd4f2c9cce2a7189127798c896c7f
┬───
│ GC Root: Global variable in native code
│
├─ android.telecom.InCallService$InCallServiceBinder instance
│ Leaking: UNKNOWN
│ Retaining 1.9 kB in 12 objects
│ this$0 instance of com.redacted.company.CallService
│ instance InCallService$InCallServiceBinder@317901080
│ ↓ InCallService$InCallServiceBinder.this$0
│ ~~~~~~
╰→ com.redacted.company.CallService instance
Leaking: YES (ObjectWatcher was watching this because com.redacted.company.CallService received Service#onDestroy() callback and Service not held by ActivityThread)
Retaining 1.3 kB in 11 objects
key = 4658065d-2277-46cb-ad96-3de0440b039b
watchDurationMillis = -3481823
retainedDurationMillis = -3486830
mApplication instance of com.redacted.company.MyApplication
mBase instance of android.app.ContextImpl
instance CallService@321294080
====================================
0 LIBRARY LEAKS
A Library Leak is a leak caused by a known bug in 3rd party code that you do not have control over.
See https://square.github.io/leakcanary/fundamentals-how-leakcanary-works/#4-categorizing-leaks
====================================
0 UNREACHABLE OBJECTS
An unreachable object is still in memory but LeakCanary could not find a strong reference path
from GC roots.
====================================
Is it complaining about a leak in android.telecom.InCallService$InCallServiceBinder?
I've reduced the code in my CallService class to simple super.() only calls for the onCallAdded and onCallRemoved functions, so my leak can't be in there.