mirror of
https://github.com/VibedByKaKi/sdmaid-se.git
synced 2026-11-12 09:37:17 +01:00
83c4d4e65e
AutomationManager.canSelfEnable() was WRITE_SECURE_SETTINGS alone, while AutomationSetupModule computed its own value as `automationManager.canSelfEnable() && !aapmBlocksAcs`. On an Android 17 device with Advanced Protection active and secure-settings access granted the two disagreed: useAcs (consent plus running-service-or-canSelfEnable) was true while the setup module's isComplete was false. Every action gated on useAcs - AppControl's canForceStop, canArchive and canRestore - was offered and could not run, because Advanced Protection rejects the accessibility bind itself, so a secure-settings write does not help. Both sites now share one predicate, decideCanSelfEnable(hasSecureSettings, advancedProtectionBlocksAcs), added beside the module's other pure decision functions in AutomationToolsHelper. The setup module drops its now redundant `&& !aapmBlocksAcs`; its computed value is unchanged, and the local aapmBlocksAcs still feeds decideAcsRestrictionHints and isAdvancedProtectionBlocked. useAcs's first clause, `isServiceEnabled() && isServiceLaunched()`, keeps its meaning: a service that is genuinely running can genuinely run the task, whatever Advanced Protection would do to a fresh bind. Only the self-enable clause is narrowed. |
||
|---|---|---|
| .. | ||
| src | ||
| build.gradle.kts | ||
| consumer-rules.pro | ||