Plan an Android in-app review request

Use relevant timing without an opinion gate

Choose a moment after meaningful use, outside a purchase or unfinished task. Google’s guidance says not to ask questions about the user’s opinion before presenting the review card. Avoid custom star screens that route only favorable answers to the store. Keep a normal support route accessible to everybody and attach no discount, currency or premium unlock to a public review.

Respect provider-controlled display behavior

Google applies a quota whose exact value is an implementation detail that can change. Do not use repeated calls to force display or build a button that assumes the automatic card always appears. Check errors and lifecycle behavior, but keep the rest of the journey intact. A completed API task is not proof that a review was shown, much less that a positive review was submitted.

Test the integration in supported environments

Use the current internal-track and fake-review-manager testing guidance. Confirm package identity, account eligibility and the distribution route where relevant. A fake manager is useful for code-path testing but does not reproduce the real store UI. Record which environment produced each result so a local fixture does not become a claim that production review submission has been observed.

Your next steps

• Choose task-based timing without a sentiment filter.
• Treat display quota as provider-controlled.
• Keep no-card behavior usable.
• Separate fixture proof from actual store behavior.