When Paying Users Still See Ads: Collapsing the Ad-Free Check Into One Place

Unify the question, not the flag

This is where I ended up doing the opposite of what I first planned.

My initial idea was to merge the state: keep one isAdFree boolean somewhere and have both purchases and rewards write into it. It is easy to build and it falls apart quickly. Rewards expire and purchases do not, so a single boolean immediately inherits a re-evaluation problem. Recompute on every navigation? Poll on a timer? And with more writers, you lose track of who last wrote false.

What actually held up was leaving the state with its owners and unifying only the question.

/**
 * The single place that decides whether an ad may be shown.
 * State stays with BillingManager / AdFreeManager; this class only
 * composes the answer for right now.
 */
class AdGate(
    private val billing: BillingManager,
    private val rewardAdFree: AdFreeManager,
) {
 
    /** True when any path — purchase, restore, or reward — suppresses ads. */
    fun isAdFree(): Boolean =
        billing.isPurchasedAdFree() || rewardAdFree.isActive()
 
    /**
     * Whether an ad may be shown. Call sites write no other condition.
     * The reason is returned so suppressions are traceable in logs.
     */
    fun evaluate(): AdDecision = when {
        billing.isPurchasedAdFree() -> AdDecision.Suppress(Reason.PURCHASED)
        rewardAdFree.isActive()     -> AdDecision.Suppress(Reason.REWARD)
        !billing.isRestoreSettled() -> AdDecision.Suppress(Reason.RESTORE_PENDING)
        else                        -> AdDecision.Allow
    }
}
 
sealed interface AdDecision {
    data object Allow : AdDecision
    data class Suppress(val reason: Reason) : AdDecision
}
 
enum class Reason { PURCHASED, REWARD, RESTORE_PENDING }

Call sites become:

when (adGate.evaluate()) {
    is AdDecision.Allow -> interstitialAd.show(this)
    is AdDecision.Suppress -> Unit  // do nothing
}

Putting RESTORE_PENDING on the suppress side is the part that earns its keep in production. The Play Billing query has not returned during the first seconds after launch. Treating "unknown" as "go ahead and show" produces a bug that is hard to reproduce and perfectly visible to the person affected: a purchaser sees ads for a few seconds every time they open the app. Losing one impression costs far less than showing an ad to someone who paid not to see one.

That "when in doubt, suppress" stance is the same conclusion I reached in Untangling Android back-button ad gates into a parallel, priority-ordered design. Ad logic becomes unreadable the moment priority is implicit.

Do not trust the device clock with an expiry

The first pitfall I hit in production was holding this temporary window against the device clock alone. The obvious implementation looks like this.

// Obvious, but survives a user rolling the device clock backwards
fun grant(durationMillis: Long) {
    prefs.edit().putLong(KEY_EXPIRES_AT, System.currentTimeMillis() + durationMillis).apply()
}
 
fun isActive(): Boolean =
    prefs.getLong(KEY_EXPIRES_AT, 0L) > System.currentTimeMillis()

System.currentTimeMillis() is user-editable in Settings. Move the clock back and the stored expiry effectively extends forever. SystemClock.elapsedRealtime() cannot be tampered with, but it resets on reboot, so it cannot carry a window across a restart on its own.

Neither works alone. To avoid a rolled-back clock while still surviving a reboot, I store both and take whichever expires sooner.

class AdFreeManager(private val prefs: SharedPreferences) {
 
    fun grant(durationMillis: Long) {
        prefs.edit()
            .putLong(KEY_WALL_EXPIRES_AT, System.currentTimeMillis() + durationMillis)
            .putLong(KEY_BOOT_EXPIRES_AT, SystemClock.elapsedRealtime() + durationMillis)
            .putLong(KEY_GRANTED_BOOT_ID, bootId())
            .apply()
    }
 
    fun isActive(): Boolean {
        val wallLeft = prefs.getLong(KEY_WALL_EXPIRES_AT, 0L) - System.currentTimeMillis()
 
        // Trust elapsedRealtime only within the boot session that granted it
        val sameBoot = prefs.getLong(KEY_GRANTED_BOOT_ID, -1L) == bootId()
        val bootLeft = if (sameBoot) {
            prefs.getLong(KEY_BOOT_EXPIRES_AT, 0L) - SystemClock.elapsedRealtime()
        } else {
            Long.MAX_VALUE  // after a reboot, fall back to wall clock only
        }
 
        return minOf(wallLeft, bootLeft) > 0L
    }
 
    /** Boot session identifier: now minus uptime is roughly the boot instant. */
    private fun bootId(): Long =
        (System.currentTimeMillis() - SystemClock.elapsedRealtime()) / 1000L
 
    private companion object {
        const val KEY_WALL_EXPIRES_AT = "ad_free_wall_expires_at"
        const val KEY_BOOT_EXPIRES_AT = "ad_free_boot_expires_at"
        const val KEY_GRANTED_BOOT_ID = "ad_free_granted_boot_id"
    }
}

Within one boot session the two clocks cross-check each other; after a reboot the wall clock decides alone. Rolling the clock backwards also shifts the estimated boot instant, so bootId() changes and the uptime branch stops applying. It is not airtight, but it closes the case where changing the date in Settings converts a short reward window into a permanent one.

If you have a backend, I recommend holding the expiry there — this whole section disappears. My wallpaper apps run without one, so this is the compromise that works inside the device. Decide based on your own architecture rather than copying mine.

A pure function turns "should test" into "can test"

The side benefit of AdGate mattered more than I expected: the decision became testable. While the logic lived as conditions scattered across Activities, writing a test for it was not realistic.

class AdGateTest {
 
    private class FakeBilling(
        private val purchased: Boolean,
        private val settled: Boolean = true,
    ) : BillingManager {
        override fun isPurchasedAdFree() = purchased
        override fun isRestoreSettled() = settled
    }
 
    private class FakeReward(private val active: Boolean) : AdFreeManager {
        override fun isActive() = active
    }
 
    @Test
    fun `suppresses while a restore is still unsettled`() {
        val gate = AdGate(FakeBilling(purchased = false, settled = false), FakeReward(false))
        assertEquals(AdDecision.Suppress(Reason.RESTORE_PENDING), gate.evaluate())
    }
 
    @Test
    fun `a purchase wins regardless of reward state`() {
        val gate = AdGate(FakeBilling(purchased = true), FakeReward(false))
        assertEquals(AdDecision.Suppress(Reason.PURCHASED), gate.evaluate())
    }
 
    @Test
    fun `allows when no path suppresses`() {
        val gate = AdGate(FakeBilling(purchased = false), FakeReward(false))
        assertEquals(AdDecision.Allow, gate.evaluate())
    }
}

More valuable than the tests themselves was finally being able to count the inputs. Three axes — purchase, reward, restore — give eight combinations, and exactly one of them permits an ad. Back when the conditions were scattered, I had no sense of that "exactly one".

Prevent the next omission structurally

Cleaning this up once does nothing for the screen you add next month. So I moved the guarantee out of human attention and into CI.

#!/usr/bin/env bash
# tools/check-ad-gate.sh
# Detect ad calls that do not go through AdGate
set -euo pipefail
 
VIOLATIONS=$(grep -rnE '\.(show|loadAd)\(' app/src/main/java \
  --include='*.kt' \
  | grep -vE 'AdGate\.kt' \
  | while IFS= read -r hit; do
      FILE="${hit%%:*}"
      # does the same file reference the gate at all?
      grep -q 'adGate' "$FILE" || echo "$hit"
    done)
 
if [ -n "$VIOLATIONS" ]; then
  echo "Ad calls not routed through AdGate:"
  echo "$VIOLATIONS"
  exit 1
fi
 
echo "ad gate check: OK"

It is a coarse, file-level check. But its actual job is to make sure anyone adding an ad to a new screen bumps into AdGate exactly once, and for that it has been enough. I chose discoverability over rigor.

Banners declared in layout XML slip past this grep entirely. I handle those by wrapping the ad view in a single custom view and making "never place AdView directly" the rule, which brings them back onto the same check.

Anything that must not appear simultaneously — dialogs, paywalls, ads — tends to converge on this shape. I landed in the same place in fixing overlapping paywall and review dialogs with a central ModalGate: stop letting each site decide visibility, and give them one place to ask.

What I handed to Claude Code, and what I kept

I delegated the inventory and the first draft of the mechanical replacements. Nothing beyond that.

The delegation paid off on exhaustive enumeration. When a person greps, they look for what they expect to exist and miss what was never written. Starting from the call sites makes the unguarded ones surface on their own.

The decision to put RESTORE_PENDING on the suppress side, though, was not derivable from anything I handed over. That is a judgment about how much a purchaser seeing an ad costs the business. An agent is fast at laying out the options; choosing among them stays with you. That boundary is clearer to me now than it was before this refactor.

One next step

If you run an app with this shape, try just one thing. List every show and loadAd call, and next to each write whether the guard in front of it reads both the purchase state and the reward state.

If even one line reads only one of them, that is where someone is being shown an ad right now. For me, that single column was reason enough to start.