Calls aren't routing back to earpiece once BT device (ie vehicle) disconnects [192585637]

Fixed

Bug

Platform

Status Update

No update yet.

Description

bn...@google.com

created issue #1

Jul 1, 2021 07:52PM

Public bug for 192338874

Calls aren't routing back to earpiece once BT device (ie vehicle) disconnects

- Build Number: google/coral/coral:S/SPB2.210513.011/7465093:user/release-keys
(Note: It is the build when sending this report. For exact build reference, please see the attached bugreport.)

What type of Android issue is this? Bluetooth

What steps would let us observe this issue?
1. Connect phone to Bluetooth 2019 Chevy Silverado
2. Make a call
3. From the truck, press handset to disconnect from Bluetooth speakers. Or from the phone, choose phone, instead of Bluetooth for audio
4. Call will continue, but sound does not come through the phone unless you turn Bluetooth off altogether.

What did you expect to happen?
Call audio should be routed to phone once disconnected from Bluetooth

What actually happened?
The call continued but the audio was no longer in the vehicle or on the phone.

How often has this happened?
Every time

What was the effect of this issue on your device usage, such as lost time or work?
High

Additional comments
Thank you all for your hard work.

Comments

bn...@google.com <bn...@google.com> Jul 1, 2021 07:52PM

Assigned to am...@google.com.

df...@gmail.com <df...@gmail.com> #2Jul 7, 2021 09:25PM

Hello there!

If I understand this request correctly, you'd like an API to retrieve all the existing products and SKUs, like the list provided here?

Can you provide more details on the workflow you have in mind and the potential usefulness of this feature?

What impact (in terms of costs, productivity, etc.) could this feature have?
What workaround (if any) are you currently using?

Kind regards.

dh...@gmail.com <dh...@gmail.com> #3Jul 12, 2021 08:47AM

Today, we are importing users from Google into Okta. We include their license information and match against a static list we have defined (based on that API list). If a new license or SKU is added on the Google side, we won’t be able to link this to the user until we’ve made a code change to add the new item to the list. We usually discover the list needs to be updated when the customer complains as we aren’t aware of changes on the Google side. When we are provisioning users, we are unable to assign them the new SKUs and have sometimes removed their Google access because of this.

The other problem comes from updating the license list on our side. Since we can’t query an API, we risk human error when manually updating the list and deploying it to customers. If someone makes a mistake, it can corrupt the whole license and SKU list for customers, which will remove all of their Google licenses.

mi...@gmail.com <mi...@gmail.com> #4Jul 15, 2021 01:09PM

In that case, can't you update the license list programmatically when a user with a new license is imported?

gw...@gmail.com <gw...@gmail.com> #5Jul 19, 2021 10:58PM

No because the list is stored as a custom template on our side, so we don't have the ability to change it during import. It's the shared list for all customers.

am...@google.com <am...@google.com> #6Jul 23, 2021 03:51PM

Marked as fixed.

Hi!

We have to make numerous calls to get this information, which counts against our quota.

Can you provide more details about this? How are you getting this information?

No because the list is stored as a custom template on our side, so we don't have the ability to change it during import.

I understand it's not feasible to update the custom template on your side during the import process?

sy...@gmail.com <sy...@gmail.com> #7Sep 13, 2021 06:58AM

Hi,

1) Sorry, this part wasn't linked to building the list but rather getting the user setup with their license information. Right now, we get the license list from the link or from when customers complain.