PRIMARY AUDIENCE
People managing their own Android phone and who want an additional recovery/control path beyond the OS vendor’s default tools. Deploy only on devices you own or have explicit permission to manage.
Android device recovery · Owner-controlled security
Veto
Android security app
A multi-channel toolkit for locating, alerting, and managing your own lost Android device.
Interface overview
1,165 across four v1.0.0 APK assetsStable release asset downloads
40 stars · 4 forks · 0 open issuesRepository snapshot
16 Oct 2026Latest repo push
Website says v2.0 Pro; latest GitHub stable release is v1.0.0Version discrepancy
01 / WHY
The problem I chose to solve
The most useful way to understand this project is to start with the friction behind it, then examine the system choices made to address that friction.
A lost phone is difficult to recover if one control channel fails. A cloud-only tracker cannot help when mobile data is unavailable, and an alert that can be easily muted is weak at drawing attention. Device recovery also needs an owner-controlled authorization model because the same capabilities can be misused if they are covert or unauthenticated.
Veto is an Android security and recovery project built around transport redundancy. The documented design combines a web dashboard and push delivery with SMS-based control paths, validates commands on the device, and routes permitted actions through native Android capabilities. The strongest defensible public story is reliability under different connectivity conditions—not surveillance.
02 / WHO IT SERVES
Where it fits in the real world
A strong implementation has a bounded audience and context. These are the use cases supported by the current design—not a claim that all of them have been validated at scale.
WHAT MAKES IT DISTINCT
- Multiple control transports: web/push and SMS-oriented commands
- Native Android actions for alarm, lock, location, and other device-recovery operations
- Command protection is documented using PIN-derived checks and encrypted command handling
- Dashboard and device app divide remote control from local execution
- Designed around minimizing always-on workers and acting when a command arrives
03 / PRODUCT SURFACE
What the system actually does
An overview of key capabilities and system features.
CAPABILITY / 01
Locate and alarm
The app documents location retrieval and a high-volume alert flow.
CAPABILITY / 02
Theft-mode macro
A combined response can coordinate device alerting and configured recovery actions.
CAPABILITY / 03
SMS command path
SMS provides a fallback when internet connectivity is not available, subject to carrier and Android permission restrictions.
CAPABILITY / 04
Web dashboard
The website describes command dispatch, maps, telemetry, and media handling.
CAPABILITY / 05
Secure commands
The README discusses AES-GCM command encryption, PIN protection, allowlisting, and salted PIN verification.
CAPABILITY / 06
Media storage
Optional uploads to a Google Drive account are documented; review consent, storage, and access controls carefully.
04 / SYSTEM MAP
Architecture & data flow
Architecture and system flow overview.
LAYER / 01
Owner console / SMS
The authorized owner issues a command through the web interface or an allowed SMS path.
LAYER / 02
Transport & delivery
Firebase Cloud Messaging / SMS / notification paths deliver an instruction when the matching service is configured.
LAYER / 03
On-device validation
The Kotlin client checks the configured PIN/allowlist/encryption rules before interpreting a request.
LAYER / 04
Permission-bound action
Android location, alarm, lock, or media capability runs within OS and permission limits.
IMPLEMENTATION STACK
Kotlin / Android, Next.js dashboard, Firebase Auth / Firestore / FCM, native SMS receivers, Android device policy/accessibility APIs, Google Drive integration, encryption and PIN-verification routines.
Kotlin / AndroidNext.js dashboardFirebase Auth / Firestore / FCMnative SMS receiversAndroid device policy/accessibility APIsGoogle Drive integrationencryption and PIN-verification routines.
05 / ENGINEERING JUDGMENT
Decisions behind the implementation
Engineering choices and design decisions behind the implementation.
- Use multiple command transports so recovery does not depend on one cloud connection.
- Keep the Android app as the enforcement point; server-side messages should not be treated as trusted by default.
- Combine actions into a recovery macro while leaving permissions and access under device-owner control.
06 / SCOPE & BOUNDARIES
Technical Considerations
Key technical details and system scope considerations.
- Use only for devices you own or where every relevant user has given explicit informed authorization. Do not market covert recording, stalking, or stealth monitoring.
- Camera, microphone, location, device-lock and background execution behavior is constrained by current Android rules, OEMs, and permissions. Tests are needed for each supported build.
- The live marketing site labels the product v2.0 Pro, but the GitHub stable release list still reports v1.0.0 (published 24 Jul 2026). Reconcile the displayed product version before public launch claims.
- Release download counts are binary asset download events, not unique people or proven recoveries.
07 / NEXT ITERATION
What I would improve next
The next step is not simply adding features. It is increasing reliability, evidence quality, user trust, and clarity about the boundaries of the system.
NEXT / 01
Align the public website version with the actual release/build channel.
NEXT / 02
Publish a permission and consent matrix, with user-visible indicators and audit events for sensitive actions.
NEXT / 03
Test lost-network, SIM-change, OS permission revocation, reboot, battery optimization, and failed command-delivery cases.
NEXT / 04
Document what media is uploaded and how it is retained or deleted.
08 / SOURCES
Sources & Resources
Project repositories and resource links.