Message Minder

A privacy-aware Android assistant that turns actionable messages into calendar plans

Android Java Google APIs Microsoft Graph Version 0.15.0 Private candidate

The goal Reduce the chance of forgetting an appointment or agreed plan without handing private conversations to a general-purpose cloud AI service. Message Minder finds actionable information, preserves uncertainty and keeps the user in control of what reaches their calendar.

01The problem

Appointments and commitments often arrive as ordinary messages: a clinic sends a time, a friend proposes dinner, or somebody changes a plan in a later reply. The useful detail is easy to lose across SMS, email and messaging notifications. Message Minder brings those details into one review and automation workflow.

I am building the app as a personal Android prototype. It focuses on conservative English-language detection instead of assuming that every date or casual question is a confirmed event. Ambiguous details, competing invitations and conflicting times remain visible for review.

02How it works

Capture: read authorised SMS and connected email, with optional notification previews for supported messaging apps.
Classify: separate actionable appointments, tasks and plans from marketing, quoted history and messages about somebody else.
Resolve: extract dates, times, duration and location while retaining uncertainty where the message is incomplete.
Review or automate: request missing details, present tentative items, or create an event when configured safety conditions are met.
Track: retain corrections, cancellations, retry state, undo information and an activity history.

03Conversation-aware plans

The 0.15.0 candidate adds invitation context. A question such as “Fancy lunch tomorrow?” waits for a later, clear acceptance before it becomes a plan. Declines, unrelated replies, stale responses, competing invitations and counterproposals do not silently create an event. When a message omits a clock time, the app can use the user's configured meal time or keep the item for clarification.

This is deliberately bounded logic rather than a claim of general language understanding. The app keeps a limited amount of recent conversation context on the device, filters its own automated replies, and provides a manual acceptance path when Android does not expose a sent RCS preview.

04Calendar and account integration

Google Identity Services for Gmail and Google Calendar authorisation.
Microsoft AppAuth and Graph-compatible email/calendar flows.
User selection of the destination calendar rather than an implicit local-calendar fallback.
Stable event or transaction identifiers so retries reuse the original draft and reduce duplicate events.
Optional work-calendar sharing, travel buffers, conflict warnings and provider reminders.

Integration status Google account connection and calendar writing have been exercised during development. Outlook-compatible paths are implemented and tested with isolated transports, but production Outlook registration and live end-to-end verification are still pending.

05Privacy and safety by design

Conversation parsing and decision logic run on the device; no AI backend receives the conversation context.
Android and provider permissions are checked before normal use, and revoked access blocks the affected workflow.
Original message text is excluded from calendar descriptions and invitations unless the user enables the relevant sharing option.
Do-not-add rules can exclude contacts, groups and phrases before calendar automation.
Quiet hours and reply limits constrain automatic clarification messages.
Tokens and provider state use the platform or SDK security mechanisms rather than embedded client secrets.
Erase controls remove captured context while leaving provider calendar events under the user's control.

06Validation evidence

The current documented candidate is version 0.15.0, installed on a Pixel 8. The following checks passed in the project validation record:

214 JVM tests covering extraction, setup gates, conversation acceptance, declines, replay deduplication, privacy and earlier scheduling workflows.
Debug and release lint, debug/test APK builds and an unsigned release AAB build.
Memory-only workflow harness using controlled reply and calendar callbacks.
Isolated Android tests on a real Pixel without sending external messages, invitations or calendar requests.
Cases for out-of-order email, stale acceptance, multiple invitations, counterproposals, saved addresses and shared-message privacy.

These checks establish repeatable behaviour in the tested cases. They do not replace live-provider, usability, accessibility, device-compatibility or long-duration background testing.

07Current limits and release gates

Notification access still depends on the user granting Android permission and on the source app exposing useful preview text.
RCS history is not generally available; sent RCS capture may be missed when no notification preview is produced.
Conversation rules are conservative and English-specific, so unfamiliar wording can be missed or held for review.
A live end-to-end acceptance test with a real calendar and a new RCS conversation remains outstanding.
Locked-device, reboot, offline and live provider-change scenarios need further real-world testing.
Public release requires signing, current store disclosures, provider verification and a viable Google Play SMS-permission pathway.
No production release or public download is being claimed on this page.

08What the project demonstrates

Android application engineering and lifecycle-aware background work.
OAuth, provider API integration and least-privilege permission design.
Privacy modelling for sensitive message and calendar data.
Rule-based parsing, state correlation, idempotent retries and recovery design.
Test-driven iteration with explicit evidence, limitations and release gates.
Translation of an everyday problem into a controlled, explainable workflow.

09Next milestones

Complete the remaining live device, provider, offline and reboot test matrix.
Finish production provider registration and verify the Outlook path end to end.
Refresh store assets and complete accessibility and broader device-layout testing.
Resolve Play distribution eligibility, signing and privacy-disclosure requirements before any public release.

back to projects