-
Notifications
You must be signed in to change notification settings - Fork 1
Multi device debugging in VS Code
The Flutter plugin for Visual Studio code has been updated to provide experimental support for Visual Studio Code’s multi-target debugging.
- You must be on latest Flutter master channel for concurrent builds to not overwrite each other and cause build failures.
- The Hot Reload button on the debug toolbar does all sessions, but Hot Restart only does the active session
To debug multiple devices concurrently you should set up a launch config for each device that has the deviceId
field set (this is the same ID you'd pass to flutter run -d xxx
). Open the launch config by clicking Debug -> Open Configurations
. Add a compound
config at the bottom that will launch both (or more) configurations at the same time:
{
"version": "0.2.0",
"configurations": [
{
"name": "Current Device",
"request": "launch",
"type": "dart"
},
{
"name": "Android",
"request": "launch",
"type": "dart",
"deviceId": "android"
},
{
"name": "iPhone",
"request": "launch",
"type": "dart",
"deviceId": "iphone"
},
],
"compounds": [
{
"name": "All Devices",
"configurations": ["Android", "iPhone"],
}
]
}
Once saved, the compound configuration will show up in the drop-down at the top of the Debug side bar.
Selecting the compound config on the Debug side bar and clicking Debug -> Start Debugging
(or Start Without Debugging
) will launched debug sessions for each device at the same time.
Note: This may be slow because there are multiple concurrent builds (it may be faster on subsequent builds). You will also see multiple progress notification windows during the builds (we can likely improve this, but right now they just run without knowledge of each other so spawn their own notifications).
When there are multiple active debug sessions, the debug toolbar will show a dropdown that lets you select the "active" debug session.
Actions on the debug toolbar will be sent only to this session (so you can step individually). The Debug Console will show a similar dropdown to switch between the output of each session.
The Variables and Watch panels on the Debug sidebar will be applied to the active debug session (being re-evaluated as you switch between them), though the Call Stack will show all sessions together, grouped by name.
All the usual functionality like hot-reload-on-save should work. Terminating an app should close only that single debug session.
The following are tips and tricks learned from connecting a large number of devices for simultaneous debugging (up to 9 at a time have been tested with these techniques).
- Make sure to use high quality USB cables, e.g. Anker Powerline+ and/or the official Apple cables
- Make sure to use a high quality USB hub, e.g. Anker 7-Port USB 3.0 Data Hub
- If you feel the device buzzing periodically, it may be connected and disconnecting, which isn't conducive to good debugging
- Make sure that the ChromeOS box is in developer mode and supports adb deployment
- Make sure the left port is used for the connection (at least for the Google Pixel family of Chrome OS devices)
- If not showing in
flutter devices
, reboot the Chrome OS device with the USB cable in place
- Changes not being replicated to the web and/or desktop app via hot reload? Clicking on the app should cause the changes to be replicated.
- Starting a debugging session always failing? Make sure that you're using the proper device name, e.g. Apple likes to use smart quotes in their device names instead of the standard apostrophe, e.g.
Bob’s iPad
instead ofBob's iPad
. - If you're still having trouble, make sure to test each configuration on its own via the Debug Sidebar instead of choosing the device to debug from the status bar -- the one in the status bar is going to ignore your launch settings and hide your errors.
- Home of the Wiki
- Roadmap
- API Reference (stable)
- API Reference (master)
- Glossary
- Contributor Guide
- Chat on Discord
- Code of Conduct
- Issue triage reports
- Our Values
- Tree hygiene
- Issue hygiene and Triage
- Style guide for Flutter repo
- Project teams
- Contributor access
- What should I work on?
- Running and writing tests
- Release process
- Rolling Dart
- Manual Engine Roll with Breaking Commits
- Updating Material Design Fonts & Icons
- Postmortems
- Setting up the Framework development environment
- The Framework architecture
- The flutter tool
- API Docs code block generation
- Running examples
- Using the Dart analyzer
- The flutter run variants
- Test coverage for package:flutter
- Writing a golden-file test for package:flutter
- Setting up the Engine development environment
- Compiling the engine
- Debugging the engine
- Using Sanitizers with the Flutter Engine
- Testing the engine
- The Engine architecture
- Flutter's modes
- Engine disk footprint
- Comparing AOT Snapshot Sizes
- Custom Flutter engine embedders
- Custom Flutter Engine Embedding in AOT Mode
- Flutter engine operation in AOT Mode
- Engine-specific Service Protocol extensions
- Crashes
- Supporting legacy platforms
- Metal on iOS FAQ
- Engine Clang Tidy Linter
- Why we have a separate engine repo
- Reduce Flutter engine size with MLGO
- Setting up the Plugins development environment
- Setting up the Packages development environment
- Plugins and Packages repository structure
- Plugin Tests
- Contributing to Plugins and Packages
- Releasing a Plugin or Package
- Unexpected Plugins and Packages failures