Android safety policy
A Wi-Fi connection or a confirmed non-Tailscale VPN triggers debugging-disable requests and settings readback. Unknown state denies new connections; the default reconnect policy requires an explicit user action.
Personal project · Device policy and coordination
ADB Guard — Android, Ubuntu & Windows Coordination
A coordination system linking Android debugging policy, an Ubuntu broker and a Windows client. Requests, approval, execution and effect verification are separate stages, with resource ownership preventing conflicting changes across devices.
Content reviewed:
- Stack
- Kotlin · Android · Python · SQLite · mTLS
- Implementation
- Android policy and approval app · Ubuntu broker and operations tools · Windows client
- Current status
- Integrated source and local regression coverage · optional boot recovery requires device validation
The problem
Requests from multiple devices can drift from what was approved or repeat a change after a connection drops. The broker binds the authenticated actor to the approved content, grants a time-limited resource lease and preserves uncertainty when the effect cannot be confirmed.
From request to verified effect
Android policy state and approval remain part of the execution checks. The broker records acceptance, execution and effect verification as separate states.
Register a request
Record content, resources, deadline and an idempotency key. Reject different requests that reuse the same key.
Authenticate approval
Bind the content digest, approval nonce and safety generation to an authenticated approver.
Lease and execute
Acquire overlapping resources in order and require the current owner and epoch before execution.
Verify and recover
Preserve uncertain outcomes as UNCERTAIN and observe the effect before any further mutation.
Implementation
Device identity and approval
Registered certificates and mTLS establish identity. The broker ignores role claims in request bodies and rechecks approval expiry, content digests and safety-state changes.
Concurrency and duplicate prevention
A SQLite ledger persists operations and resource leases. Resources are acquired together, and owner/epoch checks reject subsequent writes from stale executors.
Operations and recovery
Certificate renewal, connection reporting and recovery tools support operation. Integrated app, broker and client sources link requirements to consumers and required checks for change-impact review.
Implementation and validation scope
- Kotlin and Python local regression coverage addresses policy, approval, leases, expiry and recovery. Local results are kept separate from real-device verification.
- Broker enforcement covers registered execution paths. It does not provide operating-system isolation against direct ADB use by the same user.
- Optional boot recovery and Shizuku startup integration require separate privileges and device validation. Process visibility alone is not treated as a successful connection or task.
Implementation references
apps/android/core/…/Policy.kt · Coordination.kt— Debugging policy and approval-data validationservices/coordination/broker/core.py— Operation state, approval, leasing and recoveryservices/coordination/operations/service.py— Registered device identity and certificate renewal