DEV Community: Diven Rastdus

My Expo Device Tests Could Break Without CI Noticing. Here Is the Fix.

Diven Rastdus — Thu, 18 Jun 2026 12:09:29 +0000

My on-device QA used to be an AI tapping my app by pixel coordinates. One regression walk logged 83 raw coordinate taps. It was slow, it was flaky, and when it failed I could never tell if the app broke or the tap landed two pixels off a button.

This is the story of replacing that. The same six launch-blocker flows now run in about 90 seconds, with no model in the loop, plus a Jest guard that makes the whole thing unregressable. The app is Origo, an Expo SDK 56 (React Native 0.85) astrology app I am shipping to the Play Store.

Why the AI fell back to pixel coordinates

I was driving the Pixel 3 with an accessibility-tree tool. Point it at an element, it reads the tree, finds the node, taps the node. On a native app this is fast and stable, because native widgets populate the accessibility tree for free.

React Native does not. A <Pressable> shows up as an anonymous view unless you give it a testID. My app had nine testIDs across 164 files. So the tree-matching found almost nothing, and the tool degraded to its fallback: tap by screen percentage. That is the 83 taps. Every one is a guess at where a button rendered, and every screen size or layout tweak silently invalidates it.

The lesson is boring and load-bearing: an RN app is only as queryable as its testIDs. Fixing the QA speed was downstream of fixing that.

Step 1: testIDs on the flows that matter

I did not testID-everything. I picked the six flows that, if broken, block launch. Those are sign in, upgrade-to-pro opening the paywall, a PRO reading hitting the paywall, editing birth data, synastry (the relationship-compatibility screen) add-person refreshing the list, and sign out. Then I added stable testIDs to exactly the elements those flows touch. That took the count to 99 testIDs across 30 files, each one paying for itself.

Step 2: encode the flows in Maestro, self-contained

Maestro (2.6.0) runs YAML flows against a real device. The first version chained flows with clearState and back, and it was brittle: one flow would exit on the wrong screen and the next would start from a bad state.

The fix was to make every flow state-independent. Flow 1 clears state and tests the welcome to sign-in path itself. Flows 2 through 5 start with a plain launchApp. No state clear. On this app that preserves the signed-in Supabase session and drops you on the Today tab. So each flow re-navigates from a known state and never depends on the previous flow's exit screen.

# FLOW 2 - Upgrade-to-Pro opens the paywall (self-contained)
- launchApp                      # preserves session, lands on Today
- tapOn:
    point: "90%,92%"             # You tab
- tapOn:
    id: "upgrade-cta"
- assertVisible: "Restore"       # substring matches both paywall variants

That assertVisible: "Restore" is deliberate. Two different paywalls can render depending on whether RevenueCat's offering loaded at runtime, and "Restore" is a substring present in both. Assert the thing that is true in every valid state, not the exact string of one of them.

The trap: an on-device suite can break with zero CI signal

Here is the part that bit me and that I have not seen written down.

Those testIDs only take effect after a new build. And a Maestro failure only surfaces on-device, when someone bothers to run the suite. So if I rename upgrade-cta to upgrade-button during a refactor, nothing fails. Tests pass. CI is green. The regression suite is quietly dead, and I find out the next time I happen to plug in the phone.

A device suite that can rot silently is worse than no suite, because it tells you that you are covered when you are not.

Step 3: a Jest contract test makes the testIDs unregressable

So I pushed the guarantee down to the unit level, where it runs on every commit with no device. A plain Jest test asserts two things: every testID the Maestro suite depends on still exists in the source file that renders it, and the Maestro YAML references exactly that set and no other.

const TESTID_SOURCES: Record<string, string> = {
  'onboarding-sign-in': 'app/onboarding/index.tsx',
  'upgrade-cta': 'astro/screens/you/SubscriptionCard.tsx',
  'paywall-purchase': 'astro/screens/onboarding/CustomPaywall.tsx',
  // ... one entry per testID the suite drives
};

it.each(Object.entries(TESTID_SOURCES))(
  'testID "%s" is declared in %s',
  (testId, file) => {
    const contents = readFileSync(srcPath(file), 'utf8');
    expect(contents.includes(`testID="${testId}"`)).toBe(true);
  }
);

it('the Maestro flow references only contract testIDs (no drift)', () => {
  const flow = readFileSync('.maestro/origo-regression.yaml', 'utf8');
  const referenced = [...flow.matchAll(/\bid:\s*"([^"]+)"/g)].map((m) => m[1]);
  const contract = new Set(Object.keys(TESTID_SOURCES));
  expect(referenced.filter((id) => !contract.has(id))).toEqual([]);
});

It checks the source text, not the rendered output, on purpose. It is the literal testID="..." string the device tooling matches, so I want to assert that exact string survives, independent of render internals or RN mocks. Rename a testID and forget the YAML, the contract test goes red on the next commit. Add a flow that needs a new testID, add the pair to the map and the guard enforces it forever.

Step 4: run the same flows against the release APK

The last gap: I was testing the dev client over Metro, not the artifact users install. So the runner got a second mode. SMOKE_TARGET=installed skips all the Metro and dev-launcher setup and drives a plain installed release APK. The flows' Metro-connect step is a conditional subflow, so it is a no-op there, and the exact same six flows validate the CI build.

EMAIL=... PASSWORD=... SMOKE_TARGET=installed \
  ./scripts/device-smoke.sh .maestro/origo-regression.yaml

A couple of gotchas worth saving you the time: Maestro's GraalJS runtime has no Thread.sleep, so timed waits go through a small busy-wait helper. And tab-bar taps use a screen percentage rather than a testID, because on the Pixel 3 the tab testID bounds bleed into the Android nav bar and the tap misses. That is the one place coordinates are correct, because the position is fixed and the elements are not individually addressable.

The takeaway

Speed was never the real problem. The real problem was determinism. Three changes fixed it: make the app queryable with testIDs on the flows that matter, encode those flows so they do not depend on each other, and then guard the fragile contract (testIDs that only exist after a build, failures that only show on-device) with a unit test that runs on every commit.

If you take one thing: an on-device test suite that can break without turning anything red is a liability. Find the part that can drift silently and pin it down a layer, where the cost of breaking it is a failed CI run, not a missed regression in production.

I am building Origo in the open. Next up: the paywall that renders two different ways depending on whether RevenueCat's offering loaded, and how I stopped guessing which one a user sees. Follow if that is your kind of problem.

4 Ways RevenueCat Silently Denies Paying Users Their Entitlements

Diven Rastdus — Tue, 16 Jun 2026 12:10:50 +0000

Your store credentials are valid. RevenueCat accepted the service account. The SDK initialized without throwing. And your paying users are still seeing the free tier.

This is the second layer of the RevenueCat wiring problem. The one that doesn't produce an error. The first layer (invalid credentials, service account propagation delays) has been written about. This one hasn't. These are four bugs I found building Origo, an AI astrology app on Expo + RevenueCat + Supabase. All four were silent. All four passed tests. All four denied real users real value.

1. `Purchases.logIn()` was never called

This was the most expensive one. Three days of confused billing debugging before I found it.

Every purchase made before you call Purchases.logIn(userId) registers under an anonymous RC identity: $RCAnonymousID:some-uuid. When your RevenueCat webhook fires to update your database, it can't map an anonymous RC id to a real user row. It either skips the event or writes an orphaned record. Your server's entitlement check returns false for that user.

The purchase exists in RevenueCat's dashboard. The user paid. Nothing shows up on your backend.

The fix requires understanding what RC does with identity. You want RC's app_user_id to be your auth system's stable user id, set BEFORE any purchase happens:

const initialize = useCallback(async (userId?: string) => {
  if (!initialized || configuredApiKey !== apiKey) {
    Purchases.configure({ apiKey, appUserID: userId });
    initialized = true;
  } else if (userId && currentAppUserID !== userId) {
    // User signed in after RC was already configured; switch identity
    const loginResult = await Purchases.logIn(userId);
    currentAppUserID = userId;
    info = loginResult.customerInfo;
  }
}, []);

If your auth flow allows anonymous purchases (user buys before creating an account), call logIn() with the stable user id the moment they sign up. RC handles the client-side transfer from anonymous to identified, but your webhook still has to catch the TRANSFER event and re-key the database row. More on that in #4.

In my case, Supabase's anonymous auth preserves the user id across the anon-to-email upgrade (auth.updateUser() keeps the same uuid). So I pass the Supabase uuid to RC from the very first session, before they've ever entered an email. When they eventually link an account, the RC identity is already the final, stable uuid.

2. No `customerInfo` listener

Here's what happens when you skip a customerInfoUpdateListener:

A user purchases through your native paywall (via Purchases.presentPaywall()). The purchase succeeds. Your paywall dismisses. The user is back on the main screen, still seeing the free tier, because the component that owns isPro state hasn't been told anything changed.

The listener is how RC pushes out-of-band entitlement changes: purchases through the native paywall, server-side grants, trial conversions, grace-period resolutions. Without it, you're only checking entitlements at cold start.

useEffect(() => {
  let active = true;

  const onCustomerInfo = (info: CustomerInfo) => {
    if (active) checkEntitlements(info);
  };

  (async () => {
    await initialize();
    try {
      Purchases.addCustomerInfoUpdateListener(onCustomerInfo);
    } catch {
      // SDK not configured in dev; nothing to listen to
    }
  })();

  return () => {
    active = false;
    try {
      Purchases.removeCustomerInfoUpdateListener(onCustomerInfo);
    } catch {}
  };
}, [initialize, checkEntitlements]);

react-native-purchases v10 gotcha: addCustomerInfoUpdateListener returns void. You can't call .remove() on the return value. Cleanup is removeCustomerInfoUpdateListener(sameRef), and sameRef has to be the exact same function reference. Define the listener inside the effect, close over it, pass the same reference to both add and remove.

3. The RC session leaked between users on the same device

This bug is invisible to unit tests. You'd need an integration test that calls configure(), then logOut(), then signs in as a different user and checks their entitlements. Most test suites don't go there.

RC's SDK uses module-level state. Once Purchases.configure() has run with User A's identity, that configuration persists until you explicitly clear it. If User A signs out and User B signs in, and your initialization check says "already initialized, skip". User B inherits User A's RC session. If User A was a paying subscriber, User B gets isPro: true.

Reset your initialization bookkeeping on sign-out, right after calling Purchases.logOut():

// Call this on every sign-out, after Purchases.logOut()
export function resetRCSession() {
  initialized = false;
  configuredApiKey = null;
  currentAppUserID = undefined;
}

Purchases.logOut() returns RC to an anonymous identity. resetRCSession() clears your bookkeeping so the next initialize() doesn't short-circuit on the previous user's state.

4. The webhook handles purchases but ignores refunds and cancellations

The first three bugs are client-side. This one is server-side, and it's the one that keeps denying access after everything else is right.

Your subscription table probably gets written on INITIAL_PURCHASE and RENEWAL. If you're not handling CANCELLATION, REFUND, and TRANSFER, your database will say is_active: true for users whose subscriptions have ended. They lose access only when expires_at passes (if you even store that field).

The full event set you need, at minimum:

INITIAL_PURCHASE: create the subscription row
RENEWAL: extend expires_at
CANCELLATION: mark inactive (keep the row; they may have time remaining)
REFUND: mark inactive immediately
TRANSFER: re-key the row when RC reassigns app_user_id

TRANSFER is the one that closes the loop from bug #1. When an anonymous user creates an account and RC transfers their purchase history to a named identity, a TRANSFER event fires with transferred_from (the old anonymous id) and app_user_id (the new identified one). Ignore it, and the purchase stays associated with an id that doesn't map to any user row.

switch (event.type) {
  case 'INITIAL_PURCHASE':
  case 'RENEWAL': {
    const expiresAt = event.expiration_at_ms
      ? new Date(event.expiration_at_ms).toISOString()
      : null;
    await upsertSubscription(event.app_user_id, { is_active: true, expires_at: expiresAt });
    break;
  }
  case 'CANCELLATION':
    await updateSubscription(event.app_user_id, { is_active: false });
    break;
  case 'REFUND':
    await updateSubscription(event.app_user_id, { is_active: false, refunded: true });
    break;
  case 'TRANSFER':
    // transferred_from is an array; the relevant old id is [0]
    await transferSubscription(event.transferred_from[0], event.app_user_id);
    break;
}

The checklist

Before shipping a RevenueCat-gated feature:

Is Purchases.logIn(userId) called with the stable auth user id before any purchase can happen?
Is there an active customerInfoUpdateListener on every screen that gates on isPro?
Does sign-out call Purchases.logOut() AND reset your initialization bookkeeping?
Does the webhook handler cover CANCELLATION, REFUND, and TRANSFER, not just INITIAL_PURCHASE?

Credentials being valid is table stakes. The silent failures come after.

Building with RevenueCat on Expo/React Native and hit a different version of these? Comments are open. Also at raeduslabs.com.

RevenueCat Said My Play Store Credentials Were Invalid. They Weren't.

Diven Rastdus — Sun, 14 Jun 2026 12:11:02 +0000

I created a Google service account, uploaded the JSON key to RevenueCat, and watched my Android app reject every purchase. The dashboard said the credentials needed attention. On device, the logs showed a RevenueCat error: 7107 / Invalid Play Store credentials.

The credentials weren't invalid. I'd just made the mistake that costs a lot of mobile developers a full day: I expected Google to be fast.

Here are three Google Play Billing traps from one app launch. Two of them are Google being slow. The third costs money instead of time. All three look exactly like bugs in your code, and none of them are.

The setup

I'm building Origo, a subscription app on Expo and React Native. Payments run through RevenueCat, which validates every Google Play purchase server-side before it grants entitlements. That server-side check is the whole point. The client can't be trusted to claim "this user paid," so RevenueCat asks Google directly.

To ask Google, RevenueCat needs a service account with access to your Play Console. You create the service account in Google Cloud, generate a JSON key, grant it permissions in Play Console, and paste the key into RevenueCat. The official docs walk through it cleanly.

Then nothing works, and the docs don't warn you loudly enough about why.

Trap 1: "Invalid Play Store credentials" usually means "wait"

The first purchase test failed instantly. RevenueCat's dashboard showed a banner: Credentials need attention. On device, the SDK threw Invalid Play Store credentials. My first instinct was that I'd pasted the wrong key or missed a permission.

I hadn't. The key was correct and the permissions were correct. The problem was time.

When you create a fresh service account, Google has to propagate its access to the Play Developer API. RevenueCat's support docs put this at 24 to 48 hours. Until it finishes, every server-side validation returns an error that reads like a configuration mistake. So you "fix" a config that was never broken, re-upload the same key, and wait again.

The faster fix: you can force Google to re-evaluate the credentials instead of waiting on the background job.

Open Play Console and go to your app.
Go to Monetize → Products → Subscriptions (or In-app products).
Edit any product. Change the description. Save.

Saving a product change pokes the billing config and can validate the new credentials right away, per RevenueCat's own guidance. If you remember one thing from this post, remember that the credential error is a clock, not a bug. Editing a product can reset the clock.

Trap 2: new products return ITEM_UNAVAILABLE for hours

The second trap looks even more like a real defect. You create a subscription or a one-time product in Play Console, wire it into RevenueCat, run a purchase, and the SDK returns ITEM_UNAVAILABLE.

The product exists. You're staring at it in the console. It still says unavailable.

Same root cause: propagation. A product you created minutes ago hasn't reached the billing backend yet. One-time products in particular can take hours. I hit this with a lifetime product I'd created minutes before the test, started reading my purchase flow line by line, then realized the product was simply too new to buy.

The rule I follow now: if a product is less than a few hours old, ITEM_UNAVAILABLE isn't evidence of anything. Retest later before you touch your code. The most expensive debugging is debugging a system that simply isn't ready yet.

Trap 3: test with license testers, or you'll charge yourself

The first two were Google being slow. This one's different. It's the mistake that turns a test into a real transaction.

Google Play has no separate sandbox the way Apple does. A purchase on a live product charges a real card unless the buying account is registered as a license tester. So before any purchase test, I add our test Google account under Play Console → Settings → License testing. License testers get the full purchase flow, real dialogs, real RevenueCat validation, but no charge and no refund paperwork.

Skip this step and your "test" buys your own subscription with real money. Then you're filing a refund instead of reading logs.

The pattern underneath

The two delays share one shape. The symptom shows up at the boundary between your app and a platform you don't control, and that platform is eventually consistent. It says no now and yes in a few hours, with nothing in between that admits it's still thinking.

Your debugging instinct is to assume the last thing you changed is broken. With Google Play Billing, the last thing you changed is often correct and just not live yet. So I changed my checklist. Before I debug a billing error, I ask one question first: how old is the thing that's failing? If the answer is minutes or hours, I wait and retest before I read a single line of my own code.

That one question has saved me more time than any fix.

I'm writing up the real launch problems behind Origo as I hit them. If you're shipping subscriptions on React Native, these propagation traps are the ones I wish someone had warned me about on day one.

3 React Native Bugs That Crashed on Device but Passed Every Test

Diven Rastdus — Sat, 06 Jun 2026 12:11:18 +0000

Your test suite is green. TypeScript is happy. The web preview looks perfect.

Then you install the APK on a real phone and the app crashes before the splash screen finishes.

I shipped an Expo SDK 56 app to Google Play internal testing last week. Three separate bugs made it through 376 passing tests, clean tsc, and a working web export. None of the three involved broken logic. The code was correct. The runtime wasn't what I thought it was.

Each bug only surfaced on a physical Android device running Hermes. Here's what they were, why they slipped through, and the fixes.

Bug 1: The Gold Button That Turned Grey

My app uses a theme system. A configureTheme() function mutates a shared Colors object at runtime, and components read from it via StyleSheet.create.

The problem: my main CTA button rendered grey (RGB 231,231,231) instead of gold (RGB 213,195,139) on every screen that used the shared Button component. But screen-specific styles showed the correct gold.

Root cause: JavaScript module evaluation order.

// app/_layout.tsx (BROKEN version)
import { Button } from '@core/ui';        // Step 1: Button.tsx evaluates
import { configureTheme } from '@core/constants';
import { MY_BRAND } from '@app/config/theme';

configureTheme(MY_BRAND);                 // Step 3: Colors mutated... too late

When _layout.tsx imports @core/ui, JavaScript evaluates Button.tsx immediately. Button.tsx runs StyleSheet.create at module scope, which copies the color string by value. At that point, configureTheme() hasn't run yet, so the button captures the neutral fallback color.

Screen-level styles worked fine because route components are lazily imported after configureTheme() runs.

Why tests missed it: Jest evaluates all modules fresh per test file. Fast Refresh already mutated the Colors singleton from a previous render. Only a cold start on a real device evaluates modules in the exact import order of your entry point.

The fix: Create a bootstrap file that runs configureTheme at module scope, and import it first.

// config/themeBootstrap.ts
import { configureTheme } from '@core/constants';
import { MY_BRAND } from './theme';

configureTheme(MY_BRAND);  // Runs at module-eval time

// app/_layout.tsx (FIXED)
import './config/themeBootstrap';         // Step 1: theme configured
import { Button } from '@core/ui';        // Step 2: Button captures real colors

Rule: Any component that bakes brand colors into StyleSheet.create must be imported after configureTheme runs. Or resolve colors at render time as inline styles.

Bug 2: The Environment Variable That Existed Until It Didn't

The app crashed on launch with a clear error: EXPO_PUBLIC_SUPABASE_URL is required. But the .env file had the value. The dev server worked fine. npx expo export --platform web bundled without errors.

Root cause: Metro's static replacement only works with dot notation.

// storage/supabase.ts (BROKEN)
function readRequiredEnv(name: string): string {
  const value = process.env[name]?.trim();  // Dynamic bracket access
  if (!value) throw new Error(`${name} is required`);
  return value;
}

const SUPABASE_URL = readRequiredEnv('EXPO_PUBLIC_SUPABASE_URL');

Metro (Expo's bundler) statically replaces process.env.EXPO_PUBLIC_SUPABASE_URL with the literal string value at bundle time. It's a compile-time text substitution, not a runtime lookup.

process.env[name] is dynamic. Metro can't know what name will be at runtime, so it leaves it as-is. In the bundled Hermes bytecode, process.env is an empty object. The dynamic lookup returns undefined, and the app throws.

Why tests missed it: Node.js has real process.env at runtime. Your test runner loads values from .env files into the actual process environment. Metro's static replacement is a bundler concern that only affects the production artifact.

The fix: Static dot notation. No abstraction.

// storage/supabase.ts (FIXED)
const SUPABASE_URL = process.env.EXPO_PUBLIC_SUPABASE_URL?.trim();
const SUPABASE_ANON_KEY = process.env.EXPO_PUBLIC_SUPABASE_ANON_KEY?.trim();

if (!SUPABASE_URL) {
  throw new Error('EXPO_PUBLIC_SUPABASE_URL is required');
}

Rule: In Expo/React Native, never wrap process.env.EXPO_PUBLIC_* in a helper function that uses dynamic access. The DRY instinct is wrong here. Each env var needs its own static process.env.EXPO_PUBLIC_X line.

Bug 3: The Missing Crypto API

The app launched fine. Onboarding worked. Then the user navigated to the chat screen and got a ReferenceError: crypto is not defined.

Root cause: The uuid package calls crypto.getRandomValues() internally. Hermes (React Native's JavaScript engine) doesn't ship the Web Crypto API.

Node.js: has crypto globally since v19. Tests pass.
Chrome/Safari (web preview): has crypto on window. Web export works.
Hermes on Android: no crypto object. Crash.

ReferenceError: Property 'crypto' doesn't exist
    at v4 (uuid/dist/esm-browser/native.js:1:15)
    at ChatScreen (screens/companion.tsx:42:18)

The fix: One polyfill import at the top of your app entry, before anything else.

npm install react-native-get-random-values

// app/_layout.tsx
// This MUST be the first import. It patches globalThis.crypto
// before uuid or any other Web Crypto consumer evaluates.
import 'react-native-get-random-values';

import { useEffect } from 'react';
import { Stack } from 'expo-router';
// ... rest of imports

Rule: If any dependency uses crypto.getRandomValues() (uuid, nanoid, webcrypto-based auth libraries), add this polyfill. It's not optional on Hermes.

The Pattern

All three bugs share the same shape:

Bug	Dev/Test	Web Export	Real Device
Theme freeze	Gold (Fast Refresh)	Gold (lazy eval)	Grey (cold start)
Dynamic env	Works (real process.env)	Works (inlined)	Crash (empty object)
Missing crypto	Works (Node has it)	Works (browser has it)	Crash (Hermes lacks it)

Tests run in Node. Web preview runs in Chrome. Neither environment matches Hermes on Android. Three different reasons, but the same gap: your test environment is lying about what the production runtime can do.

What I Do Now

After these three burned a full day each, I added a mandatory step before any release build:

Cold-start the app on a real device. Not Fast Refresh. Kill the process, relaunch. This catches module-order bugs like the theme freeze.
Test the EAS build artifact, not the dev server. The dev server has real process.env. The production bundle has static replacements. They behave differently.
Install a crash monitoring SDK early. If you ship to testers without crash reporting, you're running blind. The crypto bug only triggered on a specific navigation path. A crash report with the Hermes stack trace would have cut debugging time from hours to minutes.

Your test suite verifies your logic. It doesn't verify your runtime. The device is the only source of truth.

Block YouTube Shorts and Reels on Android (Keep the App)

Diven Rastdus — Mon, 01 Jun 2026 12:07:25 +0000

Block YouTube Shorts & Reels on Android (Keep the App)

You don't have an Instagram problem. You have a Reels problem. You opened the app to reply to one DM, and 40 minutes later you're watching a guy power-wash a driveway. The DM is still unanswered. That's why the real fix isn't deleting anything. It's learning how to block YouTube Shorts and Instagram Reels on Android without blocking the whole app.

Because "just delete the app" doesn't work when you actually need it. You need Instagram for the group chat. You need YouTube for the tutorial you saved. You need TikTok open because a client posts there. The infinite feed is the part that costs you the hour, not the whole app. Kill the feed, keep the inbox.

Most app blockers can't do that. They block by package name, all or nothing. This walks through the one mechanism that actually targets the feed surface itself, and how to set it up for free with no root.

The problem: you need the app, not the Shorts and Reels feed

Think about what you actually open these apps to do.

Instagram: reply to DMs, check a specific account, post a story. None of that is Reels. Reels is the tab you tap by accident, or the suggested clip that autoplays when you close a conversation.

YouTube: a how-to video, a podcast, a saved playlist, your subscriptions. Shorts is the bar that hijacks the home feed and the swipe-up gesture that drops you into an endless vertical scroll.

TikTok is the one app where the feed is the product, but plenty of people keep it for the messages, the Following tab, or because they post and need to check comments. The For You page is the part that swallows an hour.

In every case there's a useful core and a slot-machine wrapper bolted on top. Blocking the whole app throws out the core to kill the wrapper. That's why people uninstall, reinstall three days later, and feel like they failed. They didn't fail. The tool was too blunt.

Why blocking the whole app fails

There are two reasons this fails, and they feed each other.

The first is rebound. When you hard-block an app you actually depend on, you create friction you can't sustain. You miss a message. A coworker asks why you didn't see the tag. So you unblock "just for a minute," and the block is dead. App blockers that go all-or-nothing have a short half-life for exactly that reason.

The second is work. For a lot of people now, Instagram and TikTok are part of the job. Creators, marketers, small business owners, anyone who posts. Telling them to delete the app is telling them to quit their side income. They won't, and they shouldn't. The rebound and the work reason compound: the people who most need these apps open are the ones a blunt block punishes hardest, so they're the first to switch it off.

The fix isn't more willpower or a harsher block. It's a sharper one. Cut the specific surface that's costing you time and leave the rest alone.

How in-app feed blocking works on Android (no root)

Here's the part nobody explains clearly.

Android has a system feature called the Accessibility API. It was built so screen readers and assistive apps can see what's on screen and act on it for people who can't tap or see normally. It's a legitimate, documented part of the OS. Apps that use it have to declare it, and you have to switch it on by hand in Settings.

A feed blocker uses that same API to read the structure of the screen, not the pixels and not the content. Every Android view has an ID. When Instagram renders the Reels player, that view has a resource ID. Nudge, the open-source blocker this article walks through, watches for specific IDs like reel_recycler and reel_player_page_container. When one of those appears on screen, it means you're looking at the Reels surface. Nudge throws up a block overlay and bounces you out. The DM screen has different IDs, so it's left untouched.

Same idea for YouTube Shorts and the TikTok For You feed. The blocker isn't reading what the video is about. It's detecting which screen you landed on by its layout fingerprint, then blocking only that screen.

No root required. Root is for low-level system access, and this needs none of it. It runs on a stock phone with one permission toggle.

The honest tradeoffs: this is Android only, because iOS doesn't expose an equivalent screen-reading Accessibility API to third-party apps. And resource IDs can change when an app ships a redesign, so a feed blocker occasionally needs an update to keep matching. That's the nature of the approach. Anyone who tells you their feed blocker will never break is overselling.

What Accessibility permission actually sees (and what it can't do)

This is the trust question, and it's a fair one to ask before you toggle anything on. So let's settle it before the setup steps, not after.

Accessibility permission is powerful. An app that has it can read a lot. So here's what Nudge does and doesn't do with it. It reads the layout structure of the screen to match those resource IDs. It does not log your DMs, your captions, your search history, or anything you type. It doesn't store screen content. It's matching IDs to decide "block this screen or not," then forgetting the rest.

You shouldn't take that on faith from any app. Here's why you don't have to.

Nudge requests zero internet permission. Not "promises not to use the internet." It doesn't request the INTERNET permission in its manifest at all. Android enforces this at the OS level. An app without that permission physically cannot open a network connection. No servers to phone home to, no analytics, no ads, no account to create.

So even with Accessibility access, there's nowhere for your data to go. Nudge can read the screen structure to do its job, and it can't transmit anything, because the operating system won't let it. That's a structural guarantee, not a privacy-policy promise.

And because Nudge is open source, you don't have to believe any of this either. The code is on GitHub. The manifest is right there. Anyone can confirm there's no internet permission and no data collection. If you want the deeper write-up on that design choice, here's the full piece on an open-source app blocker with no internet permission.

Step-by-step setup (YouTube, Instagram, TikTok)

The first step is the same for all three: install Nudge, open it, and grant the Accessibility permission when it asks. Android routes you to Settings > Accessibility > Nudge, and you flip it on. That's what lets Nudge see the screen structure. After that, each platform is a couple of toggles.

Block YouTube Shorts

In Nudge, open the in-app blocking section and pick YouTube.
Toggle on Shorts blocking.
Open YouTube and swipe into a Short. You'll hit Nudge's block screen instead of the feed. Regular videos, search, subscriptions, and your playlists all still work.

That's it. The Shorts shelf on the home page and the swipe-up-into-Shorts gesture both get caught.

Block Instagram Reels and Explore

Open Nudge's in-app blocking and pick Instagram.
Toggle on Reels blocking. Optionally toggle Explore too, since the Explore grid is the other main rabbit hole.
Open Instagram. DMs, your feed of people you follow, stories, and posting all work. Tap the Reels tab or hit a suggested Reel and you get the block screen.

The point is surgical. You keep the social graph you chose. You lose the algorithmic firehose you didn't.

Block the TikTok For You feed

In Nudge's in-app blocking, pick TikTok.
Toggle on For You feed blocking.
Open TikTok. The Following feed, your messages, and your profile stay reachable. The For You page gets blocked.

If TikTok is pure entertainment for you with no work angle, you might want to block the whole app on a schedule instead. But if you keep it for messages or posting, blocking just the For You feed is the move.

Pairing feed-blocking with a delay-to-open pause

Feed blocking handles the surface. But there's a second habit worth breaking: the reflexive open. The hand reaches for the phone, the thumb finds the icon, and you're in before you decided anything.

Nudge has a delay-to-open feature for that. When you open a chosen app, it makes you sit through a short breathing pause before the app loads. A few seconds of "do you actually want to be here." It sounds trivial. It isn't. That gap is where the autopilot breaks and you get a chance to choose.

Stack the two. Block Reels and Shorts so the worst surfaces are gone, and put a delay-to-open pause on Instagram itself so even the useful opens are deliberate. You can also set a daily time budget on an app, so after, say, 20 minutes it locks for the day. Friction where you need it, access where you need it.

Nudge vs other feed blockers

Several apps target the feed problem, and they're not all the same.

Tool	Feed-level blocking	Price	Open source	Internet permission
Nudge	Shorts, Reels, TikTok feed, Explore	Free, no tiers	Yes	None requested
ScreenZen	Yes, blocks Shorts/Reels surfaces + intervention screens	Free (donation-supported)	No	Not audited
Shortstop	Shorts, Reels, TikTok, Snapchat Spotlight, Facebook Reels	Free	No	Not audited
ScrollGuard	Blocks short-form feeds	Freemium, paid extras	No	Not audited
Betimeful	Hides feeds across apps	Freemium, paid plans	No	Not audited

A few honest notes. ScreenZen is genuinely good and popular, with polished intervention screens, broad app support, and versions across Android, iOS, macOS, and Windows. It's completely free and donation-supported, with no premium tier. Its real tradeoff against Nudge is a closed codebase you can't audit. Shortstop is a solid multi-platform feed blocker, covering YouTube Shorts, Instagram Reels, TikTok, Snapchat Spotlight, and Facebook Reels, and it's free. ScrollGuard and Betimeful both target short-form feeds and both run a freemium model where the better features sit behind a paywall.

A note on the "internet permission" column. Nudge is marked "None requested" because its open manifest is public and you can confirm the INTERNET permission is absent. The other apps are closed source, so their exact permission lists aren't independently auditable from the outside, which is why they're marked "not audited" rather than assumed to leak data. ScreenZen, Shortstop, and ScrollGuard all describe on-device or privacy-friendly designs, and several look good on privacy. The difference is that with Nudge you don't have to take it on trust.

Nudge's edge is narrow and specific. It's fully free with no pro tier, it's open source so you can read exactly what it does, it's Android only, and it requests no internet permission so your data physically can't leave the device. If you want polish and don't mind a closed app you can't inspect, the others are reasonable picks. ScreenZen in particular is a strong free option if cross-platform support matters more to you than an auditable codebase. If you want auditable and free with a verifiable privacy guarantee, that's the gap Nudge fills. For a wider look at the category, see the best free app blockers for Android in 2026.

FAQ

Can I block Shorts but keep YouTube?
Yes. That's the entire point of in-app blocking. Nudge blocks the Shorts surface specifically. Regular videos, search, subscriptions, and playlists keep working.

Does this need root?
No. It uses Android's Accessibility API, which works on a stock unrooted phone. You toggle one permission in Settings.

Is it free?
Yes. Nudge is 100% free. No subscription, no pro tier, no paywalled features. Open source.

Will it block the feed on every app?
Nudge covers YouTube Shorts, Instagram Reels and Explore, and the TikTok For You feed. Those are the big short-form surfaces. Coverage depends on the app's current layout, and an app redesign can require an update to keep matching.

Is it safe to grant Accessibility permission?
Accessibility is a powerful permission, so the safe move is to only grant it to apps you can verify. Nudge is open source and requests no internet permission, so even with Accessibility access it has no way to send your data anywhere. You can read the code yourself.

Why not just use Screen Time or Digital Wellbeing?
Those tools work at the app level, not the feed level. They can limit total YouTube time, but they can't let you watch a tutorial while blocking Shorts. Feed-level blocking is the missing piece.

Try it

The fastest way in today is GitHub. Nudge is open source and currently at v1.5.6, so you can read the code, check the manifest, and confirm the no-internet-permission claim before you install anything: github.com/astraedus/nudge. Build it from source and you're running in a few minutes (the Play Store and F-Droid listings are in review, so GitHub is the quickest route while those land).

Block the feed. Keep the app. Get your time back.

Originally published on raeduslabs.com. Nudge is open source on GitHub; issues and PRs welcome.

The Best Free ADHD App Blocker for Android

Diven Rastdus — Mon, 01 Jun 2026 12:06:36 +0000

The Best Free ADHD App Blocker for Android

You went to check the time. Forty minutes later you're watching a video about how octopuses taste with their arms, you have no idea how you got there, and you feel a little sick about it. You didn't decide to do that. Your thumb opened Instagram before the rest of you had a vote.

If you have ADHD, this isn't a discipline problem. It's how the wiring works. Most app blockers were built for people who don't have your wiring, which is exactly why they keep failing you. This piece covers why the usual Android app blockers fail ADHD brains, and what Nudge, a free ADHD app blocker for Android, does differently.

Why every blocker you've tried failed: one tap to bypass

You've probably installed three or four of these already. They worked for a day. Then you hit the limit, a little dialog popped up, and there was a button that said something like "add 15 minutes" or "I really need this." You tapped it without thinking. Same automatic motion that opened the app in the first place.

That's the core design flaw for an impulsive brain. If the bypass is one tap, it isn't a blocker. It's a suggestion. And a suggestion loses to a habit every time.

The other failure mode is guilt. A lot of focus apps lean on shame: streaks you can break, a tree that dies if you leave the app, a guilt trip when you slip. For some people that's fine motivation. For ADHD brains it often does the opposite. Shame is itself dysregulating. You break the streak, you feel like garbage, the discomfort makes you want to numb out, and the fastest way to numb out is the exact app you were trying to avoid. The tool meant to help becomes another source of the bad feeling it's supposed to fix.

So the bar for a free ADHD app blocker that actually holds is specific. The friction has to be just annoying enough that your conscious brain has time to wake up and ask whether you actually want this. Not a brick wall you'll resent and uninstall. A pause. And it can't run on shame.

Your thumb opens Instagram before your brain catches up

The phrase people use when they describe this is "muscle memory," and that's closer to the truth than it sounds. The sequence is: pick up phone, swipe, tap the second icon on the home screen, scroll. You can run that whole sequence while thinking about something else entirely. There was never a moment where you weighed "should I open this app" against "I have a thing due in twenty minutes."

That's the part that matters. The decision didn't lose to the impulse. The decision never showed up. By the time the conscious part of you notices, you're three Reels deep and the dopamine hit already landed. This is normal, and it's especially normal with ADHD. Understanding why matters more than blaming yourself for it.

The mechanism, in two parts: low baseline dopamine and a broken clock

ADHD brains tend to run lower on baseline dopamine, the chemical that makes ordinary tasks feel worth doing. Boring stuff feels physically harder to start, so the brain hunts for something that hits faster. A feed of short videos is the fastest hit in your pocket, and those feeds are engineered the same way slot machines are: you don't know if the next post is boring or amazing, and that uncertainty is the hook. ADHD brains, already hungry for stimulation, are unusually sensitive to it.

The second part is time blindness. ADHD messes with the internal sense of how much time has passed. "Five more minutes" genuinely feels like five minutes when it's been forty. The clock in your head is just broken in this specific way. Put those together and "why can't I stop scrolling" stops being a mystery. Low motivation to do the hard thing, plus a machine more rewarding than the hard thing, plus no reliable sense that time is passing. The scroll isn't a character flaw. It's the predictable output of that equation.

Friction, not punishment: the case for a pause over a hard block

There are two philosophies here, and they're genuinely different.

A hard block stops you cold. You can't open the app at all during the blocked window. This works for some people, but for ADHD it has two failure modes: you either rage-quit the blocker the first time it gets in the way of something you legitimately needed, or you learn the bypass and the wall stops meaning anything.

A pause is different. It lets you through, but slowly, and only after you've noticed what you're doing. The whole bet is that most of your scrolling is automatic, not deliberate. If you interrupt the automatic part, a big chunk of it just evaporates. You go to open TikTok, something makes you wait a few seconds, and in that gap you think "oh, right, I didn't actually want to do this," and you close it. No willpower required. The friction did the work.

This is how impulse control actually works. The prefrontal cortex, the planning-and-deciding part, is slower than the reflex. It needs a beat to catch up. A pause buys it that beat.

Delay-to-open as a prefrontal circuit-breaker

This is the feature that matters most, and it's the one Nudge is built around. When you try to open a distracting app, Nudge makes you wait first. You sit through a short breathing exercise. A few seconds, a slow breath, and then the app opens if you still want it.

That sounds almost too simple. It works because of the gap it creates. The automatic tap-and-scroll loop depends on speed. Break the speed and you break the loop. During those few seconds, the conscious part of you gets a chance to show up to the meeting it normally misses. Plenty of times you'll just close the app, because the impulse was never that strong. It was just fast.

It's not magic and it won't catch every time. But a circuit-breaker you have to deliberately override is a fundamentally different thing from a one-tap "skip" button.

Killing the slot machine: blocking Shorts, Reels, and TikTok feeds

Sometimes you genuinely need the app. You have to DM someone on Instagram, or post a clip, or reply to a comment. Blocking the whole app is overkill and you'll just turn the blocker off.

The slot-machine part isn't the app. It's the infinite feed inside it. YouTube Shorts. Instagram Reels. The TikTok For You page. Those are the variable-reward engines doing the real damage.

Nudge can block those specific surfaces while leaving the rest of the app working. You can open Instagram to message a friend, and Reels just isn't there. YouTube still plays the video you searched for, but the Shorts shelf is gone. You keep the useful parts and lose the parts engineered to keep you pulling the lever. There's a whole separate piece on how to block YouTube Shorts and Instagram Reels on Android without blocking the whole app if that's the main thing you're after.

Grayscale and time budgets as backup layers (honest expectations)

Two more tools, and I'll be straight about what they do and don't do.

Grayscale drains the color out of your screen. Color is part of what makes apps compelling, and a gray feed is genuinely less fun to look at. It's a real effect but a mild one. Think of it as a small tax on attention, not a wall. Some people barely notice after a week. Worth trying, don't expect miracles.

Time budgets let you set a daily cap per app. Thirty minutes of Instagram, then it locks for the day. The honest caveat: a hard daily limit can trip the same rage-quit reflex as a hard block, and if it's bypassable it's another one-tap suggestion. Time budgets work best as a backstop behind the pause, not as your main defense. The pause changes the moment-to-moment behavior. The budget catches the days the pause didn't.

Nudge: a free ADHD app blocker for Android, open source, no account

Nudge is a free Android app blocker for ADHD built around the delay-to-open pause, with feature blocking, time budgets, app groups, schedule rules, and grayscale as the supporting layers.

A few things make it unusual.

It has zero internet permission. The app literally cannot connect to the internet. Everything you do, every app you block, every minute you spend, stays on your device. There's no server to send it to because there's no connection at all. You can verify this yourself in Android's permission settings, or in the source code.

It's open source. The whole thing is on GitHub. You, or anyone you trust, can read exactly what it does. For a tool that watches which apps you open, "trust me" isn't good enough. "Read the code" is.

It's actually free. Not free-with-a-pro-tier, not free-trial, not free-but-the-good-features-cost-money. There's no subscription, no paywall, no upsell. No account to make. No email to hand over.

Here's an honest comparison against the apps people usually land on.

	Nudge	one sec	Opal	Forest	AppBlock
Platform	Android	iOS + Android	iOS + Android (Android newer/limited)	iOS + Android	Android + iOS
Pause before opening	Yes (core feature)	Yes (core feature)	No	No	Limited
Block feeds inside apps	Yes	Partial	Partial	No	Partial
Free version	Fully free	Limited free, paid upgrade	Limited free (1 rule), then paid	Paid (some free)	Free tier + paid
Subscription	None	Yes	Yes	One-time	Yes
Open source	Yes	No	No	No	No
No internet permission	Yes	No	No	No	No

To be fair to those apps: one sec had the pause-before-opening idea early and does it well, and if you're on iPhone it's a solid pick. Opal is polished and well designed, but it's iOS-first and its Android app is newer and feature-limited, with real use behind a subscription. Forest is a lovely gamified focus timer, just a different kind of tool than a blocker. AppBlock is full-featured on Android with a free tier, though the strongest features sit behind a subscription and it's closed source.

Nudge's pitch isn't "better than all of these at everything." It's narrower and more honest: if you want the pause-before-opening mechanic, on Android, for free, with the source code you can read and no way for it to phone home, that exact combination is rare. A handful of open-source Android tools chase parts of it, but the full set, especially the zero internet permission, is hard to find in one app.

If the automatic scroll is wrecking your focus and you're on Android, try the pause. The code and the latest release are on GitHub. Install it, point it at your two worst apps, and see whether a few seconds of breathing is enough to give you back the choice your thumb keeps making for you.

Honest answers to the two questions you're probably asking

Will it actually stop me? It'll stop you a lot of the time, not all of the time. If you're determined to get past it you can, because it's a pause, not a prison. That's by design. A wall you can't get over is a wall you'll uninstall. The goal is to catch the automatic 80% of scrolling, the kind you don't even decide to do, and hand the other 20% back to you as an actual choice. If you want a hard, unbreakable lock, this is the wrong tool. If you want a speed bump that lets the deciding part of your brain catch up, this is built for exactly that.

Is it safe to install if it's open source and not always on the Play Store yet? Open source is the reason it's safer, not less safe. You can read every line of what it does, which you can't do with any closed-source blocker. The zero-internet-permission design means it can't leak your data even if it wanted to. The Play Store version is in review and F-Droid has an open merge request, so installation will get more convenient over time, but the GitHub release works today.

How to start: install and first 10-minute setup

Getting going takes about ten minutes.

Install it. Right now there are two live install paths: build from source, or sideload the APK from GitHub. The Play Store listing is in review and the F-Droid merge request is open, so those routes are in progress and not live yet. If you're sideloading the APK from GitHub, Android will warn you about installing from outside the Play Store. That's the standard warning for any sideloaded app, not a Nudge-specific red flag.
Grant accessibility access. A blocker has to be able to see when you open another app, and on Android that needs the accessibility permission. This is the one permission it asks for. Combined with zero internet permission, it means the app can watch your app-switching to do its job but has no way to send that anywhere.
Pick your two or three worst apps. Don't block everything on day one. Pick the ones that actually eat your time. For most people that's two or three. Turn on delay-to-open for those.
Turn on feed blocking for the big ones. If Reels or Shorts or the TikTok feed is the real problem, switch on in-app feature blocking so you keep the app but lose the slot machine.
Leave the rest for later. Add grayscale, time budgets, schedules, and app groups once the basics have settled in for a few days. Stacking everything at once is a recipe for turning the whole thing off in frustration. Start small, let it stick, then layer up. If you came from iPhone or you're weighing the original pause app, there's a full breakdown in Nudge vs one sec on Android.

Originally published on raeduslabs.com. Nudge is open source on GitHub; issues and PRs welcome.

Open-Source App Blocker for Android With No Internet Permission

Diven Rastdus — Mon, 01 Jun 2026 12:06:31 +0000

Open-Source App Blocker for Android With No Internet Permission

You install an app blocker to spend less time staring at your phone. Then it asks for your email. Then it wants Accessibility access, which on Android means it can read the text on every screen you open. Then you find out it makes money from ads, or a "pro tier," or something murkier. So now the thing you installed to protect your attention is also watching everything you do and shipping it somewhere you can't see.

Most people never notice they made that trade. An open-source app blocker for Android with no internet permission flips it. Nudge can't track you because the operating system won't let it. There's no account to create, no telemetry, no server it phones home to. The code is on GitHub under GPL-3.0, so you don't have to trust a privacy promise. You can read the manifest yourself before you install.

The hidden cost of free app blockers: you are the product

Building an app costs time. Running servers costs money. So when an app blocker is free and has no visible business model, the money is coming from somewhere. Usually one of three places: ads, a subscription upsell, or your data.

The data path is the one people underestimate. A blocker needs to know which apps you open and how long you stay in them. That is, by design, a detailed log of your phone habits. Which apps, what time of day, how often you relapse on the ones you're trying to quit. That data has buyers. Analytics firms, ad networks, and "audience" brokers all pay for behavioral signals, and "how compulsively does this person use TikTok" is a clean signal.

You don't have to assume bad intent. The point is the capability exists, and capability plus a profit motive plus zero transparency is a bad combination for something that sits on top of your entire phone.

What Accessibility permission can see (and why that's the real risk)

Almost every Android app blocker uses the Accessibility Service API. Nudge does too. It's the only reliable way to detect which app is in the foreground and draw a blocking screen over it. There's no sinister alternative hiding behind a flag. This is how the category works.

Android's own warning label says it grants the ability to "observe your actions," "retrieve window content," and read text on screen. An Accessibility service can see the contents of the apps you use, including text you type, depending on how it's built.

The permission your blocker needs is the same permission a keylogger would want. That's not a reason to avoid blockers. It's a reason to care a lot about what the blocker does with that access, and whether it has any way to send what it sees off your device.

This is the whole argument for no internet permission. An app with Accessibility access but no network access can read your screen all it wants. It has nowhere to put the data. It's a security guard who can watch the building but has no phone, no radio, and no exit. The constraint isn't a promise about behavior. It's a wall.

The StayFree story: when your blocker gets acquired

StayFree is a popular, genuinely useful Android usage tracker and blocker. It's also a useful example of why "this app is fine today" isn't the same as "this app is fine forever."

Apps change hands. Ownership transfers, privacy policies get rewritten, a free tool adds an ad SDK in version 4.2 that wasn't there in 4.1. The app you vetted last year is not necessarily the app running on your phone today. If a blocker has the internet permission and an analytics pipeline, a change in who profits from your data is one app update away, and the update installs silently.

StayFree's fine for what it is. The point isn't that StayFree is bad. The point is that any closed-source blocker with network access is one acquisition or one update away from a policy change you won't know about.

Policy vs constraint: why "we don't track you" isn't enough

Every app's privacy policy says some version of "we respect your privacy." Freedom says it. AppBlock says it. The words are free to write and impossible to verify from the outside.

There are two ways to promise privacy:

Policy: "We could collect your data, but we promise we won't." You're trusting a sentence.
Constraint: "We can't collect your data, because the app has no way to send it anywhere." You're trusting math.

A policy can be broken quietly, changed in an update, or ignored by a future owner. A constraint is enforced by the Android operating system on every boot, whether anyone's watching or not. No internet permission is a constraint, not a promise.

Zero internet permission, explained: the app cannot open a network connection

On Android, an app can only do things it has declared permission for. Network access is android.permission.INTERNET. If an app doesn't request it in its manifest, the system blocks every attempt to open a socket. No HTTP request, no analytics ping, no silent upload. The call fails at the OS level before a single byte leaves the phone.

Nudge does not request INTERNET. That single missing line is the entire privacy story. It's what makes Nudge a true no tracking app blocker rather than a privacy app blocker for Android that only promises good behavior. Everything Nudge tracks (which apps you open, your time budgets, your block schedules) is computed and stored locally, and there is no code path that could send it out even if someone wanted to. There's no server because there's nothing a server could receive.

This is also why Nudge has no account. Accounts exist to sync data across devices through a server. No server, no sync, no account, no login, no password to leak. Your data lives in one place: your phone.

How to verify it yourself in Android Settings before installing

You don't have to trust any of this. Android tells you what an app can do.

Install the app (or download the APK without installing).
Open Settings, then Apps, find the app, and tap Permissions, or App info then Permissions.
Look for anything network-related. The system groups some permissions, but install-time permissions like internet access are visible in the full permission list.

For Nudge specifically, you can check before you even download anything. The AndroidManifest.xml is right there in the public GitHub repo. Search it for INTERNET and you'll find permissions for things like querying installed apps and the Accessibility service, but no internet access. That's the point, and you can confirm it in about thirty seconds. Once Nudge lands on F-Droid, that listing will show the same declared permission list pulled straight from the manifest, before you install.

Reading the source: what GPL-3.0 and a public repo actually buy you

"Open source" gets used loosely, so here's the concrete version. Nudge's source code is public on GitHub under the GPL-3.0 license. That gives you three things that closed apps can't offer.

First, you can read the AndroidManifest.xml yourself and confirm there's no internet permission line. It's a text file. You don't need to be a Kotlin developer to find the word INTERNET or confirm it's absent.

Second, GPL-3.0 means the published source has to match the app. The license requires that the code stays open, so a future version can't quietly close up and bolt on tracking without that change being visible in the public commit history. With a closed app, you're shown a polished store listing and nothing underneath.

Third, anyone can audit it. You personally might never read the code, but the value of open source is that someone can, and the FOSS community around F-Droid is unusually motivated to call out apps that sneak in trackers. Closed source means the only people who've seen the code are the people being paid to ship it.

No account, no telemetry, all data local: what stays on your device

Here's everything Nudge knows about you and where it lives:

Which apps you've set delay-to-open, time budgets, or schedules for. Stored on your device.
Your daily usage against those budgets. Computed on your device, in memory and local storage.
Your app groups and block rules. A local config. Yours.

There's no analytics dashboard somewhere with your name on it, because there's no "somewhere." There's no crash reporting SDK quietly uploading stack traces with device fingerprints attached. If you uninstall Nudge, the data is gone, because it was only ever on your phone to begin with.

That local-first design is also why the friction features can be aggressive without being creepy. The delay-to-open pause (a breathing beat before a distracting app launches), per-app time budgets, grayscale mode, and in-app blocking of things like YouTube Shorts and Instagram Reels all run entirely on-device. The blocker is opinionated about your attention and silent about your data.

How to install from GitHub today (and what's coming on F-Droid)

If you care enough about privacy to want no internet permission, you probably already prefer these install routes anyway. Right now there are two live paths: build from source, or sideload the APK. The store listings are still in progress.

GitHub is the most direct path, and the only one that's live today. The repo is at github.com/astraedus/nudge. You can download a release APK and install it directly (you'll need to allow installs from your browser or file manager once), or build it from source if you want maximum certainty that the APK matches the code. Either way you're getting the app straight from the source, no middleman.

F-Droid is the open-source Android app store. It only lists FOSS apps, shows the full permission list on every page, and builds apps from source itself rather than trusting a developer-uploaded binary. Nudge isn't listed there yet. There's a merge request open to get it in. Once it lands, you'll add F-Droid, search Nudge, and install, and F-Droid will show you the permissions before you commit, which is exactly the verification step from earlier.

Play Store is in review, not live yet. When it lands it'll be the easiest one-tap install for most people. The tradeoff is that the Play listing won't show you the full manifest the way F-Droid does, so if verification matters to you, GitHub (now) or F-Droid (later) is the better path.

Current version is v1.5.6, built with Kotlin and Jetpack Compose. Android only. There's no iOS version and won't be one. iOS doesn't allow the Accessibility-based foreground detection and overlay approach Nudge relies on. App limits on iOS only work through Apple's restricted Screen Time APIs (FamilyControls, ManagedSettings, DeviceActivity), which is a different architecture entirely.

FAQ

Can an app with no internet permission still block apps?

Yes, completely. Blocking is a local operation. The app watches which app comes to the foreground (via the Accessibility service) and draws a blocking screen over it (via the overlay permission). None of that needs a network. The internet permission would only ever be used to send your data somewhere, which is the one thing you don't want a blocker doing. Removing it costs you nothing and removes the entire tracking risk.

Is it really auditable, or is that just marketing?

You can check it in minutes. The code is on GitHub under GPL-3.0. Open the AndroidManifest.xml in the repo and search for INTERNET. If it's not there, the app can't make network calls, full stop. You can also check the declared permissions in Android Settings after install, or on the F-Droid page before install. "Auditable" here means the claims are falsifiable, not that you have to take them on faith.

Can a FOSS app blocker match Freedom or AppBlock?

For the core job (blocking apps, setting time budgets, adding friction), yes. The table below compares Nudge against Freedom, AppBlock, StayFree, and DigiPaws. Freedom and AppBlock win on iOS support and cross-device sync. Nudge wins on being a free, no-account, no-tracking app blocker with the hard guarantee of zero internet permission.

	Internet permission	Account required	Open source	Price	Platform
Nudge	None	No	Yes (GPL-3.0)	Free, no tiers	Android
Freedom	Yes	Yes	No	Limited free, then paid	Android + iOS
AppBlock	Yes	Optional	No	Free with paid pro	Android + iOS
StayFree	Yes	Optional	No	Free with ads / paid	Android
DigiPaws	None	No	Yes	Free	Android

Freedom and AppBlock are polished and cross-platform, and if you want iOS support or sync across devices, they're reasonable picks. DigiPaws is the closest in spirit: also open source, also free, and it skips the internet permission too, with a more gamified, mode-based take on building friction. Nudge's specific edge is the combination, and the calmer design behind it: open source, no account, completely free with no paywalled features, and the hard constraint of zero internet permission that none of the closed options can match. If you want a fuller breakdown, see our rundown of free Android app blockers for 2026.

Will the no-internet-permission guarantee break in a future update?

It can't, quietly. Because the source is public under GPL-3.0, adding the internet permission would mean a visible change to the AndroidManifest.xml in the commit history. With a closed app, that change happens behind a wall and installs in a routine update. With Nudge, it would be on the record. An Android app blocker without an account and without network access has nothing to silently flip.

If you want an app blocker that physically can't sell your phone habits, this is it. Read the code, check the manifest, and either build from source or sideload the APK from GitHub today. The F-Droid and Play Store listings are in progress. It's free, it's Android, and the privacy claims are things you can verify rather than promises you have to believe.

Originally published on raeduslabs.com. Nudge is open source on GitHub; issues and PRs welcome.

Free Opal Alternative for Android (No $99/yr Subscription)

Diven Rastdus — Fri, 29 May 2026 05:30:23 +0000

Someone on Reddit or a productivity YouTuber raved about Opal. The clean focus sessions, the "deep work" timer, the satisfying streak. So you opened the Play Store, found Opal for Android, and then hit the wall everyone hits: the free version barely blocks anything, and the part you actually wanted sits behind a subscription that runs about $99 a year. If you want a free Opal alternative for Android, that's the real problem to solve, not whether Opal exists on your phone.

Here's the short version before the long one: Opal does have an Android app now, but it's paid and noticeably thinner than the iPhone version. And there's a free, open-source Android app called Nudge that covers the part of Opal people actually care about, which is putting friction between you and the apps that eat your day, without a subscription.

Quick answer: is Opal free on Android?

Mostly no. Opal has an Android app on Google Play, and there's a free tier, but it's close to useless on its own. You get very limited blocking, and the focus features people install Opal for are part of Opal Pro, which is about $99 a year (or $19.99 a month). So if you came looking to actually use Opal on Android without paying, you'll find the free version doesn't do much.

So the real question isn't "where do I download Opal for Android." It's "what's the Android app that does what Opal does, for free." That's this article.

What people love about Opal (and what it costs)

Opal is a good app. I'm not here to trash it. The thing it gets right is intentional friction. You set up focus sessions, and when you try to open Instagram or X during one, Opal stops you with a pause screen. That tiny moment of "do you actually want this right now" is enough to break the reflex scroll for a lot of people. It also has app groups, schedules, and a dashboard that shows where your time went.

Two catches, though. The first is the price: Opal Pro runs about $99 a year, the free tier is thin, and the features people actually install it for sit behind the subscription. The second is Android specifically. Opal was built iOS-first on Apple's Screen Time API, and the Android app launched later, so it's still catching up on features and the experience isn't as robust. Opal's own team has said the Android version is newer and that they're working toward parity with iOS. That's a fair, honest position. It also means on Android you'd be paying $99/yr for the less complete version of the app.

Why Opal's Android app is the weaker one

It helps to know why, so you can decide whether it's worth paying for.

On iOS, Apple gives apps a sanctioned way to block other apps: the Screen Time / Family Controls API. Opal plugs into that. It's clean, it's system-level, and Apple maintains it.

Android doesn't have a single equivalent. To block or limit apps on Android, an app has to use the Accessibility Service or Usage Stats permissions, watch what's in the foreground, then throw up its own screen when a blocked app opens. It works, but it's a different architecture entirely. Opal had to build its Android blocking engine separately from the iOS one, which is part of why the Android app shipped later and still trails on features. This isn't unique to Opal: most screen-time apps that started on iPhone are still closing the gap on Android.

The good news for Android users: that Accessibility-based approach is exactly what the open-source Android blockers already use, and some of them are free.

What an Android Opal alternative actually needs to match

If you liked the idea of Opal, here's what the Android replacement has to do. Not the marketing checklist, the parts that matter:

Put friction in front of distracting apps so you pause before opening them.
Let you set time limits per app, not just an all-or-nothing block.
Schedule rules so blocking turns on during work or sleep automatically.
Not be annoying enough that you uninstall it in a week.

A few free Android apps cover pieces of this. ScreenZen nails the pause-before-opening idea and won't cost you anything. one sec popularized the breathing-pause pattern, but its free tier only covers one app and the rest is paywalled. Freedom does the job too, except it wants a subscription. So you're stitching together slices. The one I built, Nudge, goes after the whole list for free.

Nudge: the free Opal alternative built for Android

Nudge is a free Android app blocker built for people who keep opening apps they didn't mean to open. It's written in Kotlin with Jetpack Compose, it's open source so you can read every line, and it's currently on version 1.5.6.

It's Android-only. I'm saying that plainly because being honest about scope is the whole point of this article. If you're on iOS, Opal and one sec are solid picks. If you're on Android and don't want to pay $99 a year for the less complete Opal experience, keep reading.

Delay-to-open instead of Opal's hard sessions

Opal's model is sessions: you commit to a block of focus time, and during it certain apps are off-limits. That works if you plan your day in focus blocks.

Nudge's main tool is delay-to-open. When you go to open an app you've marked, Nudge shows a short pause first, a breathing beat where you wait a few seconds before the app opens. It's the same psychology as Opal's stop screen, but it doesn't require you to schedule a session in advance. The friction is always there for the apps you chose, every time you reach for them. For reflex-scroll opening, where you unlock your phone and Instagram is open before you decided to open it, the always-on pause tends to work better than a session you forgot to start.

If you do want session-style blocking, Nudge has schedule rules too. More on that next.

Per-app daily time budgets and schedule rules

A hard block all day is too blunt for most people. You don't want to never see Instagram. You want to not lose 90 minutes to it.

Nudge does per-app daily time budgets. Give YouTube 30 minutes a day. When you hit it, Nudge steps in. You can also group apps so a budget covers all your social apps together, not one at a time. And schedule-based rules let you say "block this group from 9 to 5" or "everything off after 11pm," so the right limits switch on without you toggling anything.

There's one more thing Nudge does that Opal's app-level blocking doesn't: in-app feature blocking. Nudge can block YouTube Shorts, Instagram Reels, and the TikTok feed while leaving the rest of the app working. So you can still message people on Instagram or watch a video someone sent you, without the infinite Reels rabbit hole. There's also a grayscale mode that drains the color out of your screen to make the whole phone less compulsively fun. If you only want the feature-blocking piece, there's a whole writeup on killing Shorts and Reels without nuking the app.

Privacy upgrade: no account, zero internet permission

This is where Nudge isn't just a free copy of Opal, it's a different deal entirely.

Nudge has zero internet permission. Not "we don't sell your data," not "we anonymize." The app cannot connect to the internet at all, because it doesn't request the permission to. You can verify this yourself in the app's permissions list or in the source code. Which apps you block, how long you spent, your schedules, all of it stays on your device and never leaves it.

There's no account to create. No email, no sign-in, no cloud sync of your usage habits. No ads. A screen-time app sees the most personal data on your phone, which is literally everything you do on it. The right amount of that to send to a server is none. So Nudge sends none. If that matters to you, there's a deeper piece on why an app blocker should have no internet permission.

Opal vs Nudge: price, privacy, and what's free

If you want a free Opal alternative on Android, this is the side-by-side that matters.

	Opal	Nudge
Platform	iOS, Android, Mac (Android newer, feature-limited)	Android only
Price	~$99/yr for Pro, thin free tier	Free, no pro tier
Open source	No	Yes, auditable
Account required	Yes	No
Internet permission	Yes (cloud sync)	None, all local
Pause before opening	Yes (focus sessions)	Yes (delay-to-open, always on)
Per-app time limits	Yes	Yes
Schedules	Yes	Yes
Block Shorts/Reels in-app	App-level blocking, not in-feed	Yes
Grayscale mode	No	Yes

Read it however you like, but the price and privacy rows settle most of it. Opal on Android is the paid, still-maturing option that syncs to an account. Nudge is free, open source, and never touches the network. The table's real job is to show that the free Android option isn't a sad downgrade. On the things that matter for actually using your phone less, it holds up.

How to install Nudge on Android

A free open-source app sounds like it should be a pain to install. It mostly isn't.

The Play Store and F-Droid listings are still in progress, so the two live ways to install Nudge today are to build from source or sideload the APK:

GitHub APK (sideload): grab the APK directly from the Nudge releases page on GitHub and install it. Android will ask you to allow installs from that source, which is a standard one-time prompt for any app outside the Play Store.
Build from source: the full code is on GitHub, so if you'd rather compile it yourself, you can. That's also how you confirm the app does exactly what it says.

The F-Droid merge request and the Play Store listing are both in progress, so those install paths will come later. For now it's sideload or build.

After install, Nudge will ask for the Accessibility permission. This is the part people get nervous about, so let's be straight about it. Accessibility access is what lets the app see which app is in the foreground so it can show the pause screen at the right moment. Every Android app blocker that isn't Google's own Digital Wellbeing needs it, because Android doesn't expose blocking any other way. The reason you can trust Nudge with it specifically is the zero internet permission plus the open source code. The app physically can't send what it sees anywhere, and you can read the code to confirm that. Broad local permission with no network is the safest version of how these apps have to work.

FAQ

Is Opal free?
There's a free tier, but it's very limited, and the focus features people install Opal for are part of Opal Pro, which is about $99 a year. So in practice, no, the version you actually want isn't free.

Is there an Android version of Opal?
Yes. Opal has an official Android app on Google Play, alongside its iPhone and Mac apps. The catch is that the Android version launched later than iOS, is still catching up on features, and the useful parts require the paid Pro subscription. If you want the same kind of friction on Android for free, you need a different app like Nudge, ScreenZen, or one sec.

Is Nudge as good as Opal?
For the core job, putting friction between you and Instagram, yes. Opal's dashboard is nicer, no argument. But on Android you'd be paying about $99 a year for Opal's less complete app, while Nudge does the actual job for free: pause before you open something, cap your daily time, and do it without a subscription. See the full rundown of free Android app blockers.

Is a free open-source app safe to give Accessibility access?
This is the right question to ask of any blocker. With Nudge the answer is yes for a concrete reason: it requests no internet permission, so anything it observes can't leave your phone, and the source is public so you can verify that. A closed-source free app with full network access is the thing to be wary of, not this.

One thing to do next

If you're on Android and you came here looking for Opal, you found the catch: the Android app is paid, and the free version barely does anything. The good news is the part of Opal you wanted, the pause that breaks the scroll, is free on Android. Grab the Nudge APK from GitHub, read the code if you're the type who reads code, and set a pause on the two apps you reach for without thinking. That's the whole game.

Free one sec Alternative for Android (Open Source) [2026]

Diven Rastdus — Fri, 29 May 2026 05:30:22 +0000

You saw a one sec demo on iOS, loved the idea of a forced breath before Instagram opens, then went looking for it on Android and found one of three things. The Android app was there, but rougher than the demo you watched. Or it worked, but blocking more than one app meant paying about $20 a year. Or it was installed, working fine, and then your Samsung silently reset its permissions overnight and the pause just stopped firing. If you searched "one sec alternative android free" because of any of those, this is for you. Nudge does the same delay-before-opening pause, on Android, free and open source, with zero tracking.

I'll be straight about what one sec gets right, where the Android version actually falls down, and where Nudge is honestly a better fit. No trashing. The mechanic one sec popularized is genuinely good. The problem is access, not idea.

What one sec actually does

The core of one sec is one move: you tap a distracting app, and instead of it opening instantly, the screen takes over for a few seconds. It tells you to take a breath. Sometimes it makes you hold the phone still until the animation finishes. Then it asks, gently, whether you still want to open the app. Often you don't. The dopamine loop that made you reach for the phone has already half-dissolved by the time the breath ends.

That's it. That's the whole trick, and it works because it inserts a conscious choice into a movement that had become automatic. one sec calls it an "intervention." Researchers who studied it found people opened their target apps a lot less when this pause was in the way. The genius is that it doesn't block you. You can always continue. It just makes you decide on purpose instead of on reflex.

So the idea is sound. The question is whether you can get it, reliably, on the phone you actually own.

Why Android users struggle with one sec

Here's where it gets frustrating. one sec was built iOS-first, and it shows.

It's paid past one app. The free tier limits you to a single app, and one sec pro runs about $20 a year on subscription (or $2.99 a month) to unlock the rest. For one breathing screen, that's a hard sell, especially when the mechanic itself is simple. You're renting a pause.

The Android build lags the iOS one. Features land on iPhone first. The Android app has historically been the second-class citizen, and reviews reflect it.

The permission-reset bug. This is the big one. On Android, an app like this needs Accessibility permission to detect when you open Instagram or TikTok and slide the pause in front of it. On a lot of Samsung devices (and some other aggressive battery-optimizers), the system kills background apps and quietly revokes Accessibility access. You wake up, open Instagram, and nothing happens. The pause is gone. You have to dig back into Settings and re-grant permission, sometimes every few days. People have reported exactly this, and it turns a habit tool into a chore. A blocker that silently stops working is worse than no blocker, because you stop trusting it.

None of this is one sec being lazy. It's the reality of building Android digital-wellbeing apps on top of a permission model that fights you. But the result is the same: Android users want the one sec experience and keep hitting a wall.

Nudge: Free one sec Alternative Built for Android

Nudge is an open-source Android app blocker. It's free. Not free-tier-with-an-upsell. There is no pro version, no paywalled feature, no subscription. The whole thing is on GitHub, so you can read the code if you want to know exactly what it does.

The headline feature is the one you came for.

Delay-to-open with a breathing beat

Open an app you've put under Nudge and a pause screen comes up first: a short breathing beat, then a choice to open it or back out. Same conscious-choice moment one sec built its name on, and it's deliberately so, because the mechanic is the good part. Nudge's contribution isn't reinventing the pause. It's making the pause free, auditable, and native to Android.

Around the pause, Nudge stacks a few more friction tools for when a single breath isn't enough. Per-app daily time budgets are the one most people reach for: give Instagram 20 minutes a day, and when it's gone, it's gone. You can also bundle all your social apps into one group and govern them together, or set schedule rules so TikTok is off during work hours and after 11pm. If a whole app is too blunt, Nudge can kill just the doomscroll surfaces. YouTube Shorts, Instagram Reels, or the TikTok feed, while keeping the rest of the app usable. And there's a grayscale mode that drains the color out of your phone so it stops looking like a slot machine.

Why a pause works better than a hard block

A wall makes you want to climb it. Most hard blockers get uninstalled in week two because they feel like a parent, and the moment you really want the app you just turn the blocker off, which trains you to override it.

A pause is different. It doesn't say no. It says "are you sure?" and lets you answer. For impulsive, ADHD-pattern reaching, that gap between the reflex and the action is exactly where the habit lives. You're not fighting yourself. You're giving the slower part of your brain a few seconds to catch up. That's why the one sec mechanic landed in the first place, and it's why Nudge built its core around the same idea instead of a brick wall. If you want the longer version of why friction beats blocking for ADHD brains, there's a separate writeup on the best free ADHD app blocker for Android.

How Nudge's privacy model differs

Nudge isn't just cheaper. It's a different posture entirely.

Most of these apps are sitting on an intimate log of your attention. A tool that watches every app you open, where does that data go? With closed-source apps you have to trust a privacy policy and hope.

Nudge has no internet permission. Not "we promise not to send your data." The app literally cannot reach the network, because that capability isn't in the build. Your list of blocked apps, your usage counts, your schedules, all of it stays on the device. There's nothing to leak, nothing to sell, no server holding your attention log.

No account. No signup. No email. You install it and it works. And because it's open source, you don't have to take my word for any of this. The code is public. Anyone can check that the network permission isn't there and that nothing's being collected. That's a kind of trust a closed-source app, free or paid, can't offer. The honesty is verifiable, not promised.

one sec vs Nudge

	one sec	Nudge
Delay-before-opening pause	Yes (the original)	Yes (same mechanic)
Platform	iOS-first, Android second	Android only
iOS support	Yes	No
Price	Free for 1 app, ~$20/yr for pro	Free, all features
Open source	No	Yes, on GitHub
Account	Optional (for cross-device pro sync)	None
Internet permission	Yes	None
Per-app time budgets	Yes	Yes
Block Reels/Shorts/TikTok feed	Not a listed feature	Yes
Grayscale mode	Not a listed feature	Yes
Samsung permission stability	Reported reset issues	Same Accessibility model, runs fully on-device with nothing to sync

Two caveats. Nudge is Android only. If you live on an iPhone, one sec is your tool, full stop, and I'm not going to pretend otherwise. And Nudge uses Accessibility permission like every app in this category, so on aggressive battery-optimizing phones you may still need to whitelist it from battery optimization to keep it reliable. What Nudge avoids is any network or sync layer at all. Everything lives on the device, so there's nothing remote that can fall out of sync or quietly change under you.

How to set up delay-to-open in Nudge

Right now there's one live route, with two more on the way.

GitHub (available now). Go to the Nudge repo, grab the latest release APK, and install it. You'll have to allow "install from unknown sources" once, which Android prompts you through. That warning is generic, not a red flag. It shows up for anything not installed from the Play Store. If you'd rather build it yourself, the full source is in that same repo.

F-Droid (in progress). F-Droid is a trusted open-source app store for Android. Nudge has a merge request open to land there, so it isn't listed yet. Once it's accepted you'll be able to add Nudge from F-Droid like any other app and get updates automatically.

Play Store (in progress). A listing is pending review, not live yet. When it's approved, that'll be the one-tap option for people who don't want to think about sideloading.

Once installed:

Open Nudge, grant Accessibility permission when it asks. This is what lets the pause appear over your apps.
Whitelist Nudge from battery optimization. This is the step that prevents the silent-stop problem on Samsung and similar phones.
Pick the apps you want a pause on. Instagram, TikTok, YouTube, whatever your weak spots are.
Turn on delay-to-open. Optionally add a daily time budget or a schedule.

Done. Next time you reflexively tap Instagram, you get a breath and a choice instead of an instant feed.

FAQ

Is there a free one sec for Android?
Nudge does exactly that. Delay-before-opening, free, unlimited apps, no subscription. one sec itself has a free tier capped at one app, and its pro version (which lifts that cap) is a subscription around $20/yr, so if you want the mechanic free and unlimited on Android, Nudge is the answer.

How much does one sec cost?
one sec is free for a single app. To block more than one app or unlock the extra interventions you need one sec pro, which runs about $20 a year, or $2.99 a month. Nudge gives you the same delay-to-open pause plus time budgets, schedules, and grayscale at no cost.

Is Nudge really free forever?
Yes. There's no pro tier, no subscription, no paywalled features, no ads. It's open source, so even if the project went quiet, the code stays public and the version you have keeps working.

Will it actually stop me, or will I just turn it off?
Nudge uses a pause, not a wall, on purpose. You can always continue past it. The point isn't to make the app impossible, it's to make opening it a choice instead of a reflex. For impulse habits, the choice usually wins more often than a hard block you eventually disable in frustration. If a pause isn't enough, layer on a time budget or a schedule.

Is it safe to install an open-source app from GitHub?
Open source is the safer option, not the riskier one, because the code is public and auditable. Nudge has no internet permission, so it can't send your data anywhere. The "unknown sources" prompt Android shows is standard for any non-Play-Store install, not a warning about Nudge specifically. If you'd rather skip sideloading entirely, wait for F-Droid or the Play Store listing.

How is this different from a regular blocker?
Most blockers are walls. Nudge's core is a pause, which research and the popularity of the one sec mechanic both suggest works better for impulsive reaching. It also bundles time budgets, schedules, in-app feature blocking for Reels and Shorts, and grayscale. If you're comparing options broadly, here's a roundup of the best free app blockers for Android in 2026.

Get Nudge

Nudge is on GitHub now. Free, open source, no account needed. The F-Droid listing is in review and the Play Store submission is pending. If you're on Android and wanted one sec, grab the APK from GitHub and you're set up in under two minutes.

Best Free App Blockers for Android (2026)

Diven Rastdus — Fri, 29 May 2026 05:28:11 +0000

You install a screen time app on a Tuesday, full of resolve. By Thursday you've found the off switch, and by the weekend you've uninstalled it because the free tier turned out to block exactly two apps before asking for $40 a year. Sound familiar?

That's the real problem with most "free" app blockers for Android. The word free is doing heavy lifting. So this is a list of the best free app blockers for Android in 2026 where free actually means free, with the catches spelled out for the ones that aren't. I built one of these tools, so I'll be upfront about that and try to be fair to everyone else.

The short answer: best free Android app blockers in 2026 at a glance

If you just want the picks:

Most feature-complete free + private: Nudge. Open source, no subscription, no internet permission, ADHD-focused friction features.
Cleanest free option for plain blocking: ScreenZen. Good pause feature and per-app daily limits, but no in-feed blocking.
The other open-source pick: DigiPaws. Promising, also does in-feed Shorts/Reels blocking, but still alpha and no breathing-pause feature yet.
Already on your phone: Google Digital Wellbeing. Fine for awareness, weak at actual enforcement.
Freemium tools worth knowing: AppBlock, Freedom, one sec, Opal. Capable, but the part you want is usually behind a paywall.

The rest of this is how I tested, what actually separates these, and where each one falls down.

How we tested (real devices, what "free" really means)

I ran each app on a Pixel 6 (Android 14) and a Samsung A54 (Android 13) for at least a few days each, doing normal stuff. Open Instagram out of habit, hit the block, see what happens. The questions I cared about:

Does the free version actually block apps, or just count your minutes?
Can you bypass it in three taps when you're weak?
Does it need an internet connection or an account?
Is there a hidden paywall on the feature that made you install it?

"Free" here means you can do the core job (block or slow down a distracting app) without paying, without a trial clock, and without a "pro" wall on the one setting you need. A tool that blocks one app free and charges for the second one is freemium, not free. I'll say which is which.

What to look for: free vs freemium, privacy, bypass-resistance, ADHD design

Four things separate a tool you'll still use in a month from one you'll delete:

Free vs freemium. Read the Play Store screenshots for the word "Pro" or a price. If the feature you want is gated, budget for it or move on.

Privacy. App blockers see everything you open. Some send that to a server. Check the permissions. An app blocker doesn't need your contacts, and it doesn't need internet at all.

Bypass-resistance. The whole point is stopping you in a weak moment. If the off switch is one tap on the block screen, it won't survive a real craving. Good friction makes quitting annoying without making the app a prison.

ADHD design. If you have ADHD, willpower-based tools fail you specifically. What works is friction at the moment of impulse, a pause that interrupts the autopilot reach for the phone. More on that below.

Three things worth knowing before you pick

Before the tool-by-tool breakdown, three decisions shape which app is right for you. Read these first and the picks below will make more sense.

If your goal is Shorts and Reels specifically, only two tools here do it. Most blockers force you to nuke the whole app. Only in-feed blocking can strip out Shorts or Reels while leaving DMs and search alone. On this list that's Nudge and DigiPaws. DigiPaws is still alpha-stage and skips the breathing pause, while Nudge pairs feed blocking with the delay-to-open pause and per-app budgets, covered in section 1.

If you have ADHD, friction beats willpower. The standard advice to "just use less screen time" is borderline insulting, because the entire issue is that the impulse fires before the deciding part of your brain gets a vote. Willpower-based tools assume you'll see a reminder and choose to stop. ADHD brains often don't get that window. A breathing pause inserts a physical delay between the reach for the phone and the dopamine hit. It's not asking you to be disciplined, it's making the autopilot loop slightly harder to complete, which is often enough to break it. That's the design principle behind delay-to-open and grayscale: change the environment, not the willpower. I wrote more about building an ADHD-friendly app blocker setup on Android for free if this is your situation.

Every app blocker needs the Accessibility permission, so the real question is what it does with it. To detect which app you're opening, all of them use the Accessibility API. That's a powerful permission. It can read what's on your screen. You're trusting whatever app you grant it to. So the privacy question isn't "does it ask for Accessibility," because they all need it. It's "what does it do with that access, and can you check?" An app with no internet permission physically can't send your screen data anywhere. An open-source app lets you read the code and confirm it. With closed-source freemium apps, you're trusting the privacy policy and the company's incentives. Sometimes that's fine. Just know which trust you're extending. There's a longer breakdown of open-source app blockers with no internet permission if you want to go deeper on the threat model.

1. Nudge: best free + open-source + privacy-first (delay-to-open)

Full disclosure: this is the one I built. Nudge is a free, open-source Android app blocker (v1.5.6 at the time of writing), built in Kotlin and Jetpack Compose. Android only. No iOS version, and I'm not going to pretend otherwise.

What it does:

Delay-to-open. When you tap a distracting app, Nudge shows a short breathing pause first. That gap is enough to ask yourself if you actually meant to open TikTok or your thumb just did it.
Per-app daily time budgets. Give Instagram 20 minutes a day. When it's gone, it's gone.
App groups and schedules. Block a whole cluster of apps during work hours or after 11pm.
In-app feature blocking. Kill YouTube Shorts, Instagram Reels, or the TikTok feed without blocking the entire app. You keep DMs and search, you lose the endless scroll.
Grayscale mode. Drains the color out of your screen so the dopamine slot machine stops looking fun.

Here's the part that matters most to me: Nudge has zero internet permission. None. The app literally can't phone home because the capability isn't in the manifest, and because it's open source you can verify that yourself instead of trusting my word. All your data stays on the device. No account, no ads, no tracking, no "pro" tier. Everything's free because there's nothing to upsell.

Where it's weak: it's Android-only, and there's no one-tap store install today. The Play Store listing is pending review and the F-Droid listing is in progress, so for now you either build it from source or sideload the APK from GitHub. If you want a polished one-tap-from-the-store experience, that's a fair reason to wait.

How Nudge blocks YouTube Shorts and Reels without nuking the app

This is the request I hear most. You don't hate YouTube, you hate Shorts. You want to message friends on Instagram without the Reels tab sucking 40 minutes out of your evening. Most app-level blockers force you to block the whole app, which means you lose the useful part to kill the bad part.

The fix is in-feed blocking, where the tool detects the Shorts or Reels surface specifically and blocks just that, leaving the rest alone. Nudge does this. There's a step-by-step guide to blocking Shorts and Reels without blocking the app if you want the exact setup.

2. ScreenZen: solid free option, but no in-feed blocking

ScreenZen is a genuinely good free app and probably the closest thing to a direct comparison. It's fully free with no premium tier. Its core idea is the same pause-before-open friction, and it does that well. You set which apps trigger a breathing screen, and it nudges you to confirm you meant to open them. It also has per-app daily limits, so credit where it's due, that's not a gap.

Where it stops short for me: there's no in-feed blocking, so you can't strip out Reels while keeping the rest of Instagram. It's an app-level tool. If all you want is a pause screen with daily limits, ScreenZen is a clean, no-nonsense choice and I'd recommend it without hesitation. If you specifically need to block the Reels or Shorts feed while keeping the rest of the app, you'll hit its ceiling.

3. DigiPaws: the other open-source pick (alpha-stage, no delay-to-open)

DigiPaws is the other open-source app blocker worth knowing about, and the open-source corner of this category is thin, so it's worth your attention. It's privacy-respecting and actively developed. It also has an in-app blocker that strips out YouTube Shorts and Instagram Reels while leaving the rest of the app usable, which makes it the only other tool here besides Nudge that does feed-level blocking.

The catch is maturity. Last I checked it's still alpha-stage, which means rough edges and features in flux. It also doesn't have the breathing delay-to-open pause that Nudge and ScreenZen lean on. If you specifically want open source and you're comfortable with alpha software and reporting bugs, DigiPaws is a legitimate option and the project deserves support. If you want something more settled, it's early days.

4. Google Digital Wellbeing: built in, but no real enforcement

It's already on most Android phones, it's free, and it costs you nothing to set up. Digital Wellbeing shows you your screen time, lets you set app timers, and has a Focus Mode and a bedtime/grayscale schedule. For pure awareness, it's fine.

The problem is enforcement. App timers are trivially easy to dismiss with an "ignore for today" tap, and there's no real friction, no breathing pause, no bypass resistance. It's designed to inform, not to stop you. If you have the self-control for a gentle reminder to work, you might not need anything else. If gentle reminders were enough, you probably wouldn't be reading this.

5. Freemium options to know (AppBlock, Freedom, one sec, Opal) and their catch

These are well-known and several are good products. But they're freemium, and the gate usually sits on the feature you actually came for.

AppBlock has a usable free tier, but stricter blocking, multiple profiles, and the harder-to-bypass modes push you toward the paid version.
Freedom is cross-platform and polished, but the free plan caps you at a handful of blocking sessions before it asks for a subscription.
one sec is built around the same pause-before-open idea Nudge and ScreenZen use, and it does it nicely, but the free version limits how many apps you can guard before going premium. (If that limit is your blocker, here's a free Android alternative to one sec.)
Opal is heavily marketed and slick, but the meaningful enforcement and deep-focus features are paid. (Same story, here's an Opal alternative for Android that's free.)

None of these are scams. They're businesses, and the subscription funds the polish. The question is just whether you want to pay a recurring fee to stop yourself opening Instagram, or whether free does the job.

Comparison table: price, platform, open source, internet permission, key feature

Tool	Real price	Platform	Open source	Needs internet	Standout feature
Nudge	Free, all features	Android	Yes	No (zero internet permission)	Delay-to-open + feed blocking + budgets
ScreenZen	Free, all features	Android, iOS, desktop	No	Core works offline	Pause-before-open + daily limits
DigiPaws	Free	Android	Yes	No	Open source feed blocking (alpha)
Digital Wellbeing	Free, built in	Android	No	Tied to Google account	Already installed
AppBlock	Freemium	Android, iOS	No	Yes	Profiles and schedules
Freedom	Freemium	Android, iOS, desktop	No	Yes	Cross-device blocking
one sec	Freemium	Android, iOS	No	Yes	Breathing pause
Opal	Freemium	Android, iOS	No	Yes	Deep focus sessions

Platform and pricing details for the freemium tools change, so check their current listings. The free/open-source/internet-permission columns are the ones that don't quietly shift on you.

Which free Android app blocker should you pick?

You want maximum features, free, and verifiable privacy: Nudge. Android only, and for now you build from source or sideload the APK while the F-Droid and Play Store listings are in progress.
You want a clean pause screen and nothing fancy: ScreenZen.
You want open source and don't mind alpha software: DigiPaws.
You want zero install effort and just need awareness: Digital Wellbeing, already on your phone.
You don't mind paying for polish: any of the freemium options, just confirm the feature you want is in their plan.

There's no single right answer. The honest version is that the best free app blocker is the one you'll still have installed next month, which usually means the one that's annoying enough to work but not so annoying you rage-uninstall it.

FAQ

What's the best free app blocker for Android?
For genuinely free with no subscription and no paywalled features, Nudge and ScreenZen are the strongest picks. Both have a pause screen and per-app daily limits. Nudge adds in-feed Shorts/Reels blocking and verifiable, no-internet-permission privacy. ScreenZen is simpler and runs on more platforms.

Are any open source?
Yes. Nudge and DigiPaws are both open source. That means you can read the code and confirm what the app actually does instead of trusting a privacy policy. DigiPaws is earlier-stage; Nudge is at v1.5.6.

Is no-subscription real, or is there always a catch?
With most "free" app blockers, the catch is a paywall on the feature you need. With Nudge it's actually free with no pro tier, because it's open source and there's nothing to upsell. The honest tradeoff is that it's Android only and the Play Store listing is still in review.

Do app blockers need internet access?
They don't have to. Most do, for accounts and sync. Nudge ships with zero internet permission, so it can't send your data anywhere even in principle. That's the kind of thing worth checking in any app's permission list.

If you want the free, open-source, no-internet-permission option, Nudge is on GitHub. You can read the code, build it yourself, or sideload the APK. The F-Droid and Play Store listings are in progress. No account, no email, no catch. And if you've been deleting screen time apps for years because the free version never did the one thing you needed, that's exactly what this one is built to fix.

5 Monitoring Blind Spots That Let My Side Projects Fail Silently

Diven Rastdus — Thu, 28 May 2026 12:10:28 +0000

I run four side projects. A journaling app, an Android app blocker, a healthcare AI tool, and a content pipeline. Total monitoring budget: $0.

Last month, one of them went down for 24 hours. Nobody told me. I found out by accident.

That scared me enough to audit all four projects. I found the same five blind spots across every single one.

1. No Uptime Checks (The "It's Probably Fine" Gap)

My journaling app runs on Supabase's free tier. Free-tier projects auto-pause after 7 days of inactivity. I knew this in theory.

In practice, I shipped a demo to a potential client. The project had been idle. Supabase paused it. The API returned nothing. The frontend showed a blank screen.

For 24 hours, anyone visiting saw a broken app. I only discovered it when I opened the dashboard for an unrelated reason.

The fix: A cron job that hits every critical endpoint every 6 hours.

#!/bin/bash
# health-check.sh - runs via cron every 6h
ENDPOINTS=(
  "https://my-app.vercel.app/api/health"
  "https://my-backend.supabase.co/rest/v1/"
)

for url in "${ENDPOINTS[@]}"; do
  status=$(curl -sf -o /dev/null -w "%{http_code}" "$url" --max-time 10)
  if [ "$status" != "200" ]; then
    python3 ~/bin/alert.py --message "DOWN: $url returned $status"
  fi
done

Total cost: $0. Runs on the same machine that runs everything else. Better Stack or UptimeRobot are better options. But this costs nothing and catches 80% of failures.

2. Unstructured Logs Across Services

My healthcare AI tool runs three microservices on Cloud Run: an MCP server, an orchestrator agent, and an interaction checker. When a patient reconciliation fails, which service caused it?

With print() statements, the answer is "good luck." Cloud Run interleaves logs from all services. One request touches all three. There's no correlation ID linking them.

I spent 40 minutes tracing a bug that turned out to be a timeout in the MCP server. The orchestrator logged "reconciliation failed." The MCP server logged nothing useful. The interaction checker never got called.

The fix: Structured JSON logs with a request ID passed through every service call.

import json, uuid, sys

def log(level, msg, **extra):
    entry = {"severity": level, "message": msg, **extra}
    print(json.dumps(entry), file=sys.stderr)

# At the request entry point
request_id = str(uuid.uuid4())[:8]
log("INFO", "Reconciliation started",
    request_id=request_id, patient_id=patient_id)

# Pass request_id to downstream services via header
# X-Request-ID: {request_id}

Cloud Run (and most log aggregators) parse JSON automatically. Now I can filter by request_id and see the full trace across services. Structured logging was the single most impactful monitoring improvement I made.

3. Zero Mobile Crash Visibility

My Android app blocker uses Kotlin and Jetpack Compose. R8 (Android's code shrinker) silently removed a class my accessibility service needed. The app installed fine. It launched fine. The core feature just... didn't work.

I found this bug during manual testing on a real device. If this had shipped to users, I would have had zero visibility. No crash reports. No error logs. Nothing.

Android's logcat only works when you're connected via USB. Once the app is on someone else's phone, you're blind.

The fix: At minimum, catch uncaught exceptions and log them somewhere you can read later.

Thread.setDefaultUncaughtExceptionHandler { thread, throwable ->
    val report = buildString {
        appendLine("Thread: ${thread.name}")
        appendLine("Error: ${throwable.message}")
        appendLine(throwable.stackTraceToString().take(2000))
    }
    // Write to local file, upload on next app launch
    File(context.filesDir, "crash.log").writeText(report)
}

Crashlytics, Sentry, or Bugfender give you stack traces, device info, and occurrence counts out of the box. This basic handler still beats flying blind when you're not ready to pay for one.

4. API Quota Exhaustion With No Warning

This week, my social media automation stopped working. No errors in my code. No exceptions. Just... nothing posted.

The X (Twitter) API returns a CreditsDepleted error when you hit your monthly quota. My posting script caught the error, logged it to a file, and moved on. Nobody reads log files proactively.

I discovered the issue 2 days later when I manually checked why engagement dropped to zero.

The fix: Treat quota and billing errors as alerts, not log lines.

try:
    response = api.post_tweet(text)
except ApiError as e:
    # CreditsDepleted = all posting dead until cycle resets. Treat as outage.
    if "CreditsDepleted" in str(e) or e.status_code == 429:
        send_alert(f"API QUOTA HIT: {e}. All posting blocked until reset.")
    else:
        logger.error(f"Tweet failed: {e}")

The distinction matters. A 500 error is transient. A quota error means everything is broken until the billing cycle resets. That deserves a push notification, not a log line buried in a file.

5. CI Tests That Don't Run Against Production

Last week, my healthcare tool's production API broke. I didn't find out from my CI pipeline. I found out from a GitHub notification that sat unread in my inbox for 3 days.

The problem: my end-to-end tests run against local Docker containers. They pass every time. But the deployed Cloud Run services had drifted. CI was green. Production was broken.

The fix: A scheduled workflow that hits the real production URLs every 6 hours.

# .github/workflows/e2e-smoke.yml
name: e2e smoke tests
on:
  schedule:
    - cron: '0 */6 * * *'
jobs:
  smoke:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: pip install httpx pytest
      - run: pytest tests/e2e/ -v
        env:
          MCP_SERVER_URL: ${{ secrets.PROD_MCP_URL }}

CI passing on localhost doesn't mean production works. Scheduled tests against real endpoints catch the drift. I also routed failure notifications to Telegram instead of GitHub's notification bell. GitHub is too noisy. A direct push notification cuts through.

The Pattern

Every one of these gaps follows the same shape: something fails, nothing tells me, I find out too late.

The fixes are embarrassingly simple. A cron job. A JSON format string. A try/except that sends a push notification instead of writing to a file. None of this is hard.

Monitoring isn't about the tool. It's about closing the loop between "something broke" and "someone who can fix it found out." If that loop is open, nothing else matters.

3 Expo SDK 56 Bugs That Crashed My App Before It Even Launched

Diven Rastdus — Wed, 27 May 2026 12:07:38 +0000

I burned four EAS cloud builds and two hours chasing crashes that had nothing to do with my code. All three bugs came from Expo SDK 56 defaults that silently break Android builds. Here's each one and how to fix it.

Bug 1: expo-av crashes with NoClassDefFoundError

I added voice recording to a dream journal app. The Expo docs for Audio still reference expo-av in some examples. So I installed it:

npx expo install expo-av

The app compiled. TypeScript was happy. Then the EAS build failed on Android with:

java.lang.NoClassDefFoundError: 
  Failed resolution of: Lio/expo/modules/video/VideoViewModel;

The expo-av package pulls in video dependencies. In SDK 56, the video module was extracted to a separate expo-video package. The old monolith references classes that no longer exist.

The fix: expo-av is deprecated starting SDK 55. Use expo-audio for audio and expo-video for video. They're separate packages now.

npm uninstall expo-av
npx expo install expo-audio

The API changed too. Old:

import { Audio } from 'expo-av';

const recording = new Audio.Recording();
await recording.prepareToRecordAsync(Audio.RecordingOptionsPresets.HIGH_QUALITY);
await recording.startAsync();

New:

import { useAudioRecorder, RecordingPresets } from 'expo-audio';

const recorder = useAudioRecorder(RecordingPresets.HIGH_QUALITY);
recorder.record();

The new API is hook-based. No more class instances, no manual cleanup. useAudioRecorder handles permissions, lifecycle, and cleanup on unmount.

Time lost: 4 EAS builds (~60 minutes). The error message mentions VideoViewModel, which sent me down a wrong path investigating video dependencies before I realized the entire package was deprecated.

Bug 2: Gradle 9.x silently breaks React Native

After fixing the audio crash, the next build failed with a different NoClassDefFoundError:

java.lang.NoClassDefFoundError: 
  com/android/build/api/variant/impl/JvmVendorSpec

npx expo prebuild generated gradle-wrapper.properties pointing to Gradle 9.3.1. Gradle 9 removed JvmVendorSpec.IBM_SEMERU, which React Native's Gradle plugin still references internally.

The error doesn't mention Gradle versions. It doesn't say "incompatible Gradle." It just throws a class-not-found at build time.

The fix: Pin Gradle to 8.x. After every npx expo prebuild, check the generated wrapper:

# Check what version prebuild generated
grep distributionUrl android/gradle/wrapper/gradle-wrapper.properties

If it says anything starting with gradle-9, change it:

distributionUrl=https\://services.gradle.org/distributions/gradle-8.13-bin.zip

Add this to CI to catch it automatically:

GRADLE_VER=$(grep -oP 'gradle-\K[0-9]+' android/gradle/wrapper/gradle-wrapper.properties)
if [ "$GRADLE_VER" -ge 9 ]; then
  echo "ERROR: Gradle $GRADLE_VER breaks React Native. Pin to 8.x"
  exit 1
fi

Time lost: 2 builds. The error looks identical to the expo-av crash (both are NoClassDefFoundError), which made me think I hadn't fully fixed bug #1.

Bug 3: Barrel exports + native modules = cascading crash

I had a standard barrel export file:

// src/dream/components/index.ts
export { DreamCard } from './DreamCard';
export { MoodPicker } from './MoodPicker';
export { VoiceRecorder } from './VoiceRecorder';

VoiceRecorder imports expo-audio. Every screen that imported anything from @dream/components would trigger the native module resolution for expo-audio, even screens that never rendered the recorder.

In Expo Go (no native modules bundled), this crashes the entire app. Not just the recording screen. Every screen.

The fix: Never barrel-export components that depend on native modules. Import them directly and lazy-load:

// src/dream/components/index.ts
export { DreamCard } from './DreamCard';
export { MoodPicker } from './MoodPicker';
// VoiceRecorder NOT barrel-exported -- requires native module
// Import directly: import { VoiceRecorder } from '@dream/components/VoiceRecorder'

On the consuming screen, use React.lazy:

import { lazy, Suspense } from 'react';

const VoiceRecorder = lazy(() =>
  import('@dream/components/VoiceRecorder')
    .then(m => ({ default: m.VoiceRecorder }))
);

// In render:
<Suspense fallback={<ActivityIndicator />}>
  <VoiceRecorder />
</Suspense>

This way the native module only loads when the component actually renders, and screens that don't use it never touch expo-audio.

Time lost: 1 hour. The crash logs pointed to the native module, not the import chain. I kept looking at expo-audio configuration when the real problem was in index.ts.

The checklist I wish I had

Before your next Expo SDK 56 Android build: grep for expo-av (replace with expo-audio/expo-video), check gradle-wrapper.properties isn't 9.x after prebuild, and audit barrel exports for native module imports.

But mostly: check the SDK changelog before choosing packages. I would have caught bug #1 in 30 seconds by reading the Expo SDK 56 changelog. The deprecation is documented. I just didn't look.

DEV Community: Diven Rastdus

My Expo Device Tests Could Break Without CI Noticing. Here Is the Fix.

Why the AI fell back to pixel coordinates

Step 1: testIDs on the flows that matter

Step 2: encode the flows in Maestro, self-contained

The trap: an on-device suite can break with zero CI signal

Step 3: a Jest contract test makes the testIDs unregressable

Step 4: run the same flows against the release APK

The takeaway

4 Ways RevenueCat Silently Denies Paying Users Their Entitlements

1. Purchases.logIn() was never called

2. No customerInfo listener

3. The RC session leaked between users on the same device

4. The webhook handles purchases but ignores refunds and cancellations

The checklist

RevenueCat Said My Play Store Credentials Were Invalid. They Weren't.

The setup

Trap 1: "Invalid Play Store credentials" usually means "wait"

Trap 2: new products return ITEM_UNAVAILABLE for hours

Trap 3: test with license testers, or you'll charge yourself

The pattern underneath

3 React Native Bugs That Crashed on Device but Passed Every Test

Bug 1: The Gold Button That Turned Grey

Bug 2: The Environment Variable That Existed Until It Didn't

Bug 3: The Missing Crypto API

The Pattern

What I Do Now

Block YouTube Shorts and Reels on Android (Keep the App)

Block YouTube Shorts & Reels on Android (Keep the App)

The problem: you need the app, not the Shorts and Reels feed

Why blocking the whole app fails

How in-app feed blocking works on Android (no root)

What Accessibility permission actually sees (and what it can't do)

Step-by-step setup (YouTube, Instagram, TikTok)

Block YouTube Shorts

Block Instagram Reels and Explore

Block the TikTok For You feed

Pairing feed-blocking with a delay-to-open pause

Nudge vs other feed blockers

FAQ

Try it

The Best Free ADHD App Blocker for Android

The Best Free ADHD App Blocker for Android

Why every blocker you've tried failed: one tap to bypass

Your thumb opens Instagram before your brain catches up

The mechanism, in two parts: low baseline dopamine and a broken clock

Friction, not punishment: the case for a pause over a hard block

Delay-to-open as a prefrontal circuit-breaker

Killing the slot machine: blocking Shorts, Reels, and TikTok feeds

Grayscale and time budgets as backup layers (honest expectations)

Nudge: a free ADHD app blocker for Android, open source, no account

Honest answers to the two questions you're probably asking

How to start: install and first 10-minute setup

Open-Source App Blocker for Android With No Internet Permission

Open-Source App Blocker for Android With No Internet Permission

The hidden cost of free app blockers: you are the product

What Accessibility permission can see (and why that's the real risk)

The StayFree story: when your blocker gets acquired

Policy vs constraint: why "we don't track you" isn't enough

Zero internet permission, explained: the app cannot open a network connection

How to verify it yourself in Android Settings before installing

Reading the source: what GPL-3.0 and a public repo actually buy you

No account, no telemetry, all data local: what stays on your device

How to install from GitHub today (and what's coming on F-Droid)

FAQ

Free Opal Alternative for Android (No $99/yr Subscription)

Quick answer: is Opal free on Android?

What people love about Opal (and what it costs)

Why Opal's Android app is the weaker one

What an Android Opal alternative actually needs to match

Nudge: the free Opal alternative built for Android

Delay-to-open instead of Opal's hard sessions

Per-app daily time budgets and schedule rules

Privacy upgrade: no account, zero internet permission

Opal vs Nudge: price, privacy, and what's free

How to install Nudge on Android

FAQ

One thing to do next

Free one sec Alternative for Android (Open Source) [2026]

What one sec actually does

1. `Purchases.logIn()` was never called

2. No `customerInfo` listener