Google Play In-App Review API: Best Practices and Testing

Quick answer: The Google Play In-App Review API shows a native rating card inside your app. You request a ReviewInfo object with requestReviewFlow(), then show the card with launchReviewFlow(). Google applies an undisclosed, time-bound quota, so the card may not appear. Never trigger it from a button, never ask "Do you like the app?" first, and test through an internal test track.

The API is part of the Google Play Core libraries. When you launch the flow, Google Play draws a bottom card where people pick one to five stars and can add an optional comment. The review is sent to the Play Store and appears publicly after Google's usual processing; Play Console Help says new reviews are generally held back for around 24 hours.

Before you write any code, check the requirements Google currently lists:

Two behaviors shape everything else. First, the API never tells you whether the card was shown or whether the person left a review. Second, Google can decline to show the card because of its quota. Your code has to work the same way in every case.

The flow has two calls, and Google's guide recommends a specific order:

1. Add the com.google.android.play:review dependency from Google's Maven repository. Kotlin projects can add com.google.android.play:review-ktx for coroutine-friendly extensions.
2. Create a manager with ReviewManagerFactory.create(context).
3. When your app reaches a good moment (for example, the player finishes a level), call manager.requestReviewFlow(). If the task succeeds, keep the returned ReviewInfo. If it fails, read the error code from ReviewException and log it.
4. Call manager.launchReviewFlow(activity, reviewInfo) and wait for the task to complete before you continue, such as advancing to the next level.
5. In the completion listener, continue your normal flow no matter what happened. Google is explicit that an error during the review flow should not be shown to the user.

Cross-platform frameworks such as Flutter and React Native rely on plugins that wrap these same two calls, so the rules below apply to them too.

Google Play enforces a time-bound quota on how often one person can see the review card. Google's documentation says that calling launchReviewFlow more than once in a short period, giving "less than a month" as an example, might not display a dialog. It also says the exact quota is an implementation detail that can change without notice.

That has three practical consequences:

• No "Rate us" button wired to the API. If the person has hit the quota, tapping the button does nothing, which looks broken. For a permanent rating link in your settings, send people to your Play Store listing instead, for example with a market://details?id=your.package.name intent.
• Your own throttle comes first. Decide when someone qualifies (sessions, days since install, success events) and remember when you last asked. Treat the quota as a ceiling you should rarely reach.
• No retry loops. If nothing appeared, you have no way of knowing why, and calling again right away only burns quota.

Google publishes strict guidelines for this API, and Play policy backs them up. Here is the short version:

The last row comes from Google Play's User Ratings, Reviews, and Installs policy, which prohibits incentivized ratings and forced or deceptive rating pop-ups. Filtering people with a sentiment question before showing the card breaks the API guidelines even if you don't offer a reward.

Good moments look the same as on iOS: right after a completed workout, a finished project, a won level or a reached goal. Bad moments are app launch, onboarding, errors and paywalls.

You can't fully test the review card on an app that isn't on Google Play, but you don't need a production release either. Google documents three options:

Google notes that quota limits are not enforced when the app was downloaded from the internal test track. Once the tester account has installed the app from that track, you can deploy newer builds to the same device from Android Studio and keep testing.

If the card still doesn't show, work through Google's troubleshooting list:

• The applicationId isn't on any Play track yet. Upload it to internal testing.
• The app isn't in the account's Play library. Download it once from the Play Store with that account.
• Several accounts are on the device and the primary one isn't selected in the Play Store.
• The account is protected, such as an enterprise account. Use a regular Gmail account.
• The account already reviewed the app. Delete that review in the Play Store.
• The Play Store was sideloaded. Use a device with a valid Play Store and Google Play services.

If you ship on both platforms, you can share most of your timing logic, but not your assumptions:

The iOS in-app review prompt guide covers Apple's side in detail. Once reviews start arriving, reply to them: Play notifies the reviewer by push and email when you answer. Our guide on how to respond to app reviews includes templates, and how to get more app reviews covers the wider funnel. If you're still preparing your listing, start with the Google Play store listing guide.