You can help improve Android by reporting issues and requesting new features using the Google Issue Tracker. Google Issue Tracker is a tool used by Google to track AOSP issues and feature requests. The Issue Tracker is available outside of Google for use by external public and partner users who need to collaborate with Google teams on specific issues and features.
To learn the basics of the Google Issue Tracker, see the Google Issue Tracker.
Report a bug
To report an AOSP bug:
- With all open bugs as the basis for your search, use the Issue Tracker's search field to see if anyone has already reported your issue or feature. Don't forget to also search closed and fixed bugs. To help you find the most popular results, sort the result by number of stars. For details on using the search field, refer to Issue Searches
- If you find your issue and it's important to you, star it! The number of stars on an issue helps Google to determine its priority.
If no one has reported your issue, create a new bug.
Refer to the section of this document that relates to the component for your bug. Bug components identify the area of Android for which the bug applies.
Fill out the provided template:
- If the issue is a bug, include the steps to reproduce the bug in the comments. A comment that simply states something isn't working is likely to require further information. The amount of detail that you provide, including log files and even a patch set, helps us address your issue.
- If the issue is a feature request, provide explicit details on the proposed feature, including the problem solved and design considerations.
If you're a device manufacturer and have the build fingerprint from the affected device, include that string in the bug.
Click Create. The bug report is created for Google to review.
To learn how to track the bug's status, refer to Track bug status.
The following four sections are designed to help you search for and report bugs using the correct component.
If you find an issue that impacts the security of Android or components in Pixel devices, file a bug using the instructions in Reporting security issues. Additionally, security bugs are eligible for the Android and Google Devices Reward Program.
If you have an issue or feature request that impacts an aspect of the Android platform, file your bug by clicking the bug icon next to the relevant component area:
Android developer tools
If you have an issue or feature request that impacts an aspect of the Android developer tools file your bug by clicking the bug icon next to the relevant component area in the following table.
|File a bug
|Information specific for Android Studio bugs
|Issues in Android Studio
|Emulator or System Images
|Information specific for Emulator bugs
|Information specific for Gradle bugs
|Information specific for Apply Changes bugs
|NDK compiler or build system issues. Not for API requests or bugs. APIs are part of the OS, and requests related to them should be filed in one of the Platform components above (if you don't know which, use Framework).
|Jetpack (androidx) Test
If you have an issue or feature request that impacts an aspect of the Android documentation, file your bug by clicking the bug icon next to the relevant component area:
|File a bug
developer.android.com (app developer documentation)
source.android.com (AOSP documentation)
Track bug status
Newly created bugs are always marked with a status of New. AOSP maintainers periodically review and triage bugs by changing their status and potentially assigning them to someone. Bugs are triaged into one of three categories:
Needs more information. The bug report doesn't have enough information for someone to prioritize or properly analyze the bug. The bug report is put on a list (New + Hotlist:NeedsInfo) until you provide the requested information. After some period of time, if no additional information is provided, the bug is given a status indicating that it won't be acted upon.
The bug is Assigned to someone and, optionally, reprioritized. The bug report has been recognized as an adequately-detailed report of a legitimate issue. The bug's is properly prioritized or is reprioritized. Finally, the bug is assigned assigned to a specific contributor to assess and analyze.
Typically, a bug remains as Assigned until someone intends to resolve the bug, at which point it is assigned an Accepted status. However, an assignee might not change a bug's status to Accepted and, instead, just fix the bug and assign a Fixed or Fixed (verified) status.
The bug won't be acted upon. A bug falls into this category for several reasons, such as the bug is a duplicate of another bug, the bug is infeasible to fix, or the bug represents functionality that is working as intended.
To track bug status:
- Open the bug and look at the priority, status, and comments fields. For explanations of priority and status, refer to the Issue fields.
- (optional) respond to any questions or comments in the comments field.
Bugs marked with a Fixed (verified) status are included in a future release of Android.
Additional information for specific statuses
Following is further explanation for a few bug statuses (in addition to the information provided in the Issue Tracker Issue fields documentation):
Won't fix (Intended behavior): An AOSP maintainer has determined that the behavior described isn't a bug, but is the intended behavior. This status is also commonly referred to as "working as intended (WAI)." For feature requests, an AOSP maintainer has determined that the request isn't going to be implemented in Android.
Won't fix (Infeasible): The changes that are needed to address the issue aren't reasonably possible. This status is also used for issues reported that can't be handled in AOSP, typically because it's related to a customized device or to an external app, or the reporter mistook the Issue Tracker as a help forum.
Fixed (Verified): This bug has been fixed, and is included in a formal release. When this status is set, we try to also set a property indicating the release containing the bug fix.
Fixed: This bug has been fixed (or feature implemented) in a source tree, but might not yet been included in a formal release.