Women Safety SOS Android App with Shake Trigger, Live Location Sharing and Emergency Contacts

The primary channel is SMS, sent from the user's own phone through Android's SMS manager, so alerts work even where mobile data is unavailable. Each message carries a help text plus a live-location link. Live location streaming between phones additionally needs internet, since position updates travel through Firebase. SMS delivery speed depends on the carrier network, typically seconds on a healthy signal.

Yes, that is the point of the design. Shake detection runs in an Android foreground service, so it keeps sampling the accelerometer while the screen is off or the app is in the background. However, some phone makers apply aggressive battery optimisation that can pause or kill background services; the user manual documents the exact battery settings to whitelist the app, and the viva discussion covers this platform reality.

Sending SMS alerts uses the user's own mobile plan, so standard carrier SMS charges apply per message — there is no subscription fee inside the app. Live location streaming uses a small amount of mobile data through Firebase. The prototype and documentation carry no recurring cost; the only real-world running cost is whatever the user's carrier charges for SMS, which the report states explicitly.

Yes. The SOS SMS path needs only cellular signal, not mobile data or Wi-Fi — the message goes out through the carrier like any text message, carrying the last known GPS coordinates. Live map streaming pauses without internet and resumes when the connection returns, and the app tells the user which mode each alert used. The limitations section documents this split behaviour so expectations stay realistic.

It is a practical disguise, not a security guarantee. Discreet mode replaces the app screen with a working calculator, so a casual glance reveals nothing, and the app icon and name can be customised to look unremarkable. A determined person inspecting the phone could still find it. The report frames this honestly: discreet mode buys time and privacy from casual observation, nothing more.

Yes, for Computer Science, IT and mobile-application programmes. It covers the full Android stack students are examined on: runtime permissions, background and foreground services, sensor APIs, location services, SMS management, local databases and Firebase integration. The honest treatment of platform limits — battery optimisation, SMS costs, GPS dependence — gives the viva discussion real substance beyond the feature list. Suitable for B.E./B.Tech final-year projects in Computer Science, IT and Mobile Application Development. problem: In an emergency, a person in distress is often unable to unlock the phone, find an app and type a message — yet most safety apps demand exactly that sequence. Manual SOS flows take too long and draw attention, shared locations arrive as one-time static pins that go stale within minutes, and emergency contact lists are frequently outdated or contacted in no useful order. A safety app must minimise the interaction needed to raise an alert, keep location live for the whole incident, reach contacts in a defined priority order, and offer quiet deterrents for situations where a loud alarm is unsafe. concept: A native Android app (Kotlin) built around two minimal-interaction triggers: a 1.5-second press-and-hold SOS button and a background accelerometer service that fires on a hard shake. Both open a 5-second cancel window, then send an SMS with a help message and live-location link to emergency contacts in priority order. Live location-sharing sessions stream GPS positions through Firebase to trusted contacts until stopped. A siren, fake incoming-call screen and discreet calculator mode cover unsafe situations quietly; an alert log timestamps everything. Platform limits (SMS cost, GPS/internet dependence, battery optimisation) are documented as they behave on real devices. features:

• [Hold-to-activate SOS button] Large on-screen SOS button firing only after a sustained 1.5-second press, with a live progress ring — implemented.
• [Emergency contacts with priority order] Add, edit and reorder trusted contacts; SOS messages go out in priority sequence — implemented.
• [Shake-triggered SOS] Background accelerometer service with Low/Medium/High sensitivity — implemented.
• [Live location-sharing sessions] GPS position streamed to selected contacts' map view until stopped — implemented.
• [5-second cancel window] Countdown with cancel option on every trigger — implemented.
• [Loud siren deterrent] Media-volume alarm tone with strobe visual — implemented.
• [Fake incoming-call screen] Believable excuse-to-leave call display — implemented.
• [Discreet calculator mode] App hides behind a working calculator — implemented.
• [Automatic escalation to security desks] Forwarding unanswered SOS to campus security or volunteers — future scope.
• [Fall detection] Accelerometer-plus-gyroscope fusion for automatic accident detection — future scope. requirements: Development machine with 8 GB RAM (minimum) and Android Studio; Kotlin with Android SDK, minimum API 26 (Android 8.0); a physical Android test device with accelerometer, GPS and SMS capability; Fused Location Provider and Firebase Realtime Database for live-location streaming with an internet connection; runtime permissions for SMS, fine location, foreground service and notifications; any modern browser for viewing the interactive UI prototype. deliverables: Complete Android app source code in Kotlin (SOS, shake service, location sharing, siren, fake call, discreet mode); interactive HTML UI prototype of every screen and flow; test documentation for background-service survival, SMS delivery and GPS behaviour; project report PDF; PPT presentation; viva Q&A preparation document; user manual with battery-optimisation whitelist steps. limitations: SMS alerts use the user's own mobile plan and standard carrier charges apply; SOS over SMS needs cellular signal while live map streaming additionally needs GPS and internet; background shake detection is subject to Android battery optimisation and aggressive OEM task killers can stop the service; siren loudness varies by device speaker with no decibel claim; discreet mode hides the app from casual observation only; the app assists response and never guarantees rescue or response times. timeline: Built-to-order project with a typical delivery of 3–4 weeks from order confirmation: week 1 covers UI prototype sign-off and trigger/sensor design; weeks 2–3 cover the native Android build including SMS, location streaming and the shake service; week 4 covers device testing, the report, PPT and viva Q&A. Timelines shift with customisation requests; the confirmed delivery date is fixed on the quotation. support: Every order includes a code and architecture walkthrough, help installing and running the app on the student's own Android device, the complete viva Q&A set, and post-delivery support for build or run issues during the review period. Customisation requests raised after delivery are quoted separately.