Use issue notes to help app developers

You can add notes to any crashes or ANRs listed on the Crashes and ANRs page in SDK Console in order to help app developers understand what caused the issue or how it can be prevented.

By clearly communicating through these notes, you can help app developers understand the nature of a crash or ANR. This includes clarifying if the issue is with the SDK, an integration problem, or an external factor. This can help you build stronger developer relations, reduce confusion, potentially decrease direct support inquiries, and empower app developers to take appropriate actions—such as updating the SDK, correcting their integration, or understanding known limitations.

We recommend you include as much information as possible, for example, the cause of the crash or ANR, how to resolve it, or how it can be prevented. You can also add links to the SDK's documentation, issue trackers, or other guidance. The message will be shown to all app developers affected by this issue so it should not address an individual developer or include salutations.

When you add a note, it's displayed in Google Play Console on the Crashes and ANRs page of each app the crash or ANR affects.

Note: Developer Notes can’t be deleted but are editable, so you'll be able to adjust the information you provide.

To add a note to a crash or an ANR, do the following:

1. Open SDK Console and select SDKs on the left menu.
2. Click on the SDK that you want to view crash or ANR information for.
3. On the left menu, select Crashes and ANRs.
4. Scroll down to the Issues table.
5. Click the right arrow () next to the issue listing if you want to add a note to.
6. On the top right of the Crash details or ANR details page, click Add note for app developers. This opens a screen in which you can choose a crash status and add or edit your note, as shown in the screenshot below.
7. Next to Crash status or ANR status, choose a category.
8. Enter your note in the text box.
   • Write a clear, concise, and actionable note (see examples below). You can use up to 500 characters.
   • Note: You can add links to the SDK’s documentation, issue trackers, or any other external destination where you provide crash-related guidance to developers.
   • Recommended: Have someone on your team review the content of the note before you proceed.
9. When you're finished, click Add note. After you add a note, it can't be deleted. You can, however, edit them by going back to the Crash details page for the crash or ANR details page for the ANR, and clicking Edit note.
10. Once submitted, the note will be in a Pending state. It may take a few days for the new note to go live and for developers to start seeing it in Play Console.

What happens after a note is updated in the SDK Console

• Once the developer note is submitted through the SDK Console interface, it enters a review queue.
• The note will be reviewed by the Play Developer Team. 
• After the review and approval by the Play Developer Team, the developer note will be published.
• Upon publication, the note becomes visible within the Google Play Console to the app developers whose applications are affected by that specific crash or ANR cluster and are using your SDK.

Developer note categories and example notes

Below are the categories and example notes to guide your communication:

 

Crash Category	Description	Overall Status	Example Notes
Fixed in Newer Version	A fix for this crash is included in a newer version of your SDK.	Fixed	Please update to com.mysdk.android.foo:foo-android:6.9.5 or higher. You can find the release notes for the fix at [LINK].
Caused by Wrong Integration	Caused by the incorrect use of an SDK API, method, or parameter by the app.	Won’t fix	This crash is caused by incorrect integration of the mysdk SDK's [feature]. Specifically, it appears that the method is not being called when the associated activity or fragment is destroyed, leading to a memory leak and subsequent crash. Recommendation: Please review your implementation to ensure [feature] is called in the onPause() or onDestroy() lifecycle methods of your activity or fragment to properly de-register the listener. For detailed guidance on integrating the mysdk, please refer to our documentation: [link]
Known Issue (Won't Fix)	A crash that is happening (e.g., on an unsupported device/OS) or a known SDK issue the SDK provider doesn't intend to fix.	Won’t fix	This crash has been identified as occurring primarily on devices running Android versions below X.Y, which are no longer actively supported by our SDK. Status: While we acknowledge the issue, we will not be providing a specific fix for these older OS versions. Our development efforts are focused on supporting Android X.Y and above. We recommend targeting newer Android versions for optimal SDK performance and stability.
Not Caused by SDK	You believe your SDK code is not responsible for this crash; the issue lies within the client application or caused by a different SDK.	Won’t fix	This crash is likely due to an issue within your application. Please review your code and consider debugging with the help of relevant tools.
Other	Caused by any other issue not listed here. Use sparingly.		com.mysdk.android.gms:mysdk:18.6.0 and higher include opt-in APIs that may help prevent this ANR. See details here [link]

Update overall status

Update the SDK Console error cluster "status" and add "developer notes" to reflect the status information for app developers.

• Navigate to the Crash details page.
• Locate the Marked as dropdown menu. Click on it to reveal status options.
• Select the most appropriate overall status based on the following criteria:

Status	Description / When to Use
Open	Investigation is ongoing, or no definitive resolution/determination has been made yet. This is typically the default status for new issues.
Fixed	The root cause has been addressed. For example, the problem was in your SDK code, and a fix is released in a specific SDK version (e.g., 17.0.1).
Won't fix	The SDK team will not be addressing this issue directly. This status covers several scenarios: General (App-side/External): The crash is due to factors outside the SDK team's control (e.g., app code error in a callback, API misuse by the app developer, unresolvable external dependency issue).  Known SDK Issue (No Fix Planned): An acknowledged issue within the SDK, but a fix is not planned (e.g., low impact, high complexity, affects unsupported platforms). Obsolete: The issue is no longer relevant (e.g., due to feature deprecation, significant architectural changes).