Commit 4e15c37c authored Apr 19, 2024 by Sal Savage

Don't replace an existing CoD with one that is unclassified

Inquiry results coming from BLE can have an inferred device class based
on the service uuids or appearence. When they can't determine the device
class through their inference rules, they return a default value of
0x001f00, or uncategorized. Without a check, we end up replacing a valid
CoD with this invalid one. This can happen very easily with dual mode
devices while we're discovering. This causes the class of device to
change in Settings from the real value, to the Setting's default of
"headset."

Bug: 311456944
Bug: 335909751
Test: m com.android.btservices
Test: Pair an iOS device. Become discoverable again briefly and check
the device details icon.

Change-Id: If5fa38103a498dff491cffd27cd3094d17f973e6

parent 51a837e3

system/btif/src/btif_dm.cc

+12 −0

Original line number	Diff line number	Diff line
		@@ -1522,7 +1522,19 @@ static void btif_dm_search_devices_evt(tBTA_DM_SEARCH_EVT event,
		uint32_t cod = devclass2uint(p_search_data->inq_res.dev_class);

		if (cod != 0) {
		/* Use the existing class of device when the one reported from inquiry
		is unclassified. Inquiry results coming from BLE can have an
		inferred device class based on the service uuids or appearence. We
		don't want this to replace the existing value below when we call
		btif_storage_add_remote_device */
		uint32_t old_cod = get_cod(&bdaddr);
		if (IS_FLAG_ENABLED(
		do_not_replace_existing_cod_with_uncategorized_cod)) {
		if (cod == COD_UNCLASSIFIED && old_cod != 0) {
		cod = old_cod;
		}
		}

		if (old_cod != cod)
		log::info("{} CoD: 0x{:06x} -> 0x{:06x}",
		ADDRESS_TO_LOGGABLE_CSTR(bdaddr), old_cod, cod);