Skip to content
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

Thank you and intention to implement AA type package for Linux Phones #11

Open
azariah001 opened this issue Apr 23, 2021 · 3 comments
Open

Comments

@azariah001
Copy link

Thank you for marking a start on this project. I started Googling around for precisely this thing last year and didn't turn up anything, turns out it was still a work in progress. Well done.

I've received my PinePhone recently so I'll be starting implementation on a number of projects the core of which will be trying to implement an Android Auto equivalent to run across as many Linux phone platforms as possible. I believe my main targets are KDE Plasma and Gnome Shell, although with LibHandy on the way to being largely mainlined in Gnome I may want to hold off touching that side of things.

The general goal of my Auto project will be to create a clean slate that devs can publish apps into in much the same way AA is, just... more open. With obvious built-in features like navigation UI roles and media roles to allow for quick implementation of PnP and remote control widgets when in other apps.

Now it does sound like I may need to come up with a way to grab the client-side certs in order to auth with most commercial head units. Wondering if periodically grabbing the AA APK and extracting the cert from it is feasible...

@tomasz-grobelny
Copy link
Owner

Thanks for kind words. Are you about to contribute some code to this repo or are you planning a completely separate implementation?
As for the certs - I think it should be feasible. Of course Google may try to make it harder (obfuscation), but in principle they have to deliver those certificates to end devices this way or another so it is just a matter of motivation, skills and time to extract those certificates in future :-)
Another way (long term) - since this looks to me like a market abuse practice - you might want to contact EU Commission or your local antitrust office to investigate the matter. I wrote to the Commission and they replied some round words, blah, blah but we do not have time. Again, a matter of how many people write to them :-)

@azariah001
Copy link
Author

Will depend on the nature of the contributions required. I will if possible implement this as a library into my codebase and commit enhancements to the core functionality here. In my mind, this is a tool to make it possible to communicate with the head unit and thus any enhancements to that side of my system should be made here for the benefit of everyone. Unless those changes are too specific to my use case in which case I might have to start maintaining a fork, but I can't see that being necessary... that's the point of Linux, write once, run everywhere with minimum modifications required.

Yeah, I am worried that the certs are already encoded into the compiled code of the app and either encoded in base64 or a more obtuse encoding/encryption standard. but fingers crossed they're just files in the app directory that can be easily extracted.

Unfortunately, I live in Australia where this sort of restriction is considered the exact opposite of market abuse. The restrictions exist (in the minds of our government) to ensure that the software can only be used within the limitations demanded by the law. According to them, the use of encryption certificates and app authorisation procedures through a central authority is needful in order to ensure that it is not possible for a user to unwittingly break the law by installing software that enables unlawful abilities. Such abilities include but are not limited to, video playback in view of the driver, games in view of the driver, extended interactions such as software keyboards while the vehicle is in motion, or decisions that require more than a single button press, etc. etc. etc. Welcome to the nanny state that is Australia.

I'm thinking because audio is going to be a very important feature I should probably concentrate on that. Right after I figure out if I can convince a stock head unit to authenticate with me... Based upon the video demo I've seen from another thread you've got touch working yeah? So audio for Android Auto can go one of two ways, when the phone is wire connected it goes over Bluetooth for music and phone calls, when using the Wireless Wifi connect protocol music goes over Wifi and phone calls go over Bluetooth. I recently acquired one of these bad boys https://www.indiegogo.com/projects/aawireless#/ to enable the Wifi connect on my USB only headunit, which is amusing because it's now transmitting the audio over Wifi then forwarding it over USB. Like... why couldn't it just do Audio over USB when direct wired... 🤷

@tomasz-grobelny
Copy link
Owner

Looking forward to your contributions! Currently AACS can receive touch events from headunit and they can be forwarded to an X application via XTest.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants