en/source/life-of-a-bug.html - platform/docs/source.android.com - Git at Google

 <html devsite>
   <head>
     <title>Life of a Bug</title>
     <meta name="project_path" value="/_project.yaml" />
     <meta name="book_path" value="/_book.yaml" />
   </head>
   <body>
   <!--
       Copyright 2017 The Android Open Source Project

       Licensed under the Apache License, Version 2.0 (the "License");
       you may not use this file except in compliance with the License.
       You may obtain a copy of the License at

           http://www.apache.org/licenses/LICENSE-2.0

       Unless required by applicable law or agreed to in writing, software
       distributed under the License is distributed on an "AS IS" BASIS,
       WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
       See the License for the specific language governing permissions and
       limitations under the License.
   -->


 <p>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
 <a href="report-bugs.html">Reporting Bugs</a> 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.</p>

 <p class="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.</p>

 <p>This is not a customer support forum. For support information, see the
 <a href="https://support.google.com/nexus">Nexus</a> and
 <a href="https://support.google.com/pixelphone">Pixel</a> help centers.
 Support for other devices is provided by the device manufacturers or by the
 carriers selling those devices.</p>

 <p>Support for Google applications is through
 <a href="http://support.google.com/">Google's support site</a>. Support
 for third-party applications is with each application's developer, e.g.
 through the contact information provided on Google Play.</p>

 <p>Here's the life of a bug, in a nutshell:</p>
 <ol>
 <li>A bug is filed, and has the state "New".</li>
 <li>An AOSP maintainer periodically reviews and triages bugs. Bugs are
 triaged into one of four <em>buckets</em>: New, Open, No-Action, or Resolved.</li>
 <li>Each bucket includes a number of states that provide more detail on the
 fate of the issue.</li>
 <li>Bugs marked as "Resolved" will eventually be included in a future
 release of the Android software.</li>
 </ol>
 </ul>

 <h2 id="bucket-details">Bucket details</h2>
 <p>
 We use the <strong>Status</strong> field in Issue Tracker to specify the status
 of an issue in the resolution process. This is consistent with the definitions
 specified in the <a
     href="https://developers.google.com/issue-tracker/concepts/issues#status">Issue
     Tracker documentation</a>.
 </p>
 <h3 id="new-issues">New issues</h3>
 <p>
 New issues include bug reports that are not yet being acted upon. The two states
 are:
 </p>
 <ul>
  <li><strong>New:</strong> The bug report has not yet been triaged (that is,
  reviewed by an AOSP maintainer.)</li>
  <li><strong>New + Hotlist:NeedsInfo:</strong> 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.</li>
 </ul>
 <h3 id="open-issues">Open issues</h3>
 <p>
 This bucket contains bugs that need action, but which are still unresolved,
 pending a change to the source code.
 </p>
 <ul>
  <li><strong>Assigned:</strong> The bug report has been recognized as an
  adequately detailed report of a legitimate issue and the bug has been assigned
  to a specific contributor to assess and analyze.</li>
  <li><strong>Accepted:</strong> The assignee has acknowledged the issue and has
  started to work on it.</li>
 </ul>
 <p>
 Typically, a bug starts in <strong>Assigned</strong>, and remains there until
 someone intends to resolve it, at which point it enters
 <strong>Accepted</strong>. However, note that this isn't a guarantee, and it's
 not uncommon for bugs to go from <strong>Assigned</strong> to one of the
 Resolved states.
 </p>
 <p>
 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.
 </p>
 <h3 id="no-action-issues">No-Action issues</h3>
 <p>
 This bucket contains bugs that are deemed to not require any action.
 </p>
 <ul>
  <li><strong>Won't Fix (Not reproducible):</strong> 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, or
  there was not enough information to fix the issue.</li>
  <li><strong>Won't Fix (Intended behavior):</strong> 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 <em>working as
  intended</em> (WAI). For feature requests, an AOSP maintainer has determined
  that the request is not going to be implemented in Android.</li>
  <li><strong>Won't Fix (Obsolete):</strong> The issue is no longer relevant due
  to changes in the product.</li>
  <li><strong>Won't Fix (Infeasible):</strong> The changes that are needed to
  address the issue are not reasonably possible. This status is also used for
  issues reported that cannot be handled in AOSP, typically because it is related
  to a customized device or to an external application, or the reporter mistook
  this tracker as a help forum.</li>
  <li><strong>Duplicate:</strong> There was already an identical report in the
  issue tracker. Any actual action will be reported on that report.</li>
 </ul>
 <h3 id="resolved-issues">Resolved issues</h3>
 <p>
 This bucket contains bugs that have had action taken, and are now considered
 resolved.
 </p>
 <ul>
  <li><strong>Fixed (verified):</strong> 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.</li>
  <li><strong>Fixed:</strong> This bug has been fixed (or feature implemented) in
  a source tree, but might not yet been included in a formal release.</li>
 </ul>
 <h2 id="other-stuff">Other stuff</h2>
 <p>
 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.</p>
   </body>
 </html>
	<html devsite>
	<head>
	<title>Life of a Bug</title>
	<meta name="project_path" value="/_project.yaml" />
	<meta name="book_path" value="/_book.yaml" />
	</head>
	<body>
	<!--
	Copyright 2017 The Android Open Source Project

	Licensed under the Apache License, Version 2.0 (the "License");
	you may not use this file except in compliance with the License.
	You may obtain a copy of the License at

	http://www.apache.org/licenses/LICENSE-2.0

	Unless required by applicable law or agreed to in writing, software
	distributed under the License is distributed on an "AS IS" BASIS,
	WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
	See the License for the specific language governing permissions and
	limitations under the License.
	-->


	<p>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
	<a href="report-bugs.html">Reporting Bugs</a> 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.</p>

	<p class="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.</p>

	<p>This is not a customer support forum. For support information, see the
	<a href="https://support.google.com/nexus">Nexus</a> and
	<a href="https://support.google.com/pixelphone">Pixel</a> help centers.
	Support for other devices is provided by the device manufacturers or by the
	carriers selling those devices.</p>

	<p>Support for Google applications is through
	<a href="http://support.google.com/">Google's support site</a>. Support
	for third-party applications is with each application's developer, e.g.
	through the contact information provided on Google Play.</p>

	<p>Here's the life of a bug, in a nutshell:</p>
	<ol>
	<li>A bug is filed, and has the state "New".</li>
	<li>An AOSP maintainer periodically reviews and triages bugs. Bugs are
	triaged into one of four <em>buckets</em>: New, Open, No-Action, or Resolved.</li>
	<li>Each bucket includes a number of states that provide more detail on the
	fate of the issue.</li>
	<li>Bugs marked as "Resolved" will eventually be included in a future
	release of the Android software.</li>
	</ol>
	</ul>

	<h2 id="bucket-details">Bucket details</h2>
	<p>
	We use the <strong>Status</strong> field in Issue Tracker to specify the status
	of an issue in the resolution process. This is consistent with the definitions
	specified in the <a
	href="https://developers.google.com/issue-tracker/concepts/issues#status">Issue
	Tracker documentation</a>.
	</p>
	<h3 id="new-issues">New issues</h3>
	<p>
	New issues include bug reports that are not yet being acted upon. The two states
	are:
	</p>
	<ul>
	<li><strong>New:</strong> The bug report has not yet been triaged (that is,
	reviewed by an AOSP maintainer.)</li>
	<li><strong>New + Hotlist:NeedsInfo:</strong> 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.</li>
	</ul>
	<h3 id="open-issues">Open issues</h3>
	<p>
	This bucket contains bugs that need action, but which are still unresolved,
	pending a change to the source code.
	</p>
	<ul>
	<li><strong>Assigned:</strong> The bug report has been recognized as an
	adequately detailed report of a legitimate issue and the bug has been assigned
	to a specific contributor to assess and analyze.</li>
	<li><strong>Accepted:</strong> The assignee has acknowledged the issue and has
	started to work on it.</li>
	</ul>
	<p>
	Typically, a bug starts in <strong>Assigned</strong>, and remains there until
	someone intends to resolve it, at which point it enters
	<strong>Accepted</strong>. However, note that this isn't a guarantee, and it's
	not uncommon for bugs to go from <strong>Assigned</strong> to one of the
	Resolved states.
	</p>
	<p>
	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.
	</p>
	<h3 id="no-action-issues">No-Action issues</h3>
	<p>
	This bucket contains bugs that are deemed to not require any action.
	</p>
	<ul>
	<li><strong>Won't Fix (Not reproducible):</strong> 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, or
	there was not enough information to fix the issue.</li>
	<li><strong>Won't Fix (Intended behavior):</strong> 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 <em>working as
	intended</em> (WAI). For feature requests, an AOSP maintainer has determined
	that the request is not going to be implemented in Android.</li>
	<li><strong>Won't Fix (Obsolete):</strong> The issue is no longer relevant due
	to changes in the product.</li>
	<li><strong>Won't Fix (Infeasible):</strong> The changes that are needed to
	address the issue are not reasonably possible. This status is also used for
	issues reported that cannot be handled in AOSP, typically because it is related
	to a customized device or to an external application, or the reporter mistook
	this tracker as a help forum.</li>
	<li><strong>Duplicate:</strong> There was already an identical report in the
	issue tracker. Any actual action will be reported on that report.</li>
	</ul>
	<h3 id="resolved-issues">Resolved issues</h3>
	<p>
	This bucket contains bugs that have had action taken, and are now considered
	resolved.
	</p>
	<ul>
	<li><strong>Fixed (verified):</strong> 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.</li>
	<li><strong>Fixed:</strong> This bug has been fixed (or feature implemented) in
	a source tree, but might not yet been included in a formal release.</li>
	</ul>
	<h2 id="other-stuff">Other stuff</h2>
	<p>
	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.</p>
	</body>
	</html>