Expose bthf

[Trevelopment]

You don't have to merge this I just wanted to show you what the baso of my madness consisted of. Nothing I did with the signal handlers or the bthf methods worked but I think its just because I didn't know how to use them correctly. so I went off on like 20 different branches off this commit but I'm getting rid of most of them because now they just look like a crazy person did them.

[Trevelopment]

I use many variations from this commit so I know that this compiles and runs well at this point
but I just took out all the override methods I wrote that didn't work as expected.

[lmagder]

I think you are the right track here for making the phone calls work correctly. This related to the input freezing issue which I think is very similar to the backup camera problems we had to work around.

Basically the car OS tracks input focus and video focus separately. There are a variety of surfaces available and video output for AA goes on the "TV_TOUCH_SURFACE" whereas the normal car UI is on "JCI_OPERA_PRIMARY". When the phone asks for video focus we tell the car to switch to the TV surface (via the SetRequiredSurfaces DBUS call) and start capturing input. However when the phone call happens (or backup camera too but different surface) the car switches back to the Opera surface but there is no event to tell us that, so the headunit code keeps handling input, which results in the car UI not working. Pressing "Home" gives up input and video focus so that's why it makes the UI work again.

So it seems like there a few options here:

1. Find a way get the car to not switch the surface. This way you can interact with the AA-based call UI. I think this is the ideal use case, but may be impossible
2. Find out somehow when the switch has happened. It seems like the BTHF DBus service is a good candidate (I think this where you were going with this PR right?). At this point we could either switch the surface back which would allow the AA UI, at the cost of an ugly flicker or give up input focus so the car UI works and then when the call is done switch back to AA.

So it seems like the CallStatus signal there is a good place to start but I'm not sure if has the right statues or even what the status codes are.

[Trevelopment]

moved this to VideoManagerClient to use the bthfstate signal to keep video focus #79

[Trevelopment]

I started to attempt option 2 before I saw this but all it does right now is log some return values of CallStatus like bthfstate at certain points so I can look at the logs. I've been brushing up on my C++ skills and I am just learning the difference between a &reference and a *pointer, ha.

Anyways bthfstate is all we need for a trigger it goes like this:

• bthfstate === 0 //no call status
• bthfstate !== 0 //in call (or other call status ie. incoming)
  so I am going to use bool inActiveCall = (bool)bthfstate

So if I remember my C++ correctly that will always be false when 0 and true when something else so that is the trigger.
Now can I use that to ask for video focus? Or suppress the videoFocusRequest as in your ideal choice? That is what I was trying to do so I am testing some logging stuff and I moved the object instance of BTHF to the videoManager so that I could try that. Going to test soon.

[Trevelopment]

OMG I just now understand how protobuf works hahahaha.

[Trevelopment]

I was toying with something in the JavaScript code, overwriting the framework._contextChange function because that is what it looks like is firing to take he focus away by automatically switching to the phone context. The thing I'm having a little trouble with is a conditional to tell that we are using AA and TV_TOUCH_SURFACE is the main screen. I tried if(framework._visibleSurfaces.indexOf("TV_TOUCH_SURFACE") !== -1) but once you open AA then that surface stays in the array so like if you exit out of the AA screen that will still be true. but if I do framework.getCurrentApp() === '_androdauto' That only works if you open AA from the applications menu. So you may know this, is whatever surface is the most forward layer framework._visibleSurfaces[0]? because that would just be too convenient. What is the best way in the JavaScript to tell that we are currently on the TV_TOUCH_SURFACE and using AA? Or we could continue down the BTHF signal route and we will probably eventually need to add some call handling to the C++ anyways. I am just trying some different angles and since I claim to be an expert at JavaScript it might be a good route because we are just trying to do this:

• if we are on TV_TOUCH_SURFACE
• suppress framework._contectChange() from changing context
• only if called by the phoneApp
• with something simple like if (uiaId === 'phone') return;

So now we have a few angles to try.
BTW, did you know that I'm the developer of AIO? I wrote that app with electron and it is like 95% JavaScript (Node and Angular).

EDIT: So this works perfectly in my emulator https://mzd.mazdatweaks.win but not in the actual car for some reason it seems like the JavaScript is not working at all which is so strange it should at least do something. But this is leading me to believe its going to have to be a native code fix within headunit that handles this.
Also I get a black screen sometimes usually when I exit AA and try to reopen it. So someone told me put the car in and out of reverse to fix it and sometimes it does.

[Trevelopment]

@lmagder Hey so I don't really know how to do this but the HU is sending a 32769 message over channel 8 the BT channel so that may help us take control of the video by controlling the audio, get me? or at least it might make it run smoother, here is the error:
/home/mazda/headunit/hu/hu_aap.cpp:922: iaap_msg_process : Unknown chan: 8
And I had done some tests before with debugging level logging and saw the messages on channel 8 were 32769 and 32770 but adding the AA_CH_BT to the conditional with the other channels didn't work because that calls the media start request but I noticed all the other channels got a media setup request first (32768) so I think it needs to be handled a special way and I don't really know how that is. But I want to see how you fix it because that's how I've been relearning my C++ from like 13 years ago in my high school Computer Science AP class. The next year the class switched to Java and so did every main line programming class I took all through College and never even looked at C++ again till I got into this.

[lmagder]

@Trevelopment You are the developer of AIO? Nice! well good work 👍 seems like there is a lot of crossover between the projects.

To be honest I actually don't have very much experience with JS dev which is likely the source of bugs like #62, maybe you have ideas? We have like the opposite development background 😃

I added a HTTP-based API to the headunit process so that the js code could call it and that seems to work, so if we could get this information somehow in JS land then it's a possible solution. Ideally though the JS portion is as simple as possible since it seems to be the part the changes most OS version to version, but I'm not against the idea if the result is good.

You could use the status request (see AAlogPoll in https://github.com/gartnera/headunit/blob/master/mazda/installer/config/androidauto/jci/gui/apps/_androidauto/js/_androidautoApp.js) to query if AA currently has video focus. GETing http://localhost:9999/status returns a json object with this info if the headunit process is running. There is also a POST command at http://localhost:9999/takeVideoFocus which is what happens when you select the AA menu option from the CMU to return to AA and we could add more arbitrarily, the code is here https://github.com/gartnera/headunit/blob/master/common/command_server.cpp

Alternatively the JS code which switches the surfaces actually fires a DBus message via a custom opera plugin (using the same API headunit uses) so if we could somehow snoop those messages on the C++ side or intercept them it would work too maybe?

I have no idea about the media start stuff in the AA_CH_BT that channel is super stubbed out. Maybe it's trying to tell us to route phone audio over BT or something. I was hoping we wouldn't need to figure this out but possibly we do once we fix the other stuff and it still doesn't work...

[Trevelopment]

@lmagder Cool man in my experience the best colab sessions I have had are with hackers with opposite skill sets as mine. Also, I always learn a lot from these kind of things and I have already went way past the C++ knowledge I had 13 years ago. Hopefully I can teach you a few things too like how to fix #62 is super easy. You can actually fix it a few ways but the easiest way is just to remove localhost. You don't even really need the file:// either but it is fine to leave it in and the 3rd way is to change the file:// to http://. When you are referencing a file directly there is no need for localhost because localhost is just an alias for 127.0.0.1 and you wouldn't try to do this: file://127.0.0.1/data/headunit.log right? Anyways now come join me over at #80