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

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

Detector	Count	Severity	Description
FragmentViewFieldRetentionLeak	11	🔴 High	Fragment stores View references in instance fields not cleared in onDestroyView()
StateHolderLeak	4	🔴 High	Static field holds UI/Context reference across configuration changes
ThreadedUIReference	1	🔴 High	Worker thread captures Activity/Fragment/View reference
ViewBindingOpportunity	15	🟢 Low	Manual findViewById() calls — ViewBinding migration opportunity

---

Detailed Findings

🔴 FragmentViewFieldRetentionLeak

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

Finding #1 — ToolsFragment

Fragment View Field Retention Leak Detected
Class: com.ds.avare.ToolsFragment

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

- onDestroyView() does not clear all View fields

Leaked Fields:
  • mSatelliteView : com.ds.avare.views.SatelliteView (assigned in onCreateView)
  • mGpsText : android.widget.TextView (assigned in onCreateView)
  • mMemView : com.ds.avare.views.MemView (assigned in onCreateView)
  • mMemText : android.widget.TextView (assigned in onCreateView)
  • mMapAreaText : android.widget.TextView (assigned in onCreateView)
  • mProgressBarExport : android.widget.ProgressBar (assigned in onCreateView)
  • mProgressBarImport : android.widget.ProgressBar (assigned in onCreateView)
  • mProgressBarDelete : android.widget.ProgressBar (assigned in onCreateView)
  • mSpinnerTypeExport : android.widget.Spinner (assigned in onCreateView)
  • mSpinnerTypeDelete : android.widget.Spinner (assi
… (truncated for brevity)

Finding #2 — BlueToothInFragment

Fragment View Field Retention Leak Detected
Class: com.ds.avare.BlueToothInFragment

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

- onDestroyView() does not clear all View fields

Leaked Fields:
  • mSpinner : android.widget.Spinner (assigned in onCreateView)
  • mTextFileSave : com.ds.avare.storage.SavedEditText (assigned in onCreateView)
  • mSecureCb : com.ds.avare.storage.SavedCheckbox (assigned in onCreateView)
  • mConnectButton : android.widget.Button (assigned in onCreateView)
  • mConnectFileSaveButton : android.widget.Button (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
  pub
… (truncated for brevity)

Finding #3 — WiFiInFragment

Fragment View Field Retention Leak Detected
Class: com.ds.avare.WiFiInFragment

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

- onDestroyView() does not clear all View fields

Leaked Fields:
  • mTextFileSave : com.ds.avare.storage.SavedEditText (assigned in onCreateView)
  • mWifiCb : android.widget.CheckBox (assigned in onCreateView)
  • mTextWifiPort : com.ds.avare.storage.SavedEditText (assigned in onCreateView)
  • mConnectFileSaveButton : android.widget.Button (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();
    mTextFileSave =
… (truncated for brevity)

Finding #4 — XplaneFragment

Fragment View Field Retention Leak Detected
Class: com.ds.avare.XplaneFragment

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

- onDestroyView() does not clear all View fields

Leaked Fields:
  • mTextXplaneIp : android.widget.TextView (assigned in onCreateView)
  • mTextXplanePort : com.ds.avare.storage.SavedEditText (assigned in onCreateView)
  • mXplaneCb : android.widget.CheckBox (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();
    mTextXplaneIp = null;
    mTextXplanePort = null;
    mXplaneCb = null;
  }

Finding #5 — USBInFragment

Fragment View Field Retention Leak Detected
Class: com.ds.avare.USBInFragment

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

- onDestroyView() does not clear all View fields

Leaked Fields:
  • mParamsText : com.ds.avare.storage.SavedEditText (assigned in onCreateView)
  • mTextFileSave : com.ds.avare.storage.SavedEditText (assigned in onCreateView)
  • mConnectButton : android.widget.Button (assigned in onCreateView)
  • mConnectFileSaveButton : android.widget.Button (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();
    mParamsText =
… (truncated for brevity)

Finding #6 — MsfsFragment

Fragment View Field Retention Leak Detected
Class: com.ds.avare.MsfsFragment

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

- onDestroyView() does not clear all View fields

Leaked Fields:
  • mTextMsfsIp : android.widget.TextView (assigned in onCreateView)
  • mTextMsfsPort : com.ds.avare.storage.SavedEditText (assigned in onCreateView)
  • mMsfsCb : android.widget.CheckBox (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();
    mTextMsfsIp = null;
    mTextMsfsPort = null;
    mMsfsCb = null;
  }

Finding #7 — USBOutFragment

Fragment View Field Retention Leak Detected
Class: com.ds.avare.USBOutFragment

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

- onDestroyView() does not clear all View fields

Leaked Fields:
  • mParamsText : com.ds.avare.storage.SavedEditText (assigned in onCreateView)
  • mConnectButton : android.widget.Button (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();
    mParamsText = null;
    mConnectButton = null;
  }

Finding #8 — FileFragment

Fragment View Field Retention Leak Detected
Class: com.ds.avare.FileFragment

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

- onDestroyView() does not clear all View fields

Leaked Fields:
  • mTextFile : com.ds.avare.storage.SavedEditText (assigned in onCreateView)
  • mConnectButton : android.widget.Button (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();
    mTextFile = null;
    mConnectButton = null;
  }

Finding #9 — BlueToothOutFragment

Fragment View Field Retention Leak Detected
Class: com.ds.avare.BlueToothOutFragment

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

- onDestroyView() does not clear all View fields

Leaked Fields:
  • mSpinner : android.widget.Spinner (assigned in onCreateView)
  • mSecureCb : com.ds.avare.storage.SavedCheckbox (assigned in onCreateView)
  • mConnectButton : android.widget.Button (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();
    mSpinner = null;
    mSecureCb = null;
    mConnectButton = null;
  }

Finding #10 — GPSSimulatorFragment

Fragment View Field Retention Leak Detected
Class: com.ds.avare.GPSSimulatorFragment

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

- onDestroyView() does not clear all View fields

Leaked Fields:
  • mLandAtCb : com.ds.avare.storage.SavedCheckbox (assigned in onCreateView)
  • mFlyToCb : com.ds.avare.storage.SavedCheckbox (assigned in onCreateView)
  • mTextLon : com.ds.avare.storage.SavedEditText (assigned in onCreateView)
  • mTextLat : com.ds.avare.storage.SavedEditText (assigned in onCreateView)
  • mTextAltitude : com.ds.avare.storage.SavedEditText (assigned in onCreateView)
  • mTextSpeed : com.ds.avare.storage.SavedEditText (assigned in onCreateView)
  • mTextHeading : com.ds.avare.storage.SavedEditText (assigned in onCreateView)
  • mButtonStart : android.widget.Button (assigned in onCreateView)

Why this is dangerous:
- Fragment views are destroyed/recreated on config changes
- Retained V
… (truncated for brevity)

Finding #11 — Dump1090Fragment

Fragment View Field Retention Leak Detected
Class: com.ds.avare.Dump1090Fragment

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

- onDestroyView() does not clear all View fields

Leaked Fields:
  • mIpAddress : com.ds.avare.storage.SavedEditText (assigned in onCreateView)
  • mConState : android.widget.CheckBox (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();
    mIpAddress = null;
    mConState = null;
  }

🔴 StateHolderLeak

Static field holds UI/Context reference across configuration changes

Finding #12 — BlueToothInFragment

Potential State Holder Memory Leak Detected
Class: com.ds.avare.BlueToothInFragment
Issue: Scenario 2: Static field 'mBt' of type 'com.ds.avare.connections.Connection' in Activity/Fragment is a custom object that may hold UI references. Static fields survive configuration changes.
Fix: Use ViewModel or SavedStateHandle to persist state across rotations.

Finding #13 — LocationActivity

Potential State Holder Memory Leak Detected
Class: com.ds.avare.LocationActivity
Issue: Scenario 2: Static field 'mConnectionTask' of type 'android.os.AsyncTask' in Activity/Fragment survives configuration changes. Async operations may hold a reference to the old UI instance.
Fix: Use instance field instead. Cancel/dispose in onDestroy().

Finding #14 — RegisterActivity

Potential State Holder Memory Leak Detected
Class: com.ds.avare.RegisterActivity
Issue: Scenario 2: Static field 'mRegisterTask' of type 'android.os.AsyncTask' in Activity/Fragment survives configuration changes. Async operations may hold a reference to the old UI instance.
Fix: Use instance field instead. Cancel/dispose in onDestroy().

Finding #15 — ChartsDownloadActivity

Potential State Holder Memory Leak Detected
Class: com.ds.avare.ChartsDownloadActivity
Issue: Scenario 2: Static field 'mChartAdapter' of type 'com.ds.avare.adapters.ChartAdapter' in Activity/Fragment is a custom object that may hold UI references. Static fields survive configuration changes.
Fix: Use ViewModel or SavedStateHandle to persist state across rotations.

🔴 ThreadedUIReference

Worker thread captures Activity/Fragment/View reference

Finding #16 — ToolsFragment\n// (Full source code omitted for brevity)\n"

{
  "text_input": "package com.ds.avare;\n\n// Class: com.ds.avare.ToolsFragment\n// (Full source code omitted for brevity)\n",
  "output": "Yes",
  "project": "avare",
  "explanation": "Scenario 1: Worker thread holds UI object reference\nClass: com.ds.avare.ToolsFragment\nMethod: void onActivityResult(int,int,android.content.Intent)\nStatement: $r8 \u003d new com.ds.avare.ToolsFragment$ExportTask\nCaptured UI objects:\n  - r0 : com.ds.avare.ToolsFragment\nRisk: UI object will be kept in memory until thread completes\nFix: Use WeakReference or avoid passing UI objects to worker threads\n"
}
{
  "text_input": "package com.ds.avare;\n\n// Class: com.ds.avare.ToolsFragment\n// (Full source code omitted for brevity)\n",
  "output": "Yes",
  "project": "avare",
  "explanation": "Scenario 1: Worker thread holds UI object reference\nClass: com.ds.avare.ToolsFragment\nMethod: void onActivityResult(int,int,android.content.Intent)\nStatement: $r9 \u003d new com.ds.avare.ToolsFragment$ImportTask
… (truncated for brevity)

🟢 ViewBindingOpportunity

Manual findViewById() calls — ViewBinding migration opportunity

Finding #17 — WebActivity

View Binding Migration Opportunity
Class: com.ds.avare.WebActivity
Type: Activity
Current Pattern: Manual view lookup
findViewById() Calls:
  • 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 — NearestActivity

View Binding Migration Opportunity
Class: com.ds.avare.NearestActivity
Type: Activity
Current Pattern: Manual view lookup
findViewById() Calls:
  • 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 — ThreeDActivity

View Binding Migration Opportunity
Class: com.ds.avare.ThreeDActivity
Type: Activity
Current Pattern: Manual view lookup
findViewById() Calls:
  • 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 #20 — SearchActivity

View Binding Migration Opportunity
Class: com.ds.avare.SearchActivity
Type: Activity
Current Pattern: Manual view lookup
findViewById() Calls:
  • 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 — PfdActivity

View Binding Migration Opportunity
Class: com.ds.avare.PfdActivity
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

Finding #22 — PlanActivity

View Binding Migration Opportunity
Class: com.ds.avare.PlanActivity
Type: Activity
Current Pattern: Manual view lookup
findViewById() Calls:
  • 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 #23 — LocationActivity

View Binding Migration Opportunity
Class: com.ds.avare.LocationActivity
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
  • 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 #24 — PlatesActivity

View Binding Migration Opportunity
Class: com.ds.avare.PlatesActivity
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
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 #25 — IOActivity

View Binding Migration Opportunity
Class: com.ds.avare.IOActivity
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 #26 — RegisterActivity

View Binding Migration Opportunity
Class: com.ds.avare.RegisterActivity
Type: Activity
Current Pattern: Manual view lookup
findViewById() Calls:
  • 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 #27 — PlatesTagActivity

View Binding Migration Opportunity
Class: com.ds.avare.PlatesTagActivity
Type: Activity
Current Pattern: Manual view lookup
findViewById() Calls:
  • findViewById in tag
  • findViewById in tag
  • findViewById in tag
  • findViewById in tag
  • findViewById in verify
  • findViewById in verify
  • findViewById in verify
  • findViewById in verify
  • 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 #28 — ChartsDownloadActivity

View Binding Migration Opportunity
Class: com.ds.avare.ChartsDownloadActivity
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
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 #29 — AircraftActivity

View Binding Migration Opportunity
Class: com.ds.avare.AircraftActivity
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 #30 — AirportActivity

View Binding Migration Opportunity
Class: com.ds.avare.AirportActivity
Type: Activity
Current Pattern: Manual view lookup
findViewById() Calls:
  • 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 #31 — MainActivity

View Binding Migration Opportunity
Class: com.ds.avare.MainActivity
Type: Activity
Current Pattern: Manual view lookup
findViewById() Calls:
  • findViewById in createTabView
  • 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

---

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 avare.