Ask for a review at two earned moments instead of on every load

[andiwand]

Follow-up to #559. That PR restored the review request in lite; this one fixes when it fires.

The problem

onLoadSuccess is reached by more than "the user opened a document":

trigger	user state
fresh open — MainActivity.loadUri (intent, picker, recent list)	just opened ✅
onStart() replay — result arrived while stopped	returning ✅
entering edit mode — EditActionModeCallback:35 → reloadUri(true)	mid-task ❌
leaving edit mode — EditActionModeCallback:59 → reloadUri(false)	mid-task ❌
after a save — onSaveSuccess → loadUri(...)	success, worth asking ✅
webview hands back a file — PageView.sendFile → loadUri(...)	mid-read ❌

Toggling edit mode twice asked twice, while the user was working.

The change

loadUri takes a freshOpen flag, reloadUri clears it, and onLoadSuccess only asks when the load was one the user asked for. PageView.sendFile passes freshOpen = false.

Saving still counts, because onSaveSuccess reloads through loadUri — that's a success the user just caused. So "keep it on save, drop it on enter/exit" falls out of one condition rather than three special cases.

The landing screen becomes the second moment, for people who open the app and browse rather than arriving with a document from another app.

The threshold

Both moments are counted in the new UsageCounters, and neither asks until the third open. A fresh install has nothing to say yet, and asking anyway costs stars — one of the 1★ reviews in the console is literally "not used it but asking for a review".

A counter rather than the length of the recently opened list: that list is capped, pruned and user-deletable, so it undercounts exactly the returning users this is meant to find, and it counts distinct documents rather than visits. MINIMUM_OPENS is one constant if 3 turns out to be the wrong number.

requestInAppRating moves out of DocumentFragment into nonfree/InAppReview so both call sites share it — also where the Play dependency belongs.

Notes

• The two counters are independent, so someone who only ever opens documents from other apps still earns the ask on the document side.
• No behaviour change for pro beyond the timing: it was already asking.
• in_app_review_eligible / _error / _start / _done now report from lite too, which is the visibility that would have caught the v4.2 regression.

Verification

spotlessCheck, assembleLiteDebug, assembleProDebug, lintProDebug and testProDebugUnitTest pass locally. The flow itself can't be exercised off a Play install — requestReviewFlow() fails into the existing in_app_review_error branch — so this is reviewed by reading, not by running.

🤖 Generated with Claude Code

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: b20dfa764c

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".