Android focus system · Local-first productivity

Reality
Android application

A personal operating layer for focus, routine, reflection, and more intentional device use.

Active release line · v1.1.1 stable on GitHubSource: Public source-available repository
Custom developer-drawn interface study for Reality; illustrative, not a captured app screenshot.
Interface overview
2,034+ downloads (site-reported)Official site counter
2,075 download events summed across 28 assets / 16 releasesGitHub release assets
v1.1.1 · 24 Aug 2026Latest stable release
29 stars · 3 forks · 2 open issuesRepository snapshot
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.

Digital wellness apps often track behavior without helping users change the conditions around it; simple timers can be easy to bypass, while productivity systems can fragment focus, sleep, habits, health signals, and calendar planning into separate products. The product concept is to make focus and routine an integrated part of how the Android device behaves.


I designed Reality around a stronger boundary than a standard to-do list: focus tools, app-blocking rules, bedtime awareness, reflections, and wake-up routines operate close to the Android device itself. The app emphasizes local-first personal records and gives users control over optional integrations. AI is an assistant path, not a reason to upload every habit or journal by default.

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.

PRIMARY AUDIENCE

People who want structured focus sessions, app-distraction controls, routines, evening reflection, calendar planning, wake-up challenges, and a way to understand personal patterns without making the product a social platform.

WHAT MAKES IT DISTINCT
  • Focus timer and app-blocking capabilities live in one Android app
  • Nightly reflection and next-day routine planning instead of timer-only productivity
  • Health Connect integrations use Android’s native health store where configured
  • Optional Google Workspace sync is designed around user-owned credentials (BYOC)
  • AI support is documented through Cloudflare Workers/Workers AI and a bring-your-own-key pathway, so do not describe every AI feature as fully on-device
03 / PRODUCT SURFACE

What the system actually does

An overview of key capabilities and system features.

CAPABILITY / 01

Tapasya focus timer

A strict focus experience, plus a companion web timer, aims to make session completion more deliberate.

CAPABILITY / 02

App blocker

Accessibility-service based app-window monitoring and time cooldown mechanisms are documented.

CAPABILITY / 03

Nightly protocol

WorkManager-driven evening reflection and next-day scheduling flow.

CAPABILITY / 04

Sleep and health context

Health Connect APIs are used for selected sleep, activity, and health-related insights when permissions are enabled.

CAPABILITY / 05

Math-based alarm

A wake-up flow uses math challenges and controls designed to reduce easy dismissal.

CAPABILITY / 06

Local intelligence

The app documents MCP-style tool registrations for tasks, calendar blocks, and app-block configurations.

CAPABILITY / 07

Optional sync

The README describes direct sync through user-controlled Google Cloud OAuth credentials.

04 / SYSTEM MAP

Architecture & data flow

Architecture and system flow overview.

LAYER / 01

Android UI & permissions

Native Kotlin screens request permissions only when their corresponding features are enabled.

LAYER / 02

Local app state

Room / local preferences keep habits, journal, and routine information on the device by default.

LAYER / 03

Native system hooks

Accessibility, alarms, WorkManager, and Health Connect connect routines with Android capabilities.

LAYER / 04

Optional external services

Google Workspace sync uses user-owned OAuth setup; AI prompts may pass through Cloudflare/model infrastructure.

IMPLEMENTATION STACK

Kotlin, Android SDK, Room, encrypted preferences, WorkManager, Accessibility Services, Health Connect, Google Workspace APIs via BYOC, Cloudflare Workers/Workers AI for assistant calls.

KotlinAndroid SDKRoomencrypted preferencesWorkManagerAccessibility ServicesHealth ConnectGoogle Workspace APIs via BYOCCloudflare Workers/Workers AI for assistant calls.
05 / ENGINEERING JUDGMENT

Decisions behind the implementation

Engineering choices and design decisions behind the implementation.

  • Use local-first storage for personal habit data instead of requiring a central account database.
  • Expose advanced integrations behind feature toggles and permission prompts.
  • Treat routine-building as a system workflow: focus, reflection, sleep, and next-day planning are connected.
  • Offer optional external integrations rather than forcing every user to connect a cloud account.
06 / SCOPE & BOUNDARIES

Technical Considerations

Key technical details and system scope considerations.

  • The public repository is source-available, but its licensing status is not equivalent to a confirmed permissive/open-source license;
  • Personal records may stay local by default, but AI requests and optional sync can transmit selected data to third-party infrastructure. Privacy statements should describe those paths exactly.
  • Android accessibility and device-admin behavior varies by OS version and OEM. Do not claim an unbypassable blocker across all devices.
  • Download totals count repeated release-asset downloads, not unique installations or active users. Site counter and GitHub asset totals are separate measurements.
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

Add a tested Android version/device compatibility matrix.

NEXT / 02

Document exactly what context is sent to the remote AI model and let users disable it.

NEXT / 03

Publish benchmarks for app launch, battery usage, and focus-session reliability before making performance claims.

NEXT / 04

Reconcile the public download counter with the GitHub release artifact counter.