search

android / codelab-android-workmanager

Apache License 2.0
546 stars 240 forks source link

Leak in SystemJobService #232

Open rickytribbia opened 3 years ago

rickytribbia commented 3 years ago

Hi everyone,

we're using WorkManager in an app in which we've also LeakCanary configured and we always receive this warning after a run of each Periodic Worker: 

    16:49:08.888    LeakCanary      ​
====================================
HEAP ANALYSIS RESULT
====================================
1 APPLICATION LEAKS

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

774 bytes retained by leaking objects
Signature: 6491376cfe66b1cac0d47b3ae180fd902719aa5
┬───
│ GC Root: Global variable in native code
│
├─ android.app.job.JobService$1 instance
│    Leaking: UNKNOWN
│    Retaining 802 B in 15 objects
│    Anonymous subclass of android.app.job.IJobService$Stub
│    this$0 instance of androidx.work.impl.background.systemjob.SystemJobService
│    ↓ JobService$1.this$0
│                   ~~~~~~
╰→ androidx.work.impl.background.systemjob.SystemJobService instance
​     Leaking: YES (ObjectWatcher was watching this because androidx.work.impl.background.systemjob.SystemJobService
​     received Service#onDestroy() callback)
​     Retaining 774 B in 14 objects
​     key = 155d4c85-1073-4df1-bd0f-250b40c959c8
​     watchDurationMillis = 5248
​     retainedDurationMillis = 246
​     mApplication instance of xx.yy.MyApp
​     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: 23
Build.MANUFACTURER: alps
LeakCanary version: 2.6
App process name: xx.yy.MyApp
Stats: LruCache[maxSize=3000,hits=101,misses=300675,hitRate=0%]
RandomAccess[bytes=11383030,reads=300675,travel=696095628841,range=23369842,size=28770980]
Heap dump reason: 1 retained objects, app is not visible
Analysis duration: 202141 ms
Heap dump file path: /storage/emulated/0/Download/leakcanary-xx.yy.MyApp/2021-03-08_16-45-32_740.
hprof
Heap dump timestamp: 1615218548838
Heap dump duration: 13889 ms
====================================

WorkManager library in use: androidx.work:work-rxjava2:2.5.0 LeakCanary library in use: com.squareup.leakcanary:leakcanary-android:2.6

Any advice? Did you see this warning yet?

I don't know if can be a useful info, but the app we're developing is a system app used on embedded device (Android based, obviously)

calren commented 3 years ago

@rickytribbia I don't believe we've seen any similar issues. Are you able to reproduce the behavior in a non-systems app running on a Android phone (not an embedded device)? If not, I suspect the problem is not with the workmanager library.

rickytribbia commented 3 years ago

Hi Calren, thank you for your answer. I don't know if you're experienced with LeakCanary; its heap analysis result print any dependencies between an instance of a retained object and the GC Root.

In the log that I printed before you can see that there aren't any classes of my app between the retained object and the root, so I have no entrypoint to investigate deep to this leak. What do you think about it? Where could I check if my code retains something about workmanager instances (androidx.work.impl.background.systemjob.SystemJobService, I think)?

calren commented 3 years ago

If possible, can you try installing your app on an Android phone and see if the same leak canary warnings are surfaced?

I suspect the leak might be coming from the embedded device and not the WorkManager library itself, so it'd be good to check if leak canary still reports the same warnings on devices not running a modified version of Android.

rickytribbia commented 3 years ago

 Hi Calren, we've tried to install our app on an Android phone: the same leak canary warnings was nevers surfaced, but the scenario is really different (our app acts as a system app, so have extended permissions), so our app in any Job runned by WorkManager always returns errors and the Job/Worker fails instantly.

Have you any advice? Another possible clue could be that we use Dagger for dependency injection also into our Worker?

ArcherEmiya05 commented 3 years ago

I also had this issue. Regarding the statement by @calren

I suspect the leak might be coming from the embedded device

Uhm, leak root cause should not depend on a device and its never been that way?

ArcherEmiya05 commented 3 years ago

This is what I get sometimes

04-28 10:58:52.125 13357-13357/com.myapp.name D/LeakCanary: ​
    ┬───
    │ GC Root: Global variable in native code
    │
    ├─ android.app.job.JobService$1 instance
    │    Leaking: UNKNOWN
    │    Retaining 602 B in 13 objects
    │    Anonymous subclass of android.app.job.IJobService$Stub
    │    this$0 instance of com.google.android.datatransport.runtime.scheduling.jobscheduling.JobInfoSchedulerService
    │    ↓ JobService$1.this$0
    │                   ~~~~~~
    ╰→ com.google.android.datatransport.runtime.scheduling.jobscheduling.JobInfoSchedulerService instance
    ​     Leaking: YES (ObjectWatcher was watching this because com.google.android.datatransport.runtime.scheduling.
    ​     jobscheduling.JobInfoSchedulerService received Service#onDestroy() callback and Service not held by
    ​     ActivityThread)
    ​     Retaining 574 B in 12 objects
    ​     key = 54f18ba8-4533-4b95-8def-6b19b6e79481
    ​     watchDurationMillis = 5260
    ​     retainedDurationMillis = 254
    ​     mApplication instance of com.myapp.name.App
    ​     mBase instance of android.app.ContextImpl

    METADATA

    Build.VERSION.SDK_INT: 21
    Build.MANUFACTURER: Xiaomi
    LeakCanary version: 2.7
    App process name: com.myapp.name
    Stats: LruCache[maxSize=3000,hits=84,misses=122288,hitRate=0%]
    RandomAccess[bytes=11522584,reads=122288,travel=37581525864,range=42112035,size=55145753]
    Heap dump reason: 1 retained objects, app is not visible
    Analysis duration: 32830 ms
Cassers commented 3 years ago

Something similar happens to me in my application

  06-29 19:38:12.834 19354-19354/com.bastechsolutions.swiftcountandroid D/LeakCanary: ​
      ┬───
      │ GC Root: Global variable in native code
      │
      ├─ android.app.job.JobService$1 instance
      │    Leaking: UNKNOWN
      │    Retaining 792 B in 13 objects
      │    Anonymous subclass of android.app.job.IJobService$Stub
      │    this$0 instance of com.google.android.datatransport.runtime.scheduling.jobscheduling.JobInfoSchedulerService
      │    ↓ JobService$1.this$0
      │                   ~~~~~~
      ╰→ com.google.android.datatransport.runtime.scheduling.jobscheduling.JobInfoSchedulerService instance
      ​     Leaking: YES (ObjectWatcher was watching this because com.google.android.datatransport.runtime.scheduling.
      ​     jobscheduling.JobInfoSchedulerService received Service#onDestroy() callback and Service not held by
      ​     ActivityThread)
      ​     Retaining 764 B in 12 objects
      ​     key = 2bf8f741-1b37-48bd-9ca1-4a13752ad556
      ​     watchDurationMillis = 5222
      ​     retainedDurationMillis = 217
      ​     mApplication instance of com.bastechsolutions.swiftcountandroid.AppDelegate
      ​     mBase instance of android.app.ContextImpl

      METADATA

      Build.VERSION.SDK_INT: 23
      Build.MANUFACTURER: BLU
      LeakCanary version: 2.7
      App process name: com.bastechsolutions.swiftcountandroid
      Stats: LruCache[maxSize=3000,hits=96,misses=26206,hitRate=0%]
      RandomAccess[bytes=2616381,reads=26206,travel=9053088550,range=15789858,size=21467640]
      Heap dump reason: 1 retained objects, app is not visible
      Analysis duration: 342982 ms

This only happens to me on a specific cell phone that I use to optimize my applications, I think the error comes out because the device has very low performance.

The device in which it happens to me is a Blue Dash G and has the following characteristics:

Screen: 5 ", 480 x 854 pixels
Processor: Mediatek MT6580 1.3GHz
RAM: 512MB
Storage: 4GB
Expansion: microSD

Camera: 5 MP
Battery: 2000 mAh
OS: Android 6.0
Profile: 9.8 mm
Weight: 157g
kmayoral commented 2 years ago

Here is a dump of my reproduction of the issue as well (as this is still happening):

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

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

2243 bytes retained by leaking objects
Signature: 953feb82863ec1b7cb6fcf77def88fd9aec7bd
┬───
│ GC Root: Java local variable
│
├─ java.lang.Thread thread
│ Leaking: UNKNOWN
│ Retaining 47.7 kB in 380 objects
│ Thread name: 'pool-10-thread-1'
│ ↓ Thread.<Java Local>
│ ~~~~~~~~~~~~
├─ com.google.android.datatransport.runtime.scheduling.jobscheduling.
│ JobInfoSchedulerService$$ExternalSyntheticLambda0 instance
│ Leaking: UNKNOWN
│ Retaining 3.8 kB in 32 objects
│ f$0 instance of com.google.android.datatransport.runtime.scheduling.
│ jobscheduling.JobInfoSchedulerService
│ ↓ JobInfoSchedulerService$$ExternalSyntheticLambda0.f$0
│ ~~~
╰→ com.google.android.datatransport.runtime.scheduling.jobscheduling.
​ JobInfoSchedulerService instance
​ Leaking: YES (ObjectWatcher was watching this because com.google.android.
​ datatransport.runtime.scheduling.jobscheduling.JobInfoSchedulerService
​ received Service#onDestroy() callback and Service not held by
​ ActivityThread)
​ Retaining 2.2 kB in 17 objects
​ key = 814cc92e-4087-400f-9ab2-7bc5d971018a
​ watchDurationMillis = 5599
​ retainedDurationMillis = 556
​ mApplication instance of com.mycompany.android.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: 31
Build.MANUFACTURER: Google
LeakCanary version: 2.7
App process name: com.mycompany.android
Stats: LruCache[maxSize=3000,hits=4454,misses=259618,hitRate=1%]
RandomAccess[bytes=13015376,reads=259618,travel=184478677083,range=60464600,size
=70558998]
Heap dump reason: 1 retained objects, app is not visible
Analysis duration: 17591 ms
Heap dump file path: /storage/emulated/0/Download/leakcanary-co.mycompany.
android/2022-01-04_10-48-37_439.hprof
Heap dump timestamp: 1641322146281
Heap dump duration: 11154 ms
====================================

The only relevant details that I can discern is this error message:

ObjectWatcher was watching this because com.google.android.
​ datatransport.runtime.scheduling.jobscheduling.JobInfoSchedulerService
​ received Service#onDestroy() callback and Service not held by
​ ActivityThread
caosc900224 commented 2 years ago

 I can reproduce the same issue on multiple device, I received this warning after run of each Periodic Worker or Enqueued Jobservice, any suggestion for the issue?

com.google.android.datatransport.runtime.scheduling.jobscheduling.JobInfoSchedulerService instance ​ Leaking: YES (ObjectWatcher was watching this because com.google.android.datatransport.runtime.scheduling. ​ jobscheduling.JobInfoSchedulerService received Service#onDestroy() callback and Service not held by ​ ActivityThread)

kazimdsaidul commented 2 years ago 
749 bytes retained by leaking objects
Signature: 99e784c1433b5477fe40e3ebca5ffce0e9dd16
┬───
│ GC Root: System class
│
├─ android.content.res.ResourcesImpl class
│    Leaking: NO (a class is never leaking)
│    ↓ static ResourcesImpl.mAppContext
│                           ~~~~~~~~~~~
├─ android.app.ContextImpl instance
│    Leaking: UNKNOWN
│    Retaining 2.0 kB in 13 objects
│    mOuterContext instance of com.google.android.datatransport.runtime.scheduling.jobscheduling.JobInfoSchedulerService
│    ContextImpl.mOuterContext is an instance of com.google.android.datatransport.runtime.scheduling.jobscheduling.
│    JobInfoSchedulerService
│    ↓ ContextImpl.mOuterContext
│                  ~~~~~~~~~~~~~
╰→ com.google.android.datatransport.runtime.scheduling.jobscheduling.JobInfoSchedulerService instance
​     Leaking: YES (ObjectWatcher was watching this because com.google.android.datatransport.runtime.scheduling.
​     jobscheduling.JobInfoSchedulerService received Service#onDestroy() callback and Service not held by
​     ActivityThread)
​     Retaining 749 B in 6 objects
​     key = 4aabceb8-2d2b-4070-b145-d412c58e3bca
​     watchDurationMillis = 135034
​     retainedDurationMillis = 130029
​     mApplication instance of com.sundarban.deliveryman.app.BaseApplication
​     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: 30
Build.MANUFACTURER: Xiaomi
LeakCanary version: 2.7
App process name: com.sundarban.deliveryman.debug
Stats: LruCache[maxSize=3000,hits=3378,misses=88914,hitRate=3%]
RandomAccess[bytes=4167110,reads=88914,travel=43953220991,range=25986646,size=33102335]
Heap dump reason: user request
Analysis duration: 6558 ms
Heap dump file path: /storage/emulated/0/Download/leakcanary-com.sundarban.deliveryman.debug/2022-03-09_12-24-58_395.
hprof
Heap dump timestamp: 1646807108270
Heap dump duration: 2847 ms
pseandersson commented 2 years ago

Any solutions to @kazimdsaidul leak?

SeniorZhai commented 2 years ago

Anyone have a solution?

┬───
│ GC Root: Thread object
│
├─ java.lang.Thread instance
│    Leaking: UNKNOWN
│    Retaining 18.0 kB in 501 objects
│    Thread name: 'pool-6-thread-1'
│    ↓ Thread<Java Local>
│            ~~~~~~~~~~~~
├─ com.google.android.datatransport.runtime.scheduling.jobscheduling.
│  JobInfoSchedulerService$$ExternalSyntheticLambda0 instance
│    Leaking: UNKNOWN
│    Retaining 3.3 kB in 30 objects
│    f$0 instance of com.google.android.datatransport.runtime.scheduling.
│    jobscheduling.JobInfoSchedulerService
│    ↓ JobInfoSchedulerService$$ExternalSyntheticLambda0.f$0
│                                                        ~~~
╰→ com.google.android.datatransport.runtime.scheduling.jobscheduling.
​  JobInfoSchedulerService instance
​     Leaking: YES (ObjectWatcher was watching this because com.google.android.
​     datatransport.runtime.scheduling.jobscheduling.JobInfoSchedulerService
​     received Service#onDestroy() callback and Service not held by
​     ActivityThread)
​     Retaining 1.8 kB in 15 objects
​     key = 2aaf8ae9-f257-49d7-aa77-08d528827eff
​     watchDurationMillis = 5551
​     retainedDurationMillis = 549
​     mApplication instance of one.mixin.android.MixinApp
​     mBase instance of android.app.ContextImpl

METADATA

Build.VERSION.SDK_INT: 31
Build.MANUFACTURER: Xiaomi
LeakCanary version: 2.9.1
App process name: one.mixin.messenger
Class count: 27917
Instance count: 281753
Primitive array count: 181885
Object array count: 43108
js361014 commented 2 years ago

I had tested workmanager on https://github.com/RachmadAgungL/Tugas6-1918070-RachmadAgungL/ and the same issue occurred.

ivannatividad commented 2 years ago

Same here, is there anyone able to figure out the issue? 

    ┬───
    │ GC Root: System class
    │
    ├─ android.content.res.ResourcesImpl class
    │    Leaking: NO (a class is never leaking)
    │    ↓ static ResourcesImpl.mAppContext
    │                           ~~~~~~~~~~~
    ├─ android.app.ContextImpl instance
    │    Leaking: UNKNOWN
    │    Retaining 2.0 kB in 13 objects
    │    mOuterContext instance of com.google.android.datatransport.runtime.scheduling.jobscheduling.JobInfoSchedulerService
    │    ContextImpl.mOuterContext is an instance of com.google.android.datatransport.runtime.scheduling.jobscheduling.
    │    JobInfoSchedulerService
    │    ↓ ContextImpl.mOuterContext
    │                  ~~~~~~~~~~~~~
    ╰→ com.google.android.datatransport.runtime.scheduling.jobscheduling.JobInfoSchedulerService instance
    ​     Leaking: YES (ObjectWatcher was watching this because com.google.android.datatransport.runtime.scheduling.
    ​     jobscheduling.JobInfoSchedulerService received Service#onDestroy() callback and Service not held by
    ​     ActivityThread)
    ​     Retaining 749 B in 6 objects
    ​     key = 106b88b8-9fc8-4bb1-bc67-f720d79fdf2f
    ​     watchDurationMillis = 10041
    ​     retainedDurationMillis = 5040
    ​     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: 30
    Build.MANUFACTURER: Xiaomi
    LeakCanary version: 2.7
    Stats: LruCache[maxSize=3000,hits=3381,misses=202478,hitRate=1%]
    RandomAccess[bytes=10806583,reads=202478,travel=110618093912,range=40792679,size=51604394]
    Heap dump reason: user request
    Analysis duration: 15401 ms
    Heap dump timestamp: 1657242946237
    Heap dump duration: 3515 ms
    ====================================
WilsonScott commented 2 years ago

any solution here ?

kaviskhandelwal commented 1 year ago

I am facing the same issue, any solution for this ?

│ GC Root: System class
│
├─ android.content.res.ResourcesImpl class
│    Leaking: NO (a class is never leaking)
│    ↓ static ResourcesImpl.mAppContext
│                           ~~~~~~~~~~~
├─ android.app.ContextImpl instance
│    Leaking: UNKNOWN
│    Retaining 1.8 kB in 18 objects
│    mOuterContext instance of androidx.work.impl.background.systemjob.SystemJobService
│    ContextImpl.mOuterContext is an instance of androidx.work.impl.background.systemjob.SystemJobService
│    ↓ ContextImpl.mOuterContext
│                  ~~~~~~~~~~~~~
╰→ androidx.work.impl.background.systemjob.SystemJobService instance
​     Leaking: YES (ObjectWatcher was watching this because androidx.work.impl.background.systemjob.SystemJobService received Service#onDestroy() callback and Service not held by ActivityThread)
​     Retaining 276 B in 6 objects
​     key = 15e32ff1-396b-46dd-a442-0eccd6afb231
​     watchDurationMillis = 6375
​     retainedDurationMillis = 1374
​     mBase instance of android.app.ContextImpl`
pmg41 commented 1 year ago

I am also facing this issue of leaks in work manager In my project : I have used Workmanager (DI using HILT) with periodic work request by using DelegatingWorkerFactory to give a local scheduled notification every (One hour / Specific Time >= 30 minute).

┬─── │ GC Root: System class │ ├─ android.content.res.ResourcesImpl class │ Leaking: NO (a class is never leaking) │ ↓ static ResourcesImpl.mAppContext │ ~~~ ├─ android.app.ContextImpl instance │ Leaking: UNKNOWN │ Retaining 2.4 kB in 47 objects │ mOuterContext instance of androidx.work.impl.foreground. │ SystemForegroundService │ ContextImpl.mOuterContext is an instance of androidx.work.impl.foreground. │ SystemForegroundService │ ↓ ContextImpl.mOuterContext │ ~~~~~ ╰→ androidx.work.impl.foreground.SystemForegroundService instance ​ Leaking: YES (ObjectWatcher was watching this because androidx.work.impl. ​ foreground.SystemForegroundService received Service#onDestroy() callback ​ and Service not held by ActivityThread) ​ Retaining 1.1 kB in 40 objects ​ key = 6584f839-414d-4ef8-9db4-c66949b01695 ​ watchDurationMillis = 53032 ​ retainedDurationMillis = 48027 ​ mApplication instance of APP_PACKAGE_NAME.base. ​ BaseApplication ​ mBase instance of android.app.ContextImpl

METADATA

Build.VERSION.SDK_INT: 30 Build.MANUFACTURER: realme LeakCanary version: 2.8.1 App process name: APP_PACKAGE_NAME Stats: LruCache[maxSize=3000,hits=36362,misses=78944,hitRate=31%] RandomAccess[bytes=3878630,reads=78944,travel=36641054393,range=22347685,size=28 595458] Analysis duration: 6089 ms

lzyang187 commented 1 year ago

┬─── │ GC Root: System class │ ├─ android.content.res.ResourcesImpl class │ Leaking: NO (a class is never leaking) │ ↓ static ResourcesImpl.mAppContext │ ~~~ ├─ android.app.ContextImpl instance │ Leaking: UNKNOWN │ Retaining 2.5 kB in 20 objects │ mOuterContext instance of androidx.work.impl.background.systemjob.SystemJobService │ ContextImpl.mOuterContext is an instance of androidx.work.impl.background.systemjob.SystemJobService │ ↓ ContextImpl.mOuterContext │ ~~~~~ ╰→ androidx.work.impl.background.systemjob.SystemJobService instance ​ Leaking: YES (ObjectWatcher was watching this because androidx.work.impl.background.systemjob.SystemJobService ​ received Service#onDestroy() callback and Service not held by ActivityThread) ​ Retaining 852 B in 9 objects ​ key = acfae287-9f8e-481d-b257-8d5e348d39ff ​ watchDurationMillis = 34718 ​ retainedDurationMillis = 29715 ​ mApplication instance of MyApplication ​ mBase instance of android.app.ContextImpl

xuegao-tzx commented 10 months ago

any solution here ?

 ┬───
                                                                                                    │ GC Root: System class
                                                                                                    │
                                                                                                    ├─ android.content.res.ResourcesImpl class
                                                                                                    │    Leaking: NO (a class is never leaking)
                                                                                                    │    ↓ static ResourcesImpl.mAppContext
                                                                                                    │                           ~~~~~~~~~~~
                                                                                                    ├─ android.app.ContextImpl instance
                                                                                                    │    Leaking: UNKNOWN
                                                                                                    │    Retaining 1.5 kB in 11 objects
                                                                                                    │    mOuterContext instance of com.google.android.datatransport.runtime.scheduling.jobscheduling.JobInfoSchedulerService
                                                                                                    │    ContextImpl.mOuterContext is an instance of com.google.android.datatransport.runtime.scheduling.jobscheduling.
                                                                                                    │    JobInfoSchedulerService
                                                                                                    │    ↓ ContextImpl.mOuterContext
                                                                                                    │                  ~~~~~~~~~~~~~
                                                                                                    ╰→ com.google.android.datatransport.runtime.scheduling.jobscheduling.JobInfoSchedulerService instance
                                                                                                    ​     Leaking: YES (ObjectWatcher was watching this because com.google.android.datatransport.runtime.scheduling.
                                                                                                    ​     jobscheduling.JobInfoSchedulerService received Service#onDestroy() callback and Service not held by
                                                                                                    ​     ActivityThread)
                                                                                                    ​     Retaining 197 B in 4 objects
                                                                                                    ​     key = 115a7645-3998-406d-8249-be6cb666783f
                                                                                                    ​     watchDurationMillis = 14187
                                                                                                    ​     retainedDurationMillis = 9187
                                                                                                    ​     mApplication instance of apps.MyApplication
                                                                                                    ​     mBase instance of android.app.ContextImpl

                                                                                                    METADATA

                                                                                                    Build.VERSION.SDK_INT: 30
                                                                                                    Build.MANUFACTURER: OPPO
                                                                                                    LeakCanary version: 2.12
                                                                                                    App process name: apps
                                                                                                    Class count: 32247
                                                                                                    Instance count: 205320
                                                                                                    Primitive array count: 140242
                                                                                                    Object array count: 34435
                                                                                                    Thread count: 77
                                                                                                    Heap total bytes: 29846808
                                                                                                    Bitmap count: 8
                                                                                                    Bitmap total bytes: 170994
                                                                                                    Large bitmap count: 0
                                                                                                    Large bitmap total bytes: 0
                                                                                                    Db 1: open /data/user/0/apps/databases/com.google.android.datatransport.events
                                                                                                    Db 2: closed /data/user/0/apps/databases/google_app_measurement_local.db
                                                                                                    Db 3: open /data/user/0/apps/databases/Monitor
                                                                                                    Db 4: open /data/user/0/apps/no_backup/androidx.work.workdb
                                                                                                    Stats: LruCache[maxSize=3000,hits=60679,misses=175062,hitRate=25%]
                                                                                                    RandomAccess[bytes=8071467,reads=175062,travel=66616777931,range=34649524,size=43241861]
                                                                                                    Analysis duration: 12878 ms
alenpmla commented 6 months ago

Hi, I'm facing the same issue in our Android app. Below is the heap analysis result from LeakCanary:

``` ┬─── │ GC Root: System class │ ├─ android.content.res.ResourcesImpl class │ Leaking: NO (a class is never leaking) │ ↓ static ResourcesImpl.mAppContext │ ~~~ ├─ android.app.ContextImpl instance │ Leaking: UNKNOWN │ Retaining 2.5 kB in 20 objects │ mOuterContext instance of androidx.work.impl.background.systemjob.SystemJobService │ ContextImpl.mOuterContext is an instance of androidx.work.impl.background.systemjob.SystemJobService │ ↓ ContextImpl.mOuterContext │ ~~~~~ ╰→ androidx.work.impl.background.systemjob.SystemJobService instance Leaking: YES (ObjectWatcher was watching this because androidx.work.impl.background.systemjob.SystemJobService received Service#onDestroy() callback and Service not held by ActivityThread) Retaining 852 B in 9 objects key = cd8968e6-3a01-4ac9-b78a-4f6c3f2f2c21 watchDurationMillis = 71115 retainedDurationMillis = 66114 mApplication instance of com.sample.app mBase instance of android.app.ContextImpl ```