Skip to content

[LeakScope] 3 Android lifecycle/memory violations detected #124

@MuhammadTehamsibAliTashfeen

Description

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

Severity Count
🔴 High 2
🟡 Medium 1
🟢 Low (improvement opportunity) 0
Detector Count Severity Description
FragmentViewFieldRetentionLeak 1 🔴 High Fragment stores View references in instance fields not cleared in onDestroyView()
ThreadedUIReference 1 🔴 High Worker thread captures Activity/Fragment/View reference
ServiceResourceManagementIssueDetector 1 🟡 Medium Service may never stop — missing stopSelf() call

Detailed Findings

🔴 FragmentViewFieldRetentionLeak

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

Finding #1LanguagesBottomSheetDialogFragment

Fragment View Field Retention Leak Detected
Class: xyz.zedler.patrick.tack.fragment.dialog.LanguagesBottomSheetDialogFragment

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

- onDestroyView() is missing

Leaked Fields:
  • binding : xyz.zedler.patrick.tack.databinding.FragmentBottomsheetLanguagesBinding (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;
  }

🔴 ThreadedUIReference

Worker thread captures Activity/Fragment/View reference

Finding #2LogFragment

Scenario 1: Worker thread holds UI object reference
Class: xyz.zedler.patrick.tack.fragment.LogFragment
Method: void loadLogcat(androidx.core.util.Consumer)
Statement: $r3 = new xyz.zedler.patrick.tack.fragment.LogFragment$$ExternalSyntheticLambda1
Captured UI objects:
  - r0 : xyz.zedler.patrick.tack.fragment.LogFragment
Risk: UI object will be kept in memory until thread completes
Fix: Use WeakReference or avoid passing UI objects to worker threads

🟡 ServiceResourceManagementIssueDetector

Service may never stop — missing stopSelf() call

Finding #3MetronomeService

⚠� Service may never stop. Consider calling stopSelf() when work is complete.
  Class: xyz.zedler.patrick.tack.service.MetronomeService
  Method: onStartCommand

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 tack-android.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions