Accessibility Service Disclosure

1. What the Accessibility API does in Anchor

Anchor for Child is a parental control app installed by a parent on a child's Android device. It pairs with a separate Anchor parent app on the parent's phone through a 6-digit code. Once paired, the parent configures rules from their device: which apps are blocked, what the bedtime window is, what the daily time limits are, what the focus periods are.

Anchor uses the Android Accessibility API for a single function: detect when a different app moves into the foreground on the child's device, in real time, so the parental control rules the parent set can take effect immediately.

Without this permission, the child device cannot reliably know which app has just been opened. Android does not expose foreground-app changes to non-system apps through any other public API. A schedule the parent sets up cannot enforce itself unless Anchor knows, the moment a blocked app is launched, that the launch happened. The Accessibility API is the supported Android mechanism for that signal.

2. The prominent disclosure shown inside the app

The user is not asked to grant the Accessibility permission silently. Anchor displays a prominent in-app disclosure before any system permission prompt, and the user has to take action twice to actually turn the permission on.

Step 1. The "One more step" screen

After the child device is paired with the parent's Anchor account, the very next screen is a permissions screen titled One more step. It explains that Anchor needs four permissions to enforce the rules the parent set up. One of those four cards is titled Accessibility service, with the following text visible to the user:

The user must tap Open Settings on that card. Anchor does not auto-enable the permission. The user is then handed off to the Android system Accessibility settings page.

Step 2. The Android system confirmation

Inside Android's own Accessibility settings, "Anchor Parental Control" appears in the list under Downloaded apps. The user must tap it, then toggle Use Anchor Parental Control on, then confirm Android's system warning dialog. That system warning shows the description Anchor supplies:

Only after the user grants the permission at the system level does the Accessibility service actually start. Anchor does not bypass, prefetch, or speed-tap any of these screens.

3. Data accessed through this permission

While the Accessibility service is running, Anchor receives only the following information from the operating system:

• The package name of the app currently in the foreground. Example: com.example.game.
• The system event that fires when the foreground app changes. Anchor uses this signal to know when to start checking the schedule.

That is the entire data scope of the Accessibility permission in Anchor. The package name is compared against the rules the parent set, and if the app is currently restricted, Anchor displays the parental block screen on top of it. No other data path is opened by this permission.

4. Data NOT accessed through this permission

The Android Accessibility API can technically expose far more than what Anchor reads. As a deliberate product decision, Anchor does not access any of the following through this permission or any other:

• Text content displayed inside any app
• Text typed by the child into any app or field
• Notification content, message previews, or push payloads
• Passwords, PINs, or any other input field content
• Screenshots, screen content, or screen recordings
• Audio of any kind, including microphone capture
• Location data of any kind (GPS, Wi-Fi, cell tower, IP)
• Browsing history or URLs visited
• Contacts, address book, call log, or SMS log
• Camera or photo library access
• Clipboard content
• Keystrokes, gesture input, or pointer data

Anchor is built for device-level enforcement, not surveillance. The Accessibility permission is the narrowest possible read on top of Android's foreground-app signal, and nothing else.

5. Stalkerware and Monitoring Apps policy compliance

Google Play's Stalkerware and Monitoring Applications policy requires parental-control apps to declare themselves clearly, stay visible on the device, and not operate in stealth mode. Anchor for Child is compliant on every required point.

• Declared as a parental control app. The Anchor for Child manifest includes android:isMonitoringTool="child_monitoring" on the <application> element, identifying the app under Google Play's parental-monitoring category.
• Installed by the parent, with the child's awareness. Anchor is installed and paired by a parent or legal guardian. The Anchor brand and product are designed around the parent-child relationship, not around concealment from the user.
• Visible app icon. The Anchor for Child app icon stays visible in the system app drawer. The app does not hide its presence from the device user.
• Rules set by the paired parent device. Schedule rules, app blocks, and bedtime windows are configured in the separate Anchor parent app on the parent's phone. The child device receives the rules and enforces them. The child device does not have a hidden silent-configuration surface.
• Persistent disclosure. The Accessibility permission state is visible to anyone who opens Android's system Accessibility settings on the child device, with the description quoted in Section 2 shown by the operating system itself.

6. How a parent or child turns this permission off

The Accessibility permission can be revoked from the child device at any time:

1. Open the Android Settings app on the child device.
2. Go to Accessibility.
3. Under Downloaded apps, tap Anchor Parental Control.
4. Toggle Use Anchor Parental Control to off.

Once the permission is off, Anchor's app blocking and schedule enforcement on the child device will stop working. Anchor does not silently re-enable the permission. The next time the parent opens the Anchor parent app, the parent will see a tamper alert indicating the accessibility service was revoked on the paired child device, because tamper events are part of the parental supervision contract.

7. Contact

For questions about the Accessibility permission, the in-app disclosure flow, or anything else covered by this page: