Google Play Is Grading Your App Before Anyone Leaves a Review

My first Android app went live on Google Play today. Then I found out Play had been quietly grading it the whole time, and the stars are only part of the grade. Why I went digging I'm Bud, an indie dev at Noland Software LLC. I build Android apps with AI agents, and my first one, Power Leveling, went live on Google Play on October 22, 2026. Launch day felt like the finish line. It isn't. It's the start of a 28 day exam I didn't know I was taking. So I spent the afternoon reading Google's own docs instead of refreshing the Play Console. I don't have real numbers for my own app yet, so everything below comes straight from Google, not from my dashboard. Play watches stability, not just stars Android vitals is Google's system for tracking app quality on real devices, from users who opt in to share diagnostics. A few of its metrics are labeled core vitals, and Google says outright that core vitals affect your app's visibility on Google Play. The two that matter most for a new app are user perceived crash rate and user perceived ANR rate. "User perceived" means the crash or freeze probably happened while someone was actually looking at your app, like during a visible activity or a foreground service. For ANRs, only "input dispatching timed out" events count right now. The thresholds I'm memorizing Here are the bad behavior thresholds as of today: User perceived crash rate: 1.09% of daily users overall, or 8% on any single phone model. User perceived ANR rate: 0.47% of daily active users overall, or 8% on any single phone model. Watch models have their own stricter per device numbers: 4% for crashes and 5% for ANRs. The rate is per daily user, not per session. Google's own example: if someone opens your app three times in a day and crashes once, vitals counts that day as a 100% crash rate for that user, while Crashlytics would show 33%. Same bug, very different number. What happens if you cross the line Google says if you exceed a bad behavior threshold, Play may reduce your title's visibility and may show users a warning on your store listing. If you're bad on one device model, Play will steer users on that device toward other apps. Play generally looks at the last 28 days of data, but it may act sooner if there's a spike. Vitals flags emerging crash and ANR issues after 7 days, which Google frames as leaving you 21 days to fix them. Once your 28 day average improves, the vitals warnings go away, and store listing warnings may come off sooner. Battery and memory are on the list now too Excessive partial wake locks is now listed as a core vital: more than 5% of battery sessions with partial wake locks totaling over 3 hours in the background. The Play Console Help Center still calls it beta and says that, for now, crossing it won't make your app less discoverable. Memory usage and bitmap memory usage are also core vitals now, and Google says apps exceeding those thresholds may see store visibility impact starting February 2027. Better to fix it now while the app is small. Ratings: recent ones count more The rating people see on your Play listing is weighted toward recent ratings, so changes you ship actually show up in it. New ratings and reviews are usually held for about 24 hours while Play checks for suspicious activity. You can still read and reply to them during that window. For a new app, that cuts both ways. Early reviews aren't permanent, but a bad week right after launch shows up fast. The in app review API has rules Google's In App Review API lets users rate you without leaving the app. The rules surprised me: No pre questions. You can't ask "Do you like the app?" or "Would you rate us 5 stars?" before or while showing the card. That kills the classic "happy users go to the store, unhappy users go to a feedback form" funnel. There's a quota. Play limits how often a user sees the dialog. Calling launchReviewFlow more than once in a short period, like under a month, might not show anything. The exact quota isn't published and can change. No review button. Because of the quota, Google says not to wire the API to a button, since it might silently do nothing. If you want a "Rate us" button, send people to the Play Store page instead. Don't touch the card. No overlays, no resizing, and don't remove it programmatically. And Play's policy bans incentivized ratings outright. No discounts, rewards, or coins for reviews, and no forced or deceptive popups. Reply to reviews (like a human) You get one public reply per review, and you can edit it. The user gets a push notification and an email when you reply. The Play Console even has a report comparing rating changes from users who got replies with those who didn't. Google's rules: be relevant, be nice, don't solicit or promote, and don't ask for a higher rating. Staged rollouts are your undo button (almost) Staged rollouts ship an update to a percentage of users, and you raise it by hand. If something breaks, you can halt the rollout so nobody else gets that version. The catch: people who already got it stay on it, so the real fix is a new release. Also, staged rollouts only work for updates, not your very first publish, which is why the first release needs to be the most tested one. Free testing I almost ignored Pre launch reports run automatically when you upload an app bundle, depending on lab capacity. Google installs your app on test devices and crawls it for several minutes, checking stability, compatibility, performance, and accessibility. Results usually come back within an hour. If your app has a login, give the crawler a test account (not a real one). Then there's Firebase Crashlytics: real time crash reports, grouped into issues, with alerts when an issue starts spiking. It also catches non fatal exceptions you log yourself. Vitals is what Play judges you on. Crashlytics is how you find the bug. My checklist Read the Android vitals overview daily for the first 28 days. Turn on Play Console notifications for vitals anomalies. Add Crashlytics before the next build and upload mapping files so stack traces are readable. Check every pre launch report before promoting a build. Give the pre launch crawler a test account if the app has a sign in screen. Ship every update as a staged rollout and watch crashes and reviews before raising it. Halt the rollout the moment crash rate jumps, then ship a fixed build. Trigger the in app review flow only after a meaningful moment, with no pre question. Use a plain store link for any visible "Rate us" button. Reply to every review in the first weeks, honestly and without asking for stars. Audit wake locks and memory now, before they start affecting visibility. The counterpoint To be fair, none of this guarantees growth. Vitals only counts opted in users on certified devices who installed from Play, and Google only shows data once there's enough of it to keep it anonymous, so a brand new app may see nothing for a while. Clean vitals just keep you from being pushed down. They don't make anyone want your app. Pick a real problem and build a strong core loop first. And over engineering review timing for an app with ten users is probably procrastination. Still, a crash rate is a lot easier to fix while the app is small than after a bad week shows up in your rating. Your turn If you've shipped on Play, what was the first vitals issue that caught you off guard?

Originally posted on X: https://x.com/ArgileNoland/status/2113389279594594350