Some phones have known problems with custom bluetooth stack implementation – check changelog for strings like those:
—-
1.12.80(16 Feb 2022)
* A bluetooth fix for some devices
—-
1.12.75(12 Feb 2022)
* Possible workaround for bluetooth bug on some handsets
—-
1.12.59 (5-Feb-2022)
* Fixes for bluetooth connection problems in Sony and OPPO handsets where the manufacturer broke bluetooth again.
—-
1.10.256 (7-Jan-2022)
* Found a bluetooth reliability issue with any device using a “Snapdragon 865” processor. Looks like a silicon issue
—
Maybe your first phone is one of those.

Also Android older than 4.2 is also known to have problems.

I tried to connect via WiFi adapter – the same problem.

Hi!

This means your adapter is returning incorrect information for values requested – this is due to the response from the adapter being malformed.

Many, *many* cheap ebay clone adapters have this issue and it is because the chip is a poor copy of an ELM327 which has bugs in protocols such as CAN and J1850 where received data is not parsed correctly by the adapter

This results in the message being returned to Torque being corrupted at the adapter side and the only fix for this is to get the adapter replaced

Torque is able to detect some of the corrupted frames being sent back, hence the message.

Other ebay adapters may have bugs in which make it take an age to connect to things like ISO9141 systems, but Torque will also detect the bad adapters in this instance too and warn

A good example of a faulty adapter can be seen when parsing the message responses in things like TorqueScan when using a CAN system – if your adapter is faulty you may see incorrectly sized frames (or frames with extra data in) – this isn’t a fault of the app, but is the adapter returning faulty information

Another (of many) issue on bad clones that when some requests are made (and in other cases when some messages are seen on the OBD bus greater than a certain size) that this also triggers a data corruption bug on the adapter chip.

Yet another issue is when you do or do not enable headers – ATH0 may work on some clones to get around *some* data corruption issues, but then in multi-ecu systems you dont know what ECU is sending what data. Headers turned on are needed for pretty much any modern vehicle now(modern being after 2007) as many have multiple ECUs that respond to functional (and in some cases multiple ECUs incorrectly respond to non functional addressing), so headers are needed.

Torque already tries to work around and ignore some bad adapter bugs, but in some instances it’s impossible to work around them all. You may only see some adapter issues when the adapter is parsing larger responses from the ECU (typically mode 21/22 or mode 05 frames).

The only other way to get this message is to deliberately send bad/corrupt data to the adapter in the manage extra PIDs part of the app, custom init string (and possibly using the OBD terminal via the TorqueScan plugin), though you would know that the data being sent is incorrect at this point

In the updates I managed to add some extra code that can better identify when the adapter is not doing what it should and this is now reported to the user that the adapter they have is probably a bad clone

In short/tldr; the clone adapters frequently found on eBay/Amazon are a mess, many of which do not work correctly, and the app was improved in recent updates to detect and report this better so at least you know the adapter has issues.