[LeakScope] 21 Android lifecycle/memory violations detected

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 21 potential issue(s) across 5 detector type(s):

Severity	Count
🔴 High	11
🟡 Medium	3
🟢 Low (improvement opportunity)	7

Detector	Count	Severity	Description
FlowRetentionLeak	1	🔴 High	Kotlin Flow collected in GlobalScope — causes retention leaks on lifecycle events
FragmentViewFieldRetentionLeak	4	🔴 High	Fragment stores View references in instance fields not cleared in onDestroyView()
ThreadedUIReference	6	🔴 High	Worker thread captures Activity/Fragment/View reference
ServiceResourceManagementIssueDetector	3	🟡 Medium	Service may never stop — missing stopSelf() call
ViewBindingOpportunity	7	🟢 Low	Manual findViewById() calls — ViewBinding migration opportunity

---

Detailed Findings

🔴 FlowRetentionLeak

Kotlin Flow collected in GlobalScope — causes retention leaks on lifecycle events

Finding #1 — MainActivity

Potential Flow Retention Memory Leak Detected
Class: com.amaze.filemanager.ui.activities.MainActivity
Source File: MainActivity.java
Issue: Flow collection not properly scoped to Activity lifecycle
Location: Method org.reactivestreams.Publisher lambda$showSftpDialog$22(java.lang.String,java.lang.String,boolean,com.amaze.filemanager.filesystem.ftp.NetCopyConnectionInfo)
Affected Flow variables:
  - $r9 : io.reactivex.Flowable
Recommendations:
- Use lifecycleScope.launch { } for Flow collection
- Use repeatOnLifecycle(Lifecycle.State.STARTED) { } for safer Flow collection
- Ensure Flow collection is cancelled in onDestroy or when the Activity is destroyed
- Consider using viewModelScope for ViewModel-scoped flows
Potential Flow Retention Memory Leak Detected
Class: com.amaze.filemanager.ui.activities.MainActivity
Source File: MainActivity.java
Issue: Flow collection not properly scoped to Activity lifecycle
Location: Method void addConnection(boolean,java.lang.String,ja
… (truncated for brevity)

🔴 FragmentViewFieldRetentionLeak

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

Finding #2 — DbViewerFragment

Fragment View Field Retention Leak Detected
Class: com.amaze.filemanager.ui.fragments.DbViewerFragment

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

- onDestroyView() is missing

Leaked Fields:
  • rootView : android.view.View (assigned in onCreateView)
  • webView : android.webkit.WebView (assigned in onCreateView)
  • loadingText : androidx.appcompat.widget.AppCompatTextView (assigned in onCreateView)
  • relativeLayout : 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();
    rootView = null;
    webVie
… (truncated for brevity)

Finding #3 — TabFragment

Fragment View Field Retention Leak Detected
Class: com.amaze.filemanager.ui.fragments.TabFragment

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:
  • rootView : android.view.ViewGroup (assigned in onCreateView)
  • dragPlaceholder : androidx.constraintlayout.widget.ConstraintLayout (assigned in onCreateView)
  • viewPager : androidx.viewpager2.widget.ViewPager2 (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();
    rootView = null;
    dragPlaceholder = null;
    viewPager =
… (truncated for brevity)

Finding #4 — MainFragment

Fragment View Field Retention Leak Detected
Class: com.amaze.filemanager.ui.fragments.MainFragment

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

- onDestroyView() is missing

Leaked Fields:
  • rootView : android.view.View (assigned in onCreateView)
  • listView : androidx.recyclerview.widget.RecyclerView (assigned in onViewCreated)
  • fastScroller : com.amaze.filemanager.ui.views.FastScroller (assigned in onViewCreated)
  • mSwipeRefreshLayout : androidx.swiperefreshlayout.widget.SwipeRefreshLayout (assigned in onViewCreated)

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
… (truncated for brevity)

Finding #5 — AppsListFragment

Fragment View Field Retention Leak Detected
Class: com.amaze.filemanager.ui.fragments.AppsListFragment

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

- onDestroyView() is missing

Leaked Fields:
  • rootView : android.view.View (assigned in onCreateView)
  • fastScroller : com.amaze.filemanager.ui.views.FastScroller (assigned in onViewCreated)

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();
    rootView = null;
    fastScroller = null;
  }

🔴 ThreadedUIReference

Worker thread captures Activity/Fragment/View reference

Finding #6 — DatabaseViewerActivity\n// (Full source code omitted for brevity)\n"

{
  "text_input": "package com.amaze.filemanager.ui.activities;\n\n// Class: com.amaze.filemanager.ui.activities.DatabaseViewerActivity\n// (Full source code omitted for brevity)\n",
  "output": "Yes",
  "project": "filemanager",
  "explanation": "Scenario 1: Worker thread holds UI object reference\nClass: com.amaze.filemanager.ui.activities.DatabaseViewerActivity\nMethod: void load(java.io.File)\nStatement: $r2 \u003d new java.lang.Thread\nCaptured UI objects:\n  - r0 : com.amaze.filemanager.ui.activities.DatabaseViewerActivity\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.amaze.filemanager.ui.activities;\n\n// Class: com.amaze.filemanager.ui.activities.DatabaseViewerActivity\n// (Full source code omitted for brevity)\n",
  "output": "Yes",
  "project": "filemanager",
  "explanation": "Scenario 1: Worker thread holds UI object reference\nClass: com.amaze.filemanag
… (truncated for brevity)

Finding #7 — MainActivity

Scenario 1: Worker thread holds UI object reference
Class: com.amaze.filemanager.ui.activities.MainActivity
Method: java.lang.Void lambda$onActivityResult$14(com.amaze.filemanager.ui.fragments.MainFragment)
Statement: r19 = new com.amaze.filemanager.asynchronous.asynctasks.DeleteTask
Captured UI objects:
  - $r2 : com.amaze.filemanager.ui.activities.MainActivity
Risk: UI object will be kept in memory until thread completes
Fix: Use WeakReference or avoid passing UI objects to worker threads

Finding #8 — AboutActivity

Scenario 1: Worker thread holds UI object reference
Class: com.amaze.filemanager.ui.activities.AboutActivity
Method: void onClick(android.view.View)
Statement: $r2 = new com.amaze.filemanager.ui.dialogs.share.ShareTask
Captured UI objects:
  - r0 : com.amaze.filemanager.ui.activities.AboutActivity
Risk: UI object will be kept in memory until thread completes
Fix: Use WeakReference or avoid passing UI objects to worker threads

Finding #9 — MainActivityHelper\n// (Full source code omitted for brevity)\n"

{
  "text_input": "package com.amaze.filemanager.utils;\n\n// Class: com.amaze.filemanager.utils.MainActivityHelper\n// (Full source code omitted for brevity)\n",
  "output": "Yes",
  "project": "filemanager",
  "explanation": "Scenario 1: Worker thread holds UI object reference\nClass: com.amaze.filemanager.utils.MainActivityHelper\nMethod: void deleteFiles(java.util.ArrayList,boolean)\nStatement: $r8 \u003d new com.amaze.filemanager.asynchronous.asynctasks.DeleteTask\nCaptured UI objects:\n  - $r4 : com.amaze.filemanager.ui.activities.MainActivity\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.amaze.filemanager.utils;\n\n// Class: com.amaze.filemanager.utils.MainActivityHelper\n// (Full source code omitted for brevity)\n",
  "output": "Yes",
  "project": "filemanager",
  "explanation": "Scenario 1: Worker thread holds UI object reference\nClass: com.amaze.filemana
… (truncated for brevity)

Finding #10 — DbViewerFragment

Scenario 1: Worker thread holds UI object reference
Class: com.amaze.filemanager.ui.fragments.DbViewerFragment
Method: android.view.View onCreateView(android.view.LayoutInflater,android.view.ViewGroup,android.os.Bundle)
Statement: $r14 = new com.amaze.filemanager.asynchronous.asynctasks.DbViewerTask
Captured UI objects:
  - $r7 : android.webkit.WebView
  - r0 : com.amaze.filemanager.ui.fragments.DbViewerFragment
Risk: UI object will be kept in memory until thread completes
Fix: Use WeakReference or avoid passing UI objects to worker threads

Finding #11 — MainFragment\n// (Full source code omitted for brevity)\n"

{
  "text_input": "package com.amaze.filemanager.ui.fragments;\n\n// Class: com.amaze.filemanager.ui.fragments.MainFragment\n// (Full source code omitted for brevity)\n",
  "output": "Yes",
  "project": "filemanager",
  "explanation": "Scenario 1: Worker thread holds UI object reference\nClass: com.amaze.filemanager.ui.fragments.MainFragment\nMethod: void resumeDecryptOperations()\nStatement: $r6 \u003d new com.amaze.filemanager.asynchronous.asynctasks.DeleteTask\nCaptured UI objects:\n  - $r1 : com.amaze.filemanager.ui.activities.MainActivity\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.amaze.filemanager.ui.fragments;\n\n// Class: com.amaze.filemanager.ui.fragments.MainFragment\n// (Full source code omitted for brevity)\n",
  "output": "Yes",
  "project": "filemanager",
  "explanation": "Scenario 1: Worker thread holds UI object reference\nClass: com.amaze.filema
… (truncated for brevity)

🟡 ServiceResourceManagementIssueDetector

Service may never stop — missing stopSelf() call

Finding #12 — CopyService

ℹ� Best Practice: Service relies on stopSelf(). For robustness, also call stopForeground(true) in onDestroy().
  Class: com.amaze.filemanager.asynchronous.services.CopyService
  Method: N/A

Finding #13 — DecryptService

⚠� Service may never stop. Consider calling stopSelf() when work is complete.
  Class: com.amaze.filemanager.asynchronous.services.DecryptService
  Method: onStartCommand
⚠� Foreground service started but never removed (missing stopForeground() / stopSelf()).
  Class: com.amaze.filemanager.asynchronous.services.DecryptService
  Method: N/A

Finding #14 — EncryptService

⚠� Service may never stop. Consider calling stopSelf() when work is complete.
  Class: com.amaze.filemanager.asynchronous.services.EncryptService
  Method: onStartCommand
⚠� Foreground service started but never removed (missing stopForeground() / stopSelf()).
  Class: com.amaze.filemanager.asynchronous.services.EncryptService
  Method: N/A

🟢 ViewBindingOpportunity

Manual findViewById() calls — ViewBinding migration opportunity

Finding #15 — DatabaseViewerActivity

View Binding Migration Opportunity
Class: com.amaze.filemanager.ui.activities.DatabaseViewerActivity
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 #16 — MainActivity

View Binding Migration Opportunity
Class: com.amaze.filemanager.ui.activities.MainActivity
Type: Activity
Current Pattern: Manual view lookup
findViewById() Calls:
  • findViewById in initBottomDragListener
  • findViewById in initialiseFabConfirmSelection
  • findViewById in lambda$initializeFabActionViews$19
  • findViewById in lambda$initializeFabActionViews$19
  • findViewById in addConnection
  • findViewById in initialiseFab
  • findViewById in initialiseViews
  • findViewById in initialiseViews
  • findViewById in onCreate
  • findViewById in onPrepareOptionsMenu
  • findViewById in onPrepareOptionsMenu
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 — AboutActivity

View Binding Migration Opportunity
Class: com.amaze.filemanager.ui.activities.AboutActivity
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 #18 — PermissionsActivity

View Binding Migration Opportunity
Class: com.amaze.filemanager.ui.activities.superclasses.PermissionsActivity
Type: Activity
Current Pattern: Manual view lookup
findViewById() Calls:
  • findViewById in requestPermission
  • findViewById in requestPermission
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 — ThemedActivity

View Binding Migration Opportunity
Class: com.amaze.filemanager.ui.activities.superclasses.ThemedActivity
Type: Activity
Current Pattern: Manual view lookup
findViewById() Calls:
  • findViewById in getToolbar
  • findViewById in initStatusBarResources
  • findViewById in initStatusBarResources
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 — ErrorActivity

View Binding Migration Opportunity
Class: com.amaze.filemanager.crashreport.ErrorActivity
Type: Activity
Current Pattern: Manual view lookup
findViewById() Calls:
  • findViewById in addGuruMeditation
  • findViewById in buildInfo
  • findViewById in buildInfo
  • 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 — TextEditorActivity

View Binding Migration Opportunity
Class: com.amaze.filemanager.ui.activities.texteditor.TextEditorActivity
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
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 AmazeFileManager.

Start by reviewing the LeakScope findings against the named classes, including MainActivity.java, DbViewerFragment, TabFragment, MainFragment, AppsListFragment, DatabaseViewerActivity, AboutActivity, MainActivityHelper, and CopyService. The report is truncated and asks for feedback rather than specifying a confirmed fix; done would require validating which of the 21 findings are accurate and documenting or addressing the confirmed issues.