Life of a Bug

In this document

The Android Open Source Project maintains a public issue tracker where you can report bugs and request features for the core 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 Android Open Source Project (AOSP) issue tracker is intended only for bugs and feature requests related to the core Android software stack, and is a technical tool for the Open Source community.

This is not a customer support forum. You can find support for Nexus devices on Google's Nexus support site. Support for other devices is provided by the device manufacturers or by the carriers selling those devices.

Support for Google applications is through Google's support site. Support for 3rd-party applications is with each application's developer, e.g. through the contact information provided on Google Play.

Here's the life of a bug, in a nutshell:

  1. A bug is filed, and has the state "New".

  2. An AOSP maintainer periodically reviews and triages bugs. Bugs are triaged into one of four "buckets": New, Open, No-Action, or Resolved.

  3. Each bucket includes a number of states that provide more detail on the fate of the issue.

  4. Bugs in the "Resolved" bucket will eventually be included in a future release of the Android software.

Bucket Details

Here is some additional information on each bucket, what it means, and how it's handled.

New Issues

New issues include bug reports that are not yet being acted upon. The two states are:

  • New: The bug report has not yet been triaged (that is, reviewed by an AOSP maintainer.)

  • NeedsInfo: 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.

Open Issues

This bucket contains bugs that need action, but which are still unresolved, pending a change to the source code.

  • Unassigned: 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.

  • Assigned: 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 someone intends to resolve it, at which point it will enter 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 a high-quality contribution fixing that bug is likely to get accepted. However, it's impossible to guarantee a fix in time for any particular release.

No-Action Issues

This bucket contains bugs that have for one reason or another been determined to not require any action.

  • Spam: A kind soul sent us some delicious pork products, that we, regrettably, do not want.

  • Duplicate: There was already an identical report in the issue tracker. Any actual action will be reported on that report.

  • Unreproducible: 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.

  • Obsolete: Similar to Unreproducible, but with a reasonable certainty that the bug did exist in the reported version but was already fixed in a later release.

  • WorkingAsIntended: An AOSP maintainer has determined that the behavior described isn't a bug, but is the intended behavior. This state is also commonly referred to as "WAI".

  • Declined: This is like WorkingAsIntended, except typically used for feature requests instead of bugs. That is, an AOSP maintainer has determined that the request is not going to be implemented in Android.

  • NotEnoughInformation: The report didn't have enough information to be able to take any action.

  • UserError: The report was the result of a user making a mistake while using Android, e.g. typing a wrong password and therefore not being able to connect to a server.

  • WrongForum: The report cannot be handled in AOSP, typically because it is related to a customized device or to an external application.

  • Question: Someone mistook the issue tracker for a help forum.

Resolved Issues

This bucket contains bugs that have had action taken, and are now considered resolved.

  • Released: This bug has been fixed, and is included in a formal release. When this state is set, we try to also set a property indicating which release it was fixed in.

  • FutureRelease: This bug has been fixed (or feature implemented) in a source tree, but has not yet been included in a formal release.

Other Stuff

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.