Skip to content

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

Open
thekrdev wants to merge 7 commits into
sameerasw:developfrom
thekrdev:feature/lockdown
Open

Added Lockdown feature and Lock phone using QS Tile Fixes #631#651
thekrdev wants to merge 7 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+).

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: In review

Development

Successfully merging this pull request may close these issues.

3 participants