ScrollLess Core Architecture - Scroll Less Docs

Overview

ScrollLess is a high-privilege digital wellbeing application designed to help users reclaim their time from “infinite scroll” behaviors. Unlike standard apps, this module operates as a background-heavy system utility. It leverages deep Android hooks to monitor which applications are active, intercept incoming notifications to reduce dopamine triggers, and physically block access to distracting apps when predefined limits are reached. The feature’s scope spans from low-level to high-level interfaces.

Architecture & Data Flow

The module follows a architecture, but with a unique “System-to-State” pipeline. Because the primary data source is the Android OS itself (via events), the flow is highly reactive.

Key Components

Component	Responsibility
`ScrollTrackService`	An that acts as the primary “eye,” detecting when the user opens specific social media or “scrolling” apps.
`NotificationListener`	Intercepts system notifications to provide a “PostBox” experience, likely batching alerts to prevent constant interruptions.
`AppTrackerService`	A that ensures the tracking logic remains active and isn’t killed by the OS.
`BlockingActivity`	A transparent, high-priority window that intercepts user interaction when an app limit is exceeded.
`BootReceiver`	Ensures the monitoring engine restarts automatically when the device is rebooted.

Operational Logic

Initialization & Persistence

Upon device start, the BootReceiver triggers the core services. The app uses a (configured via Hilt) to handle periodic data maintenance and sync tasks.

State Management

The system handles three primary states:

Monitoring: The AppTrackerService calculates active screen time in real-time.
Intervention: When a threshold is met, the BlockingActivity is launched with singleTask launch mode to ensure it sits on top of the distracting app.
PostBox Mode: Notifications are suppressed via the NotificationListener and stored in for later viewing in the PostBoxActivity.

Edge Cases & Permissions

The module is highly dependent on sensitive permissions:

Battery Optimization: The app requests REQUEST_IGNORE_BATTERY_OPTIMIZATIONS to prevent the OS from putting the tracker to sleep.
System Alert Window: Used to draw the “Blocking” UI over other applications.
Package Usage Stats: Provides the historical data needed to show usage trends.

Data Engineering & Transformation

The module acts as a data aggregator, transforming raw system events into actionable insights.

Source Tables: While the DAO files aren’t shown, the manifest and dependencies confirm a implementation for storing UsageEvents and NotificationLogs.
Transformation: The ViewModel likely uses combine or flatMapLatest on to merge real-time usage from the service with user-defined limits from .
Performance: To avoid jank, all database writes from the AccessibilityService must be dispatched on Dispatchers.IO to ensure the UI thread (which the Accessibility Service shares) remains responsive.

Dependencies

The feature relies on a robust stack for reliability and dependency management:

Hilt: Manages the lifecycle of the Repository and Services.
Retrofit: Used for syncing usage statistics or fetching remote configurations (via SCROLL_LESS_API_KEY).
Firebase: Utilizes Analytics and Crashlytics (specifically toggled for release builds) to monitor the stability of the background services.
Lottie & Konfetti: Provides visual reinforcement/rewards when users successfully limit their screen time.

// Example of the dependency injection scope found in build.gradle
implementation(libs.hilt.android)
implementation(libs.androidx.room.runtime)
implementation(libs.androidx.work.runtime.ktx)

Modules

In

Res

​Overview

​Architecture & Data Flow

​Key Components

​Operational Logic

​Initialization & Persistence

​State Management

​Edge Cases & Permissions

​Data Engineering & Transformation

​Dependencies