Skip to content

Platform-specific Extensions

This section documents API behaviors, features and capabilities that differ across platforms or are only available in specific DaaS-IoT SDK implementations.

While the Common API Surface describes the conceptual model shared by all SDK variants, some functions, diagnostic tools, drivers or system features are platform-dependent due to OS, hardware or runtime constraints.

This reference serves as a compatibility map and a source of detailed notes for integrators targeting multiple environments.

1. Transport Adapter Availability

Not all platforms support the same set of transport adapters. Typical differences include:

Transport Adapter Linux Windows macOS Android Python Qt Java
INET4 (IPv4) ✔️ ✔️ ✔️ ✔️ ✔️ ✔️ ✔️
Bluetooth ✔️ ⚠️ Limited ⚠️ Limited ✔️ Depends ✔️ ✔️
Serial / UART ✔️ ✔️ ⚠️ Partial ❌ Limited ✔️ ❌
USB adapters ✔️ ⚠️ Partial ⚠️ Limited ❌ N/A ✔️? ❌
MQTT (future) Planned Planned Planned Planned Planned Planned Planned

These are placeholders; table will be replaced with real support data.

2. Platform-specific Diagnostics

Some diagnostic features depend on OS-level APIs.

Linux

  • Low-level socket and routing statistics.
  • Access to high-resolution timers (clock_gettime).
  • Extended logging through syslog or journalctl.
  • Queryable NIC parameters (MTU, dropped packets, buffer states).

Windows

  • Integration with Windows Performance Counters.
  • Use of IOCP or event-based async sockets.
  • Differences in timestamp resolution.
  • Specialized network adapters may expose limited metadata.

macOS

  • Apple-specific time functions (mach_absolute_time).
  • Restrictions on raw-socket usage.

Android

  • Power-management aware events.
  • Network availability callbacks via Android system services.
  • Background execution constraints.

3. Time Synchronization (ATS) Extensions

While ATS is universally supported, the quality and API richness may differ by platform.

Examples of platform-specific extensions:

  • Access to hardware timestamp counters (Linux-capable NICs).
  • Adaptive sync intervals tuned to mobile/embedded systems (Android).
  • OS-specific drift compensation strategies.
  • High-precision timers available only on Unix-like systems.

4. Driver Configuration Variants

Some drivers expose additional configuration fields on certain platforms.

Examples:

INET4 driver

  • Linux: adjustable UDP buffer size, TTL hints, multicast modes.
  • Windows: automatic interface binding limitations.
  • Android: IPv4/IPv6 coexistence constraints.

Bluetooth driver

  • Android: rich discovery APIs, permissions handling.
  • Linux: BlueZ backend with service scanning.
  • Windows/macOS: often restricted or partially implemented.

5. Threading & Concurrency

Different platforms require different threading models:

Linux / macOS

  • Typically pthread-based.
  • High-resolution timers.
  • Strong event-loop integrations.

Windows

  • Threadpool API differences.
  • Different event loop semantics.
  • Potential differences in locking primitives.

Android (Java/Kotlin)

  • Integration with:
  • Handler threads
  • Executors
  • Coroutines (Kotlin)

Qt (C++)

  • Event loop separation between UI thread and SDK thread.
  • Signal/slot dispatch for callbacks.

Python

  • AsyncIO compatibility varies by transport.
  • GIL impacts threading behavior in wrappers.

6. Memory Model Differences

Some SDK operations may behave differently:

  • Alignment constraints (C++ native).
  • Buffer pinning for JNI (Java/Android).
  • Python object → C++ buffer mapping.
  • Zero-copy optimizations not available on some OSs.

7. Error Handling Extensions

While the error model is universal, the specific error types exposed by each platform may differ. Examples:

C++ (Linux/Windows/macOS)

  • Return codes vs. exceptions depend on wrapper configuration.
  • Extended driver error codes for unsupported features.

Python

  • Exception classes may group multiple C++ error states.
  • Some errors raised lazily due to async behavior.

Java/Android

  • Checked exceptions vs RuntimeException.
  • Java-specific error categories (I/O, security, lifecycle).

Qt

  • Error states may be propagated as signals (errorOccurred(…)).

8. Optional Capabilities

Some features are optional and only appear on capable platforms:

  • Advanced timing telemetry (Linux).
  • NIC-level diagnostics.
  • Bluetooth enriched discovery (Android).
  • Multi-channel broadcast optimization (Linux/Windows).
  • Hardware-timestamping for specific NICs.

These capabilities should be documented in their respective platform API pages but summarized here for cross-platform comparison.

You should consult this section when:

  • migrating an application from one platform/binding to another
  • identifying which features are portable and which are not
  • planning multi-platform deployments
  • designing an SDK wrapper for a new OS or runtime
  • preparing a compatibility matrix for a release

This page complements:

  • Common API Surface → the unified conceptual model
  • Platform SDK Guides → how to build/install/use per OS
  • Language Binding Guides → how to use Python/Qt/Java bindings
  • Platform/Binding-specific API Reference → detailed functions

10. Future Extensions

Planned additions:

  • Real compatibility matrix per version (e.g. DaaS-IoT SDK 0.20 vs 0.21)
  • Feature flags for optional SDK components
  • Automatically generated tables based on build metadata