[LeakScope] 4 Android lifecycle/memory violations detected

[MuhammadTehamsibAliTashfeen]

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 2 detector type(s):

Severity	Count
🔴 High	1
🟡 Medium	0
🟢 Low (improvement opportunity)	3

Detector	Count	Severity	Description
StateHolderLeak	1	🔴 High	Static field holds UI/Context reference across configuration changes
ViewBindingOpportunity	3	🟢 Low	Manual findViewById() calls — ViewBinding migration opportunity

---

Detailed Findings

🔴 StateHolderLeak

Static field holds UI/Context reference across configuration changes

Finding #1 — OldMainActivity

Potential State Holder Memory Leak Detected
Class: com.aof.mcinabox.activity.OldMainActivity
Issue: Scenario 2: Static field 'Setting' of type 'com.aof.mcinabox.launcher.setting.support.SettingJson' in Activity/Fragment is a custom object that may hold UI references. Static fields survive configuration changes.
Fix: Use ViewModel or SavedStateHandle to persist state across rotations.

🟢 ViewBindingOpportunity

Manual findViewById() calls — ViewBinding migration opportunity

Finding #2 — CustomizeKeyboardEditorActivity

View Binding Migration Opportunity
Class: com.aof.mcinabox.gamecontroller.ckb.CustomizeKeyboardEditorActivity
Type: Activity
Current Pattern: Manual view lookup
findViewById() Calls:
  • findViewById in initUI
  • findViewById in initUI
  • findViewById in initUI
  • findViewById in initUI
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 #3 — OldMainActivity

View Binding Migration Opportunity
Class: com.aof.mcinabox.activity.OldMainActivity
Type: Activity
Current Pattern: Manual view lookup
findViewById() Calls:
  • 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 #4 — BoatStartupActivity

View Binding Migration Opportunity
Class: com.aof.mcinabox.launcher.launch.Activity.BoatStartupActivity
Type: Activity
Current Pattern: Manual view lookup
findViewById() Calls:
  • findViewById in getSurfaceLayerView
  • findViewById in getViewsParent
  • 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 MCinaBox.