Device Owner Policies

Zero-Exfil Commitment

This device owner (DO) configuration is intentionally designed for zero data exfiltration. The app does not transmit photos, audio, video, telemetry, or identifiers to any backend. All "network" integrations in code are no-op delegates, and the control-plane base URL is disabled.

What This Page Covers

This disclosure enumerates every DevicePolicyManager capability the app uses as device owner, and explains why each is required. For runtime permissions (not device policies), see the Runtime Permission Disclosure.

Device Owner (DO) Policies Used

Policy	Purpose & Notes
lockNow via DeviceLockController (DO)	Allows the app to immediately lock the device in response to policy violations (e.g., integrity attestation failure, kill-switch absence, session watchdog timeout). This is a local action; no data leaves the device.
wipeDevice via ShutdownController (DO)	Enables factory reset escalation after repeated integrity failures or explicit policy triggers. Used only under well-defined thresholds; this is a device-local action with zero network use.
setApplicationHidden (DO)	Supports the "Hidden Workspace": selected, already-protected apps can be hidden/unhidden on the device. Hiding affects launcher visibility only; it does not uninstall or export data.
USB guard: setUsbDataSignalingEnabled (Android 14/15+, DO) or legacy addUserRestriction(DISALLOW_USB_FILE_TRANSFER) (Android 7+)	When the paired "kill-switch" device (e.g., Bluetooth tag) is absent and policy requires presence, the manager disables USB data signaling (or applies the legacy user restriction) to reduce exfil/ingress risk through USB. Automatically cleared when the device reconnects or policy no longer requires it.
forceStopPackage (Android 7.0+, DO-only)	As part of local "stream termination," the DO can request specific protected apps to be force-stopped. If unavailable on the platform or not permitted, the code falls back to killing background processes. This is entirely local and does not export data.
DO-granted runtime permission: READ_PHONE_STATE	During setup, the DO auto-grants READ_PHONE_STATE to enable SIM-swap detection. The feature computes a local hash of SIM identifiers and compares it on-device; notifications are local only.
Foreground service (system-visible notification)	The app runs a persistent foreground service (with a user-visible notification) to host local monitors (integrity, kill-switch, SOS scheduler). Starting this service is guarded by POST_NOTIFICATIONS on Android 13+; no data transmission occurs.

Implementation notes:

Network loggers/dispatchers (media capture, shutdown, SOS, SIM-swap) are backed by no-op delegates.
All capture files (photo/audio/video) are stored in app cache, encrypted locally for processing, then deleted. No upload endpoints are configured.
Control plane endpoints are initialized as disabled; telemetry queue is cleared on startup.

Accessibility Service

The app offers an optional AccessibilityService to intercept launches of selected protected apps and gate them behind authentication. Enabling it requires explicit user action in system settings and an in-app consent record. The service observes window state changes only to identify the foreground package; it does not transmit events off-device.

The AccessibilityService also enables distress PIN detection on the lock screen, allowing covert SOS triggers without visible indicators. This capability requires both Accessibility Consent and Phone Data Consent before activation.

Google Play User Data Policy Compliance

LockLoom implements two separate in-app consent disclosures for sensitive data access, each complying with Google Play's User Data Policy. Consent is immutably recorded with timestamps and functionality is gated until consent is granted.

1. Accessibility Service Consent

What data is accessed: LockLoom's optional AccessibilityService monitors app launch events (window state changes) to pause or hide protected apps until authentication succeeds, log policy bypass attempts for local security telemetry, and detect distress PIN entry on the system lock screen for covert SOS triggers. Data stays on-device.

Consent Property	Implementation
Disclosure Location	Dedicated "Launch Monitoring Disclosure" screen shown during normal app usage
Consent Mechanism	Checkbox ("I understand and consent...") + "Continue to Android settings" button
Persistence	Consent timestamp immutably recorded in device-protected storage (SharedPreferences)
Feature Gating	AccessibilityService cannot be enabled until consent is recorded; distress PIN setup is blocked without accessibility consent

2. Phone Number Data Consent

What data is collected: Phone numbers you enter as emergency contacts (stored locally only), SMS messages sent directly to these contacts when you trigger a distress PIN, your device's phone number (may be included in alerts), and GPS location (if available). Alerts are sent directly to your configured emergency contacts via SMS/email — never through any LockLoom server.

A. Phone Data Disclosure Dialog (Build 313+): Modal dialog shown when user attempts to save phone numbers. Checkbox + "I Agree" button. Modal cannot be dismissed without explicit action (dismissOnBackPress=false, dismissOnClickOutside=false).

B. Distress PIN Data Sharing Consent (Build 347+): Inline card displayed directly above distress PIN entry fields. Separate consent timestamp recorded with date display. Distress PIN cannot be set until BOTH accessibility consent AND data sharing consent are granted.

Consent Architecture Summary

Feature	Requires	Storage	Gating
Accessibility Service	Accessibility Consent only	Device-protected SharedPreferences	Service cannot be enabled until consent recorded
Save Emergency Phone Numbers	Phone Data Consent	PhoneDataConsentStore (device-protected)	Save button triggers consent dialog if not already granted
Set Distress PIN	BOTH Accessibility + Data Sharing Consent	Separate timestamps for each	Submit button blocked with toast explaining which consent(s) missing

Immutability: All consent timestamps are written to device-protected storage. Once recorded, consent cannot be retroactively modified — only revoked by the user through explicit action. Consent version tracking ensures users must re-consent if disclosure text changes materially.

Security Hardening — Runtime Protection

Measure	Details
FLAG_SECURE on security activities	All security-critical activities apply FLAG_SECURE to prevent screenshots, screen recording, and display on non-secure displays. Protects authentication screens from capture.
Clipboard auto-clear	ClipboardSecurityManager automatically clears the system clipboard when leaving security activities, preventing sensitive data from persisting in clipboard history.
Backup prevention	Android Auto Backup excludes ALL data domains. For Android 12+, data_extraction_rules.xml additionally blocks cloud backup and device-to-device transfer, preventing forensic extraction via ADB backup.
Runtime integrity detection	On-device checks for Frida/Xposed hooking, root indicators (su, Magisk), native hooks (LD_PRELOAD), debug/emulator environments. Constant-time comparison prevents timing attacks. No data transmitted.
Play Integrity attestation	Uses Google Play Integrity API for device attestation. Verdict evaluated locally. Cryptographic nonces prevent replay attacks. Nonce and verdict remain on-device.
Memory obfuscation	Security-sensitive strings are Base64-encoded and decoded only at runtime. Combined with ProGuard obfuscation, this prevents static analysis from identifying security logic.
MFA session hardening	MFA session tokens encrypted with AES-GCM and validated via HMAC. Keys stored in Android Keystore with HSM backing when available. Sessions bound to device.

Data Handling & Retention

Local-only Processing

Photos, audio, and video are captured to app cache, encrypted with a device-specific key, and then deleted.
SIM-swap uses a local hash of SIM info; the previous/current hash lives in app/private storage.
Accessibility events are observed transiently to gate app launches; they are not exported.

No Control Plane

ControlPlaneEndpoints are initialized in a disabled state.
On startup, the telemetry queue is cleared.
All "remote logger/dispatcher" interfaces resolve to no-op implementations.

Platform Guardrails & Version Notes

USB guarding prefers setUsbDataSignalingEnabled on Android 14/15+ and falls back to DISALLOW_USB_FILE_TRANSFER on Android 7+.
forceStopPackage is invoked only on Android 7.0+ when available to a DO.
Bluetooth monitoring honors BLUETOOTH_CONNECT (12+) or legacy permissions; if missing, the system defaults to "disconnected" without crashing.
Foreground service types are set appropriately across OS versions; the service will not start without user notification consent on 13+.

Summary

The DO configuration above reflects exactly what the app enforces on-device and does not add any networked behaviors to LockLoom servers. All sensitive operations (lock, wipe, hide apps, USB guard, force-stop) are strictly local. Distress alerts go directly to user-configured emergency contacts via SMS and email — never through any backend.

User consent is paramount: Both Accessibility Service usage and Phone Number data collection require explicit in-app consent with immutable timestamp recording. Features are gated until consent is granted, ensuring compliance with Google Play's User Data Policy.