search

flutter / flutter

Flutter makes it easy and fast to build beautiful apps for mobile and beyond
https://flutter.dev
BSD 3-Clause "New" or "Revised" License
166.2k stars 27.49k forks source link

Running on device causes Lost connection to device. Exited on startup #134285

Closed Moncader closed 1 year ago

Moncader commented 1 year ago

Is there an existing issue for this?

Steps to reproduce

Actual results

I have already filed an issue on the vscode dart side here: https://github.com/Dart-Code/Dart-Code/issues/4726

While attempting to start a Flutter application, running from VSCode only sometimes (about a 50% chance) simply fails after the APK gets installed, the app's splash screen shows, and the VM service gets connected to with the message

Lost connection to device.
Exited

My entire development team is encountering this issue on multiple computers (all Mac) across multiple types of Android devices.

Logs

Logs Since this is executed from VSCode only, I've attached logs that were requested over on the vscode tracker. ([Dart: Capture Debugging Logs command](https://dartcode.org/docs/logging/#capture-debugging-logs)) https://gist.github.com/Moncader/6f5072d72679da2cf5d9f34b6aa78b83

Flutter Doctor output

Doctor output ```console Doctor summary (to see all details, run flutter doctor -v): [✓] Flutter (Channel stable, 3.13.0, on macOS 13.5.1 22G90 darwin-arm64, locale en-CA) [✓] Android toolchain - develop for Android devices (Android SDK version 32.1.0-rc1) [✓] Xcode - develop for iOS and macOS (Xcode 14.1) [✓] Chrome - develop for the web [✓] Android Studio (version 2022.3) [✓] VS Code (version 1.82.0) [✓] Connected device (3 available) [✓] Network resources • No issues found! ```
Moncader commented 1 year ago

cc @DanTup

DanTup commented 1 year ago

I tried reproducing this on a MacBook w/ Ventura 13.4 on two Android devices I have, but without success. I used current stable Flutter 3.13.3 and a newly created application using the Flutter: New Project command and chose Application. I ran each app and ensured the app fully loaded and remained visible for a few seconds before stopping the session.

@Moncader one thing I noticed is that you were already using legacy debug adapters in your first try, so testing with "dart.previewSdkDaps": false, wouldn't have changed anything. Is it possible you can test with "dart.previewSdkDaps": true, to see if it makes any difference? (I suspect not, but it's worth testing because there are some differences between the debug adapters).

Moncader commented 1 year ago

@DanTup Manually setting it to true seems to have fixed the issue.

I assume since this is a 'preview' flag, it's not enabled by default hence why all our team members have the same issue?

huycozy commented 1 year ago

I'm not sure how previewSdkDaps is related to the tool but I tried configuring it to true/false and running it on my device (Realme 6, Android 11), but could not reproduce this issue. Checking this on the latest Flutter stable 3.13.3.

@Moncader I notice there is a difference between Flutter/Dart extension versions:

Your:

Dart Code extension: 3.73.20230906
Flutter extension: 3.73.20230904 (activated)

Mine: 

Dart: v3.72.2
Flutter: v3.72.0

Are you using pre-release versions? Do you team members also use those versions?

Moncader commented 1 year ago

@huycozy Yes I do seem to be on the preview version. However, my teammates are not and are on the same version as you are.

DanTup commented 1 year ago

Manually setting it to true seems to have fixed the issue.

Ah, that's interesting! I did test with both legacy and new SDK DAPs but couldn't reproduce on either. If this solves the issue I would recommend just setting that flag for all the team. In the near future, the SDK DAPs will be the default and everyone will use them. The legacy DAPs are not being further developed.

I assume since this is a 'preview' flag, it's not enabled by default hence why all our team members have the same issue?

This change is rolling out gradually, so on the latest Flutter version around 30% of users are currently opted-in. The flag was added before the rollout began and was kept as a way of explicitly opting in/out during the migration (if it's unset, then it will be controlled by the experiment % that is being increased over time).

I'm not sure how previewSdkDaps is related to the tool but I tried configuring it to true/false and running it on my device

The "debug adapters" (which I often refer to as "DAPs" collectively after the Debug Adapter Protocol, because it's easier to say than "DAs") are adapters that translates between VS Code (and other DAP-compliant editors) and the Dart VM's debugger protocol ("The VM Service Protocol").

The original implementation of the debugger adapters was written in TypeScript specifically for the Dart VS Code extension and lives/ships in the VS Code extension. The new debug adapters live inside the Dart/Flutter SDKs so that a) they can be written in Dart and use existing libraries for communicating with the VM Service, and b) they can be easily used be other DAP-compliant editors (other than VS Code) without needing to clone the VS Code extension source.

The VS Code extension is switching users over to the new SDK DAPs gradually (while we monitor for errors/bug reports) and the previewSdkDaps flag allows you to explicitly enable/disable them. If it's set to false you'll get the legacy debug adapters (from the Dart VS Code extension) and if you set to true you'll get the new SDK debug adapters (from the "dart debug_adapter" and "flutter debug_adapter" commands). If it's unset, it will be controlled by the "experiment" which has a percentage of users that is slowly increasing.

Are you using pre-release versions? Do you team members also use those versions?

I don't think being on the pre-release VS Code extension will make a difference here because there should be no differences in the debug adapters between them. That said, I don't know what might be causing this - it's odd for a whole team to be affected by it on different devices and it to reproduce on a newly created app (which rules out anything specific in their app). My guess is that there is some subtle bug or race condition in the legacy DAPs that's being triggered here, but I've not been able to reproduce it and I don't see anything obviously bad in the logs.

If the issue definitely doesn't occur on the new SDK DAPs, I'd be inclined to close this though. Everyone will soon be on the new DAPs and can enable them today if they happen to hit an issue like this.

However, if this issue does start coming up in the SDK DAPs, it definitely requires tracking down.

huycozy commented 1 year ago

Thank @DanTup for these insights. Based on the information provided and confirmation from @Moncader that the issue can be solved using the DAPs SDK, I'm going to close this issue.

@Moncader Please feel free to write a comment if you have this issue with SDK DAPs, and I will reopen this for investigation. Thank you!

github-actions[bot] commented 1 year ago

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.