Google Play Testing Feedback: Where Tester Reports Land
An Android beta produces three kinds of signal: what testers tell you, what Google's test devices find, and what real devices report about crashes. Google Play handles all three, in different parts of Play Console. This guide covers where each one lands, what it can and can't tell you, and how to work through it without letting it pile up. Google's details below are from its own pages as of 8 September 2026.
The short version
- Closed and open testers send private feedback from the Play Store: a star rating and some text.
- It lands in Play Console under Ratings and reviews > Testing feedback, where you can filter, search and reply. It doesn't affect your public rating.
- The pre-launch report adds crashes, ANRs and accessibility findings from Google's test devices.
- Android vitals shows crash and ANR rates from real devices whose owners share usage data.
- Google documents no way for a tester to attach a screenshot, so give testers a channel of your own as well.
How testers send feedback
Google's help page for Play Store users, Try new Android apps before their official release, describes the tester's side as of 8 September 2026. A tester opens the Play Store, taps their profile icon, goes to Manage apps & devices and then Beta, opens your app, and taps Write feedback under "Private feedback to developer". They tap the stars to rate the app and type into a text box. Both are required before they can post. Google tells testers that their feedback on beta and early access apps is visible to the developer and nobody else.
That private feedback is for testers on your closed and open tracks. Google's page Set up an open, closed, or internal test adds two points. Testers can't leave public reviews for test versions, and feedback from test users won't affect your app's public rating. It also suggests a direct channel, such as an email address, a website or a forum. You give each track a feedback URL or email address in Play Console, and it shows on the tester opt-in page. Our guide to Google Play testing tracks covers that setup.
Where it lands in Play Console
As of 8 September 2026, Google's help page View and analyze your app's ratings and reviews puts tester feedback on its own page: Ratings and reviews > Testing feedback. Public reviews of your production app sit next to it under Ratings and reviews > Reviews. On the Testing feedback page you can:
- filter by date, language, reply state, app version, device and more;
- search the text for specific words;
- reply to the tester from Play Console.
Google says this beta feedback is visible to you and can't be seen on Google Play. You can also ask for an email when new testing feedback arrives, in your Play Console notification preferences. During an active beta, turn that on, so nobody has to remember to look.
What Play doesn't give you
If you come from TestFlight, a few things are missing. We checked Google's tester instructions and the Play Console Help pages above, as of 8 September 2026:
- No screenshots. TestFlight lets a tester take a screenshot inside your beta, mark it up and send it. Google's instructions describe a star rating and a text box, and say nothing about attaching a screenshot or any other file. We found no Play Console page describing screenshot feedback from testers.
- Written in the Play Store, not in your beta. Google's instructions send testers to your app's page in the Play Store. The one in-app route is the In-App Review API: Google's In-App Reviews page says that when an app is on a closed test track, the rating and review it collects are shared privately with you. That is still a rating, not a bug report.
- A rating on every report. A tester who wants to report one bug still has to pick a number of stars, which says little about a single build.
- No comment on a crash. Crash data reaches you through the pre-launch report and Android vitals, separately from anything a tester writes.
None of that makes Play's feedback useless. It does mean that for a bug you need to see, you should ask testers to email a screenshot to the address on your opt-in page, or give them a way to send one from inside the app.
The pre-launch report: crashes and accessibility
The pre-launch report is feedback from Google's own test devices rather than from people. Play runs it when you upload an app bundle, capacity permitting, by installing your app on devices in its test lab and crawling it. Google's page Understand your pre-launch report describes the results as of 8 September 2026:
- The overview, at Test and release > Testing > Pre-launch report > Overview, groups errors, warnings and minor issues under Stability, Performance and Accessibility.
- Errors include crashes, ANRs, use of defective libraries and use of unsupported APIs that have been restricted.
- The Stability tab gives the stack trace, how many devices showed the issue, and each device's details, with a screenshot and video from the test.
- Crashes found by the report come from test devices, so they don't affect your crash statistics.
- Accessibility findings fall into four groups: content labelling for screen readers, touch target size, implementation (layout issues that make the app hard to use for people with motor impairments), and low contrast.
Note the screenshots here are from Google's crawler, not from a tester. They show where the crawler was when something broke, which is often enough to reproduce it. The accessibility findings are worth a look on every upload, because nobody on a small team checks touch targets by hand on every screen.
Android vitals: what real devices report
Android vitals is the third source. As of 8 September 2026, Google's page on Android vitals explains that when a user allows it, their device tracks app quality data such as stability, performance and battery use, and Google Play collects it. You see it on the Android vitals dashboard in Play Console, or through the Google Play Developer Reporting API.
The core vitals include the user-perceived crash rate and the user-perceived ANR rate, and both have bad behaviour thresholds that Google publishes:
| Core vital | Overall, across devices | Per phone model |
|---|---|---|
| User-perceived crash rate | 1.09% | 8% |
| User-perceived ANR rate | 0.47% | 8% |
Google says that if your app exceeds a bad behaviour threshold, Play may reduce its visibility and may show users a warning on your store listing. Play assesses quality over the last 28 days. So a beta is the cheap place to catch a crash: once it reaches production, it counts.
A routine for working through it
- Look daily during an active beta. Testing feedback, then the latest pre-launch report, then vitals.
- Sort each item into crash, bug, confusion or idea. Confusion is a design problem, not a tester problem.
- Reproduce on the version named in the feedback. The app version filter makes it easy to see whether one build is to blame.
- Reply. A short note saying a fix is in the next build keeps people testing.
- Move ideas somewhere they will survive. More on this below.
How FeedbackKit fits in
Testing feedback is a one-way inbox of notes, one per tester, tied to a build. That suits bugs. It suits feature ideas badly: thirty testers can ask for offline maps in thirty separate notes, nothing adds them up, and no tester can see that someone already asked. Your production users, who are most of your users, never see the Testing feedback page at all.
FeedbackKit gives feature requests a board inside your app. Users post a request once and everyone else votes and comments on it. A new request starts with its submitter's vote. Each request carries one of six statuses, Pending, Approved, In Progress, TestFlight, Completed or Rejected, so people can see what happened to their idea. The beta status is called TestFlight, after Apple's service, and Android users see that same label; many teams use it to mean "in testing", whichever store's beta it is. When the status changes, the person who submitted the request is emailed if the new status is in the project's list, as explained in our guide to closing the loop.
On Android the board comes from the Jetpack Compose screens in the Kotlin SDK, and there are SDKs for Flutter and React Native too. Your team gets push notifications for new requests and comments in the FeedbackKit app. Here is how a request board looks in FeedbackKit, with sample data from a fictional hiking app:
Requests people can vote on
Public reviews are the other place feature requests turn up; our guide to replying to Google Play reviews covers those. If you also ship on iOS, see TestFlight feedback. Plans are on the pricing page, and you can start free.