Howto: Use the Issue Tracker

The issue tracker - unlike the forums - is NOT the place for user help. The issue tracker's purpose is to identify problems with CyanogenMod itself, and make Cyanogen and other developers' life easier. Cyanogen (steve.kondik on the tracker) has final say on all issues, so if he changes it to "wontfix", arguing will not help.

Enhancement requests are welcome (a maintainer will change the type from 'defect' to 'enhancement'), but please see below about searching, as there are several 'enhancements' that have been turned down.

Before you report anything

• First, make sure your issue isn't covered on the troubleshooting page. Many of the frequent issues with solutions are listed there.
• Second, search the forums for similar issues.
• Third, ask around in #cyanogenmod on irc.freenode.net. This can be an excellent source of information on new issues.
• Fourth, make sure your issue isn't already reported:
  • Search this page, using as few words as possible.
    • try a couple different terms; remember that not all reports/reporters are going to be worded how you think of the problem
    • try with the general category of problem, eg 'bluetooth' or 'BT'

If you find an issue that is the same problem as yours, comment on it instead of opening a new one. Include any information that's different in your case from the original report. Please don't just post "me too" type replies, just star the issue to 'vote' for it and be updated by email of additional comments. If the issue is closed and you're having the same problem, don't open a new one; comment on the existing one and one of the maintainers can re-open the issue.

Reporting an issue

So you've found an issue that hasn't been reported and nobody in #cyanogenmod can help (or they told you to report the issue). Click 'New Issue' in the upper left-hand corner and fill out the template in the issue tracker fully (don't erase it and start writing freeform):

Summary:

Be descriptive but terse here; "FC in Music with WMA mp4" is good, "Camera issue" isn't, and "OMG BIG PROBLEMS" is horrible. Remember that this is what other people will see when they search for issues, so make it obvious what the problem is (without putting so much text in that the tracker has to wordwrap). The issue maintainers can change this after submission if needed.

Please include the following info from FASTBOOT mode; MODEL?, HBOOT?, RADIO?

Depending on your model, fastboot/spl/bootloader mode can probably be reached by booting the device with the camera button, volume down, or 'back' held down. If you can't find it, see if you can find information on this page. This information isn't always pertinent, but please fill it in anyway. The top line of text describes the hardware model, the second line provides HBOOT info, and the third line provides the RADIO version. At a minimum you should know the model name of the device and radio version is also in settings»about device, under 'Baseband version' after the _

Which version of CyanogenMod? / What url did you download it from? / Which gapps & where did you download it?

This should be pretty self explanatory. Note that you should upgrade to the latest version of CyanogenMod and gapps before reporting an issue. Many fixes aren't listed in the changelog for given versions. However, if you've experienced an issue for several versions, say so here.

Did you wipe before flashing (if so, what)?

While not necessary for each upgrade/install, wiping ('factory reset' or alt+w from recovery) the user data can solve a lot of issues. To test, make a nandroid backup, wipe, and reinstall CyanogenMod. You can then test the issue again and restore the nandroid to get your data back. If wiping does solve the problem, then don't report the issue, as the cause is bad data somewhere in the system. Further investigation might lead you to the individual data causing the problem, and you can remove that and keep the rest of your data. Amon_Ra's and the ClockworkMod recoveries have many different options for wiping, list any/all that you have done here.

Have you tried rebooting?

While this should be obvious, sometimes it isn't.

Are you using a task killer?

Applications that automatically kill tasks or 'manage memory' cause more issues than they solve. If you can't duplicate an issue without a task manager installed/running, then don't report it.

Are you using JIT?

JIT in Android 2.1 and earlier is buggy. If you can't duplicate an issue while not running JIT, don't report it.

Are you using a custom kernel?

Many custom kernels from awesome developers like pershoot and kmobs have undervolting, overclocking, or other neat features. If you have an issue and can't duplicate it with the stock kernel that comes in CyanogenMod, please report the issue to whomever you got the kernel from. Note that bcrook/radix 32A/EBI1 ports don't count as 'custom kernels'.

Attach a logcat/last_kmsg of the issue in plain text.

Any issues without a logcat will be marked as 'Invalid'. There are several ways to get a logcat. You can either paste the relevant area (e.g. 'unhandled exception' and the 10-20 lines after) or you can attach a text file (please name it something more descriptive than 'logcat.txt') at the bottom of the report form. The log that logcat pulls from does not survive reboots, however. For reports of reboot/restarting issues, attach/paste the file(s) at /proc/last_kmsg and/or /data/dontpanic/* Attach logcats as .txt, not .doc[x] or any other specialized format.

What steps will reproduce the problem?

Please be as verbose and precise as possible here. "take a picture" is less helpful than "1. press camera button, 2. let camera app load, 3. press the button on the screen". The more specific information you give here, the more likely other people can reproduce the problem and possibly provide a solution.

Please provide any additional information below.

This is your space to include any other information you think might be pertinent. Obviously this form is not completely comprehensive, so tell us here if you're using 3rd party apps for a given task, or what other things you've tried to solve it. While we don't need a list of every 3rd party app on the device, knowing what apps you have that might have something to do with the issue is a good thing.

Even if you fill this out entirely, aren't duplicating another issue, and have done your best to solve it, it may still be closed without a solution. There are various reasons why:

Issue Statuses

Open Issues

• NeedInfo = Information requested from user; will be closed as stale if not provided in 48h.
• New = All issues start at 'new'. Most never get past this state for various reasons.
• Reviewed = Issue has been looked at (by a developer) but not replicated
• Verified = Problem has been replicated by at least 3 reporters or one of the senior users. It still may be an Android issue, and may not necessarily be fixed by CyanogenMod.
• Accepted = Problem identified as a CyanogenMod issue. Most likely only set by a developer.
• PatchSupplied = someone has attached a patch for the reported problem/enhancement, but it hasn't been accepted yet.
• Started = Work on this issue has begun, or a previously fixed/shouldbefixed issue has been repeated after the fix.
• ShouldBeFixed = A fix will be in the next release or the fix in the current release is still being tested.

Closed Issues

• AndroidIssue = The bug is endemic to Android itself, and won't be fixed in CyanogenMod. Often Steve fixes Android bugs, but some are more difficult than others.
• Fixed = Developer made source code changes, no new reports have been made.
• Invalid = This was not a valid issue report. Anyone following the above instructions shouldn't have to worry about this status.
• Duplicate = This report duplicates an existing issue.
• WontFix = We decided to not take action on this issue. Developers will decide that certain bugs are too hard/annoying to fix and/or aren't serious enough to bother with. This status is used on rejected Enhancement requests as well.
• ItsNotABugItsAFeature = This is working as intended by the developers.
• StaleIssue = If you don't keep upgrading and reporting on an issue, it'll probably be marked stale after a new release. The maintainers will request updates once before resorting to this tag. Also used for unresolved 'needinfo' issues.
• AppIssue = Issues with specific applications that aren't a part of CyanogenMod will be tagged this, especially if the app maker updates and fixes the problem.
• UserIssue = Seems to be a one off issue with the users device. Likely if one person reports a bug and it mysteriously disappears with an upgrade/wipe/other.
• HardwareIssue = Suspected hardware issue. Obviously harder to prove and more annoying/expensive to fix. SD card issues get this sometimes.

Note that just because an issue is 'closed' does not mean you cannot comment on it or that the maintainers can't reopen it. Unlike, e.g. forum threads that are 'locked'.

Priorities

All issues start at 'normal' priority and can only be changed by the maintainers. Many do not progress past this priority. Only issues that are confirmed by multiple sources and impair some basic functionality of the device get upgraded, and even then may not be. For the most part the developers prioritize their work based on things they can duplicate, things that bug them, or similar. Asking for the priority of an issue to be changed will not work. The best way to make it obvious that your issue is important is to have other people star it. THIS DOES NOT MEAN THAT YOU SHOULD SPAM ANYWHERE WITH THE ISSUE. Anyone having similar issues (and paying attention to the top of this page) should be able to find your issue by searching, which is another good reason to make sure you're descriptive as possible.

Starring

This is how you can 'vote' for an issue and automatically receive email updates with new posts. While not strictly followed, the number of 'votes' an issue has does tell the maintainers how widespread a problem is (or how popular an enhancement request is). Note that just because you can get 50 other people to star your issue, it will not necessarily make it a higher priority.

Final thoughts from PsychoI3oy the BugMonkey

Never take anything on the tracker personally (and please don't post anything that could be taken personally; the maintainers can and do delete posts). If your pet issue isn't solved in a timely fashion, is closed without a solution, or the maintainers comment that they can't duplicate it, don't get bent out of shape. Remember that open source development is not only not-for-profit, it's not-for-pay for most of the maintainers/ops/admins/moderators. We like helping and do this for fun, but nobody owes any user anything. If you have an issue that bugs you or prevents you from using features, just stay on the last version that it worked on. With the exception of -RC builds, there is no imperative to constantly upgrade to the latest-and-greatest; if 6.1.0 works for you, use it. That being said, please do upgrade and check the status of bugs regularly, even if you don't use the updated version for day-to-day work. Along these lines, posts of "this sucks, I'm going back to 6.0.0" or "this sucks, I'm going to $otherdeveloper" will not convince anyone to work harder on your bug, and may get your issue closed. Keep the posts professional and constructive and most importantly informative, and we'll all do what we can to fix the issues.

TL;DR: answer all the questions, provide a log, and NO NIGHTLIES.