[LeakScope] 22 Android lifecycle/memory violations detected

[MuhammadTehamsibAliTashfeen]

LeakScope: Android Lifecycle & Memory Leak Violations

About this report: This issue was automatically generated by LeakScope, a static analysis tool for Android lifecycle violations and memory leaks built on the Soot framework. This is part of an ongoing academic research study targeting ICSE 2027. No immediate action is required — we would greatly appreciate your feedback on whether these findings are accurate.

Summary

LeakScope detected 22 potential issue(s) across 2 detector type(s):

Severity	Count
🔴 High	16
🟡 Medium	0
🟢 Low (improvement opportunity)	6

Detector	Count	Severity	Description
FragmentViewFieldRetentionLeak	16	🔴 High	Fragment stores View references in instance fields not cleared in onDestroyView()
ViewBindingOpportunity	6	🟢 Low	Manual findViewById() calls — ViewBinding migration opportunity

---

Detailed Findings

🔴 FragmentViewFieldRetentionLeak

Fragment stores View references in instance fields not cleared in onDestroyView()

Finding #1 — StatusIndicatorFragment

Fragment View Field Retention Leak Detected
Class: com.cometchat.javasampleapp.fragments.shared.views.StatusIndicatorFragment

Issue:
- Fragment stores View references in instance fields
- These fields are not cleared when the view is destroyed

- onDestroyView() is missing

Leaked Fields:
  • parentView : android.widget.LinearLayout (assigned in onCreateView)

Why this is dangerous:
- Fragment views are destroyed/recreated on config changes
- Retained View references prevent garbage collection
- Leaked Views hold references to Activity Context
- Can cause OutOfMemoryError with repeated Fragment transactions

Recommended Fix:
Override onDestroyView() and clear all View/Binding fields:
  @Override
  public void onDestroyView() {
    super.onDestroyView();
    parentView = null;
  }

Finding #2 — LocalizeFragment

Fragment View Field Retention Leak Detected
Class: com.cometchat.javasampleapp.fragments.shared.resources.LocalizeFragment

Issue:
- Fragment stores View references in instance fields
- These fields are not cleared when the view is destroyed

- onDestroyView() is missing

Leaked Fields:
  • parentView : android.widget.LinearLayout (assigned in onCreateView)

Why this is dangerous:
- Fragment views are destroyed/recreated on config changes
- Retained View references prevent garbage collection
- Leaked Views hold references to Activity Context
- Can cause OutOfMemoryError with repeated Fragment transactions

Recommended Fix:
Override onDestroyView() and clear all View/Binding fields:
  @Override
  public void onDestroyView() {
    super.onDestroyView();
    parentView = null;
  }

Finding #3 — SchedulerBubbleFragment

Fragment View Field Retention Leak Detected
Class: com.cometchat.javasampleapp.fragments.shared.views.SchedulerBubbleFragment

Issue:
- Fragment stores View references in instance fields
- These fields are not cleared when the view is destroyed

- onDestroyView() is missing

Leaked Fields:
  • schedulerBubble : com.cometchat.chatuikit.shared.views.CometChatSchedulerBubble.CometChatSchedulerBubble (assigned in onCreateView)
  • cardView : com.google.android.material.card.MaterialCardView (assigned in onCreateView)

Why this is dangerous:
- Fragment views are destroyed/recreated on config changes
- Retained View references prevent garbage collection
- Leaked Views hold references to Activity Context
- Can cause OutOfMemoryError with repeated Fragment transactions

Recommended Fix:
Override onDestroyView() and clear all View/Binding fields:
  @Override
  public void onDestroyView() {
    super.onDestroyView();
    schedulerBubble = null;
    cardView = null;
  }

Finding #4 — ListItemFragment

Fragment View Field Retention Leak Detected
Class: com.cometchat.javasampleapp.fragments.shared.views.ListItemFragment

Issue:
- Fragment stores View references in instance fields
- These fields are not cleared when the view is destroyed

- onDestroyView() is missing

Leaked Fields:
  • parentView : android.widget.LinearLayout (assigned in onCreateView)

Why this is dangerous:
- Fragment views are destroyed/recreated on config changes
- Retained View references prevent garbage collection
- Leaked Views hold references to Activity Context
- Can cause OutOfMemoryError with repeated Fragment transactions

Recommended Fix:
Override onDestroyView() and clear all View/Binding fields:
  @Override
  public void onDestroyView() {
    super.onDestroyView();
    parentView = null;
  }

Finding #5 — AvatarFragment

Fragment View Field Retention Leak Detected
Class: com.cometchat.javasampleapp.fragments.shared.views.AvatarFragment

Issue:
- Fragment stores View references in instance fields
- These fields are not cleared when the view is destroyed

- onDestroyView() is missing

Leaked Fields:
  • avatar : com.cometchat.chatuikit.shared.views.CometChatAvatar.CometChatAvatar (assigned in onCreateView)
  • parentView : android.widget.LinearLayout (assigned in onCreateView)
  • cornerRadiusLayout : com.google.android.material.textfield.TextInputLayout (assigned in onCreateView)

Why this is dangerous:
- Fragment views are destroyed/recreated on config changes
- Retained View references prevent garbage collection
- Leaked Views hold references to Activity Context
- Can cause OutOfMemoryError with repeated Fragment transactions

Recommended Fix:
Override onDestroyView() and clear all View/Binding fields:
  @Override
  public void onDestroyView() {
    super.onDestroyView();
    avatar = null;
    
… (truncated for brevity)

Finding #6 — CallLogHistoryFragment

Fragment View Field Retention Leak Detected
Class: com.cometchat.javasampleapp.fragments.calls.CallLogHistoryFragment

Issue:
- Fragment stores View references in instance fields
- These fields are not cleared when the view is destroyed

- onDestroyView() is missing

Leaked Fields:
  • cometChatCallLogHistory : com.cometchat.chatuikit.calls.callhistory.CometChatCallLogHistory (assigned in onCreateView)

Why this is dangerous:
- Fragment views are destroyed/recreated on config changes
- Retained View references prevent garbage collection
- Leaked Views hold references to Activity Context
- Can cause OutOfMemoryError with repeated Fragment transactions

Recommended Fix:
Override onDestroyView() and clear all View/Binding fields:
  @Override
  public void onDestroyView() {
    super.onDestroyView();
    cometChatCallLogHistory = null;
  }

Finding #7 — CallLogParticipantsFragment

Fragment View Field Retention Leak Detected
Class: com.cometchat.javasampleapp.fragments.calls.CallLogParticipantsFragment

Issue:
- Fragment stores View references in instance fields
- These fields are not cleared when the view is destroyed

- onDestroyView() is missing

Leaked Fields:
  • cometChatCallLogParticipants : com.cometchat.chatuikit.calls.callparticipants.CometChatCallLogParticipants (assigned in onCreateView)

Why this is dangerous:
- Fragment views are destroyed/recreated on config changes
- Retained View references prevent garbage collection
- Leaked Views hold references to Activity Context
- Can cause OutOfMemoryError with repeated Fragment transactions

Recommended Fix:
Override onDestroyView() and clear all View/Binding fields:
  @Override
  public void onDestroyView() {
    super.onDestroyView();
    cometChatCallLogParticipants = null;
  }

Finding #8 — CallLogDetailsFragment

Fragment View Field Retention Leak Detected
Class: com.cometchat.javasampleapp.fragments.calls.CallLogDetailsFragment

Issue:
- Fragment stores View references in instance fields
- These fields are not cleared when the view is destroyed

- onDestroyView() is missing

Leaked Fields:
  • cometChatCallLogDetails : com.cometchat.chatuikit.calls.calldetails.CometChatCallLogDetails (assigned in onCreateView)

Why this is dangerous:
- Fragment views are destroyed/recreated on config changes
- Retained View references prevent garbage collection
- Leaked Views hold references to Activity Context
- Can cause OutOfMemoryError with repeated Fragment transactions

Recommended Fix:
Override onDestroyView() and clear all View/Binding fields:
  @Override
  public void onDestroyView() {
    super.onDestroyView();
    cometChatCallLogDetails = null;
  }

Finding #9 — MessageReceiptFragment

Fragment View Field Retention Leak Detected
Class: com.cometchat.javasampleapp.fragments.shared.views.MessageReceiptFragment

Issue:
- Fragment stores View references in instance fields
- These fields are not cleared when the view is destroyed

- onDestroyView() is missing

Leaked Fields:
  • messageReceiptRead : com.cometchat.chatuikit.shared.views.CometChatReceipt.CometChatReceipt (assigned in onCreateView)
  • parentView : android.widget.LinearLayout (assigned in onCreateView)
  • messageReceiptDeliver : com.cometchat.chatuikit.shared.views.CometChatReceipt.CometChatReceipt (assigned in onCreateView)
  • messageReceiptSent : com.cometchat.chatuikit.shared.views.CometChatReceipt.CometChatReceipt (assigned in onCreateView)
  • messageReceiptProgress : com.cometchat.chatuikit.shared.views.CometChatReceipt.CometChatReceipt (assigned in onCreateView)
  • messageReceiptError : com.cometchat.chatuikit.shared.views.CometChatReceipt.CometChatReceipt (assigned in onCreateView)

Wh
… (truncated for brevity)

Finding #10 — CallLogRecordingFragment

Fragment View Field Retention Leak Detected
Class: com.cometchat.javasampleapp.fragments.calls.CallLogRecordingFragment

Issue:
- Fragment stores View references in instance fields
- These fields are not cleared when the view is destroyed

- onDestroyView() is missing

Leaked Fields:
  • cometChatCallLogRecordings : com.cometchat.chatuikit.calls.callrecordings.CometChatCallLogRecordings (assigned in onCreateView)

Why this is dangerous:
- Fragment views are destroyed/recreated on config changes
- Retained View references prevent garbage collection
- Leaked Views hold references to Activity Context
- Can cause OutOfMemoryError with repeated Fragment transactions

Recommended Fix:
Override onDestroyView() and clear all View/Binding fields:
  @Override
  public void onDestroyView() {
    super.onDestroyView();
    cometChatCallLogRecordings = null;
  }

Finding #11 — BadgeCountFragment

Fragment View Field Retention Leak Detected
Class: com.cometchat.javasampleapp.fragments.shared.views.BadgeCountFragment

Issue:
- Fragment stores View references in instance fields
- These fields are not cleared when the view is destroyed

- onDestroyView() is missing

Leaked Fields:
  • badgeCountLayout : com.google.android.material.textfield.TextInputLayout (assigned in onCreateView)
  • badgeCountEdt : com.google.android.material.textfield.TextInputEditText (assigned in onCreateView)
  • parentView : android.widget.LinearLayout (assigned in onCreateView)

Why this is dangerous:
- Fragment views are destroyed/recreated on config changes
- Retained View references prevent garbage collection
- Leaked Views hold references to Activity Context
- Can cause OutOfMemoryError with repeated Fragment transactions

Recommended Fix:
Override onDestroyView() and clear all View/Binding fields:
  @Override
  public void onDestroyView() {
    super.onDestroyView();
    badgeCountLayout = null
… (truncated for brevity)

Finding #12 — FormBubbleFragment

Fragment View Field Retention Leak Detected
Class: com.cometchat.javasampleapp.fragments.shared.views.FormBubbleFragment

Issue:
- Fragment stores View references in instance fields
- These fields are not cleared when the view is destroyed

- onDestroyView() is missing

Leaked Fields:
  • parentLayout : android.widget.LinearLayout (assigned in onCreateView)
  • formBubble : com.cometchat.chatuikit.shared.views.CometChatFormbubble.CometChatFormBubble (assigned in onCreateView)

Why this is dangerous:
- Fragment views are destroyed/recreated on config changes
- Retained View references prevent garbage collection
- Leaked Views hold references to Activity Context
- Can cause OutOfMemoryError with repeated Fragment transactions

Recommended Fix:
Override onDestroyView() and clear all View/Binding fields:
  @Override
  public void onDestroyView() {
    super.onDestroyView();
    parentLayout = null;
    formBubble = null;
  }

Finding #13 — MessageComposerFragment

Fragment View Field Retention Leak Detected
Class: com.cometchat.javasampleapp.fragments.messages.MessageComposerFragment

Issue:
- Fragment stores View references in instance fields
- These fields are not cleared when the view is destroyed

- onDestroyView() is missing

Leaked Fields:
  • parentView : android.widget.RelativeLayout (assigned in onCreateView)

Why this is dangerous:
- Fragment views are destroyed/recreated on config changes
- Retained View references prevent garbage collection
- Leaked Views hold references to Activity Context
- Can cause OutOfMemoryError with repeated Fragment transactions

Recommended Fix:
Override onDestroyView() and clear all View/Binding fields:
  @Override
  public void onDestroyView() {
    super.onDestroyView();
    parentView = null;
  }

Finding #14 — SoundManagerFragment

Fragment View Field Retention Leak Detected
Class: com.cometchat.javasampleapp.fragments.shared.resources.SoundManagerFragment

Issue:
- Fragment stores View references in instance fields
- These fields are not cleared when the view is destroyed

- onDestroyView() is missing

Leaked Fields:
  • parentView : android.widget.LinearLayout (assigned in onCreateView)

Why this is dangerous:
- Fragment views are destroyed/recreated on config changes
- Retained View references prevent garbage collection
- Leaked Views hold references to Activity Context
- Can cause OutOfMemoryError with repeated Fragment transactions

Recommended Fix:
Override onDestroyView() and clear all View/Binding fields:
  @Override
  public void onDestroyView() {
    super.onDestroyView();
    parentView = null;
  }

Finding #15 — ThemeFragment

Fragment View Field Retention Leak Detected
Class: com.cometchat.javasampleapp.fragments.shared.resources.ThemeFragment

Issue:
- Fragment stores View references in instance fields
- These fields are not cleared when the view is destroyed

- onDestroyView() is missing

Leaked Fields:
  • parentView : android.widget.LinearLayout (assigned in onCreateView)

Why this is dangerous:
- Fragment views are destroyed/recreated on config changes
- Retained View references prevent garbage collection
- Leaked Views hold references to Activity Context
- Can cause OutOfMemoryError with repeated Fragment transactions

Recommended Fix:
Override onDestroyView() and clear all View/Binding fields:
  @Override
  public void onDestroyView() {
    super.onDestroyView();
    parentView = null;
  }

Finding #16 — CardBubbleFragment

Fragment View Field Retention Leak Detected
Class: com.cometchat.javasampleapp.fragments.shared.views.CardBubbleFragment

Issue:
- Fragment stores View references in instance fields
- These fields are not cleared when the view is destroyed

- onDestroyView() is missing

Leaked Fields:
  • parentLayout : android.widget.LinearLayout (assigned in onCreateView)
  • cardBubble : com.cometchat.chatuikit.shared.views.CometChatCardBubble.CometChatCardBubble (assigned in onCreateView)
  • scrollView : android.widget.ScrollView (assigned in onCreateView)

Why this is dangerous:
- Fragment views are destroyed/recreated on config changes
- Retained View references prevent garbage collection
- Leaked Views hold references to Activity Context
- Can cause OutOfMemoryError with repeated Fragment transactions

Recommended Fix:
Override onDestroyView() and clear all View/Binding fields:
  @Override
  public void onDestroyView() {
    super.onDestroyView();
    parentLayout = null;
    cardBubble =
… (truncated for brevity)

🟢 ViewBindingOpportunity

Manual findViewById() calls — ViewBinding migration opportunity

Finding #17 — CreateUserActivity

View Binding Migration Opportunity
Class: com.cometchat.javasampleapp.activity.CreateUserActivity
Type: Activity
Current Pattern: Manual view lookup
findViewById() Calls:
  • findViewById in setUpUI
  • findViewById in setUpUI
  • findViewById in setUpUI
  • findViewById in setUpUI
  • findViewById in onCreate
  • findViewById in onCreate
  • findViewById in onCreate
  • findViewById in onCreate
  • findViewById in onCreate
Benefits of View Binding:
- Eliminates boilerplate findViewById() calls
- Compile-time type safety for view references
- Reduced null pointer exceptions
- Cleaner, more maintainable code
Note: This is a code modernization suggestion, not a memory leak

Finding #18 — LoginActivity

View Binding Migration Opportunity
Class: com.cometchat.javasampleapp.activity.LoginActivity
Type: Activity
Current Pattern: Manual view lookup
findViewById() Calls:
  • findViewById in setUpUI
  • findViewById in setUpUI
  • findViewById in setUpUI
  • findViewById in setUpUI
  • findViewById in lambda$onCreate$1$com-cometchat-javasampleapp-activity-LoginActivity
  • findViewById in onCreate
  • findViewById in onCreate
  • findViewById in onCreate
  • findViewById in onCreate
  • findViewById in onCreate
Benefits of View Binding:
- Eliminates boilerplate findViewById() calls
- Compile-time type safety for view references
- Reduced null pointer exceptions
- Cleaner, more maintainable code
Note: This is a code modernization suggestion, not a memory leak

Finding #19 — ComponentListActivity

View Binding Migration Opportunity
Class: com.cometchat.javasampleapp.activity.ComponentListActivity
Type: Activity
Current Pattern: Manual view lookup
findViewById() Calls:
  • findViewById in setUpUI
  • findViewById in setUpUI
  • findViewById in setUpUI
  • findViewById in setUpUI
  • findViewById in setUpUI
  • findViewById in setUpUI
  • findViewById in setUpUI
  • findViewById in setUpUI
  • findViewById in setUpUI
  • findViewById in setUpUI
  • findViewById in setUpUI
  • findViewById in setUpUI
  • findViewById in setUpUI
  • findViewById in setUpUI
  • findViewById in setUpUI
  • findViewById in setUpUI
  • findViewById in setUpUI
  • findViewById in setUpUI
  • findViewById in setUpUI
  • findViewById in setUpUI
  • findViewById in setUpUI
  • findViewById in setUpUI
  • findViewById in setUpUI
  • findViewById in setUpUI
  • findViewById in setUpUI
  • findViewById in setUpUI
  • findViewById in setUpUI
  • findViewBy
… (truncated for brevity)

Finding #20 — HomeActivity

View Binding Migration Opportunity
Class: com.cometchat.javasampleapp.activity.HomeActivity
Type: Activity
Current Pattern: Manual view lookup
findViewById() Calls:
  • findViewById in onCreate
  • findViewById in onCreate
  • findViewById in onCreate
  • findViewById in onCreate
  • findViewById in onCreate
  • findViewById in onCreate
  • findViewById in onCreate
  • findViewById in onCreate
  • findViewById in onCreate
  • findViewById in onCreate
Benefits of View Binding:
- Eliminates boilerplate findViewById() calls
- Compile-time type safety for view references
- Reduced null pointer exceptions
- Cleaner, more maintainable code
Note: This is a code modernization suggestion, not a memory leak

Finding #21 — MainActivity

View Binding Migration Opportunity
Class: com.cometchat.javasampleapp.activity.MainActivity
Type: Activity
Current Pattern: Manual view lookup
findViewById() Calls:
  • findViewById in lambda$onCreate$1$com-cometchat-javasampleapp-activity-MainActivity
  • findViewById in lambda$onCreate$2$com-cometchat-javasampleapp-activity-MainActivity
  • findViewById in lambda$onCreate$3$com-cometchat-javasampleapp-activity-MainActivity
  • findViewById in lambda$onCreate$4$com-cometchat-javasampleapp-activity-MainActivity
  • findViewById in onCreate
  • findViewById in onCreate
  • findViewById in onCreate
  • findViewById in onCreate
  • findViewById in onCreate
  • findViewById in onCreate
  • findViewById in onCreate
  • findViewById in onCreate
  • findViewById in onCreate
  • findViewById in onCreate
  • findViewById in onCreate
  • findViewById in onCreate
  • findViewById in onCreate
  • findViewById in onCreate
  • findViewById in onCreate
  • find
… (truncated for brevity)

Finding #22 — ComponentLaunchActivity

View Binding Migration Opportunity
Class: com.cometchat.javasampleapp.activity.ComponentLaunchActivity
Type: Activity
Current Pattern: Manual view lookup
findViewById() Calls:
  • findViewById in onCreate
Benefits of View Binding:
- Eliminates boilerplate findViewById() calls
- Compile-time type safety for view references
- Reduced null pointer exceptions
- Cleaner, more maintainable code
Note: This is a code modernization suggestion, not a memory leak

---

How to respond to this issue:

• If a finding is a true positive: consider applying the recommended fix and closing this issue.
• If a finding is a false positive: please leave a comment explaining why — your feedback directly improves our research.
• If you have questions: reply here or open a discussion.

This report was generated by LeakScope as part of the ICSE 2027 research artifact. Tool analyzes compiled APKs using Soot static analysis on cometchat-sample-app-android-java.

[cometchat-helpcenter-bot]

Hritika (CometChat Team) replied:

Hello,

We are currently looking into the query you have raised, please allow us some time. We will get back to you once we have an update.

We appreciate your patience.

Regards,

Hritika Naik
Sign up for service and maintenance updates.
CometChat