Memory leak in WearCounterDataService

[abaker]

I followed the datalayer sample in my app and LeakCanary is reporting a leak.

You can repro by adding debugImplementation("com.squareup.leakcanary:leakcanary-android:2.14") to the datalayer sample phone app, then running the counter sample:

HEAP ANALYSIS RESULT
====================================
1 APPLICATION LEAKS

References underlined with "~~~" are likely causes.
Learn more at https://squ.re/leaks.

19240 bytes retained by leaking objects
Displaying only 1 leak trace out of 4 with the same signature
Signature: 4d877d1eda15953b09c43cdec3b03952589dec2b
┬───
│ GC Root: Global variable in native code
│
├─ com.google.android.gms.wearable.zzaf instance
│    Leaking: UNKNOWN
│    Retaining 5.4 kB in 119 objects
│    zza instance of com.google.android.horologist.datalayer.sample.grpc.WearCounterDataService
│    ↓ zzaf.zza
│           ~~~
╰→ com.google.android.horologist.datalayer.sample.grpc.WearCounterDataService instance
​     Leaking: YES (ObjectWatcher was watching this because com.google.android.horologist.datalayer.sample.grpc.
​     WearCounterDataService received Service#onDestroy() callback and Service not held by ActivityThread)
​     Retaining 4.8 kB in 118 objects
​     key = 6826990e-ec2f-4470-a1cb-9fa592161abb
​     watchDurationMillis = 29175
​     retainedDurationMillis = 24174
​     mApplication instance of com.google.android.horologist.datalayer.sample.App
​     mBase instance of android.app.ContextImpl
====================================
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.
====================================
METADATA

Please include this in bug reports and Stack Overflow questions.

Build.VERSION.SDK_INT: 35
Build.MANUFACTURER: Google
LeakCanary version: 2.14
App process name: com.google.android.horologist.datalayer.sample.debug
Class count: 35201
Instance count: 241157
Primitive array count: 176679
Object array count: 36071
Thread count: 24
Heap total bytes: 32191601
Bitmap count: 1
Bitmap total bytes: 3969
Large bitmap count: 0
Large bitmap total bytes: 0
Stats: LruCache[maxSize=3000,hits=122033,misses=226410,hitRate=35%]
RandomAccess[bytes=11112706,reads=226410,travel=84606655111,range=39689848,size=49173189]
Heap dump reason: user request
Analysis duration: 11289 ms
Heap dump file path: /storage/emulated/0/Download/leakcanary-com.google.android.horologist.datalayer.sample.
debug/2024-12-20_14-35-17_138.hprof
Heap dump timestamp: 1734726933225
Heap dump duration: 2219 ms
====================================

[yschimke]

Thanks for the report.

I'm assuming that field (zzaf.zza) is from com.google.android.gms.wearable.WearableListenerService

Can you tell if it is actually a bug in Horologist code, rather than the underlying GMS library?