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 2 potential issue(s) across 2 detector type(s):
| Severity |
Count |
| 🔴 High |
1 |
| 🟡 Medium |
0 |
| 🟢 Low (improvement opportunity) |
1 |
| Detector |
Count |
Severity |
Description |
ThreadedUIReference |
1 |
🔴 High |
Worker thread captures Activity/Fragment/View reference |
ViewBindingOpportunity |
1 |
🟢 Low |
Manual findViewById() calls — ViewBinding migration opportunity |
Detailed Findings
🔴 ThreadedUIReference
Worker thread captures Activity/Fragment/View reference
Finding #1 — MainActivity\n// (Full source code omitted for brevity)\n"
{
"text_input": "package io.github.subhamtyagi.ocr;\n\n// Class: io.github.subhamtyagi.ocr.MainActivity\n// (Full source code omitted for brevity)\n",
"output": "Yes",
"project": "subhamtyagi",
"explanation": "Scenario 1: Worker thread holds UI object reference\nClass: io.github.subhamtyagi.ocr.MainActivity\nMethod: void startImageTextReaderThread(java.io.File,java.util.Set)\nStatement: $r3 \u003d new java.lang.Thread\nCaptured UI objects:\n - r0 : io.github.subhamtyagi.ocr.MainActivity\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 io.github.subhamtyagi.ocr;\n\n// Class: io.github.subhamtyagi.ocr.MainActivity\n// (Full source code omitted for brevity)\n",
"output": "Yes",
"project": "subhamtyagi",
"explanation": "Scenario 1: Worker thread holds UI object reference\nClass: io.github.subhamtyagi.ocr.MainActivity\nMethod: void startImageTextReaderThread(jav
… (truncated for brevity)
🟢 ViewBindingOpportunity
Manual findViewById() calls — ViewBinding migration opportunity
Finding #2 — MainActivity
View Binding Migration Opportunity
Class: io.github.subhamtyagi.ocr.MainActivity
Type: Activity
Current Pattern: Manual view lookup
findViewById() Calls:
• findViewById in onCreate
• findViewById in onCreate
• findViewById in onCreate
• findViewById in onCreate
• 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
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 android-ocr.
LeakScope: Android Lifecycle & Memory Leak Violations
Summary
LeakScope detected 2 potential issue(s) across 2 detector type(s):
ThreadedUIReferenceViewBindingOpportunityDetailed Findings
🔴
ThreadedUIReferenceWorker thread captures Activity/Fragment/View reference
Finding #1 —
MainActivity\n// (Full source code omitted for brevity)\n"🟢
ViewBindingOpportunityManual findViewById() calls — ViewBinding migration opportunity
Finding #2 —
MainActivityHow 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 android-ocr.