Show account-creation modal recurrently (every 60 days) for logged-out users

[yaelirub]

Description

Port the iOS recurring "Encourage Account Creation" (EAC) modal to Android.

Background: signup conversions have been trending down. The EAC modal — the "We noticed you're not logged in" prompt with the sync / backups / recommendations benefits — had a positive impact on signups when it ran in 2025, but it was a one-shot (shown once then disabled, and suppressed entirely for new installs) tied to app updates. This makes it recurring: shown to logged-out users on a 60-day cadence, decoupled from app updates, matching the iOS change (pocket-casts-ios#4985 / PCIOS-900).

What changed

• AccountEncouragement (utils, new) — pure, unit-testable cadence logic: decide(isEligible, lastShown, now, interval) → Show / Wait, with a 60-day interval. Shows on the first eligible launch (no anchor yet), once the interval elapses, or when the stored anchor is in the future (backwards device clock / restored skewed backup, which would otherwise suppress the modal indefinitely).
• Settings — replaced the one-shot showFreeAccountEncouragement: Boolean with freeAccountEncouragementLastShown: Instant? (the cadence anchor).
• MainActivity.encourageAccountCreation() — gates on the new ENCOURAGE_ACCOUNT_CREATION feature flag, computes eligibility (logged out and past onboarding via hasCompletedOnboarding()), and shows the modal on the first eligible launch, then every 60 days while the user stays logged out. The anchor is recorded when the modal is shown. The post-restore login prompt anchors the clock so it doesn't double-show.
• AppLifecycleObserver — fresh installs anchor the cadence at install time, so the modal waits a full 60-day interval before its first show (matching iOS, which anchors in AppDelegate's case .installed). Existing users upgrading leave the anchor null and see it on the first eligible launch.
• Feature — added ENCOURAGE_ACCOUNT_CREATION (default on, Firebase remote flag + dev toggle) for parity with the iOS feature flag / a remote kill-switch.

Signed-in users never see it; existing inline login prompts are unchanged.

Part of DSGPOC-88.

Fixes PCDROID-728

Testing Instructions

The real interval is 60 days; to exercise the cadence quickly, use a debug build and adjust the device clock, or clear app data between runs.

1. Ensure the ENCOURAGE_ACCOUNT_CREATION feature flag is enabled (Beta Features screen).
2. On a logged-out device that has completed initial onboarding, launch the app → confirm the EAC modal appears on this first eligible launch.
   • On a fresh install, the cadence is anchored at install time, so the modal does not appear on the next launch — it waits a full interval.
3. Dismiss the modal and relaunch within the interval → confirm it does not reappear.
4. Advance past the 60-day interval (device clock / data reset) and relaunch → confirm it appears again.
5. Log in and relaunch → confirm the modal never appears for a signed-in user.
6. Tablet: confirm the benefits dialog (AccountBenefitsFragment) shows instead of the full onboarding flow.

Note: unit tests for the new AccountEncouragement decision logic pass (:modules:services:utils:testDebugUnitTest --tests "*AccountEncouragementTest"). The :app module compiles cleanly. I was unable to run :modules:features:shared unit tests locally due to a pre-existing :modules:services:crashlogging KSP/Dagger build failure (cannot find symbol: class CrashLogging) that reproduces on main without these changes — flagging separately.

Screenshots or Screencast

Checklist

• If this is a user-facing change, I have added an entry in CHANGELOG.md
• Ensure the linter passes (./gradlew spotlessApply to automatically apply formatting/linting)
• I have considered whether it makes sense to add tests for my changes
• All strings that need to be localized are in modules/services/localization/src/main/res/values/strings.xml
• Any jetpack compose components I added or changed are covered by compose previews
• I have updated (or requested that someone edit) the Event Horizon schema to reflect any new or changed analytics.

I have tested any UI changes...

🤖 Generated with Claude Code

[geekygecko]

Looks good!

Is it showing the message too soon after they first install the app? They’ve already decided not to create an account, but then the next time they open the app, they’re presented with this page.

account.mp4

[geekygecko]

Would it be possible to add to the prompt for Opus to reduce the comments to one line? It seems to be overexplaining and producing comments that might not be necessary.

[yaelirub]

Yes! Updated here: 6fcf1ce. I wish we could use a shared Claude memory

[yaelirub]

Thanks for the review, @geekygecko . You're right about the modal appearing first launch after declining account creation in onboarding, and this turned out to be a divergence from iOS rather than intended behaviour.

Fixed in 99efa04 by anchoring on fresh install in AppLifecycleObserver (the direct analogue of the iOS hook) and removing the fragile completion-handler anchoring. Added coverage for both halves: new installs anchor, upgrades don't.

I've also corrected the PR description, which claimed dropping the new-install suppression "matched iOS" — that was backwards.

[claude]

(non-blocking) This block is guarded by getMigratedVersionCode() == 0, and that value is only written by VersionMigrationsWorker (VersionMigrationsWorker.kt:207), which is enqueued asynchronously from PocketCastsApplication.setupApp(). Every process start before the worker completes re-runs handleNewInstallOrUpgrade() — the other new-install writes here are idempotent booleans, but a timestamp isn't, so the anchor slides forward on each of those starts.

In practice the worker runs within the first session, so the drift is minutes. Worth knowing, though, that "anchored at install time" is really "anchored at the last process start before migrations ran."

[claude]

Claude finished @yaelirub's task in 1m 13s —— View job

---

Review — commits since last pass (5999dad, 6fcf1ce)

The two new commits are the Firebase key rename (encourage_account_creation → encourage_account_creation_recurring, unique in the enum) and comment trimming. Both are clean, and the trimming didn't remove anything load-bearing. No new findings.

Three findings from earlier passes are still open on the current tree:

Blocking

• app/.../ui/MainActivity.kt:717 — signing out still re-triggers the modal on the next foreground (see the existing thread on this block). The anchor is only written on show / restore / fresh install, so a user signed in since before this ships has a null anchor; sign out → background → return gives them "We noticed you're not logged in" immediately. Either anchor on sign-out or confirm iOS does the same.

Non-blocking

• app/.../ui/MainActivity.kt:499,717 — updateModifiedAt = true on both writes is a dead write; this pref isn't in SyncSettingsTask, and AppReviewManagerImpl uses false for the same pattern. Fix this →
• app/.../ui/MainActivity.kt:361 — launchedInitialOnboarding is still not persisted in onSaveInstanceState (line 789). The fresh-install anchor added in 99efa04 closes the common case, so this now only bites a pre-99efa04 install that never finished onboarding and is recreated mid-onboarding — much narrower than when I first raised it, but the guard still silently disappears on recreation.
  · branch eac-60-day-recurring

[yaelirub]

• app/.../ui/MainActivity.kt:717 — signing out still re-triggers the modal on the next foreground (see the existing thread on this block). The anchor is only written on show / restore / fresh install, so a user signed in since before this ships has a null anchor; sign out → background → return gives them "We noticed you're not logged in" immediately. Either anchor on sign-out or confirm iOS does the same.

I think it's good that it shows up in the next foreground after sign-out as most sign outs are accidental