-
Notifications
You must be signed in to change notification settings - Fork 28.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use adb logcat
to discover if startApp
might have failed.
#162185
Use adb logcat
to discover if startApp
might have failed.
#162185
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
RSLGTM
Any thoughts about the false positives? I imagine with this setup, if I wrote: import 'package:flutter/material.dart';
void main() {
print('Error: Jonah is a bad');
} ... then we'd report it as a launch failure, which probably is not right? Maybe it's OK? |
// For apps that use the VM service protocol, we *do* have a signal that the app | ||
// appears to have started, and can wait until the VM service is discovered, and | ||
// then check "startupLogs" to see if an error was detected so far. | ||
if (checkErrorFromStartupLogs() case final String error) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could concievably get a successfull connection but still see an error log right?
Could we ignore this error if we have a vm service URI?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The reverse is also true though, we get a VM service URI when we otherwise don't have a successful connection :-/ (fatal Impeller)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, so we connect but then get the connection is closed error. Yeah, I dunno. Maybe you could do something like set an error bit and if an http exception is encountered then assume the app crashed. But if that is happening way later its not going to be possible to track.
I don't think there is going to be a foolproof method here. Unless we want to add some magic string to these known errors that would be less likely to colide than "Error"
I've been convinced to mark this blocked/paused until we can filter log messages and generally have more stable signals. |
This pull request has been changed to a draft. The currently pending flutter-gold status will not be able to resolve until a new commit is pushed or the change is marked ready for review again. For more guidance, visit Writing a golden file test for Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing. |
Changes how
AndroidDevice.startApp
decides if the launch succeeded or failed by sniffingadb logcat
instead of just relying on thestdout
ofadb shell am start
, which from what I can tell is extremely inconsistent.This hypothetically could have false positives if there are startup logs that print the text
Error:
(this false positive existed before too, but there was just a good chance we'd miss the log), so I'm open to other suggestions as well.Fixes #162087.
After this change,
flutter drive lib/will_never_start_successfully.dart
does fail:It would be nice not to restart twice, but we have no way of distinguishing "this is a failure that cannot be recovered" and I'm not sure we have a good way (
F/flutter
?). I'd be open to another PR that improves this, feedback welcome.