Inspiration
“Text me when you get home” is something many women hear every day. But what happens if a situation becomes unsafe before you can reach your phone? We wanted to build something that could help in that moment, without requiring someone to unlock a screen or visibly ask for help. Guardian Angel grew from that idea: discreet support that fits into everyday life, from walking home at night to meeting someone new.
What it does
Guardian Angel is an Android personal safety prototype that combines safer journey planning with hands-free alerts.
Users can explore reported incidents, nearby safe places, and route options that consider lighting and safety alongside travel time. With Walk with Angel, the app follows their journey and can notify a trusted contact when they arrive.
If something feels wrong, a wake word activates discreet recording and transcription. Personal codewords let users keep a record, alert trusted contacts with their location, call their first guardian, or send an all-clear. Audio processing happens entirely on the phone, keeping recordings off external servers.
How we built it
We built Guardian Angel with Kotlin and Jetpack Compose, using Material 3 for the interface and Room for local storage.
For on-device audio processing, we combined sherpa-onnx for wake-word detection, Moonshine Tiny and Silero VAD for transcription, CAM++ for voice identification, and YAMNet for sound-event detection. Google Maps, fused location services, and Berkeley PD and UCPD open data support the mapping experience.
An Android foreground service keeps an active journey running when the phone is locked or another app is open.
Challenges we ran into
A major challenge was bringing speech recognition, location tracking, maps, and alerts together in a flow that someone could use under stress.
Android permissions also shaped the experience. Direct SMS alerts require permission; without it, the app must open a prefilled message for the user to send. Making that difference clear matters.
Running audio models locally introduced tradeoffs in app size and performance. Reliability remains an area for improvement: wake-word thresholds need testing in noisy, real-world environments, and transcript storage needs stronger protection.
Accomplishments that we're proud of
We’re proud of bringing journey planning, discreet voice controls, location sharing, and session records into one working prototype.
Keeping audio processing on the device was an especially meaningful achievement. We also built a journey experience that continues with the phone locked and added automated tests across core components.
Most of all, we’re proud that the design centers a practical question: What can someone actually do when reaching for their phone feels unsafe?
What we learned
We learned that a safety app needs clear, predictable behavior. Users need to know whether an alert was sent, what information was shared, and what happens when a permission is unavailable.
We also learned that privacy requires attention throughout the system. Local audio processing is a useful foundation, but secure storage, deletion controls, and careful testing matter just as much.
Safety estimates need honest communication, too. Reported incidents and lighting can inform a route choice, but they cannot guarantee that a route is safe.
What's next for Guardian Angel
Our next step is to test the prototype with consenting users in controlled scenarios, focusing on voice activation, false alarms, accessibility, and alert delivery.
We also want to encrypt stored transcripts, reduce the size of bundled models, improve battery efficiency, and make permission and delivery status easier to understand.
As we expand beyond Berkeley, we plan to evaluate local data quality carefully and refine the experience through feedback from women with different routines and safety needs.
Log in or sign up for Devpost to join the conversation.