AACS icon indicating copy to clipboard operation
AACS copied to clipboard

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

Open azariah001 opened this issue 3 years ago • 3 comments

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...

azariah001 avatar Apr 23 '21 01:04 azariah001

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 :-)

tomasz-grobelny avatar Apr 23 '21 11:04 tomasz-grobelny

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... :shrug:

azariah001 avatar Apr 27 '21 06:04 azariah001

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

tomasz-grobelny avatar May 02 '21 22:05 tomasz-grobelny