How Anchor holds ยท Tamper events

What happens when your kid tampers with parental control settings. Tamper events surface.

You know because Anchor surfaces tamper events in real time: Accessibility revoked, Device Admin disabled, clock manipulated, suspicious app installed, force-stop attempted. The events stream to your parent feed when the kid's device is online, and queue with original timestamps if the device was offline at the time.

The events Anchor surfaces when a child tries to disable enforcement. Real-time when the device is online, queued offline with original timestamps preserved when the device is offline.

See the event types Read the Bypass Test

Anchor's tamper detection runs continuously on the child device through TamperDetector, which polls permission states and surfaces events when something changes. The events Anchor surfaces include Accessibility revoked (CRITICAL), Overlay permission revoked (HIGH), Usage Stats revoked (HIGH), Device Admin disabled (CRITICAL), time or timezone changed, force-stop or kill of the enforcement service detected at restart, Safe Mode boot detected, and suspicious app installed (sideloaded clone in a blocked category). Each event carries a severity, the device state at the moment of the event, and human-readable details that flow to the parent feed. When the device is online, events surface in real time. When the device is offline, the offline tamper queue (Layer 04) preserves every event locally with its original timestamp and flushes to the parent app on reconnect. A revocation attempted at 9:47 p.m. while the device is in airplane mode arrives in the parent feed as a 9:47 p.m. event, not a delivery-time event. Anchor is Android-exclusive at present, with other platforms on the roadmap without committed timing.

The event types

What Anchor surfaces, event by event.

Four severity-classified event types, each tied to a specific tamper attempt Anchor's detector recognizes.

  1. 01
    Accessibility Service revoked: CRITICAL

    The kid opened Settings, navigated to Accessibility, found Anchor in the installed services list, and toggled it off. Anchor's TamperDetector polls Accessibility state and detects the transition from enabled to disabled. The event surfaces with severity CRITICAL because Accessibility is the permission Anchor uses to detect which app is in the foreground. Without it, schedule enforcement stops working.

  2. 02
    Device Admin disabled: CRITICAL

    The kid opened Settings, navigated to Device Admin apps, and toggled Anchor's admin grant off. The TamperDetector polls Device Admin state. On detecting the transition from enabled to disabled, Anchor emits a CRITICAL tamper event. Device Admin is the foundation of the uninstall block, so its removal is the highest-severity event Anchor surfaces.

  3. 03
    Overlay or Usage Stats revoked: HIGH

    The kid toggled off Display over other apps (Overlay) or Usage access (Usage Stats) for Anchor. These permissions let Anchor present the block overlay and track time-limit consumption respectively. Revocation surfaces as HIGH severity because the capabilities are recoverable when the kid re-grants the permission, unlike Accessibility and Device Admin which require an explicit re-prompt flow.

  4. 04
    Suspicious app installed: LOW

    The kid sideloaded an APK or installed a lookalike of a blocked app from the Play Store. PackageChangeReceiver fires within seconds, checks the new app against the category map and clone-keyword list, and emits SUSPICIOUS_APP_INSTALLED if the install belongs to a parent-blocked category. The event includes the package name, app label, and category so the parent can decide whether to block the new package.

Additional event types include time and timezone changes (detected by TimeChangeReceiver), force-stop or kill of the EnforcementService (detected by service restart logic), and Safe Mode boot (detected by BootReceiver). Every event flows through the same persistence and delivery pipeline.

The structural gap

Why most parental controls do not surface tamper events.

Most Android parental control products report on the cooperative side of supervision: what apps the kid used, how long, when. They surface the activity feed that a cooperative child generates by simply using the device. That data answers the question "what did my kid do today."

What most products do not surface is the bypass-attempt feed: when the kid tried to disable enforcement, when permissions got revoked, when clocks got manipulated, when force-stops happened. The reason most products do not surface these events is that they do not detect them in the first place. Without a continuous polling detector watching for permission state transitions, the moment a kid revokes Accessibility is invisible to the product. The dashboard still says "active" while enforcement has stopped.

The structural gap is the difference between activity reporting and tamper-attempt reporting. The two channels answer different questions: "what did my kid do" versus "did my kid try to defeat the rules." A parent who only sees the activity channel cannot tell when the rules stopped applying. Anchor surfaces both channels.

How Anchor surfaces events

Layer 04: Offline tamper queue.

04 Attack: tamper while offline to suppress the alert

Tamper events queue locally with original timestamps, flush to parent feed on reconnect

Anchor's offline tamper queue is the architectural layer that ensures every tamper event reaches the parent feed regardless of network state. When TamperDetector emits an event, the event writes to tamper-protected local storage on the child device first. The event includes the original timestamp at the moment of detection, the severity classification, the device state at the time, and a human-readable detail string.

If the child device is online, the event flushes to the Anchor backend immediately and arrives in the parent feed within seconds. If the child device is offline (airplane mode, no signal, intentionally disconnected by the kid), the event sits in the local queue until network returns. On reconnect, the queue flushes to the backend with the original timestamps intact. A revocation attempted at 9:47 p.m. with the device in airplane mode surfaces as a 9:47 p.m. event in the parent feed, even if the parent first sees it at 10:23 p.m. when the device comes back online.

The kid cannot suppress the alert by tampering offline. The original moment is what gets recorded, not the delivery moment. Going offline to bypass enforcement does not buy invisibility, it just delays the alert.

Verdict: Holds

The full moat

Layer 04 in the four-layer context.

Tamper-event surfacing lives in Layer 04 OFFLINE. The other three layers generate the events that the offline queue preserves and delivers.

01 Tampering

Watchdog-protected Device Admin

Detects revocation attempts on Accessibility, Overlay, Usage Stats, and Device Admin. Emits the events the offline queue preserves.

02 Clock

Server-truth time

Schedule decisions ride on backend time. The clock-change events Anchor detects feed the same queue.

03 Reset

Parent-side pair persistence

Factory reset emits a device-unbound event. Pair persistence holds the household binding regardless.

04 Offline

Offline tamper queue

Every event from Layers 01, 02, 03 flows through this queue. Timestamps preserved. Delivery guaranteed.

What this means

For your household.

Your kid can still try to tamper. Revoke a permission. Disable Device Admin. Change the clock. Sideload a clone. Force-stop the service. The attempts themselves happen on Android because the OS exposes these controls to the device user.

What changes is what your parent feed shows. Every attempt produces an event with a severity, a timestamp, a device-state snapshot, and a human-readable note. When the device is online, you see the event in real time. When the device is offline, the event queues locally with its original timestamp and surfaces on the next reconnect. The kid cannot trade time for invisibility, and cannot trade airplane mode for a clean window of no enforcement reporting.

Tamper events become the second channel of your parent feed: not "what did my kid do," but "did my kid try to defeat the rules."

See Anchor pricing Join the Founders Offer

How Anchor holds the bypass routes

Per-route deep dives on the bypass attempts Anchor was engineered to close.

Uninstall block

Watchdog-protected Device Admin in detail.

Clock change defense

Server-truth time in detail.

Permission revocation defense

The continuous watchdog in detail.

App cloning defense

Category-aware sideload detection.

Or read the full Bypass Test methodology for the verdict table across all routes and four competitors.

FAQ

About tamper events.

Anchor's TamperDetector polls the child device for permission state transitions and emits tamper events on detection. The event types include Accessibility revoked (CRITICAL), Overlay permission revoked (HIGH), Usage Stats revoked, Device Admin disabled (CRITICAL), time or timezone changed, suspicious app installed (sideloaded clone), force-stop or kill of the enforcement service, and Safe Mode boot detected. Each event carries a severity (CRITICAL, HIGH, LOW), the device state at the moment of the event, and human-readable details that surface to the parent feed.
Anchor's offline tamper queue (Layer 04) preserves every tamper event locally with its original timestamp. When the child device reconnects, the queue flushes to the Anchor backend with timestamps intact. A revocation attempted at 9:47 p.m. while the device is in airplane mode surfaces as a 9:47 p.m. event in the parent feed even if the parent first sees it at 10:23 p.m. when the device comes back online. The original moment is what gets recorded, not the delivery moment.
No. Force-stopping the EnforcementService is itself a tamper event Anchor detects on service restart. Anchor's foreground service architecture survives most kill attempts, and the BootReceiver re-arms enforcement after device reboot. If Anchor Child gets force-stopped, the next service tick detects the state transition and queues a tamper event with the original timestamp. The kid cannot create a clean window of no enforcement by killing the service first.
No. Tamper events are a separate channel from the standard activity feed. The activity feed shows which apps were foregrounded and for how long, sourced from Android's Usage Stats permission. Tamper events show specifically when a kid tried to disable, manipulate, or bypass Anchor's enforcement. The two channels surface together in the parent app but represent different signals: one is cooperative-supervision visibility, the other is bypass-attempt visibility.