hehonghui / hehonghui/AndroidEventBus

[LeakScope] 4 Android lifecycle/memory violations detected

Open
#63 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Java
Stars
1.6k
Forks
390
PR merge metrics
No merged PRs in 30d

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

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

Detailed Findings
🔴 FragmentViewFieldRetentionLeak

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

Finding #1 — ConstactFragment

Fragment View Field Retention Leak Detected
Class: com.android.eventbus.demo.fragment.ConstactFragment

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

- onDestroyView() is missing

Leaked Fields:
  • mListView : android.widget.ListView (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();
    mListView = null;
  }

Finding #2 — MenuFragment

Fragment View Field Retention Leak Detected
Class: com.android.eventbus.demo.fragment.MenuFragment

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

- onDestroyView() is missing

Leaked Fields:
  • mUserNameTv : android.widget.TextView (assigned in onCreateView)
  • mThreadTv : android.widget.TextView (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();
    mUserNameTv = null;
    mThreadTv = null;
  }
🔴 ThreadedUIReference

Worker thread captures Activity/Fragment/View reference

Finding #3 — MenuFragment

Scenario 1: Worker thread holds UI object reference
Class: com.android.eventbus.demo.fragment.MenuFragment
Method: void startThreads()
Statement: $r1 = new com.android.eventbus.demo.fragment.MenuFragment$PostThread
Captured UI objects:
  - r0 : com.android.eventbus.demo.fragment.MenuFragment
Risk: UI object will be kept in memory until thread completes
Fix: Use WeakReference or avoid passing UI objects to worker threads
🟢 ViewBindingOpportunity

Manual findViewById() calls — ViewBinding migration opportunity

Finding #4 — StickyActivity

View Binding Migration Opportunity
Class: com.android.eventbus.demo.StickyActivity
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

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

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Inspect ConstactFragment and MenuFragment, focusing on onCreateView(), the missing onDestroyView(), and MenuFragment.startThreads(); then inspect StickyActivity.onCreate() for the reported lookups. Verify whether the four reported findings are true positives or false positives, and document the result in a reply with any applied fixes.

Written by the indexing model from the issue text.

Assessment

Tech stack
android, java
Domain
mobile
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.