FamilyGuard
Shared-device parental control built around who is holding the phone.
FamilyGuard is an Android parental control concept for households where one phone may be shared casually by adults and younger siblings. Instead of restricting everyone, it applies limits only when a registered younger user is detected.
The idea is designed for a single shared device, no root access, and practical household use where the parent should stay completely unrestricted.
Project Summary
Most parental control tools assume a child owns their own device. FamilyGuard is built for a different reality: a parent's Android phone that younger siblings sometimes pick up and use.
The core insight is identity-aware restriction. The phone should only enforce time limits and curfews when it recognizes one of the registered younger users, while the parent and other approved adults remain unaffected.
How It Works
| User | System Behaviour |
|---|---|
| Parent | Nothing changes. Full unrestricted access. |
| Older Sibling / Approved Adult | Nothing changes. Full unrestricted access. |
| Registered Junior | Their daily timer starts and curfew / quota rules are enforced. |
| Unregistered Person | Treated as unrestricted by design for this household setup. |
Core Features
Per-child Daily Limit
Each registered junior can have their own screen time quota.
Night Curfew
The phone can lock for a junior when usage happens past the configured curfew time.
Face-triggered Enforcement
Rules are applied based on who the app detects after unlock, not simply because the phone was unlocked.
Session Pause Logic
If the phone changes hands mid-session, the timer can pause instead of punishing the wrong person.
Daily Reset
Limits and lock states reset automatically at midnight.
Parent Settings
The parent can register faces, edit limits, adjust curfews, and temporarily disable the app.
Technical Architecture
| Component | Role |
|---|---|
| Kotlin | Main Android implementation language. |
| ML Kit Face Detection | Finds the face region inside the camera frame. |
| TensorFlow Lite FaceNet | Produces embeddings for face comparison. |
| CameraX | Handles the short front-camera check after unlock. |
| Room Database | Stores registered juniors, usage values, and session records. |
| DevicePolicyManager | Allows the app to lock the screen programmatically. |
| Foreground Service + Receivers | Supports runtime monitoring, unlock detection, and reboot survival. |
Main Components
RegisterActivity
One-time setup flow for registering each junior and saving their restriction profile.
UnlockReceiver
Watches for post-unlock events and starts the face-check flow.
FaceCheckService
The runtime engine that checks the active user and decides whether to allow, time, or lock the session.
FaceMatcher
Compares the live camera frame against stored junior embeddings using a similarity threshold.
LockManager
Applies lock actions when a daily limit is reached or curfew is violated.
MidnightResetReceiver
Resets daily usage values and lock flags at the start of a new day.
Implementation Phases
Known Constraints
The concept works within Android's normal sandbox, which creates some unavoidable tradeoffs.
Post-unlock Window
There is still a short gap after unlock before the app can react and re-lock if needed.
No Pre-unlock Camera Access
Without root access, the app cannot inspect the user before the phone has already been unlocked.
Battery Management Issues
Some Android skins may aggressively kill background services unless manually whitelisted.
Household-specific Design
The logic intentionally treats unregistered faces as unrestricted because the problem is narrowly defined for one family setup.
Want to Talk About It?
Reach out if you want to discuss the Android architecture, the face-matching logic, or the shared-device design decisions behind the app.
Get in Touch