[Feature request]Serve the floating lock button through the accessibility service instead of `SYSTEM_ALERT_WINDOW

[jpgjm]

screen-20260725-014005.mp4

Summary
TapLock already requires the accessibility service for screen locking, and it can host overlays too via WindowManager.LayoutParams.TYPE_ACCESSIBILITY_OVERLAY. Please migrate the Floating Lock Button from FloatingButtonService (which needs Draw-over-other-apps) to an overlay hosted by TapLockAccessibilityService.

Why

• One less permission — users no longer have to grant SYSTEM_ALERT_WINDOW (Draw over other apps). One fewer permission screen in first-run setup, one fewer sensitive permission on the Play Store listing.
• Consistency with the existing codebase — TapLockAccessibilityService already uses TYPE_ACCESSIBILITY_OVERLAY in three places (status bar overlay, edge overlays, corner overlays). The floating button is currently the only overlay that takes the SYSTEM_ALERT_WINDOW path via a separate service.
• Removes a dead foreground-service notification path — FloatingButtonService calls startForeground with a NotificationCompat.Builder, but the app never requests the Android 13+ runtime POST_NOTIFICATIONS permission anywhere (only declares it in the manifest). On Android 13+ that means the notification is silently never shown, even though the service is running. The app also doesn't surface any in-app UI hint that notifications are needed — no banner, no setup step, no toggle-time explainer — so unless the user happens to notice this on their own and manually grants POST_NOTIFICATIONS from Android's system settings, the notification stays hidden forever. Moving to an accessibility overlay drops the entire FGS + notification code path, which is currently non-functional anyway.
• Potentially usable above the lock screen — accessibility overlays can render on top of the keyguard on many devices, which TYPE_APPLICATION_OVERLAY cannot.

Implementation sketch (from a quick read of the source)

1. In TapLockAccessibilityService, add a floatingLockButton: View? field alongside the existing statusBarOverlay, leftEdgeOverlay, etc.
2. Add addFloatingLockButton() / removeFloatingLockButton() / updateFloatingLockButton(sizeDp, opacityPercent) methods mirroring the existing addStatusBarOverlay() pattern, but with:
   • LayoutParams(size, size, TYPE_ACCESSIBILITY_OVERLAY, FLAG_NOT_FOCUSABLE, PixelFormat.TRANSLUCENT)
   • gravity = Gravity.TOP or Gravity.START, saved x/y from SharedPreferences
   • The same OnTouchListener drag / edge-snap logic that lives in FloatingButtonService.addFloatingButton() today
   • The same custom-icon lookup via File(filesDir, "custom_widget_icon.png"), which works fine from the accessibility service context
3. Have the SharedPreferences change listener in the accessibility service react to floating_button_enabled, floating_button_size_dp, floating_button_opacity_percent and add / remove / update the view accordingly.
4. Delete FloatingButtonService, its <service> entry in the manifest, android.permission.SYSTEM_ALERT_WINDOW, and (since the FGS goes away) android.permission.POST_NOTIFICATIONS unless it is needed elsewhere. Remove Settings.canDrawOverlays() gates and the overlay-permission request UI in MainActivity.
5. Replace restartFloatingButtonServiceIfRunning() with a call into the accessibility service via its instance singleton, e.g. TapLockAccessibilityService.instance?.updateFloatingLockButton(...). This also solves the sibling live-preview feature request — in-place updateViewLayout / view.alpha = ... becomes trivial once the view is owned by the accessibility service.

Non-goals / caveats

• If the accessibility service is disabled the floating button won't work, but that is already true for locking itself, so it's not a new failure mode.
• Lock-screen layering can vary by OEM. If universal support isn't reliable, gating "show on lock screen" behind a toggle (default off) would be a safe compromise.
• Drag-through-touch behavior needs re-testing under TYPE_ACCESSIBILITY_OVERLAY; the existing edge / corner overlays already receive touches from the same service, so this should be a small delta.

[modelorona]

Thanks for opening this! I didn't get notified and just saw.