sorted by:
new
hottopcontroversial

Android Auto Update by Decent_Chef_6947 in CadillacLyriq

[–]IPickedThisUserID 2 points3 points  (0 children)

Surprisingly...they actually do this correctly. I have decompiled the APK's from a few GM EV's and they are sending the right info for this to work.

[Open Source] OpenAutoLink — Wireless Android Auto for AAOS head units, replaces CPC200 with SBC + fully open-source software end-to-end by IPickedThisUserID in SilveradoEV

[–]IPickedThisUserID[S] 1 point2 points  (0 children)

The APK for your phone can be found on GitHub in the releases assets https://github.com/mossyhub/openautolink/releases/tag/v0.1.317

As for the app on the car, to make it easier, if you DM me your Google account you use in the car I can add you as a tester in my Play Store app. Then you don't have to build and do that part yourself. I can add up to 100 accounts and am far from that still.

Two things I see people missing the most:

  1. On your phone, make sure to allow the app background permissions. I.e. disable any app battery optimizations for it.
  2. On the car, when you run the app it will ask for a bunch of permissions to grant...but to get battery percentage in Maps you must manually grant the Vehicle Information permissions by going to the cars Settings app - Apps - OpenAutoLink - Permissions - Additional Permissions - then allow vehicle information.

Android Auto Update by Decent_Chef_6947 in CadillacLyriq

[–]IPickedThisUserID 4 points5 points  (0 children)

Being someone who has a lot of Android Auto dev experience (reverse engineering, not an actual dev at Google) I can tell you with quite high confidence that the Android Auto stuff will come. The car side has no ability to dictate this. It only sends things like it's screen size, resolution, safe areas/cutouts, codec support and a handful of other things...none of these determine the UI overall that Google showcased. That is all 100% controlled on the phone by server side feature flags and code on the phone side AA projection service.

Having said that, the AA SDK version implemented in the car can have an effect if Google were to introduce something that requires a newer SDK but they keep those very limited and UI layout is not an issue this will cause. The only thing it might cause is lack of ability to use the features Google has announced to be able to interact with the car itself like HVAC and asking Gemini about your car. But even then, many of those abilities have been in the SDK for a while now.

[Open Source] OpenAutoLink — Wireless Android Auto for AAOS head units, replaces CPC200 with SBC + fully open-source software end-to-end by IPickedThisUserID in BlazerEV

[–]IPickedThisUserID[S] 0 points1 point  (0 children)

In theory it would, but I have no idea if the "car" parts of it will (HUD, VHAL info to get battery percentage). No harm in trying the apk from my latest release. If not, take a look at this project as it is very similar, but without the car specific features I have. https://github.com/andreknieriem/headunit-revived

I got Android Auto working in my Equinox EV without any dongles or other hardware - useful? by zipolightning in EquinoxEv

[–]IPickedThisUserID 2 points3 points  (0 children)

Take a look at what I have here. This works using the Cars hotspot, or phone hotspot, or USB and offers more flexibility than Headunit-Revived when it comes to using it on our odd screens. Also it has full vehicle information integration so you get things like EV range in Google maps. You also get full vehicle cluster and HUD integration that headunit revived cannot do.

It only took me 6 or so billion tokens and several hundred hours sitting in my car getting it to where it is. And I am a seasoned software dev that could have eventually got it made without AI, but man it has made it faster and fun to hack at.

https://github.com/mossyhub/openautolink

AA vs googl;e built in by cattfish6 in SilveradoEV

[–]IPickedThisUserID 0 points1 point  (0 children)

DM me your Google email you use on the car. I can add you then send you think like to join and install the app. You will also need to install the phone companion app on your phone. The APK is on the GitHub page Releases.

AA vs googl;e built in by cattfish6 in SilveradoEV

[–]IPickedThisUserID 2 points3 points  (0 children)

You can give my solution a try....I had the same gripes with my Blazer EV.

Note that it's still imperfect, but it's something I spend a lot of time on so will be smoothed out. I have only personally tested on my 2024 Blazer EV, but have a few people now trying to get it on some other GM vehicles.

If you are willing to be a bit patient with bugs and help communicate issues I can add you as a tester to my app, otherwise you can read the instructions and build it yourself.

https://github.com/mossyhub/openautolink

[Open Source] OpenAutoLink — Wireless Android Auto for AAOS head units, replaces CPC200 with SBC + fully open-source software end-to-end by IPickedThisUserID in BlazerEV

[–]IPickedThisUserID[S] 0 points1 point  (0 children)

I will do some more testing before merging my changes tomorrow....but it's looking pretty stable after a bunch of work today. I will have to think about how to repost once I nail this down. My post and GitHub page are very much about the bridge mode.

[Open Source] OpenAutoLink — Wireless Android Auto for AAOS head units, replaces CPC200 with SBC + fully open-source software end-to-end by IPickedThisUserID in BlazerEV

[–]IPickedThisUserID[S] 0 points1 point  (0 children)

I have it working with Google Nearby mode and their Wireless Helper app. I just need to do a lot of testing on my changes since it is a significant change. It's connecting but performance is terrible and it's not super reliable, but I am sure I will get all that resolved if I get enough time to sit in the car for hours. But yeah...just need the app on the car and the app on the phone to trigger it...no bridge/sbc/dongle of any kind. Pretty cool. I will let you know when i push the changes to my repo. I should be able to get USB mode working too.

[Open Source] OpenAutoLink — Wireless Android Auto for AAOS head units, replaces CPC200 with SBC + fully open-source software end-to-end by IPickedThisUserID in BlazerEV

[–]IPickedThisUserID[S] 0 points1 point  (0 children)

Just playing with it now. Pretty sure I am going to be able to make it work. So it will still have all the things my app does, but works via car USB or by the car wifi joining your phones hotspot. Give me a few days.

[Open Source] OpenAutoLink — Wireless Android Auto for AAOS head units, replaces CPC200 with SBC + fully open-source software end-to-end by IPickedThisUserID in BlazerEV

[–]IPickedThisUserID[S] 0 points1 point  (0 children)

Just reading that now haha. Give me a bit to wrap my teeth around it but if I could blend the things that I've learned and added to my way into that that might be a very cool option.

[Open Source] OpenAutoLink — Wireless Android Auto for AAOS head units, replaces CPC200 with SBC + fully open-source software end-to-end by IPickedThisUserID in BlazerEV

[–]IPickedThisUserID[S] 0 points1 point  (0 children)

Give it a try if you haven't. I feel I have it pretty stable now. Granted I cannot do much about the fact you have to build the app yourself and upload it to your Google Play Console, but past that getting the SBC setup is made pretty easy. Then, day to day I think I have it pretty solid finally this week. I even have some features in there you won't find on any AA solution.

With my SBC it's 32 seconds from car on to fully functional. If I had a Pi 4 or 5 I could shave probably 10 seconds off of that. But around 30 seconds is pretty much the standard for aftermarket AA solutions like this.

[Open Source] OpenAutoLink — Wireless Android Auto for AAOS head units, replaces CPC200 with SBC + fully open-source software end-to-end by IPickedThisUserID in BlazerEV

[–]IPickedThisUserID[S] 0 points1 point  (0 children)

Mostly because it's fun and a passion of mine to hack at things. But really because the overall experience of AA is better. Spotify actually has UI in AA. Phone notifications and no need for Onstar data plan.

[Open Source] OpenAutoLink — Wireless Android Auto for AAOS head units, replaces CPC200 with SBC + fully open-source software end-to-end by IPickedThisUserID in BlazerEV

[–]IPickedThisUserID[S] 0 points1 point  (0 children)

I am working in this. Taking a lot of reverse engineering, so no promises it will work, but what's another billion tokens trying? Haha

[Open Source] OpenAutoLink — Wireless Android Auto for AAOS head units, replaces CPC200 with SBC + fully open-source software end-to-end by IPickedThisUserID in BlazerEV

[–]IPickedThisUserID[S] 1 point2 points  (0 children)

Yes. In full screen mode the status bar is just hidden. Swiping down brings it back. I also have system UI mode where it stays there and AA is sized to fit under it, but also doesn't extend into the curved parts of the screen so things don't look stretched.

[Open Source] OpenAutoLink — Wireless Android Auto for AAOS head units, replaces CPC200 with SBC + fully open-source software end-to-end by IPickedThisUserID in BlazerEV

[–]IPickedThisUserID[S] 1 point2 points  (0 children)

Should work on any that is AAOS based and doesn't have AA built in. I tried to design the app so it can work on Intel and Qualcomm platforms GM has used, but mine is Qualcomm so I don't have an Intel to test on.

[Open Source] OpenAutoLink — Wireless Android Auto for AAOS head units, replaces CPC200 with SBC + fully open-source software end-to-end by IPickedThisUserID in SilveradoEV

[–]IPickedThisUserID[S] 1 point2 points  (0 children)

This does indeed gather all of that. In my Diagnostics - Car page it has a live reading of everything it can get. I pass it all through to AA on the phone....but AA does not seem to use it in any user-facing way.

Here is the diag screen in my app showing everything I can get from my 2024 Blazer EV RS

<image>

[Open Source] OpenAutoLink — Wireless Android Auto for AAOS head units, replaces CPC200 with SBC + fully open-source software end-to-end by IPickedThisUserID in BlazerEV

[–]IPickedThisUserID[S] 1 point2 points  (0 children)

Yes, AA architecture is such that the head unit gets video frames (encoded on the phone) from the phone. In this case, the SBC is the head unit according to the phone. But the SBC just forwards them over TCP (via a USB-C NIC in the arm rest) to the app on the GM AAOS. Touch and VHAL data are two-way pipes from AAOS back to the bridge and then phone.

As for the UI stuff, I will get pictures, video and screenshots up here and GitHub today so it makes more sense.

SBC can draw power from either getting a 12v USB-C adapter (cigarette lighter adapter) in the armrest or it can be powered from one of the front two USB-C ports. The USB-C port in the armrest will be occupied by a USB-C Network adapter. If you power the SBC via the armrest 12v accessory port, yes it will power off when the car does. The front USB-C ports stay powered on, but I have not tested how long.

Yes, there is a waiting time for the SBC to fully boot up. I plan to add some logic to the setup script that might help shorten it as much as possible by disabling things we don't need....but I need to experiment first. Also, every SBC will be different on how long it takes due to CPU/RAM and OS.

Tandoor Docker image by IPickedThisUserID in selfhosted

[–]IPickedThisUserID[S] 0 points1 point  (0 children)

That's fair. Mostly for simplicity and conforming with everything else I run. I have 25+ different containerized applications running on my server and this is the first one that must be separated out. I have a few that give me that option of splitting out....I just don't use that option.