[LeakScope] 19 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 19 potential issue(s) across 3 detector type(s):

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

Detector	Count	Severity	Description
FragmentViewFieldRetentionLeak	10	🔴 High	Fragment stores View references in instance fields not cleared in onDestroyView()
StateHolderLeak	3	🔴 High	Static field holds UI/Context reference across configuration changes
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 — CategoryFragment

Fragment View Field Retention Leak Detected
Class: com.quintus.labs.grocerystore.fragment.CategoryFragment

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

- onDestroyView() is missing

Leaked Fields:
  • recyclerView : androidx.recyclerview.widget.RecyclerView (assigned in onCreateView)
  • progress : android.view.View (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();
    recyclerView = null;
    progress = null;
  }

Finding #2 — OffrersFragment

Fragment View Field Retention Leak Detected
Class: com.quintus.labs.grocerystore.fragment.OffrersFragment

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

- onDestroyView() is missing

Leaked Fields:
  • recyclerView : androidx.recyclerview.widget.RecyclerView (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();
    recyclerView = null;
  }

Finding #3 — NewProductFragment

Fragment View Field Retention Leak Detected
Class: com.quintus.labs.grocerystore.fragment.NewProductFragment

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

- onDestroyView() is missing

Leaked Fields:
  • nRecyclerView : androidx.recyclerview.widget.RecyclerView (assigned in onCreateView)
  • progress : android.view.View (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();
    nRecyclerView = null;
    progress = null;
  }

Finding #4 — ProfileFragment

Fragment View Field Retention Leak Detected
Class: com.quintus.labs.grocerystore.fragment.ProfileFragment

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

- onDestroyView() is missing

Leaked Fields:
  • name : android.widget.TextView (assigned in onCreateView)
  • email : android.widget.TextView (assigned in onCreateView)
  • mobile : android.widget.TextView (assigned in onCreateView)
  • address : android.widget.TextView (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();
    name = null;
    email = null;
    mobile = null;
    address
… (truncated for brevity)

Finding #5 — HomeFragment

Fragment View Field Retention Leak Detected
Class: com.quintus.labs.grocerystore.fragment.HomeFragment

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

- onDestroyView() is missing

Leaked Fields:
  • recyclerView : androidx.recyclerview.widget.RecyclerView (assigned in onCreateView)
  • pRecyclerView : androidx.recyclerview.widget.RecyclerView (assigned in onCreateView)
  • nRecyclerView : androidx.recyclerview.widget.RecyclerView (assigned in onCreateView)
  • progress : android.view.View (assigned in onCreateView)
  • viewPager : androidx.viewpager.widget.ViewPager (assigned in onCreateView)
  • sliderDotspanel : 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 Fragmen
… (truncated for brevity)

Finding #6 — PaymentFragment

Fragment View Field Retention Leak Detected
Class: com.quintus.labs.grocerystore.fragment.PaymentFragment

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

- onDestroyView() is missing

Leaked Fields:
  • paymentGroup : android.widget.RadioGroup (assigned in onCreateView)
  • card : android.widget.RadioButton (assigned in onCreateView)
  • cash : android.widget.RadioButton (assigned in onCreateView)
  • cardFrame : android.widget.FrameLayout (assigned in onCreateView)
  • payll : android.widget.LinearLayout (assigned in onCreateView)
  • pay : android.widget.TextView (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/Bi
… (truncated for brevity)

Finding #7 — AddressFragment

Fragment View Field Retention Leak Detected
Class: com.quintus.labs.grocerystore.fragment.AddressFragment

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

- onDestroyView() is missing

Leaked Fields:
  • citySpinner : android.widget.Spinner (assigned in onCreateView)
  • stateSpinner : android.widget.Spinner (assigned in onCreateView)
  • name : android.widget.EditText (assigned in onCreateView)
  • email : android.widget.EditText (assigned in onCreateView)
  • mobile : android.widget.EditText (assigned in onCreateView)
  • address : android.widget.EditText (assigned in onCreateView)
  • zip : android.widget.EditText (assigned in onCreateView)
  • progress : android.view.View (assigned in onCreateView)
  • txt_pyment : android.widget.TextView (assigned in onCreateView)

Why this is dangerous:
- Fragment views are destroyed/recreated on config changes
- Retained View references prevent garbage colle
… (truncated for brevity)

Finding #8 — ConfirmFragment

Fragment View Field Retention Leak Detected
Class: com.quintus.labs.grocerystore.fragment.ConfirmFragment

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

- onDestroyView() is missing

Leaked Fields:
  • recyclerView : androidx.recyclerview.widget.RecyclerView (assigned in onCreateView)
  • totalAmount : android.widget.TextView (assigned in onCreateView)
  • total : android.widget.TextView (assigned in onCreateView)
  • shipping : android.widget.TextView (assigned in onCreateView)
  • back : android.widget.TextView (assigned in onCreateView)
  • order : android.widget.TextView (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 
… (truncated for brevity)

Finding #9 — MyOrderFragment

Fragment View Field Retention Leak Detected
Class: com.quintus.labs.grocerystore.fragment.MyOrderFragment

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

- onDestroyView() is missing

Leaked Fields:
  • recyclerView : androidx.recyclerview.widget.RecyclerView (assigned in onCreateView)
  • linearLayout : 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();
    recyclerView = null;
    linearLayout = null;
  }

Finding #10 — PopularProductFragment

Fragment View Field Retention Leak Detected
Class: com.quintus.labs.grocerystore.fragment.PopularProductFragment

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

- onDestroyView() is missing

Leaked Fields:
  • pRecyclerView : androidx.recyclerview.widget.RecyclerView (assigned in onCreateView)
  • progress : android.view.View (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();
    pRecyclerView = null;
    progress = null;
  }

🔴 StateHolderLeak

Static field holds UI/Context reference across configuration changes

Finding #11 — ForgotPassword_Fragment

Potential State Holder Memory Leak Detected
Class: com.quintus.labs.grocerystore.fragment.ForgotPassword_Fragment
Issue: Scenario 2: Static field 'back' of type 'android.widget.TextView' in Activity/Fragment directly holds a UI reference across rotations. Old UI cannot be garbage collected.
Fix: Use instance field instead. Set to null in onDestroy().

Potential State Holder Memory Leak Detected
Class: com.quintus.labs.grocerystore.fragment.ForgotPassword_Fragment
Issue: Scenario 2: Static field 'code' of type 'android.widget.EditText' in Activity/Fragment directly holds a UI reference across rotations. Old UI cannot be garbage collected.
Fix: Use instance field instead. Set to null in onDestroy().

Potential State Holder Memory Leak Detected
Class: com.quintus.labs.grocerystore.fragment.ForgotPassword_Fragment
Issue: Scenario 2: Static field 'confirm_password' of type 'android.widget.EditText' in Activity/Fragment directly holds a UI reference across rotations. Old UI cannot be garbage
… (truncated for brevity)

Finding #12 — LoginFragment

Potential State Holder Memory Leak Detected
Class: com.quintus.labs.grocerystore.fragment.LoginFragment
Issue: Scenario 2: Static field 'forgotPassword' of type 'android.widget.TextView' in Activity/Fragment directly holds a UI reference across rotations. Old UI cannot be garbage collected.
Fix: Use instance field instead. Set to null in onDestroy().

Potential State Holder Memory Leak Detected
Class: com.quintus.labs.grocerystore.fragment.LoginFragment
Issue: Scenario 2: Static field 'loginButton' of type 'android.widget.Button' in Activity/Fragment directly holds a UI reference across rotations. Old UI cannot be garbage collected.
Fix: Use instance field instead. Set to null in onDestroy().

Potential State Holder Memory Leak Detected
Class: com.quintus.labs.grocerystore.fragment.LoginFragment
Issue: Scenario 2: Static field 'loginLayout' of type 'android.widget.LinearLayout' in Activity/Fragment directly holds a UI reference across rotations. Old UI cannot be garbage collected.
Fix:
… (truncated for brevity)

Finding #13 — SignUpFragment

Potential State Holder Memory Leak Detected
Class: com.quintus.labs.grocerystore.fragment.SignUpFragment
Issue: Scenario 2: Static field 'fullName' of type 'android.widget.EditText' in Activity/Fragment directly holds a UI reference across rotations. Old UI cannot be garbage collected.
Fix: Use instance field instead. Set to null in onDestroy().

Potential State Holder Memory Leak Detected
Class: com.quintus.labs.grocerystore.fragment.SignUpFragment
Issue: Scenario 2: Static field 'login' of type 'android.widget.TextView' in Activity/Fragment directly holds a UI reference across rotations. Old UI cannot be garbage collected.
Fix: Use instance field instead. Set to null in onDestroy().

Potential State Holder Memory Leak Detected
Class: com.quintus.labs.grocerystore.fragment.SignUpFragment
Issue: Scenario 2: Static field 'mobileNumber' of type 'android.widget.EditText' in Activity/Fragment directly holds a UI reference across rotations. Old UI cannot be garbage collected.
Fix: Use insta
… (truncated for brevity)

🟢 ViewBindingOpportunity

Manual findViewById() calls — ViewBinding migration opportunity

Finding #14 — CartActivity

View Binding Migration Opportunity
Class: com.quintus.labs.grocerystore.activity.CartActivity
Type: Activity
Current Pattern: Manual view lookup
findViewById() Calls:
  • findViewById in setUpCartRecyclerview
  • 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 #15 — ProductActivity

View Binding Migration Opportunity
Class: com.quintus.labs.grocerystore.activity.ProductActivity
Type: Activity
Current Pattern: Manual view lookup
findViewById() Calls:
  • 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 #16 — WelcomeActivity

View Binding Migration Opportunity
Class: com.quintus.labs.grocerystore.activity.WelcomeActivity
Type: Activity
Current Pattern: Manual view lookup
findViewById() Calls:
  • 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 #17 — MainActivity

View Binding Migration Opportunity
Class: com.quintus.labs.grocerystore.activity.MainActivity
Type: Activity
Current Pattern: Manual view lookup
findViewById() Calls:
  • findViewById in displaySelectedScreen
  • findViewById in onBackPressed
  • findViewById in onCreate
  • findViewById in onCreate
  • findViewById in onCreate
  • findViewById in onCreate
  • findViewById in onCreate
  • findViewById in onCreate
  • findViewById in onCreate
  • findViewById in onCreateOptionsMenu
  • findViewById in onCreateOptionsMenu
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 — ProductViewActivity

View Binding Migration Opportunity
Class: com.quintus.labs.grocerystore.activity.ProductViewActivity
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
  • 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 — LoginRegisterActivity

View Binding Migration Opportunity
Class: com.quintus.labs.grocerystore.activity.LoginRegisterActivity
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 GroceryStore-with-server.