Skip to content

refactor: Centralize app flow handling and service event dispatching - #770

Draft
Mudit200408 wants to merge 1 commit into
sameerasw:developfrom
Mudit200408:feat-app-detection
Draft

refactor: Centralize app flow handling and service event dispatching#770
Mudit200408 wants to merge 1 commit into
sameerasw:developfrom
Mudit200408:feat-app-detection

Conversation

@Mudit200408

Copy link
Copy Markdown
Contributor

Refactors and centralizes app flow handling and service event dispatching.

@sameerasw
sameerasw self-requested a review August 21, 2026 09:22

@sameerasw sameerasw left a comment

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 Logic Flaws & Design Concerns

⚠️ Race Condition between Accessibility Events & UsageStats Polling

  • In AppFlowHandler.onPackageChanged:
    val oldPackage = currentPackage
    currentPackage = packageName // <--- Mutated unconditionally on every call!
    ...
    if (isFromUsageStats == useUsageAccess) {
        checkAppLock(packageName)
        checkHighlightNightLight(packageName)
        checkAppAutomations(packageName)
        checkGestureBarAutomation(packageName)
    }
  • If useUsageAccess is enabled, accessibility window state changes still call onPackageChanged(..., isFromUsageStats = false).
  • This prematurely updates currentPackage without executing any of the checks. When AppDetectionService polls shortly after, oldPackage and currentPackage are already corrupted or identical, potentially missing exit/entry actions in App Automations and App Lock.

📋 Summary Verdict

Area Status Notes
Architectural Goal ⚠️ Incomplete Centralizing app flow is a good idea, but implementation drops core features.
Shut Up & Freeze Features ❌ Broken Core restoration and countdown logic was completely deleted.
Lifecycle Safety ❌ Broken destroy() leaves a zombie singleton instance.
Gradle / Build Files ❌ Unwanted Adds a binary .jar and modifies gradlew.

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔴 Issue 1: Complete Deletion of "Shut Up" & "App Freeze on Exit" Logic (Severe Regression)

  • What happened: Over 500 lines of critical background logic were deleted from AppFlowHandler.kt without being moved anywhere:
    • Shut Up Settings Restoration: restoreShutUpSettings(), checkShutUpRestore(), and Shizuku auto-restarting logic were completely stripped.
    • Restore Notification & Promoted Ongoing Notification: The ongoing restore notification (NOTIFICATION_ID_SHUTUP_RESTORE), ACTION_RESTORE_NOW, and interactive restore actions were deleted.
    • Freeze on Exit / Auto-Archive Countdowns: activeCountdowns, ACTION_FREEZE_NOW, and ACTION_ABORT_FREEZE broadcast receivers and notifications were removed.
  • Impact: Merging this will completely break the Shut Up feature and App Freeze-on-Exit automations, preventing system settings from ever being restored and frozen apps from being managed on app exit.

Comment on lines +147 to +151
if (::appFlowHandler.isInitialized) {
appFlowHandler.destroy()
}
} catch (_: Exception) {
}

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔴 Issue 2: Singleton Lifecycle & Premature Listener Teardown (State Corruption)

  • Location: AppDetectionService.kt:147–151 & AppFlowHandler.kt:84–95
  • What happened:
    • AppFlowHandler is now a static singleton INSTANCE.
    • When AppDetectionService.onDestroy() runs, it calls appFlowHandler.destroy(), which unregisters SharedPreferences listeners, ComponentCallbacks, and the MEDIA_PLAYBACK_CHANGED broadcast receiver from the application context.
    • However, INSTANCE is never reset to null.
  • Impact: If AppDetectionService restarts or ScreenOffAccessibilityService continues using AppFlowHandler, the handler is left in a dead/unregistered state where preference changes and media events are permanently ignored until a full process kill.

Comment thread gradlew

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔴 Issue 3: Unrelated / Suspicious Gradle Binary & Wrapper Script Changes

  • Files Modified:
    • gradle/wrapper/gradle-wrapper.jar (Binary added: +53 KB)
    • gradlew (Modified invocation from -jar to -classpath)
  • Impact: Changes to binary wrapper jars or gradlew execution in a feature PR are a security concern, unnecessary, and out-of-scope.

@sameerasw
sameerasw marked this pull request as draft August 21, 2026 09:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Backlog

Development

Successfully merging this pull request may close these issues.

2 participants