Sentry and Google Play Data safety: review crash and performance data

Why Sentry needs an implementation review

Sentry is an error-monitoring service, not a fixed data package. A minimal crash-reporting setup can send stack traces and diagnostic context. A broader setup can add performance transactions, breadcrumbs, user identifiers, custom tags, request data, or session replay. The name of the dependency cannot tell you which of those are active in your release build.

Google Play's Data safety section asks about your app's collection and sharing behavior. Review what the Android SDK captures, what your app adds, what your server forwards, and what your team can see in Sentry. Start with the release configuration and the initialization code, then test a representative crash and performance event without using real personal information.

Declora organizes the review in an App Passport with App Facts. The Sentry Service Profile suggests crash logs as likely and performance data as possible. These are catalog suggestions with reasons and evidence. You confirm them against your production configuration; Declora does not turn a likely fact into a declaration on your behalf.

Crash logs are only the first layer

Crash reporting often includes a stack trace, operating-system details, app version, device context, and timestamps. Review the Sentry event payload and the SDK options that control what is attached. If you set a user ID, email, username, or custom context, the event may carry information beyond the diagnostic signal itself.

Inspect your error boundaries, exception handlers, logging calls, and beforeSend or equivalent hooks. Search for values placed into breadcrumbs, tags, extra data, request headers, or custom messages. User-entered text can enter a report through an exception message, a navigation breadcrumb, or a debug log even when you never intended to send it.

The App Facts for crash logs and optional user context should be confirmed separately. A crash-reporting integration does not prove that your app attaches a signed-in user's identity. Conversely, turning off a visible user field does not prove that custom logs contain no personal information. Test the payload you actually send.

Performance monitoring and replay are different choices

Performance monitoring can capture transactions, spans, navigation timing, network activity, or other diagnostic signals. The catalog treats performance data as possible because teams enable it differently. Confirm the sample rate, environment filters, integrations, and release configuration rather than relying on a default from an SDK guide.

Session Replay requires a further review. If you enable it, check which screens and interactions can be captured, how text and media are masked, and whether replay is active in production. A replay feature can change the data story even when your original Sentry setup was limited to crash reports. Verify the payload and the privacy controls that apply to your app.

Do not use the existence of a beforeSend hook as proof that all sensitive values are removed. Confirm the filtering logic with test events, including a form containing dummy values, a navigation action, and a failed network request. Keep the test data synthetic and document the result for the developer who confirms the App Fact.

Collection and sharing are separate decisions

Google Play's form distinguishes data collected by your app from data shared with another company. Sentry is a service provider that receives events from your app or backend, but your answer still depends on what those events contain and how your app's data flow is configured. A crash log with no user context is not the same as a crash log enriched with account data or user-entered content.

Review the dimensions one at a time:

• What diagnostic fields leave the device?
• Which fields are generated by Sentry, and which are added by your app?
• Does an event include an account ID, email, name, or custom user text?
• Is performance monitoring or replay enabled for production?
• Can users avoid providing a value that your app later places in an event?
• What deletion process applies to events connected to a user request?

If you cannot answer a question from code, inspect a production-like build and the Sentry project settings. Keep an unresolved App Fact awaiting confirmation instead of filling the gap with a general statement about Sentry.

A reliable Sentry review sequence

1. Record the SDK version and the initialization options used by the published Android build.
2. Inspect user context, breadcrumbs, tags, extras, logs, and network integrations.
3. Confirm whether performance monitoring and Session Replay are enabled in production.
4. Trigger controlled test events and inspect the resulting payloads in Sentry.
5. Check redaction hooks and masking rules with synthetic personal-data examples.
6. Compare the confirmed App Facts with your Google Play form and privacy wording.
7. Run a Consistency Check before publishing or changing the release configuration.

Use Safe Mode when you want to review uncertain facts without immediately changing your store-facing output. A reviewer can ask the right owner to verify a flag, integration, or payload. Once confirmed, keep the decision tied to the release configuration that it describes.

Public Pages and responsible review

Public Pages can make your product's privacy explanation easier for your team to inspect and share. They do not replace a payload review, a Google Play declaration, or the internal decision about whether a diagnostic event contains user data. Keep the public explanation aligned with the confirmed behavior, especially when you enable replay or add user context.

Declora is not a law firm and cannot guarantee store approval. Its App Passport, App Facts, Safe Mode, Public Pages, and Consistency Check help you structure evidence and find mismatches; you remain responsible for confirming production behavior and completing Google Play's form.

FAQ

Does using Sentry automatically mean I collect personal information?

No. Sentry's data depends on the SDK configuration and the values your app attaches to events. Crash logs may be likely, while user context, performance data, replay, and custom text require an implementation review. Confirm each App Fact separately.

Does turning off Session Replay remove every Sentry privacy question?

No. Crash logs, breadcrumbs, tags, network context, user identifiers, and custom keys can still carry data. Review the event payload and initialization code for the release build. Replay is one configuration choice, not the whole Sentry data flow.

What should I do if I cannot tell whether a breadcrumb includes user text?

Treat the App Fact as awaiting confirmation, then create a controlled test with synthetic values and inspect the event in Sentry. Review the code that records the breadcrumb and any redaction hook. Do not claim that the field is absent until the production-like path has been checked.

Can Declora guarantee that my Google Play submission will be approved?

No. Declora is not a law firm and cannot guarantee store approval. It can organize App Facts, show catalog-derived guidance, and run a Consistency Check, while you confirm the implementation and submit the final form.