Skip to content

Added Lockdown feature and Lock phone using QS Tile Fixes #631 - #651

Merged
sameerasw merged 11 commits into
sameerasw:developfrom
thekrdev:feature/lockdown
Aug 5, 2026
Merged

Added Lockdown feature and Lock phone using QS Tile Fixes #631#651
sameerasw merged 11 commits into
sameerasw:developfrom
thekrdev:feature/lockdown

Conversation

@thekrdev

Copy link
Copy Markdown
Contributor
  • Lockdown feature requires shizuku, if no shizuku permission, It'll normally lock your phone, no lockdowns.
  • Lockdown feature removes weak unlock methods like face, fingerprint and require secure methods like pin, password or pattern.
  • it works but you may face some bugs like It'll ask 2-3 times to unlock, bcs of adb glicthes... but it works.

If you don't want lockdown, you can continue with accessibility permission, by just adding the qs tile.

Close #631

thomasborgogno and others added 6 commits July 30, 2026 17:13
## Summary

Adds two new automation trigger types: **Bluetooth device
connected/disconnected** and **Wi-Fi network connected/disconnected**.
Users can now build automations that fire an action when the phone
connects to (or disconnects from) a specific paired Bluetooth device or
a specific Wi-Fi network — the same way existing triggers like Charger
Connected or Schedule work today.

## What's new

- **`Trigger.kt`**: 4 new sealed subtypes —
`BluetoothConnected`/`BluetoothDisconnected` (device address + name) and
`WifiConnected`/`WifiDisconnected` (SSID), all configurable via a
settings sheet like `Trigger.Schedule`.
- **`BluetoothModule`** (new): dynamic `BroadcastReceiver` on
`ACTION_ACL_CONNECTED`/`ACTION_ACL_DISCONNECTED`, filtered by MAC
address.
- **`WifiModule`** (new): `ConnectivityManager.NetworkCallback` on the
Wi-Fi transport, resolving the active SSID via `WifiManager` and firing
on connect/lost.
- **`AutomationManager`**: wires both modules into the existing module
lifecycle (same pattern as Power/Display/Time modules).
- **Editor UI**: two new trigger entries in `AutomationEditorActivity`,
each configurable through a bottom sheet:
- `BluetoothDeviceSelectionSheet` — pick from the phone's paired devices
(requests `BLUETOOTH_CONNECT` on Android 12+).
- `WifiNetworkSelectionSheet` — if the app has **Shizuku** (or root)
authorized, it runs `cmd wifi list-networks` under shell privileges and
lets the user pick straight from the device's saved networks; otherwise
it falls back to manual SSID entry with a "Use Current Network" helper
(requests `ACCESS_FINE_LOCATION`, needed by Android to read the current
SSID).
- **Manifest**: added `ACCESS_WIFI_STATE` (the Bluetooth/location
permissions needed were already present).

## Why

Requested enhancement to make automations react to connectivity context
(e.g. "turn on Wi-Fi calling when connected to home network", "mute when
a specific headset disconnects") without needing a schedule or manual
toggle.

## Test plan

- [ ] Create a Trigger automation on "Bluetooth Device
Connected"/"Disconnected" for a paired device and verify the linked
action fires on connect/disconnect.
- [ ] Create a Trigger automation on "Wi-Fi Network
Connected"/"Disconnected".
- [ ] Verify triggers still fire correctly after the app/service is
killed and restarted (foreground service reattachment).
…iver registration context in BluetoothModule
…selection sheets to use RoundedCardContainer
@sameerasw
sameerasw self-requested a review August 2, 2026 08:10
@sameerasw sameerasw added the enhancement New feature or request label Aug 2, 2026
@sameerasw sameerasw moved this from Backlog to In review in Essentials Progress Aug 2, 2026

@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.

Hi! Can you take a look at these concerns?

Potential Issues & Recommendations

1. Code Duplication with Existing Screen Locking Logic

  • Issue: Screen locking logic (input keyevent KEYCODE_POWER and ScreenOffAccessibilityService.performGlobalAction) is duplicated in LockdownTileService.kt, ScreenOffWidgetProvider.kt, and AodForceTurnOffHandler.kt.
  • Recommendation: Refactor into a unified DeviceLockUtils helper so ScreenOffWidgetProvider, LockdownTileService, and AodForceTurnOffHandler share the exact same locking and permission checks without code duplication.

2. Lockdown Mode Does Not Turn Off Screen Immediately

  • Issue: cmd lock_settings require-strong-auth sets the strong auth flag for the next lock event, but does not turn off or lock the screen by itself on many OEM builds.
  • Recommendation: Follow up the require-strong-auth command with input keyevent KEYCODE_POWER (or Accessibility GLOBAL_ACTION_LOCK_SCREEN) so tapping the tile turns off the display and locks the device instantly.

3. Hardcoded --user 0 Flag

  • Issue: Hardcoding --user 0 in cmd lock_settings require-strong-auth ... --user 0 only targets the primary owner profile.
  • Recommendation: Resolve user ID dynamically via android.os.Process.myUserHandle().hashCode() so it works correctly in Work Profiles and Secondary Users / Private Spaces (Android 15+).

@thekrdev

thekrdev commented Aug 5, 2026

Copy link
Copy Markdown
Contributor Author

Hi, I've fixed those issues and used device admin policy instead of shizuku/adb, it's easier and stable for users.

@sameerasw

Copy link
Copy Markdown
Owner

Thank you

@sameerasw
sameerasw merged commit 6e60f52 into sameerasw:develop Aug 5, 2026
1 check passed
@github-project-automation github-project-automation Bot moved this from In review to Done in Essentials Progress Aug 5, 2026
@thekrdev

thekrdev commented Aug 5, 2026 via email

Copy link
Copy Markdown
Contributor Author

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

3 participants