raianrashidrimon/echosafe-a_woman_safety_app

1. Project shape

- EchoSafe is a single-module Android app in app/, written in Java with Gradle Kotlin DSL build files.

- The app is structured around Activity-based screens rather than fragments or a visible service layer.

2. Startup and navigation flow

- SplashActivity is the entry point for app launch.

- From there, users are routed into the authentication flow (LoginActivity, RegistrationActivity) or into the main app.

- HomeScreenActivity acts as the central hub from which the safety features are launched.

3. Authentication boundary

- The repo includes google-services.json, so Firebase is integrated.

- The login/registration screens are likely backed by Firebase authentication or related Firebase setup, forming the app’s main external backend dependency.

- This is the main boundary between the device UI and cloud identity services.

4. Main feature hub

- HomeScreenActivity is the orchestration layer for the app’s core actions.

- It connects the user to separate feature screens for SOS, siren, contacts, audio recording, fake call, location, self-defense, and helpline content.

5. Emergency contacts subsystem

- AddContactActivity and ViewContactsActivity manage the emergency contact list.

- The README says contacts are limited to up to 5, and users can add, view, and delete them.

- This subsystem is important because it feeds the SOS workflow.

6. SOS / location sharing path

- The SOS feature is described as sending a text message with the user’s current location to saved contacts.

- This implies interaction with Android location APIs and SMS/texting capabilities.

- Data flow is: location acquisition → message construction → dispatch to emergency contacts.

7. Location-only feature

- MainActivity appears to represent the “Where Am I?” capability from the README.

- This is a separate location lookup/use case from SOS, likely focused on showing the user’s current position without messaging.

- It shares the same device-level location dependency as the SOS flow.

8. Audio evidence and alarm subsystem

- RecordAudioActivity handles audio capture and saves a recording locally as an MP3 after a period of time.

- The app also includes res/raw/siren_sound.mp3, which is used by the siren feature.

- These are two distinct media paths: one records from the microphone, the other plays bundled alarm audio.

9. Fake call and escape aids

- FakeCallActivity generates a fake incoming call experience as a social escape mechanism.

- SelfDefenceActivity and HelpLineActivity are informational/support screens rather than transactional features.

- These screens widen the app beyond emergency response into prevention and guidance.

10. UI/resource layer

- The visual layer is defined entirely in XML layouts under res/layout, with custom drawables for cards, buttons, and branding.

- Themes, colors, and style resources live in res/values, and the siren sound is packaged as a local raw asset.

- This makes the app largely self-contained on-device for presentation and media assets.

11. Platform and infrastructure dependencies

- The app relies on standard Android runtime capabilities: activity navigation, location, audio recording/playback, and messaging/telephony-related functions.

- Firebase is the only visible external cloud integration; no separate server backend or API layer is present in the tree.

12. Testing and quality boundary

- There are both instrumentation tests (androidTest) and unit tests (test), indicating the project follows standard Android test separation.

- The repository is designed as a consumer app with a fairly thin codebase and feature-specific screens, which is important for diagramming the architecture as a UI-driven mobile client.