Bluetooth Management

Introduction

Bluetooth Management in FlxOS provides the core infrastructure for wireless communication between the ESP32 microcontroller and external peripherals. The system is designed around a centralized management singleton that handles device state, scanning operations, and hardware abstraction. It integrates closely with the broader Connectivity Manager to ensure seamless state synchronization across the operating system.

The scope of Bluetooth Management currently encompasses basic lifecycle control (enabling/disabling) and device discovery (scanning). According to the project roadmap, advanced features such as device pairing and file transfer via OBEX are planned for future releases.

Sources: main/core/connectivity/bluetooth/BluetoothManager.hpp, ROADMAP.md:83-85, main/main.cpp:32

Core Architecture

The Bluetooth subsystem follows a singleton pattern, ensuring a single point of control for hardware resources. The architecture consists of a backend manager and a corresponding UI layer within the Settings application.

BluetoothManager Class

The BluetoothManager is the primary controller for Bluetooth operations. It maintains the internal state of the Bluetooth radio and provides an interface for external modules to toggle power and initiate scans.

The diagram shows the relationship between the hardware manager, the global connectivity coordinator, and the user interface.
Sources: main/core/connectivity/bluetooth/BluetoothManager.hpp:10-25, main/core/apps/settings/bluetooth/BluetoothSettings.hpp:33-40

Implementation Details

State Management

Bluetooth state is managed through a combination of local boolean flags and reactive subjects. The ConnectivityManager exposes a BluetoothEnabledSubject which allows the UI to reactively update when the Bluetooth state changes.

Sources: main/core/connectivity/ConnectivityManager.hpp:75, main/core/apps/settings/bluetooth/BluetoothSettings.hpp:34-40

Device Scanning

Scanning is initiated through the UI, which calls the manager to begin discovery. Currently, the implementation uses a timer-based mock scan to simulate the discovery of various device classes.

The sequence depicts the current scanning workflow, including UI feedback and the asynchronous callback mechanism.
Sources: main/core/apps/settings/bluetooth/BluetoothSettings.hpp:80-101

UI Integration

The Bluetooth management interface is located within the Settings application. It utilizes the LVGL library to provide a modern, interactive experience.

Key UI Features:

• Header Toggle: A switch located in the header allows for immediate activation/deactivation of the Bluetooth radio.
• Status Label: Displays the current state (Ready, Disabled, or Scanning).
• Device List: Categorizes discovered peripherals into "Paired Devices" and "Available Devices".
• Refresh Button: Triggers a new scan for nearby devices using a refresh icon (LV_SYMBOL_REFRESH).

Sources: main/core/apps/settings/bluetooth/BluetoothSettings.hpp:24-78

UI Event Handling

// main/core/apps/settings/bluetooth/BluetoothSettings.hpp:42-51
lv_obj_add_event_cb(
    m_btSwitch,
    [](https://github.com/flxos-labs/flxos/blob/HEAD/lv_event_t*%20e) {
        auto* sw = lv_event_get_target_obj(e);
        auto* instance = (BluetoothSettings*)lv_event_get_user_data(e);
        bool const enabled = lv_obj_has_state(sw, LV_STATE_CHECKED);
        BluetoothManager::getInstance().enable(enabled);
        instance->refresh();
    },
    LV_EVENT_VALUE_CHANGED, this
);

Sources: main/core/apps/settings/bluetooth/BluetoothSettings.hpp:42-51

Build Configuration

Bluetooth source files are conditionally included in the build process via CMake. While the core BluetoothManager is always included, the GUI components like BluetoothSettings are excluded when CONFIG_FLXOS_HEADLESS_MODE is enabled.

Sources: main/CMakeLists.txt:5, main/main.cpp:32

Summary

The Bluetooth Management system in FlxOS provides an extensible foundation for wireless connectivity. By leveraging a singleton manager and a reactive UI, it ensures that Bluetooth hardware remains synchronized with the operating system's state. While current functionality focuses on lifecycle and discovery, the architecture is prepared for the integration of pairing and file transfer protocols as outlined in the project roadmap.