Company Bluetooth device is discoverable on a colleague's phone but not on my new phone — what should I check first?

Conclusion first: When an app connects to a company-developed Bluetooth device, and a colleague's phone can discover it but your new phone cannot, it is usually not because the device is broken or the phone brand is poor. Rather, one of four layers is misaligned: permission declarations, scan method, broadcast and protocol format, and vendor background policies. Based on 2026 mobile delivery experience, locating the layer first before changing code is more effective than repeatedly swapping test phones; switching phones only verifies whether the issue is model-related and cannot solve permission and protocol-layer problems.

Check by the four layers first; don't rush to switch phones

Bluetooth link failures are naturally layered: if the system has not granted permission, the scan code will not execute at all; if the scan filter is wrong, the device will not appear in the list even if its name is correct; if the connection succeeds but notifications are not subscribed, the UI may show "connected" while data never arrives. The point of layered troubleshooting is that each layer has phenomena you can observe separately, which avoids changing one line of code and hoping for the best.

1. Permission layer: Since Android 12, the "Nearby Devices" permission coexists with the older location permission, and iOS requires declaring Bluetooth usage in the project configuration; when permission is not granted, the scan API usually returns an empty list and does not throw an exception.
2. Scan layer: BLE scans often filter by service UUID or device name prefix, and hard-coded conditions can cause devices to be missed; Classic Bluetooth uses device discovery, which is not the same as BLE.
3. Connection and protocol layer: Pairing state, GATT services and characteristics, write type, notification subscription, and packet length negotiation — missing any one may allow a connection but no data.
4. System and environment layer: Vendor power-saving and background restrictions, system Bluetooth switch, whether the peripheral is already occupied by another phone, and whether the peripheral firmware is in discoverable mode.

The rule of thumb can be simplified to one sentence: Only when two devices of different brands and different major OS versions both cannot discover it is it worth suspecting the device side; if only one phone cannot discover it, first check that phone's permissions and switches.

Being discoverable does not mean it can connect; don't skip protocol and technology selection

Many projects treat a successful connection as the finish line, but pairing, connecting, and sending/receiving data are three different things. Pairing only establishes a trust relationship; connecting establishes the link; whether data can be sent and received also depends on whether services and characteristics match and whether notifications are subscribed successfully. On Android in particular, it is easy to see "connected" but fail to read values, usually because characteristic properties and implementation method were not confirmed.

A practical approach is to split the communication layer into five steps: discover services, match characteristics, subscribe to notifications, send/receive commands, and disconnect/reconnect — with logs at each step. Disconnect/reconnect is often overlooked: when users walk out of Bluetooth range and come back, the app needs to recover on its own; otherwise it will be perceived as intermittent.

• Services and characteristics: Must match the peripheral's real UUIDs; when documentation and firmware disagree, the peripheral is authoritative.
• Write type: Write with response and write without response have different timing requirements; sending commands back-to-back can cause packet loss.
• Notification subscription: Without subscription, data is not pushed proactively, and the UI may stay on "connected".
• Packet length and reconnection: Long commands need fragmentation or negotiation; for reconnection, use backoff retries and give users clear prompts.

Which Bluetooth mode to use is usually decided by the peripheral, not by the app alone. Based on common 2026 delivery situations, BLE is better for intermittent small data, while Classic Bluetooth is better for continuous transmission. Comparison checklist:

• Classic Bluetooth (including serial-port protocols): Suitable for continuous data streams such as printers and acquisition peripherals; platform support varies considerably, and some categories have peripheral certification requirements that need to be checked against official specifications.
• BLE: Suitable for low-power intermittent communication such as sensors, door locks, and badges; cross-platform implementation is relatively consistent but clearly affected by system background policies.
• Integration effort (experience range): When protocol documentation is complete, getting the core link working commonly takes 3–10 working days; when documentation is missing and packet capture reverse-engineering is needed, the timeline commonly doubles.
• Testing cost: Recommend covering at least two major OS versions, more than three brand models, and peripheral firmware versions; this part is often underestimated.

Delivery reality: only a manual, with the protocol table reverse-engineered

A common situation in projects: the client provides a Word manual with no GATT service table, the budget is planned for two weeks, and the hardware was built by a colleague from the previous generation. A more reliable approach is to first use the vendor's debugging tool or packet capture to confirm the real service UUIDs and command format, then send the reverse-engineered protocol table back to the client for written confirmation. The cost is two or three extra days in the confirmation step, but the benefit is not having to redo entire sections after writing according to the manual; based on experience range, rework in the communication layer usually costs more than upfront verification, because you have to rewrite command encapsulation and rerun compatibility tests. In similar peripheral integration projects, we usually list protocol table confirmation as a separate delivery milestone.

Pre-launch pass line and applicable boundaries

Acceptance criteria should be written as a checkable list, not just "it can connect". The pass line is roughly: stable device discovery on target models, automatic recovery after disconnection, understandable prompts on exceptions, and failure causes distinguishable in logs.

• Can stably discover and connect to the target peripheral on two major OS versions and more than three brand models.
• Can recover in all three cases: disconnect/reconnect, leaving range and returning, and turning system Bluetooth off and back on.
• When permission is denied, there is clear guidance rather than silent failure.
• Key steps have logs that distinguish permission issues, timeout issues, or data format issues.
• Protocol tables, UUID lists, and command descriptions are delivered with the source code to avoid guessing after a team change.

When direct Bluetooth is suitable: the peripheral is enterprise-owned or the model can be specified, the business strongly depends on real-time acquisition and control, and firmware and protocol documentation can be required. When Bluetooth is not suitable or unnecessary: the peripheral vendor already provides a cloud API and data can tolerate delayed reporting; user device models are highly fragmented and firmware versions cannot be constrained; or the feature only replaces one manual input. Boundary statement: If the peripheral vendor already provides a cloud API, direct Bluetooth from the app is generally optional rather than mandatory; going through the server side commonly saves a significant portion of compatibility and permission-related work (experience range).

FAQ

On Android 12 and above, if the app cannot scan Bluetooth devices, what should I check first?

First check whether the Nearby Devices permission is declared and requested at runtime; then check the system Bluetooth and location switches. If both are fine, suspect that the scan filter conditions are wrong.

The peripheral is already paired, but the app still cannot connect — is that normal?

It is a common phenomenon. Pairing only establishes a trust relationship and does not mean the channel is usable; you still need to check the service UUIDs, characteristic properties, and whether notifications are subscribed successfully.

With the same app, iPhone can connect but Android cannot — which side is usually the problem?

Most often it is a difference in implementation between the two platforms, or the peripheral only supports a single connection. First rule out the peripheral being occupied by a previous phone, then compare permissions and UUID configuration on both sides.

How long does Bluetooth integration usually take, and can we launch first and add it later?

When protocol documentation is complete, the core link commonly takes 3–10 working days; when documentation is missing and packet capture reverse-engineering is needed, it commonly doubles. Whether it can be added later depends on whether the peripheral is part of the core business flow.

If Bluetooth is only one optional path for hardware integration, first confirm whether the peripheral already has a cloud API, then decide whether to implement direct connection in the app. Scheduling permission verification, protocol table confirmation, and multi-model testing into the timeline can reduce post-launch rework. When hardware models are fragmented and firmware versions cannot be constrained, prioritize server-side integration or manual entry as alternatives.