Discrepancy in Manufacturer Data Handling Between iOS and Android

[GabrieleMazzola]

Before open an issue

• I have checked the closed issues and haven’t found a similar one.
• I understand that hardware issues cannot be debugged here.
• I have verified my code, installation, and phone permissions. The library is working but there is an inconsistent behavior between iOS and Android.

---

Describe the bug

I’m seeing a discrepancy in how manufacturer data is reported by react-native-ble-manager on iOS vs. Android when the peripheral includes two separate manufacturer data fields (one in the advertising packet and one in the scan response), both using the same company ID.

• On iOS, the manufacturer data is merged (concatenated) from both advertising and scan response.
• On Android, only the scan response portion is exposed (the advertising portion gets overwritten/ignored).

This makes it difficult to build consistent cross-platform logic in our app that relies on manufacturer data bytes.

---

To Reproduce

1. Set up a BLE peripheral that advertises two manufacturer data fields under the same company ID 0xAABB:

   • Advertising Packet (in my case):

     FF BB AA 01 02 03 04 (FF for manufacturerData, '01 02 03 04' is the payload)
     

   • Scan Response (in my case):

     FF BB AA 05 06 07 08 (FF for manufacturerData, '05 06 07 08' is the payload)
     

2. Use react-native-ble-manager (for example, the library’s example app).

3. Log the manufacturer data from the discovered peripheral on both iOS and Android. In my case, I simply changed the renderItem function (of the example app in this repo) to log the platform, manufacturerRawData and rawData:

const renderItem = ({ item }: { item: Peripheral }) => {

    const bytesToHexString = (bytes: number[] | undefined) => {
      if (!bytes) return '';
      return bytes.map(byte => byte.toString(16).padStart(2, '0')).join('');
    };

    console.log(`
        ${Platform.OS} - Manufacturer Data: ${bytesToHexString(item.advertising.manufacturerRawData?.bytes)}
      ${Platform.OS} - Raw Data: ${bytesToHexString(item.advertising.rawData?.bytes)}`);

    const backgroundColor = item.connected ? '#069400' : Colors.white;
    return (
      <TouchableHighlight
        underlayColor="#0082FC"
        onPress={() => togglePeripheralConnection(item)}
      >
        <View style={[styles.row, { backgroundColor }]}>
          <Text style={styles.peripheralName}>
            {/* completeLocalName (item.name) & shortAdvertisingName (advertising.localName) may not always be the same */}
            {item.name} - {item?.advertising?.localName}
            {item.connecting && ' - Connecting...'}
          </Text>
          <Text style={styles.rssi}>RSSI: {item.rssi}</Text>
          <Text style={styles.peripheralId}>{item.id}</Text>
        </View>
      </TouchableHighlight>
    );
  };

5. Observe:

   • iOS merges the adv + scan response manufacturer data into one long chunk.
   • Android only shows the scan response portion (the adv data is replaced).

---

Expected behavior

I would expect either:

1. Both platforms to present the same final manufacturer data (whether merged or overwritten),
2. OR an explicit way to differentiate “advertising” vs. “scan response” data so I can handle them consistently in my app.

Currently, the difference causes confusion and complicates cross-platform development.

---

Screenshots

The entire raw data was logged on Android (not available on iOS) with item.advertising.rawData?.bytes and converted to hex:

0201060f0941415f393039383736353433323307ffbbaa0102030407ffbbaa05060708000000000000000000000000000000000000000000000000000000

As you can see, the raw data on Android has both the initial adv payload:

ffbbaa01020304

and the scan response

ffbbaa05060708

iOS (Logged in the example app)

Used item.advertising.manufacturerRawData?.bytes and converted to hex.

bbaa0102030405060708

Splitting it out:

• bb aa – Company ID (0xAABB, reversed on-air)
• 01 02 03 04 – Advertising packet data
• 05 06 07 08 – Scan response data

iOS concatenates the advertising and scan response manufacturer data for the same Company ID.

Android (Logged in the example app)

Used item.advertising.manufacturerRawData?.bytes and converted to hex.

0000aabb05060708

Splitting it out:

• 00 00 aa bb – Company ID (not sure why zero-padded)
• 05 06 07 08 – Scan response data

The advertising data chunk (05 06 07 08) related to the manufacturer data is missing on Android because it’s overwritten by the scan response for the same Company ID.

---

Smartphone

• Device: iPhone 14 Pro, Xiaomi Mi11i
• OS: iOS 18.1.1, Android 13
• react-native-ble-manager version: 12.1.2
• react-native version: example app of this library

---

Additional context

• The usecase of having multiple manufacturerData with the same Company ID is useful when the custom data that needs to be sent from the peripheral is larger than what fits into the advertising packet. In this case, the scan response can be used to send longer payloads.
• This issue arises from differences in how the iOS BLE stack merges adv + scan response data and how Android overwrites it.
• Ideally, react-native-ble-manager could unify or provide an API to handle these data collisions consistently.
• Thank you for this library and for any guidance on handling this scenario!

P.S. I have a patch locally that addresses this issue, but I am not sure it's the best way yet. Will keep working on it and create a PR soon, any help from the maintainers is welcome, as I have not worked on native Android code before.

[GabrieleMazzola]

It seems that the Bluetooth specifications for this use case are unclear. While the spec defines how advertising and scan response data should be transmitted over the air, it does not mandate how platforms should handle or expose this data to applications when the same AD type (e.g., Manufacturer Data) is present in both packets.

That said, my goal is to focus on having consistent behavior across platforms, as this would greatly simplify cross-platform app development.

Since iOS is already merging the advertising and scan response manufacturer data for us (and we don’t have access to the raw advertising or scan response packets at the app level), the practical solution would likely involve adapting Android’s behavior to match iOS’s: when structuring the output on Android, we could concatenate the manufacturer data from the advertising packet and scan response if they share the same Company ID, just like iOS does.

This would provide a unified, consistent output across platforms without introducing discrepancies for the same BLE peripheral.

Thank you for considering this!

[GabrieleMazzola]

Hoping to add additional useful information, I am attaching here the results of scanning with nRFConnect the peripheral (on iOS and Android).

Android

As you can see, two manufacturerData are available, with both payloads.

iOS

As you can see, only one manufacturerData is available, with one single, concatenated payload.

[marcosinigaglia]

Hi @GabrieleMazzola , are you sure it is not some problem with the BLE device? I have never seen such behaviour and the payload does not seem that big.

[GabrieleMazzola]

Hi @marcosinigaglia, thanks for answering. What do you mean with "the payload does not seem that big"? I believe size is not the issue here, but rather the fact that the native Android API (advertisingData.getManufacturerSpecificData()) to get the specific manufacturer data overrides the manufacturerData with the scan response.

In fact, if I patch the library with this, I get the exact same output on iOS and Android:

diff --git a/android/src/main/java/it/innove/DefaultPeripheral.java b/android/src/main/java/it/innove/DefaultPeripheral.java
index c154a36476a1edb46ec0f7240b0fcd08168a63c3..b1b5dee4fb046bba31a7ffa823f13bb2882b786b 100644
--- a/android/src/main/java/it/innove/DefaultPeripheral.java
+++ b/android/src/main/java/it/innove/DefaultPeripheral.java
@@ -17,7 +17,6 @@ import com.facebook.react.bridge.WritableMap;
 import java.nio.ByteBuffer;
 import java.util.Map;
 
-
 @SuppressLint("MissingPermission")
 public class DefaultPeripheral extends Peripheral {
 
@@ -73,29 +72,66 @@ public class DefaultPeripheral extends Peripheral {
                 if (advertisingData.getServiceData() != null) {
                     for (Map.Entry<ParcelUuid, byte[]> entry : advertisingData.getServiceData().entrySet()) {
                         if (entry.getValue() != null) {
-                            serviceData.putMap(UUIDHelper.uuidToString((entry.getKey()).getUuid()), byteArrayToWritableMap(entry.getValue()));
+                            serviceData.putMap(UUIDHelper.uuidToString((entry.getKey()).getUuid()),
+                                    byteArrayToWritableMap(entry.getValue()));
                         }
                     }
                 }
                 advertising.putMap("serviceData", serviceData);
 
                 WritableMap manufacturerData = Arguments.createMap();
-                SparseArray<byte[]> manufacturerRawData = advertisingData.getManufacturerSpecificData();
-                byte[] manufacturerRawBytes = new byte[0];
-                if (manufacturerRawData != null && manufacturerRawData.size() > 0) {
-                    int key = manufacturerRawData.keyAt(0);
-                    byte[] data = manufacturerRawData.valueAt(0);
-                    manufacturerData.putMap(String.format("%04x", key), byteArrayToWritableMap(data));
-
-                    ByteBuffer keyBuffer = ByteBuffer.allocate(Integer.SIZE / Byte.SIZE);
-                    keyBuffer.putInt(key);
-                    byte[] keyBytes = keyBuffer.array();
-                    manufacturerRawBytes = new byte[keyBytes.length + data.length];
-                    System.arraycopy(keyBytes, 0, manufacturerRawBytes, 0, keyBytes.length);
-                    System.arraycopy(data, 0, manufacturerRawBytes, keyBytes.length, data.length);
+                byte[] combinedManufacturerData = null;
+
+                // We must use raw bytes because getManufacturerSpecificData() doesn't give us
+                // all segments.
+                int index = 0;
+                while (index < advertisingDataBytes.length) {
+                    int length = advertisingDataBytes[index] & 0xFF;
+                    if (length == 0 || index + length + 1 > advertisingDataBytes.length)
+                        break;
+
+                    int type = advertisingDataBytes[index + 1] & 0xFF;
+                    if (type == 0xFF && length > 3) {
+                        try {
+                            // Get manufacturer ID (2 bytes, little-endian)
+                            int manufacturerId = ((advertisingDataBytes[index + 3] & 0xFF) << 8)
+                                    | (advertisingDataBytes[index + 2] & 0xFF);
+                            byte[] data = new byte[length - 3];
+                            System.arraycopy(advertisingDataBytes, index + 4, data, 0, length - 3);
+
+                            // Create 2-byte manufacturer ID for raw data
+                            byte[] keyBytes = new byte[] { advertisingDataBytes[index + 2],
+                                    advertisingDataBytes[index + 3] };
+
+                            // Handle first and subsequent segments
+                            if (combinedManufacturerData == null) {
+                                combinedManufacturerData = new byte[keyBytes.length + data.length];
+                                System.arraycopy(keyBytes, 0, combinedManufacturerData, 0, keyBytes.length);
+                                System.arraycopy(data, 0, combinedManufacturerData, keyBytes.length, data.length);
+                            } else {
+                                byte[] newCombined = new byte[combinedManufacturerData.length + data.length];
+                                System.arraycopy(combinedManufacturerData, 0, newCombined, 0,
+                                        combinedManufacturerData.length);
+                                System.arraycopy(data, 0, newCombined, combinedManufacturerData.length, data.length);
+                                combinedManufacturerData = newCombined;
+                            }
+
+                            WritableMap dataMap = Arguments.createMap();
+                            WritableArray dataArray = Arguments.createArray();
+                            for (byte b : data) {
+                                dataArray.pushInt(b & 0xFF);
+                            }
+                            dataMap.putArray("bytes", dataArray);
+                            manufacturerData.putMap(String.format("%04x", manufacturerId), dataMap);
+                        } catch (Exception e) {
+                            // Skip this segment if there's an error
+                        }
+                    }
+                    index += length + 1;
                 }
+
                 advertising.putMap("manufacturerData", manufacturerData);
-                advertising.putMap("manufacturerRawData", byteArrayToWritableMap(manufacturerRawBytes));
+                advertising.putMap("manufacturerRawData", byteArrayToWritableMap(combinedManufacturerData));
 
                 advertising.putInt("txPowerLevel", advertisingData.getTxPowerLevel());
             }

[marcosinigaglia]

Hi @GabrieleMazzola , sorry, I hadn't read it right and I thought the manufacturerData was split into two because of the length. I will try to see if I can simulate this but it is not a behaviour I have seen before, if you want in the meantime you can create the PR with your solution.

[GabrieleMazzola]

Hey @marcosinigaglia, sorry but I haven't managed to find the time to open a PR, I will try to do so in the coming week. Have you by any change managed to simulate this behaviour?

[marcosinigaglia]

Hi @GabrieleMazzola , with my development kit I'm unable to simulate the behaviour, I can only set the advertising's manufacturer data.

[GabrieleMazzola]

Ah I see, you mean you can't really put the manufacturer data both in the advertising data as well as in the scan response?

[marcosinigaglia]

The documentation is not clear but I think what I am going to set is the advertising date of the scan response. So I think your case is rare. Is it a custom ble device?

[GabrieleMazzola]

Correct, it's a custom ble device that we are creating together with another company specializing in embedded development.

[aharta2001]

Hi @marcosinigaglia ,

I’ve been running some rigorous tests on iOS and noticed an inconsistency in the BLE advertisement data when scanning the same device multiple times. Sometimes I receive the manufacturerRawData, and other times it’s completely missing, even though the device itself and its signal (rssi) remain the same.

Here are two console logs captured for the same BLE device:

Object 1 :
{
"advertising": {
"isConnectable": 1,
"kCBAdvDataRxPrimaryPHY": 129,
"kCBAdvDataRxSecondaryPHY": 0,
"kCBAdvDataTimestamp": 771759696.890295,
"localName": "GBS-2012-B",
"serviceUUIDs": ["a602"]
},
"id": "4161bad4-d0d7-65a6-dc28-380c6f13f18a",
"name": "GBS-2012-B",
"rssi": -62
}

Object 2:
{
"advertising": {
"localName": "GBS-2012-B",
"kCBAdvDataTimestamp": 771759357.295839,
"manufacturerRawData": {
"data": "EjRWeAEIuNC1/Fs=",
"bytes": [18, 52, 86, 120, 1, 8, 184, 208, 181, 252, 91],
"CDVType": "ArrayBuffer"
},
"isConnectable": 1,
"manufacturerData": {
"3412": {
"data": "VngBCLjQtfxb",
"bytes": [86, 120, 1, 8, 184, 208, 181, 252, 91],
"CDVType": "ArrayBuffer"
}
},
"kCBAdvDataRxSecondaryPHY": 0,
"kCBAdvDataRxPrimaryPHY": 129,
"serviceUUIDs": ["a602"]
},
"id": "4161bad4-d0d7-65a6-dc28-380c6f13f18a",
"name": "GBS-2012-B",
"rssi": -65
}

As you can see, Object 1 is missing the manufacturerRawData, while Object 2 contains it.

➡️ Issue: This inconsistency makes it challenging to rely on the manufacturer data for device identification or processing logic.

Is this a limitation or known behavior with iOS BLE scanning? Or could this be related to how the react-native-ble-manager processes advertising packets internally on iOS?

Any insights, suggestions, or workarounds would be greatly appreciated.

Thanks for your time and support!

[marcosinigaglia]

@aharta2001 problably is how your device advertise.