Hi, Stop Gambling — LoopLock

An Android recovery firewall where every attempted loophole can become the next local protection rule—and AI can never unlock it.

Comment

Inspiration

Static gambling blockers remember a list. The difficult moment comes when a person finds a new app, mirror, or other workaround and the blocker remains unchanged. LoopLock asks a more precise question: how can a phone preserve the decision someone made while calm, adapt to a new loophole, and still ensure automation can never weaken protection?

LoopLock is an application-ready beta for voluntary adult self-use on a personally owned Android device. It is a working, installable product for the documented Android reference environment—not treatment, crisis support, surveillance, a global public release, or a promise of tamper-proof protection.

What it does

The user reviews and starts a time-bound recovery commitment. Deterministic Android code blocks the selected harmless BetBurst fixture locally. If the user separately pre-authorized new-install quarantine, installing the harmless LuckyMirror fixture creates a quarantine rule before any network request.

A retryable background workflow sends one bounded event to a private Cloud Run service. A Google ADK agent using Gemini 3.5 Flash classifies only the controlled fixture metadata and can return only TIGHTEN or REVIEW. Firestore stores one minimal idempotent event/result record. The phone then applies a closed monotonic validator: a matching additive rule may be accepted; malformed, late, mismatched, duplicate, or weakening output retains quarantine and cannot modify the commitment.

The demo disables network access and proves the accepted LuckyMirror rule still blocks from local state. It also sends a deliberately invalid UNLOCK proposal through the real local validator and shows ACTION_NOT_ALLOWED with the same end time and retained rule.

How we built it

  • Native Kotlin, Jetpack Compose, Room, WorkManager, and a package-only Android accessibility service for the application-ready consumer beta.
  • Versioned JSON Schemas shared by Kotlin and Python for a closed event and proposal contract.
  • FastAPI plus Google Agent Development Kit on a private Cloud Run service.
  • Gemini 3.5 Flash through Vertex AI for bounded fixture classification.
  • Firestore for minimal, idempotent, lease-fenced event/result state.
  • An IAM-authenticated Mac proxy with adb reverse for demo connectivity; it is explicitly not the production mobile-authentication design.
  • Harmless repository-owned fixture APKs with no gambling mechanics, accounts, payments, advertising, analytics, network access, or third-party assets.

The enforcement trust boundary is intentionally asymmetric: Android can create, persist, validate, and enforce rules. The agent can propose a tighter rule but has no tool, credential, endpoint, or code path that can unlock, delete, shorten, disable, or directly enforce one.

Challenges

The hardest product decision was being honest about Android. A normal consumer app cannot prevent a user from revoking accessibility permission or uninstalling it, and Google Play policy imposes important limits on non-accessibility use of accessibility services and package visibility. LoopLock therefore reports Action required when permission is gone and treats managed-device strong mode as separate future work.

The hardest engineering work was making retries safe. Local quarantine must exist before upload; cloud processing must be idempotent; raw metadata must be scrubbed after terminal processing; duplicate or late responses must be no-ops; and wall-clock rollback must not cause early expiry. Those properties are tested across Kotlin, on-device Room tests, and Python.

Accomplishments

  • Two clean end-to-end rehearsals passed through Android, the private Cloud Run service, Google ADK, Gemini 3.5 Flash, and Firestore.
  • A fresh installed-APK verification on Android API 36 completed the full local lifecycle: honest missing-permission state, selected-app blocking, new-install quarantine, two retained rules, planned expiry, and normal access after the end.
  • Local quarantine preceded upload, and an accepted additive rule continued blocking offline.
  • Three identical cloud retries produced one minimal terminal Firestore document.
  • A visible UNLOCK attempt was rejected without changing the commitment end or protection rules.
  • The current suite passes 27 Android JVM tests, 14 API-36 on-device tests, and 28 backend tests.
  • The product collects no screen content, typed text, screenshots, messages, contacts, financial data, full app inventory, or real gambling activity.

What we learned

Agent safety is clearer when authority is designed out, not merely requested in a prompt. Gemini is valuable here because it interprets a new event inside a small closed action space. The phone remains responsible for policy monotonicity and enforcement. We also learned that privacy and idempotency reinforce each other: a stable opaque event ID and target hash are sufficient to prove retry behavior without storing an account or long-form activity history.

What's next

Production work would require lived-experience and clinical co-design, false-positive review and appeals, security and privacy assessment, accessibility and Google Play policy review, broader curated app/domain intelligence, delayed recovery governance, and a separately designed managed-device mode. Site blocking and arbitrary installed-app discovery are not claims of this hackathon build.

Data sources and third-party code

The working demo uses only repository-owned fake package names and metadata; it does not use a gambling provider, third-party gambling dataset, account, payment, or personal activity. Standard open-source dependencies are declared and pinned in Gradle and backend/uv.lock, including AndroidX/Jetpack, Kotlin serialization, Retrofit/OkHttp, FastAPI, Pydantic, Google ADK, and the Google Cloud Firestore client. The project was newly built during the submission period with Codex used as a coding and documentation assistant.

Built With

  • android
  • cloud-run
  • docker
  • fastapi
  • firestore
  • gemini-3.5-flash
  • google-adk
  • jetpack-compose
  • kotlin
  • python
  • room
  • vertex-ai
  • workmanager
Share this project:

Updates

Submission history