Issue Lifecycle and Reporting Guidelines

Issue tracker

The public-facing issue tracker URL is issuetracker.google.com. If you visit this URL from a corp account, it will immediately redirect you to the internal-facing issue tracker URL. Make sure that any links you paste publicly have the correct public-facing URL.

The top-level Jetpack component is Android Public Tracker > App Development > Jetpack (androidx).

Reporting guidelines

Issue Tracker isn't a developer support forum. For support information, consider StackOverflow.

Support for Google apps is through Google's support site. Support for third-party apps is provided by the app's developer, for example through the contact information provided on Google Play.

  1. Search for your bug to see if anyone has already reported it. Don't forget to search for all issues, not just open ones, as your issue might already have been reported and closed. To help you find the most popular results, sort the result by number of stars.

  2. If you find your issue and it's important to you, star it! The number of stars on a bug helps us know which bugs are most important to fix.

  3. If no one has reported your bug, file the bug. First, browse for the correct component -- typically this has a 1:1 correspondence with Maven group ID -- and fill out the provided template.

  4. Include as much information in the bug as you can, following the instructions for the bug queue that you‘re targeting. A bug that simply says something isn’t working doesn't help much, and will probably be closed without any action. The amount of detail that you provide, such as a minimal sample project, log files, repro steps, and even a patch set, helps us address your issue.

Status definitions

StatusDescription
NewThe default for public bugs. Waiting for someone to validate,
: : reproduce, or otherwise confirm that this is actionable. :
AssignedPending action from the assignee. May be reassigned.
AcceptedActively being worked on by the assignee. Do not reassign.
FixedFixed in the development branch. Do not re-open unless the fix is
: : reverted. :
WontFixCovers all the reasons we chose to close the issue without taking
: : action (can't repro, working as intended, obsolete). :

Priority criteria and SLOs

PriorityCriteriaResolution time
P0This priority is limited toLess than 1 day. Don't go home
: : service outages, blocking : until this is fixed. :
: : issues, or other types of work : :
: : stoppage such as issues on the : :
: : Platform chase list requiring : :
: : immediate attention. : :
P1This priority is limited toWithin the next 7 days
: : work that requires rapid : :
: : resolution, but can be dealt : :
: : with in a slightly longer time : :
: : window than P0. : :
P2Won't ship without this.Within the current release
P3Would rather not ship withoutLess than 365 days
: : this, but would decide case by : :
: : case. : :
P4Issue has not yet beenN/A (must triage in under 14
: : prioritized (default as of Feb : days) :
: : 2013). : :

Issue lifecycle

  1. When an issue is reported, it is set to Assigned status for default assignee (typically the library owner) with a priority of P4.
    • Some components have an empty default assignee and will be manually assigned by the triage cop
  2. Once an issue has been triaged by the assignee, its priority will be raised from P4 according to severity.
  3. The issue may still be reassigned at this point. Bug bounty issues are likely to change assignees.
  4. A status of Accepted means the assignee is actively working on the issue.
  5. A status of Fixed means that the issue has been resolved in the development branch. Please note that it may take some time for the fix to propagate into various release channels (internal repositories, Google Maven, etc.). Do not re-open an issue because the fix has not yet propagated into a specific release channel. Do not re-open an issue that has been fixed unless the fix was reverted or the exact reported issue is still occurring.