You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Make it real easy to open an issue with crash reports and logs #1657
Imagine a flutter report-bug command. It could grab any crash report from iOS, any recent logs, the flutter version, the Dart version, and then send it off to GitHub as an issue.
We want to make it as simple as
Example UI:
$ flutter report-bug
Sorry you ran into trouble, but we appreciate the bug report.
This command collects potentially relevant information and opens a public bug report for the Flutter team as a GitHub issue. Please review the information before you confirm.
Flutter version: ...
Dart version: ...
OS: mac
Crash file: path/to/file
Log: path/to/file or print out what we will send
OK to make this information public as a GitHub issue? [y/N]
I was actually thinking about this a few days ago. I think it works best as a flag to flutter run, since that lets you capture potentially important information in the building and deployment of the app.
Let's reopen this. #45360 is triggered for flutter crashes, but it would be nice to have something the user could trigger if they are hitting a non-crashing bug. We should be able to reuse a lot of that code.
Let's reopen this. #45360 is triggered for flutter crashes, but it would be nice to have something the user could trigger if they are hitting a non-crashing bug. We should be able to reuse a lot of that code.
What sort of non-crashing bugs were you thinking of? Just general failures in the tool (e.g., no device found)?
I don't think this is something that the tool team will have time to work on, and I can't think of a good way to implement this in the UI. Going to close this as not planned for now.
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.
Activity
Hixie commentedon Jan 26, 2017
cc @tvolkert who might be interested in this
tvolkert commentedon Jan 26, 2017
I was actually thinking about this a few days ago. I think it works best as a flag to
flutter run, since that lets you capture potentially important information in the building and deployment of the app.tvolkert commentedon Jan 26, 2017
flutter run --bugreportzanderso commentedon Jan 17, 2020
@jmagman's work here in this area is what we decided to do for this.
jmagman commentedon May 26, 2020
Let's reopen this. #45360 is triggered for
fluttercrashes, but it would be nice to have something the user could trigger if they are hitting a non-crashing bug. We should be able to reuse a lot of that code.2 remaining items
[firebase_core] replace invokeMethod with invokeMapMethod, add type p…
bkonyi commentedon Sep 30, 2024
What sort of non-crashing bugs were you thinking of? Just general failures in the tool (e.g., no device found)?
jmagman commentedon Sep 30, 2024
Yes, or even bugs in Flutter itself "I launch my app and the screen is black" that would collect verbose logs, doctor, etc
bkonyi commentedon Jun 27, 2025
I don't think this is something that the tool team will have time to work on, and I can't think of a good way to implement this in the UI. Going to close this as not planned for now.
github-actions commentedon Jul 11, 2025
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.