Bluetooth Development Guide: Migrating from Windows to Android


Bluetooth Development Guide: Migrating from Windows to Android

Migrating from the Windows SPP serial port approach to the Android platform is a significant transition. On Windows, Bluetooth SPP devices are mapped to virtual serial ports (COM ports), allowing developers to read and write data as they would with ordinary serial devices. On Android, due to differences in system architecture and design philosophy, there is no concept of virtual serial ports; communication must be performed directly through Bluetooth APIs. These differences extend beyond API invocation to include permission management, thread handling, and more.

For BLE (Bluetooth Low Energy) device migration, although both Windows and Android use the GATT protocol for communication, implementation approaches differ significantly. Windows provides a relatively intuitive synchronous API calling model, while Android uses an asynchronous callback mechanism that requires developers to adapt to an event-driven programming model. In addition, Android enforces stricter permission management for Bluetooth scanning and connections, especially with the new Bluetooth permission requirements introduced in Android 12 and above.

This document explains the key considerations and implementation recommendations for this migration process.

As a device provider, the following is a framework-level overview for customers migrating from Windows SPP virtual serial port development to Android. It does not cover specific code implementation:

Platform Differences Overview

Main Differences Between Windows and Android Bluetooth Development

  1. Development Environment and Languages

    • Windows typically uses C++, C#, .NET, and similar languages
    • Android uses Flutter, Java, or Kotlin, developed in Android Studio

  2. API Structure

    • On Windows, SPP appears as a virtual COM port and can be accessed using serial port programming
    • Android has no virtual COM port concept; dedicated Bluetooth APIs must be used

  3. Permission Management

    • Windows permissions are relatively straightforward
    • Android has a strict permission model; runtime permissions are required from Android 6.0 onward

SPP Migration Framework

From Windows SPP to Android SPP

  1. Pairing Process Changes

    • Windows: After pairing in system Bluetooth settings, a COM port is created automatically
    • Android: Pairing must be implemented programmatically; there is no virtual COM port

  2. Connection Method Conversion

    • Windows: Operate through the COM port—open the serial port, read and write
    • Android: Implement using classes such as BluetoothAdapter, BluetoothDevice, and BluetoothSocket

  3. Data Transmission Conversion

    • Windows: Use serial port read/write functions
    • Android: Read and write through the Socket input and output streams

BLE Migration Framework

From Windows BLE to Android BLE

  1. Service Discovery Process

    • Windows: Use the Windows.Devices.Bluetooth namespace
    • Android: Use BluetoothGatt-related classes

  2. Connection and Service Discovery

    • Windows: Obtain services and characteristics through APIs
    • Android: Handle connection state and service discovery through callbacks

  3. Characteristic Operation Conversion

    • Windows: Call characteristic read/write methods directly
    • Android: Handle read/write results and notifications through callbacks

Permission Handling Framework

Android Bluetooth Permission Requirements

  • Basic Bluetooth permissions: BLUETOOTH, BLUETOOTH_ADMIN
  • Android 6.0+ requires location permission: ACCESS_FINE_LOCATION
  • Android 12+ new permissions: BLUETOOTH_SCAN, BLUETOOTH_CONNECT

Migration Recommendations

  1. Architecture Adjustments

    • Consider using an abstraction layer to separate Bluetooth communication logic from business logic
    • Create a common interface to handle both SPP and BLE modes

  2. Thread Handling

    • Bluetooth operations on Android must not run on the main thread
    • Use asynchronous mechanisms to handle Bluetooth operations

  3. Lifecycle Management

    • Manage Bluetooth resources in Activity/Fragment lifecycle methods
    • Handle connection state when the app moves to the background

  4. Debugging and Testing

    • Use professional tools to verify device communication
    • Test permissions and compatibility across different Android versions

Through this framework overview, customers should understand the main differences and considerations when migrating from Windows to Android, preparing them for subsequent implementation. We recommend that customers first become familiar with the Android Bluetooth APIs, then implement functionality step by step according to this framework, paying attention to compatibility across different Android versions.