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 11 potential issue(s) across 3 detector type(s):
| Severity |
Count |
| 🔴 High |
11 |
| 🟡 Medium |
0 |
| 🟢 Low (improvement opportunity) |
0 |
| Detector |
Count |
Severity |
Description |
FragmentViewFieldRetentionLeak |
7 |
🔴 High |
Fragment stores View references in instance fields not cleared in onDestroyView() |
StateHolderLeak |
1 |
🔴 High |
Static field holds UI/Context reference across configuration changes |
ThreadedUIReference |
3 |
🔴 High |
Worker thread captures Activity/Fragment/View reference |
Detailed Findings
🔴 FragmentViewFieldRetentionLeak
Fragment stores View references in instance fields not cleared in onDestroyView()
Finding #1 — DirectoryBaseFragment
Fragment View Field Retention Leak Detected
Class: se.arctosoft.vault.DirectoryBaseFragment
Issue:
- Fragment stores View references in instance fields
- These fields are not cleared when the view is destroyed
- onDestroyView() is missing
Leaked Fields:
• binding : se.arctosoft.vault.databinding.FragmentDirectoryBinding (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();
binding = null;
}
Finding #2 — BottomSheetDeleteFragment
Fragment View Field Retention Leak Detected
Class: se.arctosoft.vault.BottomSheetDeleteFragment
Issue:
- Fragment stores View references in instance fields
- These fields are not cleared when the view is destroyed
- onDestroyView() is missing
Leaked Fields:
• binding : se.arctosoft.vault.databinding.BottomSheetDeleteBinding (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();
binding = null;
}
Finding #3 — BottomSheetCopyFragment
Fragment View Field Retention Leak Detected
Class: se.arctosoft.vault.BottomSheetCopyFragment
Issue:
- Fragment stores View references in instance fields
- These fields are not cleared when the view is destroyed
- onDestroyView() is missing
Leaked Fields:
• binding : se.arctosoft.vault.databinding.BottomSheetCopyBinding (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();
binding = null;
}
Finding #4 — BottomSheetImportFragment
Fragment View Field Retention Leak Detected
Class: se.arctosoft.vault.BottomSheetImportFragment
Issue:
- Fragment stores View references in instance fields
- These fields are not cleared when the view is destroyed
- onDestroyView() is missing
Leaked Fields:
• binding : se.arctosoft.vault.databinding.BottomSheetImportBinding (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();
binding = null;
}
Finding #5 — BottomSheetExportFragment
Fragment View Field Retention Leak Detected
Class: se.arctosoft.vault.BottomSheetExportFragment
Issue:
- Fragment stores View references in instance fields
- These fields are not cleared when the view is destroyed
- onDestroyView() is missing
Leaked Fields:
• binding : se.arctosoft.vault.databinding.BottomSheetExportBinding (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();
binding = null;
}
Finding #6 — BottomSheetMoveFragment
Fragment View Field Retention Leak Detected
Class: se.arctosoft.vault.BottomSheetMoveFragment
Issue:
- Fragment stores View references in instance fields
- These fields are not cleared when the view is destroyed
- onDestroyView() is missing
Leaked Fields:
• binding : se.arctosoft.vault.databinding.BottomSheetCopyBinding (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();
binding = null;
}
Finding #7 — PasswordFragment
Fragment View Field Retention Leak Detected
Class: se.arctosoft.vault.PasswordFragment
Issue:
- Fragment stores View references in instance fields
- These fields are not cleared when the view is destroyed
- onDestroyView() is missing
Leaked Fields:
• binding : se.arctosoft.vault.databinding.FragmentPasswordBinding (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();
binding = null;
}
🔴 StateHolderLeak
Static field holds UI/Context reference across configuration changes
Finding #8 — Toaster
Potential State Holder Memory Leak Detected
Class: se.arctosoft.vault.utils.Toaster
Issue: Scenario 1: Long-lived class field 'toast' of type 'android.widget.Toast' holds UI reference. Prevents UI garbage collection.
Fix: Avoid storing UI in long-lived components. Use WeakReference.
🔴 ThreadedUIReference
Worker thread captures Activity/Fragment/View reference
Finding #9 — DirectoryBaseFragment\n// (Full source code omitted for brevity)\n"
{
"text_input": "package se.arctosoft.vault;\n\n// Class: se.arctosoft.vault.DirectoryBaseFragment\n// (Full source code omitted for brevity)\n",
"output": "Yes",
"project": "vault",
"explanation": "Scenario 1: Worker thread holds UI object reference\nClass: se.arctosoft.vault.DirectoryBaseFragment\nMethod: void filterBy(int)\nStatement: $r1 \u003d new java.lang.Thread\nCaptured UI objects:\n - r0 : se.arctosoft.vault.DirectoryBaseFragment\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 se.arctosoft.vault;\n\n// Class: se.arctosoft.vault.DirectoryBaseFragment\n// (Full source code omitted for brevity)\n",
"output": "Yes",
"project": "vault",
"explanation": "Scenario 1: Worker thread holds UI object reference\nClass: se.arctosoft.vault.DirectoryBaseFragment\nMethod: void filterBy(int)\nStatement: $r2 \u003d new se.arctosoft.vault.DirectoryBaseFragment$$Exte
… (truncated for brevity)
Finding #10 — DirectoryAllFragment\n// (Full source code omitted for brevity)\n"
{
"text_input": "package se.arctosoft.vault;\n\n// Class: se.arctosoft.vault.DirectoryAllFragment\n// (Full source code omitted for brevity)\n",
"output": "Yes",
"project": "vault",
"explanation": "Scenario 1: Worker thread holds UI object reference\nClass: se.arctosoft.vault.DirectoryAllFragment\nMethod: void findAllFiles()\nStatement: $r1 \u003d new java.lang.Thread\nCaptured UI objects:\n - r0 : se.arctosoft.vault.DirectoryAllFragment\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 se.arctosoft.vault;\n\n// Class: se.arctosoft.vault.DirectoryAllFragment\n// (Full source code omitted for brevity)\n",
"output": "Yes",
"project": "vault",
"explanation": "Scenario 1: Worker thread holds UI object reference\nClass: se.arctosoft.vault.DirectoryAllFragment\nMethod: void findAllFiles()\nStatement: $r2 \u003d new se.arctosoft.vault.DirectoryAllFragment$$External
… (truncated for brevity)
Finding #11 — DirectoryFragment\n// (Full source code omitted for brevity)\n"
{
"text_input": "package se.arctosoft.vault;\n\n// Class: se.arctosoft.vault.DirectoryFragment\n// (Full source code omitted for brevity)\n",
"output": "Yes",
"project": "vault",
"explanation": "Scenario 1: Worker thread holds UI object reference\nClass: se.arctosoft.vault.DirectoryFragment\nMethod: void addRootFolders()\nStatement: $r5 \u003d new java.lang.Thread\nCaptured UI objects:\n - r0 : se.arctosoft.vault.DirectoryFragment\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 se.arctosoft.vault;\n\n// Class: se.arctosoft.vault.DirectoryFragment\n// (Full source code omitted for brevity)\n",
"output": "Yes",
"project": "vault",
"explanation": "Scenario 1: Worker thread holds UI object reference\nClass: se.arctosoft.vault.DirectoryFragment\nMethod: void addRootFolders()\nStatement: r6 \u003d new se.arctosoft.vault.DirectoryFragment$$ExternalSyntheticLambda
… (truncated for brevity)
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 Valv-Android.
LeakScope: Android Lifecycle & Memory Leak Violations
Summary
LeakScope detected 11 potential issue(s) across 3 detector type(s):
FragmentViewFieldRetentionLeakStateHolderLeakThreadedUIReferenceDetailed Findings
🔴
FragmentViewFieldRetentionLeakFragment stores View references in instance fields not cleared in onDestroyView()
Finding #1 —
DirectoryBaseFragmentFinding #2 —
BottomSheetDeleteFragmentFinding #3 —
BottomSheetCopyFragmentFinding #4 —
BottomSheetImportFragmentFinding #5 —
BottomSheetExportFragmentFinding #6 —
BottomSheetMoveFragmentFinding #7 —
PasswordFragment🔴
StateHolderLeakStatic field holds UI/Context reference across configuration changes
Finding #8 —
Toaster🔴
ThreadedUIReferenceWorker thread captures Activity/Fragment/View reference
Finding #9 —
DirectoryBaseFragment\n// (Full source code omitted for brevity)\n"Finding #10 —
DirectoryAllFragment\n// (Full source code omitted for brevity)\n"Finding #11 —
DirectoryFragment\n// (Full source code omitted for brevity)\n"How to respond to this issue:
This report was generated by LeakScope as part of the ICSE 2027 research artifact. Tool analyzes compiled APKs using Soot static analysis on Valv-Android.