-
-
Notifications
You must be signed in to change notification settings - Fork 262
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
suddenly "Lock" #680
Comments
Same problem here. |
Facing the same problem (with both wired and wireless connection), when I used crankshaft today after a couple of weeks. Also phone screen showed a message, something like installed app in Android auto does not work with wired connection... |
Same! Pi 4, Galaxy Flip 6, AA-Wireless (but also doesn't work with a direct USB connection to the phone). Tried a clean install of crankshaft-ng without any additional changes with the same result. I'll try to see some logs as soon as I can find the time to take my pi within range of my home wifi to run some diagnostics over ssh. Note: the Edit2: I've bumped my Android Auto app version to |
Same with Samsung Galaxy S24 Ultra/ RPi3B+. |
I hadn't even thought to try that, but audio comes through for me, too. In fact, if I play a Youtube video on my phone, the audio from that comes through to the Crankshaft device. Somewhere in my travels (but which I have now lost track of), I saw a reference to turning on "allow videos while driving". If I ever find that again, I'll try it since the AA projection is just some sort of video stream (I think). |
The logcat on my phone when trying to connect to Crankshaft includes this line:
I don't know what it means or what to do about it, but it seems like it's probably significant. FWIW:
|
I have disabled the Android Auto app on my phone and then deinstalled all updates. At the same time I also completely reinstalled crankshaft on the Pi. |
That encouraging!
I wonder how you got to that version instead of one of the 12.9.* versions that I have. I was in the beta program for AA, but leaving the beta program still left me with the 12.9.* version I reported earlier. If I remove all updates for the AA app, it leaves me with something that identifies itself as a "stub" that can't connect to anything until you follow its prompt to update it. I figured that's something that Google changed when they made AA a hidden app a while back. My phone is a Google Pixel 6a. What's yours? |
Ho ho! I guess normal app activity is that it wouldn't update to an earlier version just because I left the beta program. I uninstalled updates to AA and then applied fresh updates, leaving me at For others who had the same problem, what AA versions were you using? |
FWIW, I reported this in the AA community help forum, but I don't know if that will get any attention. |
I uninstalled the Android Auto updates and it is working again too. I'm back to 12.6.643244 on Android Auto and so far so good. |
@dcolecpa Were you on the app beta before you uninstalled the AA updates? |
No. I was on "2022-09-11-crankshaft-ng-66525ef-pi2.img". |
@dcolecpa I meant the beta channel of the AA app on your phone, not Crankshaft. |
Sorry, I misunderstood. No I wasn't on beta for the Android Auto. |
I had the same issue since about a week. Out of the blue, didn't change a thing that might have caused issues. After removing the updates of the Android Auto app I'm also back on 12.6.643244 and now all is working fine again. It looks like something changed in the 12.9 version that crankshaft didn't like? |
Same for me, running crankshaft for years and it broke this week. Let's see if we can fix this somehow |
Same here. Many-year user. Just broke recently. My AA version that broke it was 12.7.643414. At the time my girl still had 12.6.643254, and her phone still worked consistently. Her phone has since updated to 12.8.643614 and no longer works either. |
Pressing "uninstall" in the play Store removed updates and that made it work again for now. Quick solution for now, but not for the long term |
The folks at Bluewave Stuidos (OpenAuto Pro) also seem to have this issue, as they stopped selling it and locked down the forum. |
I figured that was the reason. I was actually considering purchasing a license if their forks of openauto/aasdk would have been more up to date than the public ones. But alas that was not the case. I tried building opendsh to see if that would work for me. So far no luck (but this has to do with my unfamiliarity with the project as well as my lack of time since I became a dad). For now I'm driving without only audio nav over bluetooth, but I hope I can retry opendsh and get a working build to try this time... |
Add me to the list of "latest AA not working for me". Multiple phones: Found it wasn't working for my pixels; crankshaft would say it's connected but wouldn't go into android auto. Motorola wasn't up to date at the time so it worked, then I updated AA on it and then had the same issues. Uninstalled updates and wanted to do the first time setup. Uninstalled updates on my pixel 7A (this is my main phone) and it started working again like it's a new car, then said something about updates which I did and has been working since. |
My phone updated to 12.7.643414-release, and now Crankshaft is broken in this way again. Things still work with my factory AA headunit (via an AAwireless dongle). @DJFliX You mentioned opendsh. I built and tried that. Same symptoms as for Crankshaft, which is not surprising since it uses the same openauto substrate AFAICT. |
I'm going to chime in and say I have the same issue. I had to downgrade to Android Auto 12.4.6. I'm running Android 11 on a Sony Xperia 5 II. I'm willing to provide any logs and test any configurations. I loved this project for years and want to keep using it! |
Good to know! I am still surprised by the lack of reports of AA being
broken for Opendsh users on their Slack. But I suspect AA is a secondary
feature for most Opendsh users whereas for Crankshaft close to 100% of
users AA is the only thing they use crankshaft for.
I have downgraded to 12.6 but am experiencing frequent disconnects. Since I'm using AAWireless the reconencts do happen automatically but this does mean 20 second interruptions of music and nav which isnt great. I had never experienced this before...
…On Tue, 24 Sept 2024, 21:08 WJCarpenter, ***@***.***> wrote:
My phone updated to 12.7.643414-release, and now Crankshaft is broken in
this way again. Things still work with my factory AA headunit (via an
AAwireless dongle).
@DJFliX <https://github.com/DJFliX> You mentioned opendsh. I built and
tried that. Same symptoms as for Crankshaft, which is not surprising since
it uses the same openauto substrate AFAICT.
—
Reply to this email directly, view it on GitHub
<#680 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABJ6DNJ2O7N6U54EUIP2HQLZYG2D3AVCNFSM6AAAAABOKJIW4KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNZSGEYDSNZWGQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
It seems odd to me, too. I suspect there may be more to it than just the AA app version, like maybe some other dependent library or something that varies from phone to phone.
For the last couple months (not sure how long) my factory AA headunit, which I also use with AAwireless, occasionally stalls with some message about losing bluetooth connectivity. It resumes after a few seconds. It's been rare enough that I just put up with it. (Before I learned more about how AA works, I blamed a lot of things on the firmware inside my head unit. Now that I know about AA projection, it seems like almost every glitch has to be in the AA app on the phone.) |
I make a point to disable auto updates as much as possible. I also haven't changed any crankshaft settings in months. So there's only two things that could have changed on my phone to break things.
I only noticed crankshaft broke when I manually updated AA but it's possible changes in Google services play a role in the incompatibility. |
I also have same issue I used wireless Android auto using CS few months ago. And I tried to connect again yesterday, it didn't works. |
I'm going to pop in here and say that the official build provides me with the exact same problems with multiple phones, and Android Auto doesn't wanna stay in a specific version other than the latest. @SonOfGib 's version from your linked git in this thread has solved the problem of connecting to my phone, thank you for your efforts! However, note that I'm not past configuration stage as I do not have a touch screen to continue. |
Is possible to download a working fixed RiP4 img bin file that we can simply load to our SD card? I am not familiar with pi or programming and so far did not find an easy way to fix the crankshaft. I only use USB, no need wifi |
Hello! To anyone asking "is there an image already that I can just flash": the goal of an issue in Gitlab is to track progress towards fixing an issue. This issue is currently still "open". This means that there is no official release of the project that incorporates a fix. @SonOfGib is of the people who has done extensive work on the subject and he has created an unofficial build that fixes this specific issue. However there are no guarantees that this doesn't have any side effects or will continue to work with new AA releases. So proceed with care. People in this thread are not paid to do so, their incentive is to either fix it because they benefit from the project themselves, or because they want to benefit others (or both). Because of that no deadlines or promises are set regarding when (and if) the issue will be resolved. It is generally most productive for everyone involved if the discussion in a thread like this is limited to diagnosis, discovery and fixes of the issue. You're very welcome to share details on your setup if you think you're using a setup that hasn't been shared so far (see other posts for examples). In particular the version of the Android Auto app on your phone is relevant. |
I got a notification from Android Auto telling me that I'll need to update the app soon to be able to continue using AA (I disabled updates when this issue first started). From the looks of it, using the build from @SonOfGib is the only current solution? Do I just use Crankshaft's normal update function to update my existing install? |
So @SonOfGib, I've been following your development, I saw today that you have posted these commits: SonOfGib/openauto@e3aa777 Does this mean that you completely fixed the reason that video wasn't working on >12.6? Does this mean that wireless Android Auto also works with your builds? I am an unfortunate OpenAuto-Pro user so I won't be able to test your solution, but I'm interested to know, so we can try to think of a way to incorporate it to our closed-source system. Can you explain if there is any easy-hack way to make it work again for our builds? |
I have not tried using the updater personally. People are welcome to try the image I have put up on my github fork but its offered with no guarantees etc etc. I am not comfortable opening a PR back here without some additional testing, as I don't have an actual headunit setup right now. I am just running the code on my pc and my RPI3.
I did find the cause of the AA no video issue and updated the code to fix it. However the fixed wifi stuff doesn't do really anything at all right now. I do suspect that those channels/messages are used to setup AA wireless and I do plan to investigate it eventually. Right now I am focused on updating crankshaft to debian bookworm. Buster is pretty old and makes developing annoying. #678 (reply in thread) |
👍 to that |
Hi, What was the fix mentioned here to get video working? |
Essentially I realized that openauto was advertising a wifi channel that AA tried to open. And I guess what happens is because it is waiting for openauto to respond it never starts sending video. So I implemented a message handler for the wifi channel and that solved the issue. It doesn't really do anything aside from respond to those 2 messages (1 to open the channel, 1 to request wifi credentials?) |
Thanks. I read it that you had maybe setup a channel but still had video
issues which you trained separately. I've been implementing the found
information for AAP1.6 implementing many of the underlying remaining
services (at least in framework). While I've now got my update working with
lots of rewrites, mine never gets passed the handshake stage and never
tells me if any underlying message that's not being handled.
It seems like the phone is trying to pair to the car and failing after
that.
I'll need to make sure I've got all protocols in place
…On Fri, 8 Nov 2024, 00:30 Sean Gibson, ***@***.***> wrote:
Hi,
What was the fix mentioned here to get video working?
Essentially I realized that openauto was advertising a wifi channel that
AA tried to open. And I guess what happens is because it is waiting for
openauto to respond it never starts sending video. So I implemented a
message handler for the wifi channel and that solved the issue. It doesn't
really do anything aside from respond to those 2 messages (1 to open the
channel, 1 to request wifi credentials?)
—
Reply to this email directly, view it on GitHub
<#680 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFU2N5DA73HKGBXQRPMZLBLZ7QAYTAVCNFSM6AAAAABOKJIW4KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINRTGQ4DKOJWHE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Ok, I understand. So let me understand something, coming from OAP-Pro. Crankshaft doesn't have a working native AA wireless? BlueWave had implemented it a long time ago (some years), and you could connect to it wirelessly without inputting IP addresses and using the Developer settings. So, if crankshaft didn't have this, it's weird that both OAP-Pro and crankshaft got the no-video issue after AA 12.6. It feels like BlueWave must have already implemented your wifi message handler. There should be something inside your approach that fixes the no-video issue, besides implementing the whole handler. Any specific code about specific versions or protocols negotiated? It's a shame Bluewave sold and disappeared, they would have been helpful. |
Probably not, though it's possible I don't understand how to set it up. I can get this far with the @SonOfGib build:
|
I'm seeing the same as you. Using this build https://github.com/SonOfGib/crankshaft/releases/tag/v2024.10.30.1 on RPI3 and Android 14 with AA 12.7.643414 and 12.9.643854 EDIT: I have tried updating to 13.1.644254, Wifi is still stuck on "Looking for Android Auto". But then I tried with USB again, that instantly worked. Might there be some wifi settings on the phone that ignores the handler you added, @SonOfGib? |
@SonOfGib I've tried your package on Android 14, AA 13.0.644004. Video works wonderfully! I've thusfar encountered two issues, though I'm not sure if they're related to Crankshaft, AA, or my own causes:
Could there be changes in one of the above too, perhaps? |
Google maps has always been finicky for me. I get navigation to work by:
Maybe this will work for you? |
@TobiasDeBruijn I can confirm the issue with Google Maps on the SonOfGib build from 30th of October. For me however the issue seems to occur only when I use my AAWireless adapter. In addition the connection seems to crash in an unrecoverable way. Sometimes the OS on the pi will reboot entirely when that happens. When I connect my phone directly to the Pi, Google Maps works as intended and no such reboots occur. At this point I'll take any kind of AA I can get: I got the dreaded popup from Google as well telling me that soon an update will be forced. |
I'm happy to test for you, but I'm wondering what you mean by "headunit setup"? So you mean setup in your car? If so, my setup can easily be taken out of my car and do changes that you request and then I go off and test them. I have installed your image but got a problem with Google maps which other people have mentioned. Weirdly though, it seems fine with Waze. Also whilst I had a network cable plugged into my Pi 3B, I noticed that it's saying it has updates: Worth doing those updates do you think and seeing what happens? I mean, from my perspective it doesn't take me long to wipe the memory card and reinstall Crankshft if needed |
I haven't looked, but I imagine the update would come from the CS repo and undo what you get in this unofficial build. |
IRT wireless Android Auto, that is currently only supported via the headunit server as described in the wiki here. To be clear, the changes I made have not enabled wireless AA, they were just to fix the no video issue.
@Geekyadz Yeah I don't have a setup that I would consider equivalent to a real head unit setup (no touch screen, no amp/dac audio out, no microphone or backup camera etc.) at the moment. Would you mind reporting as much detail about the issue you (and others) are seeing as you can? I think it would be best to report it as a new issue here: https://github.com/SonOfGib/crankshaft/issues. |
Will do tomorrow at some point, and I'll add a video from my YouTube about it. Oh and for reference: I've got no backup camera either but I've tested what I can with it and that side appears fine to me (ie no differences from using the latest "official" image for crankshaft). Got an idea regarding that, but I'll let you update to Bookworm first cos I don't know how possible it would be Also I have no DAC either but sending the phone with audio is fine; I'm still able to hear maps etc through my car's stereo which is connected to my phone's Bluetooth. USB microphone also appears to be working. |
Well, this is awkward. Doesn't want to do it when I'm at my mechanics and also it seems that Google maps wants to dox me. I'll try it again when I'm at home |
Update: tried again from home and no sign of it. I'll check again in the morning, but maybe it needed to "settle down" a little? |
Didn't do it again this morning. Suspect maybe this was just a glitch on Google's part? Unless my phone has now decided to have a hissy fit with my mobile network at give as well as where I was yesterday? @SonOfGib if it happens for me again I'll let you know in your fork. @TobiasDeBruijn are you still getting the same issue as I was? Also there's another Android Auto update pending for me; I'll install it later and put any issues I find tomorrow in here |
I have pleasure in announcing after a few weeks of hard work, I have overhauled the AASDK Protobuf files, AASDK, and OpenAuto references, to try to bring this up to v1.6 Protocol. From my side things look good, and runs great over the wire, but I'm having some troubles with Bluetooth and Wifi. I plan to release this update through my own fork, with the next week or so, so if anyone wants to bring in the updates, they're more than welcome. Things on my agenda include: I also want to tidy up the GUI with a switch between simple and dev mode, and I want to overhaul the Python scripts and bring everything a bit more into C++ with a daemon service. |
Well, from my side I just use USB, but I'll keep an eye out for it. "integration with OBD to report vehicle sensor information back to AA, implementation of basic Vendor Extensions with a companion app" peaks my curiosity though; is this included when you release it? And how does it work? Ie did the pi connect to an ODB reader and then it fetched things from there? I mean, from my side, Car Scanner ( https://play.google.com/store/apps/details?id=com.ovz.carscanner ) needs to have the phone connected to an ODB reader but will display the values of whatever you want in android auto but it's a full screen app, and as _long as it's able to get the values (or at least it did when connecting to demo mode - I don't recall testing it in my car fully). If that doesn't make sense please let me know and I'll sort out a video |
Well before I found OpenAuto, I had KODI on my Raspberry Pi and had written a number of Python scripts to interact. I had two raspberry pi's, one had a canbus hat listening to the data and sending it upstream to my main car pc. This collected CanBus information and uploaded telemetry into the cloud where I had a companion app to show me details. My goal is to recreate a similar ecosystem tacked on to OpenAuto, hopefully with the advantage of using Vendor Extension channels so the companion app can simply upload everything itself from the phone rather than needing a WiFi router in the car as well! I then hooked it into the Google Assistant so you could ask questions about your car. |
@Geekyadz Sorry for the late reply. But yes, I do still have the issue. I've in the meantime had an android update and AA update, but that did not solve the issue. I also have an AA Wireless, and you mentioned it only happened to you with it. Unfortunately mine doesn't work either directly via the USB cable. (Doesn't work as in YTMusic and GMaps don't work, I've not tried other apps) |
@TobiasDeBruijn I had that issue when connecting via USB, I had forgot to disconnect from the Crankshaft hotspot. |
That doesn't seem to be the issue for me. I'll give @sjdean's new works a shot once they're released. Hopefully that can fix it 🙏 |
Discussed in #678
Originally posted by wjcarpenter September 1, 2024
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.
The text was updated successfully, but these errors were encountered: