# polar-ble-sdk: streaming heart rate and ECG from Polar devices over Bluetooth LE

> The Polar BLE SDK is the official Android and iOS SDK for Polar sensors and watches, covering Bluetooth LE connection, real-time heart rate, ECG, accelerometer and PPG data from a listed set of devices. It suits app developers building on Polar hardware, and it is licensed under a custom Polar SDK licence rather than an open source licence.

**polarofficial/polar-ble-sdk** — Repository includes SDK and code examples. More info https://polar.com/en/developers

- Repository: https://github.com/polarofficial/polar-ble-sdk
- Stars: 758 · Forks: 250
- Language: Swift
- License: NOASSERTION
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/polarofficial-polar-ble-sdk

## One SDK for two mobile platforms, with the code split by language

The Polar BLE SDK is the official SDK for Polar sensors and watches on Android and iOS. The repository description says what it is for in one line: build apps that connect via Bluetooth LE and stream real-time heart rate, ECG, accelerometer, PPG and more from Polar devices.

The layout makes the two-platform split explicit. The top-level entries include sources/ for the SDK source code on Android and iOS, examples/ with an example-android and an example-ios project, demos/ which contains an Android ECG demo application, documentation/ for SDK documentation and product guides, technical_documentation/ for specs and diagrams, and docs/ for generated API documentation. A Package.swift file sits at the top level for Swift Package Manager, and PolarBleSdk.podspec covers the CocoaPods route, so the iOS side has two distribution mechanisms and the Android side has one.

The generated API reference is published for both platforms, with separate Android and iOS documentation sites under the polarofficial.github.io domain, and a jitpack.yml at the root is what makes the Android dependency resolvable.

The project is not a hobby library. It is the vendor's own SDK, which means the device behaviour, the GATT layout and the data formats come from the same organisation that makes the sensors.

## The supported device list is per product, and that list is the contract

Rather than a vague compatibility claim, the documentation carries a table of supported products, each with its own guide file: Polar 360 and Polar Loop, the Polar H10, the Polar H9, the Polar Verity Sense, the Polar OH1, the Polar Ignite 3, the Polar Vantage V3 and M3 with the Grit X2 Pro and Grit X2, and the Polar Pacer and Pacer Pro. For the watches there is a separate document, UsingSDKWithWatches.md, for watch-specific guidance.

The pattern here is that the SDK is not a generic BLE client. A Polar device exposes different characteristics, and a heart rate stream is a different protocol from an ECG stream, which is different again from the accelerometer. Reading the per-product guide before writing code is not optional reading, it is the first step, because what a device can deliver is a property of that device.

The topic set in the repository includes offline recording, and there is a dedicated guide for it, plus a guide explaining SDK Mode and one for the time system, which matters because sensor data has to be timestamped consistently. There are also guides for first time use and device setup, for firmware updates, for PPI data, and a sync implementation guideline, which is the piece you need if your app is expected to move data to a server.

## Android install is minSdk 33, a JitPack repository and one dependency line

The Android getting started section is specific about the setup. First, the build file needs a minimum SDK level of 33 or higher:

```gradle
android {
    ...
    defaultConfig {
        ...
        minSdk 33
    }
}
```

Second, the JitPack repository has to be added to the repositories settings:

```gradle
   ...
    repositories {
        ...
        maven { url 'https://jitpack.io' }
        ...
    }
}
```

Third, the dependency itself, with the version left as a variable to fill in:

```gradle
dependencies {
    implementation 'com.github.polarofficial:polar-ble-sdk:${sdk_version}'
}
```

The coordinate is a JitPack path, github.com.polarofficial with the repository name, which is why the jitpack.yml file at the root is not optional decoration: it tells JitPack how to build the artifact for consumers.

The documentation then says to start the application in that directory. For the iOS side, the quickstart section in the repository covers Android explicitly, and the Swift Package Manager manifest and the podspec are the two integration routes the tree shows for Apple platforms. The API reference links for iOS and Android point at the same repository's documentation site, so the two platforms are documented in parallel rather than one being an afterthought.

## Bluetooth permissions are the hard part of the Android setup

The manifest section is longer than the dependency section, and that reflects reality. The SDK needs Bluetooth scan permission to search for BLE devices, and it does not use the scan to determine location, so the neverForLocation flag can be used. It needs Bluetooth connect permission for the devices it finds.

Then there is the legacy layer. For devices on API 30 or older, the legacy BLUETOOTH and BLUETOOTH_ADMIN permissions are needed to connect to paired devices and to discover and pair them. On those same older devices, the SDK needs fine location permission for the Bluetooth scan to return results, and coarse location permission is required as well if fine location is requested. The comment in the manifest is explicit that a fine location permission request on API 30 needs the coarse one too, and that an app needing location for other purposes should remove the android:maxSdkVersion="30" limit on the fine location entry.

The manifest block also requests INTERNET permission, with a comment saying the SDK needs it to check and download firmware updates. That is a detail worth noticing: the SDK reaches out to the network for firmware, which is a behaviour your privacy review will want to see justified.

The runtime request follows the same version logic, branching on Build.VERSION.SDK_INT for Q, for S and above, and for anything older.

## Runtime permission requests branch on the Android version

Declaring permissions in the manifest is only half of the work on Android, and the documentation shows the runtime half. The request logic branches on the API level, because the permission model changed twice:

```kt
    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.Q) {
        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.S) {
            requestPermissions(arrayOf(Manifest.permission.BLUETOOTH_SCAN, Manifest.permission.BLUETOOTH_CONNECT), PERMISSION_REQUEST_CODE)
        } else {
            requestPermissions(arrayOf(Manifest.permission.ACCESS_FINE_LOCATION), PERMISSION_REQUEST_CODE)
        }
    } else {
        requestPermissions(arrayOf(Manifest.permission.ACCESS_COARSE_LOCATION), PERMISSION_REQUEST_CODE)
    }
```

On Android 12 and above, the app asks for the two Bluetooth permissions together. On Android 10, which is API 29 and the Q branch, it asks for fine location, because that is what the scan needs on that release. Below that, coarse location is what gets requested.

This branching is not incidental detail, it is the shape of the whole integration. A device that supports the current Bluetooth permission model and a device stuck on an older one need different manifests and different runtime flows, and an app that supports both has to carry both code paths.

The code example section points at the examples/example-android folder for a full project, and the heart rate walkthrough is presented as the key things to look at, so the repository does carry runnable sample code rather than fragments.

## A custom Polar licence, a version policy, and a third party listing

This is not an open source licence in the usual sense, and that is the first thing to settle before you build on it. The repository is licensed under a custom licence that GitHub cannot classify, and the terms live in Polar_SDK_License.txt at the root. There is a ThirdPartySoftwareListing.txt next to it, and the README has a section on third party code and licences, which tells you the vendored components are tracked but does not reproduce the terms in the readme itself. Whether your organisation can ship an app built with it is a question for whoever reads that file, not for this article.

Two governance documents are worth reading before you integrate. SDK-VERSIONING-POLICY.md describes how the SDK version changes, and the recent release history shows the version climbing steadily: 8.2.0 on 2026-08-18, 8.3.0 on 2026-09-09, and 8.4.0 on 2026-10-01. A minor version bump every few weeks is a fast-moving dependency, and the versioning policy is the document that tells you what a bump means for your build. The repository also carries an AGENTS.md and a CODEOWNERS-style collaboration section in the readme, and the readme has its own sections for collaboration, troubleshooting and known issues.

The last push was on 2026-10-01, the same day as the 8.4.0 release, so the repository is current rather than abandoned.

## Where the SDK is the wrong tool

The clearest case against it is a device that is not in the table. The supported products list is a closed set of Polar hardware, and a competitor sensor, or a newer Polar model that has not been added, will not work with this SDK. A team whose fleet of devices is mixed across vendors needs a different approach, and the per-product structure of the documentation means there is no generic BLE layer to fall back on.

The second case is a product that does not need the hardware. If a wearable app is mostly about the phone, the SDK brings a Bluetooth permission model, a vendor version policy, a custom licence and a native dependency to a project that may not need any of it. The offline recording and sync guidelines are also substantial machinery, and a team with no interest in on-device recording has no use for them.

The third limit is the platform floor. The Android path requires minSdk 33, which is a real constraint on the device population your app can still reach, and the iOS path is not detailed in the repository's quickstart beyond the Package.swift manifest and the podspec, so an iOS-only team will spend more time in the API reference and the example-ios project than the readme suggests.

One more practical limit: the documentation is organised around Polar's own product line and the SDK's own release cycle. There is no compatibility matrix for older Android or iOS versions of the SDK, and the troubleshooting material is described in the readme's contents but not reproduced in it, so a support question during integration means going to the documentation site rather than searching the repository.

## Conclusion

polar-ble-sdk is the right dependency for an app team that has to read heart rate, ECG or accelerometer data from Polar hardware, because it is the vendor's own SDK, the supported device list is spelled out per product, and the Android side installs from JitPack with a single dependency line. It is the wrong choice for a team that wants a permissive open source licence, because the repository ships Polar_SDK_License.txt and a separate third party software listing rather than an MIT or Apache grant, and the README does not summarise the terms. Before you adopt it, check the three things that decide the outcome: whether your specific device appears in the supported products table, since the SDK covers a listed set of Polar 360, Loop, H10, H9, Verity Sense, OH1, Ignite 3, Vantage V3, M3, Grit X2 Pro, Grit X2, Pacer and Pacer Pro; whether the platform you target is the one you have, since the quickstart in the documentation covers Android only, with the iOS path handled by Package.swift and the podspec; and the minimum OS level, since the Android setup requires minSdk 33 or higher.

## FAQ

### How do I add the Polar BLE SDK to an Android project?

Set minSdk to 33 or higher in build.gradle, add the JitPack repository with maven { url 'https://jitpack.io' }, and add the dependency implementation 'com.github.polarofficial:polar-ble-sdk:${sdk_version}'. The AndroidManifest.xml also needs the Bluetooth scan, connect, legacy Bluetooth, location and INTERNET permissions.

### Which Polar devices does the Polar BLE SDK support?

The supported products table covers Polar 360 and Polar Loop, the H10 and H9, the Verity Sense, the OH1, the Ignite 3, the Vantage V3 and M3 with the Grit X2 Pro and Grit X2, and the Pacer and Pacer Pro. Each product has its own guide file under documentation/products, and watches have a separate UsingSDKWithWatches.md guide.

### Is the Polar BLE SDK open source?

It is distributed under a custom Polar SDK licence held in Polar_SDK_License.txt at the repository root, which GitHub cannot classify, alongside a ThirdPartySoftwareListing.txt for the bundled third party code. The repository also publishes SDK-VERSIONING-POLICY.md, and the version history shows 8.2.0, 8.3.0 and 8.4.0 released between 2026-08-18 and 2026-10-01.

## Sources

- [Issues](https://github.com/polarofficial/polar-ble-sdk/issues)
- [polarofficial/polar-ble-sdk on GitHub](https://github.com/polarofficial/polar-ble-sdk)
- [README](https://github.com/polarofficial/polar-ble-sdk/blob/master/README.md)
- [Releases](https://github.com/polarofficial/polar-ble-sdk/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/polarofficial-polar-ble-sdk