Skip to content

androidSdk/bin/emulator support#523

Draft
kolchurinvv wants to merge 2 commits into
nvim-flutter:mainfrom
kolchurinvv:dev
Draft

androidSdk/bin/emulator support#523
kolchurinvv wants to merge 2 commits into
nvim-flutter:mainfrom
kolchurinvv:dev

Conversation

@kolchurinvv
Copy link
Copy Markdown

@kolchurinvv kolchurinvv commented Apr 23, 2026

The WHY

For whatever reason my NixOS + nix develop shell which encapsulates my flutter project doesn't want to load qemu aka emulators into the Nvidia VRAM when launched via flutter emualtor --launch emulator_id, but the emulator @emulator_id -gpu host -accel on works like a charm.

The intention of the Draft PR is to gauge whether this affects other people and could be useful to a wider audience 😄
There could be potential to capture user input to extend the launch options with the ones listed inemulator --help

This adds a rudimentary support for **/*/androidSdk/bin/emulator binary.

  • -gpu host, -accel on and others - currently hard-coded what i needed.
  • creates another FlutterEmulatorsAvds list command which relies on emulator binary
  • launches the emulators from the list via the emulator @emulator_id .. args

known issues:

  • when emulator binary is used to launch the emulators, on closing the emulator, the entire log is pushed to the Notifications. I'm not sure what would be the best way to handle this
  • this will probably break on MacOS - haven't tested it there (i do have a mac so i will be able to test there soon)
  • no idea whether it'll work on Windows - can't test with that

@kolchurinvv kolchurinvv changed the title Emulator binary support androidSdk/bin/emulator support Apr 23, 2026
@kolchurinvv
Copy link
Copy Markdown
Author

@sidlatau sorry for the direct '@' -- only want to make sure this has been noticed :) would love to hear thoughts :)

@sidlatau
Copy link
Copy Markdown
Collaborator

sidlatau commented May 9, 2026

I like the use case here. Having an escape hatch for environments where flutter emulator --launch is not enough seems valuable.
That said, I think I'd prefer a more flexible first version than adding a separate FlutterEmulatorsAvds flow in core.
My main concern with the current shape is that it introduces a second emulator listing/launch path that is Android-SDK-specific, hard-codes launch flags, and pushes more platform/path handling into the plugin itself. That feels like higher maintenance than we probably want here.
I wonder if a better first step would be to keep the existing :FlutterEmulators picker and add a configurable emulator launch hook in setup(), something along these lines:

require("flutter-tools").setup({
  emulators = {
    launcher = function(emulator, paths)
      if emulator.system ~= "android" then
        return nil
      end
      local emulator_bin = vim.fn.exepath("emulator")
      if emulator_bin == "" then
        return nil
      end
      local args = { "@" .. emulator.id, "-gpu", "host", "-accel", "on" }
      if emulator.cold_boot then
        table.insert(args, "-no-snapshot-load")
      end
      return {
        command = emulator_bin,
        args = args,
      }
    end,
  },
})

With that model:

  1. Returning nil would keep today's default flutter emulator --launch ... behavior.
  2. Returning a launch spec would let users fully override the launch command for their environment.
  3. We would not need a second FlutterEmulatorsAvds command or separate AVD parsing/listing logic in core.
  4. It would also leave room to grow later into something more Dart-Code-like, for example emulators.custom, without painting the public API into an Android-specific corner.
    So from a maintenance/API point of view, I think I'd lean toward a configurable launch override as a first step, rather than merging a dedicated AVD flow.
    For naming, I would use emulators.launcher.

@kolchurinvv
Copy link
Copy Markdown
Author

Thanks for the feedback - all valid. as of right now this existing implementation solved my immediate problem, but the PR should include a more generalized solution for sure 😄 Let me take a stab at re-writing the implementation with your suggestions in mind and i'll get back to you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants