Time Stop

Precision app-time control for Android power users who want policy, telemetry, and enforcement in the same loop.

Stock screen-time tools are usually built for reports, daily caps, and focus modes. Time Stop is built for people who want sharper controls: per-app quotas, per-launch timers, weekly allow/block windows, shared group budgets, cooldowns after forced exits, Hook verification, and diagnostics that show what is actually happening inside the target process.

Why Not Just Use Stock Screen Time?

Different Android vendors ship different screen-time features, but the usual model is still broad and UI-driven. Time Stop prefers LSPosed when a current Hook is active and otherwise provides non-root control through accessibility foreground events plus Android usage access.

- Dimension: Core model Stock screen time: Usage reports, daily limits, focus modes Time Stop: Composable enforcement rules for selected apps

- Dimension: Time granularity Stock screen time: Mostly daily totals Time Stop: Daily quota + per-launch timer + post-exit cooldown

- Dimension: Schedule logic Stock screen time: Commonly fixed focus windows Time Stop: Allow-only or block-during weekly windows, multi-day and overnight aware

- Dimension: Shared budgets Stock screen time: Rare or vendor-specific Time Stop: App groups with one shared daily allowance

- Dimension: Enforcement path Stock screen time: System blocker or reminder Time Stop: Countdown plus force exit by default, or an optional standalone Time Stop break page

- Dimension: Observability Stock screen time: Usually hidden Time Stop: Hook heartbeat, rule source, limit hits, and diagnostic logs

- Dimension: Runtime Stock screen time: System feature Time Stop: LSPosed when available, or non-root accessibility + usage access

Time Stop is not a soft "please stop scrolling" timer. It is a small policy engine for app usage: rules, foreground accounting, warning UI, exit execution, statistics, update checks, and field diagnostics all live in one workflow.

Feature Highlights

- Feature: Independent app rules What it does: Each app keeps its own enabled state, daily quota, per-launch quota, schedule windows, warning style, and cooldown behavior.

- Feature: App groups and shared allowance What it does: Put multiple apps into one group with shared daily, per-launch, schedule, and cooldown rules. Group members run only the group policy; saved personal rules are suspended and resume after removal.

- Feature: Non-root basic protection What it does: Uses a content-blind accessibility service for foreground package changes plus Android usage access for daily calibration. An opt-in enhanced compatibility mode adds package-only content-change events for ROMs that miss normal window events; it still retrieves no nodes, text, input, or notifications and uses no foreground service or continuous polling.

- Feature: Optional Shizuku enhancement What it does: Shizuku only executes a validated force-stop for configured third-party targets. Missing permission, a stopped service, binder failure, or a protected system package falls back to the normal restriction page.

- Feature: Daily cumulative mode What it does: Uses the stronger source for each app: Android system usage when available, or Hook-local foreground accounting, then resets at local midnight.

- Feature: Per-launch mode What it does: Starts a fresh timer when the target app's main process begins a foreground session.

- Feature: Session planning What it does: Optionally asks for a 5, 10, 15, 30, or custom 1–1440 minute plan when the target process first opens. Quick choices and a direct numeric minute field share one compact page, while the fixed footer keeps exit and skip actions visible. Values beyond the earliest remaining timed quota are rejected.

- Feature: Weekly schedules What it does: Supports allow-only and block-during windows across multiple weekdays, including overnight ranges. Schedule blocks cannot be bypassed with the delay action.

- Feature: Foreground-only accounting What it does: Counts only the onResume to onPause phase. Background residency does not burn the quota.

- Feature: Warning UI What it does: Shows a five-second top banner or opt-in full-screen warning matching the selected global color, with an optional one-shot long vibration, an exit action, and layout handling for portrait, landscape, display cutouts, and immersive apps.

- Feature: Enforcement mode What it does: Defaults to closing the task and safe third-party target process. The themed standalone break page uses a 30-second, single-use internal token, offers an exit-to-Home action, and attempts to pause common media. Media-object hooks are installed only when a target process starts in break-page mode, so force-stop and reopen managed apps after switching modes.

- Feature: Language What it does: Supports system-default, Simplified Chinese, and English UI; Hook warnings use the same preference.

- Feature: Appearance What it does: Offers health green, calm blue, and focus purple across management and target-side surfaces, each with follow-system, light, and dark modes.

- Feature: Delay action What it does: Lets the user add 1-60 minutes for normal time limits while keeping schedule blocks strict.

- Feature: Post-exit cooldown What it does: Blocks reopening for 1-1,440 minutes after a daily or per-launch quota event. A group uses one fixed shared cooldown window for all members; repeated openings never refresh its start or inflate limit-hit counts. Schedule denials do not start cooldown.

- Feature: Group sync loop What it does: Grouped foreground apps synchronize usage every 15 seconds without keeping the manager app alive.

- Feature: Hook and scope status What it does: Reads framework and scope state through the optional libxposed service when supported, can request missing scope with framework confirmation, and keeps the current-version Hook heartbeat as the compatibility fallback.

- Feature: Diagnostics What it does: Logs Hook setup, rule reads, timer starts, sync events, stats writes, and limit exits so configuration problems are traceable.

- Feature: System-app guardrails What it does: Third-party apps can have their target process terminated; system apps only have their UI closed.

- Feature: Updates and feedback What it does: Checks GitHub Releases automatically when the manager opens (rate-limited and configurable), actively prompts for a new stable release, uses Android's download manager for APK updates, and offers email diagnostics or QQ group 1009712674 for feedback and beta participation.

Changing a rule resets the Hook-local accumulator for that app, but Android's system usage for the current day remains part of the daily baseline when usage access is granted. That makes rule tweaking visible, not a loophole.

Installation

1. Install the APK, open Time Stop, select target apps, and save rules or groups. 2. For non-root protection, enable it in Settings and grant the disclosed accessibility service plus usage access. Android manages the service lifecycle; Time Stop adds no foreground service. 3. Optionally enable Shizuku enhancement and grant its permission. It improves execution only and is not used for timing. 4. On rooted devices, enable the module in LSPosed and scope controlled apps. Force-stop and reopen targets after scope changes; a current Hook heartbeat automatically takes priority over non-root timing.

Time Stop checks required non-root permissions when the manager opens and when it returns from system settings. Missing accessibility or usage access is reported as inactive protection; missing Shizuku permission is reported separately while the basic restriction-page fallback remains available.

When upgrading from a build that stored its only rule copy in LSPosed's redirected preferences, open Time Stop once while the module is still enabled. This performs a one-time migration to the stable private manager store. After that migration, disabling LSPosed no longer switches the manager UI to a different rule database.

On frameworks that expose the modern service, Time Stop can read scope before the target app is opened and request missing packages through the framework confirmation UI. Older frameworks fall back to the persisted HOOK_READY heartbeat, so "Hook verified" means the target app has successfully loaded this module version before.

License

Copyright © 2026 时停项目作者 (TACPR). All rights reserved.

This software is provided for personal, non-commercial use only. Modification, redistribution, and commercial use are prohibited without written authorization.