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

Severity	Count
🔴 High	9
🟡 Medium	0
🟢 Low (improvement opportunity)	5

Detector	Count	Severity	Description
FragmentViewFieldRetentionLeak	3	🔴 High	Fragment stores View references in instance fields not cleared in onDestroyView()
ThreadedUIReference	6	🔴 High	Worker thread captures Activity/Fragment/View reference
ViewBindingOpportunity	5	🟢 Low	Manual findViewById() calls — ViewBinding migration opportunity

---

Detailed Findings

🔴 FragmentViewFieldRetentionLeak

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

Finding #1 — GsFileBrowserFragment

Fragment View Field Retention Leak Detected
Class: net.gsantner.opoc.frontend.filebrowser.GsFileBrowserFragment

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

- onDestroyView() is missing

Leaked Fields:
  • _recyclerList : androidx.recyclerview.widget.RecyclerView (assigned in onViewCreated)
  • _swipe : androidx.swiperefreshlayout.widget.SwipeRefreshLayout (assigned in onViewCreated)
  • _emptyHint : android.widget.TextView (assigned in onViewCreated)
  • _toolbar : androidx.appcompat.widget.Toolbar (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 #2 — DocumentEditAndViewFragment

Fragment View Field Retention Leak Detected
Class: net.gsantner.markor.activity.DocumentEditAndViewFragment

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

- onDestroyView() is missing

Leaked Fields:
  • _hlEditor : net.gsantner.markor.frontend.textview.HighlightingEditor (assigned in onViewCreated)
  • _editorHolder : android.view.ViewGroup (assigned in onViewCreated)
  • _textActionsBar : android.view.ViewGroup (assigned in onViewCreated)
  • _webView : android.webkit.WebView (assigned in onViewCreated)
  • _verticalScrollView : net.gsantner.markor.frontend.DraggableScrollbarScrollView (assigned in onViewCreated)
  • _lineNumbersView : net.gsantner.markor.frontend.textview.LineNumbersTextView (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 Con
… (truncated for brevity)

Finding #3 — GsFileBrowserDialog

Fragment View Field Retention Leak Detected
Class: net.gsantner.opoc.frontend.filebrowser.GsFileBrowserDialog

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

- onDestroyView() is missing

Leaked Fields:
  • _recyclerList : androidx.recyclerview.widget.RecyclerView (assigned in onViewCreated)
  • _toolBar : androidx.appcompat.widget.Toolbar (assigned in onViewCreated)
  • _buttonCancel : android.widget.TextView (assigned in onViewCreated)
  • _buttonOk : android.widget.TextView (assigned in onViewCreated)
  • _homeButton : android.widget.ImageButton (assigned in onViewCreated)
  • _buttonNewDir : android.widget.ImageButton (assigned in onViewCreated)
  • _buttonSearch : android.widget.ImageButton (assigned in onViewCreated)
  • _searchEdit : android.widget.EditText (assigned in onViewCreated)
  • _buttonNeutral : android.widget.TextView (assigned in onViewCreated)

Why this is dangerous:
- Fragment
… (truncated for brevity)

🔴 ThreadedUIReference

Worker thread captures Activity/Fragment/View reference

Finding #4 — OpenFromShortcutOrWidgetActivity

Scenario 1: Worker thread holds UI object reference
Class: net.gsantner.markor.activity.openeditor.OpenFromShortcutOrWidgetActivity
Method: void launchActivityAndFinish(android.content.Intent)
Statement: staticinvoke <net.gsantner.markor.activity.DocumentActivity: void launch(android.app.Activity,android.content.Intent)>(r0, $r1)
Captured UI objects:
  - r0 : net.gsantner.markor.activity.openeditor.OpenFromShortcutOrWidgetActivity
Risk: UI object will be kept in memory until thread completes
Fix: Use WeakReference or avoid passing UI objects to worker threads

Finding #5 — MainActivity

Scenario 1: Worker thread holds UI object reference
Class: net.gsantner.markor.activity.MainActivity
Method: void newItemCallback(java.io.File)
Statement: staticinvoke <net.gsantner.markor.activity.DocumentActivity: void launch(android.app.Activity,java.io.File,java.lang.Boolean,java.lang.Integer)>(r0, $r1, $r2, null)
Captured UI objects:
  - r0 : net.gsantner.markor.activity.MainActivity
Risk: UI object will be kept in memory until thread completes
Fix: Use WeakReference or avoid passing UI objects to worker threads

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

{
  "text_input": "package net.gsantner.opoc.frontend.filebrowser;\n\n// Class: net.gsantner.opoc.frontend.filebrowser.GsFileBrowserFragment\n// (Full source code omitted for brevity)\n",
  "output": "Yes",
  "project": "opoc",
  "explanation": "Scenario 1: Worker thread holds UI object reference\nClass: net.gsantner.opoc.frontend.filebrowser.GsFileBrowserFragment\nMethod: void lambda$onOptionsItemSelected$3$net-gsantner-opoc-frontend-filebrowser-GsFileBrowserFragment(java.util.Set)\nStatement: $r2 \u003d new java.lang.Thread\nCaptured UI objects:\n  - r0 : net.gsantner.opoc.frontend.filebrowser.GsFileBrowserFragment\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 net.gsantner.opoc.frontend.filebrowser;\n\n// Class: net.gsantner.opoc.frontend.filebrowser.GsFileBrowserFragment\n// (Full source code omitted for brevity)\n",
  "output": "Yes",
  "project": "opoc",
  "explan
… (truncated for brevity)

Finding #7 — DocumentActivity\n// (Full source code omitted for brevity)\n"

{
  "text_input": "package net.gsantner.markor.activity;\n\n// Class: net.gsantner.markor.activity.DocumentActivity\n// (Full source code omitted for brevity)\n",
  "output": "Yes",
  "project": "markor",
  "explanation": "Scenario 1: Worker thread holds UI object reference\nClass: net.gsantner.markor.activity.DocumentActivity\nMethod: void handleLaunchingIntent(android.content.Intent)\nStatement: staticinvoke \u003cnet.gsantner.markor.activity.DocumentActivity: void launch(android.app.Activity,java.io.File,java.lang.Boolean,java.lang.Integer)\u003e(r0, $r4, r9, r8)\nCaptured UI objects:\n  - r0 : net.gsantner.markor.activity.DocumentActivity\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 net.gsantner.markor.activity;\n\n// Class: net.gsantner.markor.activity.DocumentActivity\n// (Full source code omitted for brevity)\n",
  "output": "Yes",
  "project": "markor",
  "exp
… (truncated for brevity)

Finding #8 — DocumentEditAndViewFragment

Scenario 1: Worker thread holds UI object reference
Class: net.gsantner.markor.activity.DocumentEditAndViewFragment
Method: void lambda$onOptionsItemSelected$12$net-gsantner-markor-activity-DocumentEditAndViewFragment(android.app.Activity)
Statement: staticinvoke <net.gsantner.markor.activity.MainActivity: void launch(android.app.Activity,java.io.File,boolean)>($r1, $r3, 0)
Captured UI objects:
  - $r1 : android.app.Activity
Risk: UI object will be kept in memory until thread completes
Fix: Use WeakReference or avoid passing UI objects to worker threads

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

{
  "text_input": "package net.gsantner.markor.activity;\n\n// Class: net.gsantner.markor.activity.DocumentShareIntoFragment$ShareIntoImportOptionsFragment\n// (Full source code omitted for brevity)\n",
  "output": "Yes",
  "project": "markor",
  "explanation": "Scenario 1: Worker thread holds UI object reference\nClass: net.gsantner.markor.activity.DocumentShareIntoFragment$ShareIntoImportOptionsFragment\nMethod: void attachOrCopyAndClose(java.io.File,boolean)\nStatement: staticinvoke \u003cnet.gsantner.markor.activity.MainActivity: void launch(android.app.Activity,java.io.File,boolean)\u003e($r2, $r1, 0)\nCaptured UI objects:\n  - $r2 : androidx.fragment.app.FragmentActivity\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 net.gsantner.markor.activity;\n\n// Class: net.gsantner.markor.activity.DocumentShareIntoFragment$ShareIntoImportOptionsFragment\n// (Full source cod
… (truncated for brevity)

🟢 ViewBindingOpportunity

Manual findViewById() calls — ViewBinding migration opportunity

Finding #10 — ActionButtonSettingsActivity

View Binding Migration Opportunity
Class: net.gsantner.markor.activity.ActionButtonSettingsActivity
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 #11 — MainActivity

View Binding Migration Opportunity
Class: net.gsantner.markor.activity.MainActivity
Type: Activity
Current Pattern: Manual view lookup
findViewById() Calls:
  • 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 #12 — SettingsActivity

View Binding Migration Opportunity
Class: net.gsantner.markor.activity.SettingsActivity
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 #13 — DocumentActivity

View Binding Migration Opportunity
Class: net.gsantner.markor.activity.DocumentActivity
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 #14 — GsActivityBase

View Binding Migration Opportunity
Class: net.gsantner.opoc.frontend.base.GsActivityBase
Type: Activity
Current Pattern: Manual view lookup
findViewById() Calls:
  • findViewById in getToolbar
  • findViewById in setTitle
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 markor.

Review the listed classes, including GsFileBrowserFragment, DocumentEditAndViewFragment, GsFileBrowserDialog, MainActivity, DocumentActivity, and the related activities, against the three reported detector categories. Start by checking the referenced lifecycle methods, worker-thread calls, and findViewById() sites. Done means determining whether each reported finding is accurate and recording which findings need action.