The Android Open Source project maintains a public issue tracker where you can report bugs and request features for the Android software stack. (For details on this issue tracker, please see the Reporting Bugs page.) Reporting bugs is great (thank you!), but what happens to a bug report once you file it? This page describes the Life of a Bug.
Please note: the the Android Open Source Project (AOSP) issue tracker is intended only for bugs & feature requests related to the Android software stack. Because many users find their way here looking for the Google apps for Android (such as Gmail and so on), we have components set up for their convenience. However, these apps are not part of Android, and any issues reported on these components are not guaranteed to to receive attention. Most notably, to report issues related to Android Market, you should visit the Android Market Support Forum.
Here's the Life of a Bug, in a nutshell:
Here is some additional information on each bucket, what it means, and how it's handled.
New issues include bug reports that are not yet being acted upon. The two states are:
The bug report has not yet been triaged (that is, reviewed by an AOSP contributor.)
The bug report has insufficient information to act upon. The person who reported the bug needs to provide additional detail before it can be triaged. If enough time passes and no new information is provided, the bug may be closed by default, as one of the No-Action states.
This bucket contains bugs that need action, but which are still unresolved, pending a change to the source code.
The bug report has been recognized as an adequately detailed report of a legitimate issue, but has not yet been assigned to an AOSP contributor to be fixed. Typically, bugs in this state are considered low priority, at least insofar that if they were high priority, they'd be assigned to a contributor.
Like Unassigned, but the issue
represented is being tracked in a separate bug database. For example, the bug
might have been reported via an internal bug-tracking system,
which is considered the "master" copy. (For instance, Google maintains one
such private issue tracker, intended primarily for bugs which contain
sensitive information which can't be revealed publicly.)
Like Unassigned, but the bug has been
actually assigned to a specific contributor to fix.
Typically, a given bug will start in Unassigned, where it
will remain until it is associated with a specific upcoming release, at which
point it will enter Reviewed or Assigned. However,
note that this isn't a guarantee, and it's not uncommon for bugs to go from
Unassigned to one of the Resolved states.
In general, if a bug is in one of these Open states, the AOSP team has recognized it as a legitimate issue and will fix it according to the product priorities and milestones. However, it's impossible to guarantee a fix in time for any particular release.
This bucket contains bugs that have for one reason or another been determined to not require any action.
A kind soul sent us some delicious pork products, that we, regrettably, do not want.
Someone mistook the issue tracker for a help forum. (This is not as uncommon as you might think: many users whose native language isn't English misunderstand the site and make this mistake.)
An AOSP contributor attempted to reproduce the behavior described, and was unable to do so. This sometimes means that the bug is legitimate but simply rare or difficult to reproduce, and sometimes means that the bug was fixed in a later release.
An AOSP contributor has determined that the behavior described isn't a bug, but is the intended behavior. This state is also commonly referred to as "WAI".
This is like WorkingAsIntended, except
typically used for feature requests instead of bugs. That is, an AOSP
contributor has determined that the request is not going to be implemented in
Android.
This bucket contains bugs that have had action taken, and are now considered resolved.
This bug has been fixed (or feature implemented) in a source tree, but has not yet been included in a formal Android platform release. (Note that this may also include fixes that exist in a private source tree that has not yet been contributed to a public tree.)
This bug has been fixed, and is included in a formal Android platform release. When this state is set, we try to also set a property indicating which release it was fixed in.
This bug is a duplicate of another, existing bug report.
The states and lifecycle above are how we generally try to track software. However, Android contains a lot of software and gets a correspondingly large number of bugs. As a result, sometimes bugs don't make it through all the states in a formal progression. We do try to keep the system up to date, but we tend to do so in periodic "bug sweeps" where we review the database and make updates.
Since the AOSP is essentially constantly evolving, we do make tweaks to the list of bug states and the lifecycle described above. When we do this, however, we'll be sure to update this page as well.
Finally, you should be aware that for a variety of reasons, there are actually multiple issue trackers for Android-related issues. The Google Code Project Hosting Issue Tracker is the only official public issue tracker; however, Google also maintains a private issue tracker, own, as do most OEMs. We try to keep the public issue tracker in sync with private issue trackers wherever possible, but in cases where confidential information and security issues are involved, this isn't always possible.