suddenly "Lock"

[wjcarpenter]

I started tinkering with CS about a month or so back. I fired it up and used my mouse to operate it while displaying over HDMI. Everything looked pretty cool and stable. I got a nice touchscreen, bolted my RPi 3B+ to it and repeated the experiment. It worked great, and the touchscreen stuff worked just dandy. I plugged in my phone (Pixel 6a) and up came AA. It behaved the way I expected.

Time went by while I was waiting for additional mail order parts, 3D printing a case, and doing unrelated things. With everything in hand a couple days ago, I repeated my experiments, including plugging in my phone for the first time in a few weeks. CS reacted by throwing up the word "Lock" in the upper left corner and ignoring touches or mouse clicks on the screen. When I unplug my phone, CS goes back to its normal responsive self.

Thinking I might have tweaked something the wrong way, I started over with a freshly downloaded image file. Same "Lock" symptoms. I also locally built the image and got the same "Lock" symptoms. I know the generic advice is to check my USB cable. I've tried about a half dozen different cables between my phone and CS, but I don't really think that's the problem.

I'm just starting my spelunking in the source code, but I wonder if someone has already been down this path and figured it out. (I'm not providing any logs at the moment because I don't want to bother someone into spending time on this unless it's something they already have ideas about. I can provide them if desired.) My hypothesis at the moment is something changed in an Android monthly update, and now the handshaking between my phone and CS is getting something confused. Things definitely get as far as CS recording my phone info into the /tmp/android_device file.

[wjcarpenter]

After poking around at things quite a bit, it seems the touch screen isn't actually disabled. It more like that AA screen which should replace the main menu screen just isn't showing up. If I turn on debug mode, touches on the screen show up as deep down as the aasdk logging.

My interpretation, which could be really off-base, is that my phone thinks the crankshaft screen is displaying the projected AA display, and aasdk is sending those touch events down to the phone. I also turned on debugging on the phone side of AA, but there is so much stuff in the resulting logcat that I am not quite sure what is significant and what is not.

Does anyone here already have any familiarity with looking at the phone logcat for troubleshooting cranskshaft situations? (or any other suggestions, of course)

[MatthewOnTour]

Hi, I had been using the crankshaft for 3 months, and just after I got back from vacation about 4 days ago, I encountered the same problem. I have no idea what could have gone wrong because I wasn’t home and hadn’t been tinkering with the crankshaft in any way. I have a Samsung S23, but based on this, I’m guessing some update in Android Auto caused the issue.

[wjcarpenter]

Thanks for the confirmation that it's not just me. 😃

I connected to the Crankshaft with a phone that had not been powered on for a couple of months. I don't think it had time to update any AA-related stuff on the phone (but I can't be 100% sure). Same symptoms.

I have a car with a manufacturer head unit that supports AA, so my plan is to capture a logcat from that and compare it to a logcat when connecting to Crankshaft. There's tons of stuff in the logcat, so I don't know if that will shed any light.

[gridleym]

I've also recently encountered this "Lock" appearing at the top left of the CS screen. It all worked perfectly, then one day during a car journey, the phone disconnected and ever since, displays "Lock" on the screen . I've tried re-installing and different Android phones, but still get the issue. This is the only reference I've seen to show I am not alone with the problem.

I am using a Pixel 7 with latest Android 14 & rp4

[wjcarpenter]

We've been trying to sort it out in an "issue" with the same title as this thread. So far, no joy.

[SonOfGib]

So we know now that the wifi service is somehow causing this issue. I have made a patched version of openauto available on my github fork of this repo. I think I will try to figure out if there is some way to fix that functionality instead of just removing it. If I can figure it out, my plan is to raise a pr back to this project so we can have a properly fixed crankshaft. Commenting out the wifi service seems too hacky :D

[wjcarpenter]

Commenting out the wifi service seems too hacky

Agreed. If you/we aren't able to figure out a fix, maybe implementing a config to optionally disable/enable the wifi service would be a useful stop-gap.

[SonOfGib]

Ok, I believe I have figured out why the wifi service was causing Android Auto to lock up and I will make a change for that shortly. In the course of figuring it out, I realized that the wifi and bluetooth services in openauto don't actually do much. They seem to be unfinished implementations, perhaps of the wireless AA protocol? They don't seem to have anything to do with the wireless AA that crankshaft supports, which is done via the head unit server from the phone.

It also seems like some of the protobufs in aasdk are not correct. It seems like the ones documented online by milek7 are more accurate, so I will try to reconcile the two at some point.

[SonOfGib]

I have uploaded new prebuilts for openauto/aasdk and have created another "release" image here: https://github.com/SonOfGib/crankshaft/releases/tag/v2024.10.30.1 This is not an official release, but I want to make it available for people who are interested in using/testing it.

[wjcarpenter]

Pretty cool @SonOfGib. I hope to get a.xhance to test it some this weekend.

Does this have wi-fi service back to being enabled or still disabled?

[wjcarpenter]

I am working on a list of things that I want to work on

You didn't say you were looking for suggestions, but then again you didn't say you weren't. 😄 I don't know how hard it would be to do this (since I have been too busy/lazy to look into it), but it would be great to be able to cross-compile the prebuilts in the same way that we can cross-compile the CS layer. Targetting RPi but built on an x86_64 Linux box. That's done with some docker trickery and works quite well for the CS layer (after a couple of build tweaks that have recently been merged there).

[SonOfGib]

Its not quite as well implemented as the one in the crankshaft repo, but there are two docker compose files intended for cross compiling now. Check ./buildenv in the sonofgib-newdev branches for aasdk and openauto and see if it works for you. It was working on my build system.

[wjcarpenter]

Cool. I'll give them a look, though it will be a few days.

[wjcarpenter]

The cross-compile of aasdk went without a hitch. The cross-compile of openauto failed with this complaint:

openauto-build-1  | CMake Error: AutoMoc (btservice): The moc test command failed: /usr/local/qt5/bin/moc -h
openauto-build-1  | -- Build files have been written to: /src/build
openauto-build-1  | make: *** No targets specified and no makefile found.  Stop.
openauto-build-1  | /entrypoint.sh: line 8: cd: ../bin: No such file or directory
openauto-build-1  | mv: cannot stat 'autoapp': No such file or directory
openauto-build-1  | mv: cannot stat 'btservice': No such file or directory
openauto-build-1 exited with code 1

BTW, in cross-compile.md, there is a minor typo (buildenv/pi_binaries/aasdk_armhf.dev instead of buildenv/pi_binaries/aasdk_armhf.deb). Also, when gathering up the files for buster.tar.gz, the library /opt/vc/src/hello_pi/libs/ilclient/libilclient.a didn't exist on my RPi3. It got created after I ran a simple make in that directory.

[SonOfGib]

Yeah you have to build those hello_pi projects, I'll add a note about that to the cross-compile.md. I'll make some improvements next time I go to use it.

[wjcarpenter]

@SonOfGib I only had a limited amount of time, but your unofficial release worked for me (RPi 3, Pixel 6a, USB stick instead of sdcard).

There was something weird that I still don't understand. The first couple of times I booted it, the openauto interface did not come up. In fact, it didn't get far enough to even bring up the wired network interface. While I was contemplating how I might be able to get logs, etc, with no connectivity, another boot was successful and the AA experience went as desired. Later reboots were also good. The only thing I can guess is that some first-time-boot stuff was taking way longer than I expected. I waited at least 5 minutes. (I had done the rootfs resize outside of the CS environment, so it shouldn't be that.) Anyhow, if nobody else reports anything, I'm OK with it being "just one of those things". 😸

As usual, thanks again for your work on this that benefits all of us