ConnMan on AGL ivi-homescreen, Part 2: Plugin Registration & Channel Wiring

In Part 1 we covered the big picture: what ConnMan is, how AGL’s ivi-homescreen plugin architecture works, and the overall design of the plugin. In this part we zoom into the C++ side — specifically connman_plugin.cc — and understand exactly how a plugin registers with Flutter, handles method calls, and streams D-Bus events up to Dart.

The ivi-homescreen Plugin Entry Point

Every plugin must expose a C linkage entry point that matches the ABI expected by the embedder. For ivi-homescreen (which uses the standard Flutter desktop plugin API), this is a function named after the plugin:

1
#ifdef __cplusplus
2
extern "C" {
3
#endif
4

5
void connman_plugin_register_with_registrar(
6
    FlutterDesktopPluginRegistrarRef registrar);
7

8
#ifdef __cplusplus
9
}
10
#endif

The embedder calls this function at startup, passing a FlutterDesktopPluginRegistrarRef. In connman_plugin.cc, we unwrap that into a typed C++ flutter::PluginRegistrar and hand it to the plugin class:

1
void connman_plugin_register_with_registrar(
2
    FlutterDesktopPluginRegistrarRef registrar) {
3
  connman_plugin::ConnmanPlugin::RegisterWithRegistrar(
4
      flutter::PluginRegistrarManager::GetInstance()
5
          ->GetRegistrar<flutter::PluginRegistrar>(registrar));
6
}

This is all boilerplate — the interesting logic starts in RegisterWithRegistrar.

Plugin Class Architecture

The plugin is implemented as a C++ class that extends flutter::Plugin. It owns:

A flutter::MethodChannel — for bidirectional RPC with Dart.
A flutter::EventChannel — for streaming D-Bus signals to Dart.
A ConnmanAgent — the D-Bus object that ConnMan calls when it needs credentials.
A std::mutex + EventSink pair — for thread-safe event emission.
A vector<unique_ptr<sdbus::IProxy>> — proxy objects kept alive for D-Bus signal subscriptions.

1
class ConnmanPlugin : public flutter::Plugin {
2
 public:
3
  static void RegisterWithRegistrar(flutter::PluginRegistrar* registrar);
4

5
  explicit ConnmanPlugin(
6
      std::unique_ptr<flutter::MethodChannel<flutter::EncodableValue>> channel,
7
      flutter::BinaryMessenger* messenger)
8
      : channel_(std::move(channel)), messenger_(messenger) {
9
    agent_ = std::make_unique<ConnmanAgent>(channel_.get());
10
    SetupEventChannel();
11
  }
12

13
 private:
14
  std::unique_ptr<flutter::MethodChannel<flutter::EncodableValue>> channel_;
15
  std::unique_ptr<flutter::EventChannel<flutter::EncodableValue>> event_channel_;
16
  flutter::BinaryMessenger* messenger_;
17
  std::unique_ptr<ConnmanAgent> agent_;
18

19
  std::mutex sink_mutex_;
20
  std::unique_ptr<flutter::EventSink<flutter::EncodableValue>> event_sink_;
21
  std::vector<std::unique_ptr<sdbus::IProxy>> signal_proxies_;
22
  // ...
23
};

Tip

The channel_ pointer is passed to ConnmanAgent so the agent can invoke Dart methods (requestInput) on the same channel. Both live for the lifetime of the plugin.

Registering the MethodChannel

RegisterWithRegistrar creates the MethodChannel and wires the call handler:

1
void ConnmanPlugin::RegisterWithRegistrar(flutter::PluginRegistrar* registrar) {
2
  auto channel =
3
      std::make_unique<flutter::MethodChannel<flutter::EncodableValue>>(
4
          registrar->messenger(), "io.github.jaydon2020",
5
          &flutter::StandardMethodCodec::GetInstance());
6

7
  auto plugin = std::make_unique<ConnmanPlugin>(std::move(channel),
8
                                                registrar->messenger());
9

10
  plugin->channel_->SetMethodCallHandler(
11
      [plugin_pointer = plugin.get()](const auto& call, auto result) {
12
        plugin_pointer->HandleMethodCall(call, std::move(result));
13
      });
14

15
  registrar->AddPlugin(std::move(plugin));
16
}

A few things worth noting:

Channel name: "io.github.jaydon2020" must match exactly what the Dart side uses in MethodChannel('io.github.jaydon2020').
StandardMethodCodec: this codec serializes method calls and results using Flutter’s standard binary format. Both C++ and Dart must use the same codec.
Ownership: plugin is moved into registrar->AddPlugin(...), so the registrar owns the plugin for its lifetime. The lambda captures plugin_pointer (a raw pointer), which is safe since the pointer lifetime is tied to the plugin’s.

Dispatching Method Calls

HandleMethodCall is the single dispatch point for all incoming Dart calls. It is deliberately a thin router — it validates arguments and forwards to the appropriate module:

1
void HandleMethodCall(
2
    const flutter::MethodCall<flutter::EncodableValue>& call,
3
    std::unique_ptr<flutter::MethodResult<flutter::EncodableValue>> result) {
4
  const auto& name = call.method_name();
5

6
  if (name == "getWifiTechnology") {
7
    ConnmanTechnology::GetWifiTechnology(std::move(result));
8

9
  } else if (name == "setWifiPowered") {
10
    const auto* args = std::get_if<flutter::EncodableMap>(call.arguments());
11
    if (args) {
12
      auto powered = GetArgument<bool>(*args, "powered");
13
      if (powered.has_value()) {
14
        ConnmanTechnology::SetWifiPowered(*powered, std::move(result));
15
        return;
16
      }
17
    }
18
    result->Error("INVALID_ARGUMENTS", "Expected boolean 'powered'");
19

20
  } else if (name == "scanWifi") {
21
    ConnmanTechnology::ScanWifi(std::move(result));
22

23
  } else if (name == "getWifiServices") {
24
    ConnmanService::GetWifiServices(std::move(result));
25

26
  } else if (name == "connectService" || name == "disconnectService" ||
27
             name == "removeService") {
28
    const auto* args = std::get_if<flutter::EncodableMap>(call.arguments());
29
    std::optional<std::string> path;
30
    if (args) path = GetArgument<std::string>(*args, "path");
31

32
    if (!path.has_value() || path->empty()) {
33
      result->Error("INVALID_ARGUMENTS", "Expected string 'path'");
34
      return;
35
    }
36
    if (name == "connectService")
37
      ConnmanService::ConnectService(*path, std::move(result));
38
    else if (name == "disconnectService")
39
      ConnmanService::DisconnectService(*path, std::move(result));
40
    else
41
      ConnmanService::RemoveService(*path, std::move(result));
42

43
  } else {
44
    result->NotImplemented();
45
  }
46
}

The GetArgument<T> helper (from connman_helpers.h) safely extracts typed values from the EncodableMap:

1
template <typename T>
2
std::optional<T> GetArgument(const flutter::EncodableMap& args,
3
                              const std::string& key) {
4
  auto it = args.find(flutter::EncodableValue(key));
5
  if (it != args.end() && std::holds_alternative<T>(it->second)) {
6
    return std::get<T>(it->second);
7
  }
8
  return std::nullopt;
9
}

This is a pattern worth adopting in any plugin — it keeps argument extraction safe, concise, and type-checked without exceptions.

Setting Up the EventChannel

The EventChannel is the mechanism for pushing unsolicited events from C++ to Dart — perfect for D-Bus signals. It is set up in SetupEventChannel():

1
void SetupEventChannel() {
2
  event_channel_ =
3
      std::make_unique<flutter::EventChannel<flutter::EncodableValue>>(
4
          messenger_, "io.github.jaydon2020/events",
5
          &flutter::StandardMethodCodec::GetInstance());
6

7
  auto handler = std::make_unique<
8
      flutter::StreamHandlerFunctions<flutter::EncodableValue>>(
9
    // onListen: Dart subscribed
10
    [this](const flutter::EncodableValue* /*args*/,
11
           std::unique_ptr<flutter::EventSink<flutter::EncodableValue>> sink) {
12
      std::lock_guard<std::mutex> lock(sink_mutex_);
13
      event_sink_ = std::move(sink);
14
      SubscribeToSignals();
15
      return nullptr;
16
    },
17
    // onCancel: Dart unsubscribed
18
    [this](const flutter::EncodableValue* /*args*/) {
19
      std::lock_guard<std::mutex> lock(sink_mutex_);
20
      signal_proxies_.clear();  // stop listening to signals
21
      event_sink_ = nullptr;
22
      return nullptr;
23
    });
24

25
  event_channel_->SetStreamHandler(std::move(handler));
26
}

The lifecycle is clean:

onListen fires when the Dart side calls eventChannel.receiveBroadcastStream().listen(...). This is when we start subscribing to D-Bus signals and hand the event_sink_ to the signal handlers.
onCancel fires when the stream subscription is cancelled. We clear the proxy objects (which stops signal delivery) and null out the sink.

Subscribing to D-Bus Signals

Once Dart is listening, SubscribeToSignals() creates three types of subscriptions:

1
void SubscribeToSignals() {
2
  try {
3
    auto& bus = plugin_common_sdbus::SystemDBus::Instance().GetConnection();
4

5
    // 1. Manager ServicesChanged — fires when the list of services changes
6
    auto mgr_proxy = sdbus::createProxy(bus, sdbus::ServiceName("net.connman"),
7
                                        sdbus::ObjectPath("/"));
8
    mgr_proxy->uponSignal("ServicesChanged")
9
        .onInterface("net.connman.Manager")
10
        .call([this](const std::vector<...>& /*changed*/,
11
                     const std::vector<sdbus::ObjectPath>& /*removed*/) {
12
          ConnmanService::PushServicesUpdate(sink_mutex_, event_sink_);
13
        });
14
    signal_proxies_.push_back(std::move(mgr_proxy));
15

16
    // 2. Technology PropertyChanged — e.g. Wi-Fi powered on/off
17
    ConnmanTechnology::SubscribeToPropertyChanged(
18
        signal_proxies_, sink_mutex_, event_sink_);
19

20
    // 3. Service PropertyChanged — e.g. state, strength
21
    ConnmanService::SubscribeToPropertyChanged(
22
        signal_proxies_, sink_mutex_, event_sink_);
23

24
  } catch (const sdbus::Error& e) {
25
    std::cerr << "Failed to subscribe to ConnMan signals: "
26
              << e.getMessage() << std::endl;
27
  }
28
}

The proxy objects are stored in signal_proxies_ to keep them alive — sdbus-c++ signal subscriptions are tied to the lifetime of the proxy object. When onCancel clears signal_proxies_, the proxies are destroyed and the corresponding signal subscriptions are automatically cancelled.

Note

plugin_common_sdbus::SystemDBus::Instance().GetConnection() returns a shared D-Bus system connection managed by ivi-homescreen’s plugin_common library. All plugins in the ivi-homescreen plugin suite share one connection to the system bus.

Thread Safety

The event_sink_ is accessed from two different threads:

The D-Bus event loop thread (where signals are delivered by sdbus-c++)
The main/Flutter platform thread (where onListen/onCancel run)

Every access to event_sink_ is protected by sink_mutex_. The signal callbacks use std::lock_guard<std::mutex> before calling event_sink_->Success(...):

1
std::lock_guard<std::mutex> lock(sink_mutex_);
2
if (event_sink_) {
3
  event_sink_->Success(flutter::EncodableValue(event));
4
}

The null check if (event_sink_) is critical — D-Bus events can arrive briefly after the Dart subscription has been cancelled (between the moment the proxy is cleared and the D-Bus thread processes the cancellation).

Summary

In this part we covered:

The C linkage entry point required by ivi-homescreen
How the MethodChannel is created and how calls are dispatched to the right module
How the EventChannel is set up with onListen/onCancel lifecycle hooks
How D-Bus signal subscriptions are started on listen and torn down on cancel
The thread safety pattern for emitting events from the D-Bus thread

In Part 3, we will go deeper into the two D-Bus operation modules: ConnmanTechnology (Wi-Fi radio control) and ConnmanService (network operations), and look at how blocking D-Bus calls are offloaded to background threads.