yashsingh1/xdaforums huggingface dataset:
[Android Auto General] mikereidis:
Thank you very much. :)

I posted figuring someone else might know the trick, and just last night was thinking they probably just added a header.

If anyone, anywhere has any secret documents, info, etc, about Android Auto, please feel free to email them to me at mikereidis@gmail.com .

I have made good progress on reverse engineering the protocol, but if the Pioneer code is not obfuscated that will make things a bit easier.

I'm laughing a bit because the Pioneer SSL/RSA certificates and private keys I extracted seem to match, and should make the crypto handshake possible, though I note one of the certs expires this summer.

Then I realize that DMCA CAN affect anyone trying to sell an app through Google, an American company...
[Android Auto General] miloshdrown:
Any chance you can share those strings and a snippet of how you sent them?
[Android Auto General] Schischu:
Ok took me a lot longer than [MENTION=3575078]mikereidis[/MENTION], but finally:

MANUFACTURER: "Android"
MODEL: "Android Auto"
DESCRIPTION: ""
VERSION: "1.0"
URI: ""
SERIAL: ""

Ends with

I/CAR.GAL ( 2649): IO exception: java.io.IOException: read failed: EIO (I/O error)
E/CAR.GAL ( 2649): ReaderThread: exiting due to IO error
W/CAR.SERVICE( 2649): Critical error 3 msg: IO error
[Android Auto General] Schischu:
Small steps:

I/ActivityManager( 1902): START u0 {act=android.hardware.usb.action.USB_ACCESSORY_ATTACHED flg=0x10000000 cmp=com.google.android.gms/.car.FirstActivity (has extras)} from uid 1000 on display 0
D/CAR.CLIENT(28853): Skip meta-data checks; first-party skip list [com.google.android.gms]
D/CAR.SERVICE(28853): Package in whitelist; name: com.google.android.gms
D/CAR.FIRST(28853): Not connected to car, starting connection.
D/CAR.SERVICE(28853): connectToCar, connectionType:1
D/CAR.TEL.CarCallService(28853): Creating a new CarCallService.
D/CAR.TEL.PhoneAdapter(28853): Creating a new PhoneAdapter instance
D/CAR.TEL.PhoneAdapter(28853): setListener: com.google.android.gms.car.dk@263be7e2
D/CAR.TEL.PhoneAdapter(28853): Returning an existing PhoneAdapter instance.
D/CAR.TEL.CarCallService(28853): Starting CarCallService with initial phone null
I/SslWrapperNative(28853): SSL native library successfully initialized!
D/CAR.GAL (28853): onChannelOpened() for service null
D/CAR.GAL (28853): skipping onEndPointReady() for endpoint com.google.android.gms.car.senderprotocol.q@2f4c773
D/CAR.GAL (28853): skipping onServiceStarted() for endpoint com.google.android.gms.car.senderprotocol.q@2f4c773
D/CAR.FIRST(28853): USB connection, finish activity after launch

D/CAR.CLIENT(28853): disconnect
I/CAR.SERVICE(28853): listener not found in list
D/CAR.SERVICE(28853): Unregistering car connection listener com.google.android.gms.car.dx@e4a67cf clients:0

Edit:

I'm pretty sure that I have to send the unencrypted VersionRequest, however the correct protocol is not that clear.

Simply sending

only causes:
[Android Auto General] Schischu:
I also tried 0, 3 as header but no luck, I think I forgot something before as I can see with usbmon that my connection is being reset after the write.

I've sent you my code, maybe you can take a look.

Regarding SSL, I think is is "just" to secure a unsecure connection which transfers lots of very very sensitive information.
[Android Auto General] Schischu:
[MENTION=3575078]mikereidis[/MENTION]: Any help?

Edit: Ok got it. It was a mixup with the endpoint addresses, argh....

Edit:

And authenticated:

Edit4:

Transmitting encrypted message is working! I have successfully extracted the Android logos from the encrypted ServiceDiscoveryRequest. :)
[Android Auto General] mikereidis:
Wow ! :)

Now I'd like to see YOUR code...

I've replied by email.
[Android Auto General] mikereidis:
Just bought a Pioneer AVH-4100NEX, so I guess I'm "serious" now. :) : http://www.ebay.com/itm/NEW-PIONEER...e-5-6-ANDROID-DVD-AV-AVH4100NEX-/111640882661

Anyone wanna buy a HeadUnit app for tablets when it's ready ?

I've reached a point where I'll be able to get answers more quickly by sniffing the USB than the reams of horribly obfuscated code.

I think the "Open" in "Open Automotive Protocol" was swiped from "Open Automotive Alliance" : http://en.wikipedia.org/wiki/Open_Automotive_Alliance

Meaning it's "Open" to Auto manufacturers and tech companies of a certain size/fee paying abilities, and closed to we mere mortal small developers.

I guess we can just send a cert in some form for the SSL handshake, but I haven't figured that out yet. I managed to bypass the SSL encryption though by building my own neutered version of the ssl wrapper JNI library.

But then I'm stuck at the same issue. AA thinks the "car" is moving and won't setup. I'm guessing I have to send something that says the parking brake is on or the gear is in park.

I figured out many parameters for the service discovery, but the first seems to be the very important "What services does this car/HU support". And this is some weird smash together of various stuff into a single byte array. Will be easier to sniff perhaps than decode entirely in Java and Smali code.

And then some of these Services are at a higher "Channel Level" that may have their own authentications, as I have seen hints of in the code.

I still think the HUs may be able to authenticate AA; the Pioneer firmware seems to call a "Verify Peer" function that AA does not. And if not now, authentication could go both ways in a future update.

The HTC Android Auto competitor announcement seems silly, but AA authentication prevents companies like HTC from piggybacking for free on Google's AA protocol.

On the plus side, AA will likely have to remain compatible with old firmware (for which private keys may be extractable) for some time. AA has an HU firmware update feature, but I'm not sure it will be used.

Where do I find a contact email to ask if I can join ? (LOL). Don't call us, we'll call you...
[Android Auto General] brainscollector:
I was trying to send you pm but you have them turned off, so, yeah, I would like if there will be one ready to use :)
[Android Auto General] mikereidis:
:)

Post publicly, or if it's private just email me at mikereidis@gmail.com .

Like many devs here on XDA, with PMs enabled, I get WAY too many PMs asking privately for help with my apps, and they almost always come from non-customers.
[Android Auto General] Schischu:
I/FsmController(16049): fireEvent(EVENT_CAR_PARKED)

:)
[Android Auto General] mikereidis:
You figured out Sensor Service response and channel ?

I presume you'll be releasing an app at some point ?
[Android Auto General] Schischu:
If you mean an android app, than no.

At the moment it is more like creating an unofficial AOA documentation.

Long term it would be nice to create a OpenSource AOA implementation for headunits.

Edit: Yeah I am receiving the VideoStream on my PC, but how to playback it, hm.
[Android Auto General] Anton2079:
I may be overstepping this request I'm sure. I really wish I could help some more as well, even with my software development experience, not really familiar with reverse engineering...

However maybe we could just display it on the device in use somehow... from a secondary app? Then at least you could use your phone in a cradle and have the functionality :)
[Android Auto General] Schischu:
VideoStream, see Attachment :) :) :)
[Android Auto General] diagdave:
An open source AOA implementation is exactly what I'm after! My head unit in my car is playing up and I'm tempted to build my own replacement. Being able to include this would be great.
[Android Auto General] Schischu:
Whats next? :P
[Android Auto General] diagdave:
Release :)

Amazing how fast you got that running
[Android Auto General] brainscollector:
What's next ? That would be awesome if it would work on tablet :)
[Android Auto General] mikereidis:
An app of course. :)

Please feel free to share your code and docs at any time.
[Android Auto General] mikereidis:
A standalone mode, without a second device to act as HU was my first goal.

But then I realized it would be tricky, and Google could throw up many roadblocks to that route, intentionally or not.

AA is designed so that the phone display turns off. This would have to be worked around and would not be the only obstacle.

AA is designed to work with HUs, so Google really can't prevent that, except through HU crypto validation that we can probably work around, with root on the phone as a last resort.

IF we could virtualize Android we could get a standalone mode. IE have one instance of Android running AA with a dark virtual display, communicating with the main instance running an HU app through some virtual USB/other connection.

But I'm not aware of any easy way to run a virtual instance of Android on a device.

I also think having a second device for HU makes a lot of sense; the HU USB connector charges the device, the HU stays in the car, passengers can hook their phone if they desire, wired connections from HU for speaker amps...

We can buy Nexus tablets for $200, less used, and the screen is bigger and capacitive and better resolution than 800x480 HUs.

Beyond this, as a developer, it's a LOT easier to support an HU app on 3-4 Nexus tablets than trying to support an app on thousands of different phones.

When somebody reports problems I could ask: Is this phone known to work with real HUs ? If not, it won't work with the HU app. Supporting 1000's of different phones is virtually impossible. Supporting 4 tablets: feasible.

Do NOT underestimate the difficulties of dealing with Android fragmentation; dealing with stock phones and thousands of different ROMs and rooted/AOSP/custom ROM'd devices etc.

I deal with this crap every day and I am very tired of it. I ONLY have 13 devices that I presently test my Spirit apps on; And every day someone says "It has this strange problem on my less popular device"... And I scratch my head and can easily spend hours trying to fix the apps for one person.
[Android Auto General] Anton2079:
OK, I understand.

The reason why I thought it would also be cool, is because my headunit has HDMI in so I thought I could display it on that as well...

But yes I definitely see your point, fragmentation makes it tough! Your idea makes more sense!

Keep up the good work!
[Android Auto General] brainscollector:
Oh lucky me that I love nexus devices and have nexus 7 2013 :) can't wait to see working HU emulator on android for tablets.
[Android Auto General] diagdave:
I assume that in the first case you will be doing a Linux based implementation. Android is ok but I would imagine a linux solution would be easier and move versatile? Even if its only docs so we could create our own versions using the 'AOA' api that would be great. From the looks of the screenshots its running on ubuntu? Is the video stream H264? How is it going with the audio input/output. Please let us know if you need any help with anything. (Sorry for all the questions)
[Android Auto General] mikereidis:
I was using the word "emulator", but I think if it's functional, we could say the device is a real HU, albeit in the form of a tablet perhaps.

The Pioneer AA HU's run a custom version of Android themselves; for the AA function it runs a binary with hooks into Android APIs: AAPPlayer; we might not call that an app, but it's not really too different; an actual Java app can do the same thing.

An app that runs on a tablet could also likely run on the many Chinese/etc cheap-ish HUs out there, though the buttons and knobs might not work without customization.

"Real" HUs likely have knobs and buttons, but here again something custom could be done.

Virtual on-screen knobs and buttons could be done, but it's not the same without physical parts; Steering wheel controls should be possible with the right hardware.
[Android Auto General] mikereidis:
I presume your questions are directed at Schischu, but I'll give some thoughts if you don't mind.

IMO, Android is the way to go on this. Android tablets are commodity items that sell in the millions (I think), while stuff that runs Gnu/Linux is much less mainstream.

My initial tests were run on my main Linux development PC because it was convenient at that point. But now I am running an Android app, based on Google's sample code that does remote projection; H264 for video (surprise :) and I think HID for remote touch.

I am not as far along as Schischu at this point, I can tell AA that I have a Parking Brake and other sensors, but I haven't cracked the Channel Open Response yet, and he's also opened the video channel too. If Schischu would release his code or documentation that would help me, but I'll get it eventually regardless, especially once I get my Pioneer 4100NEX to sniff the USB.

Yes it's H264.

If he has video working, it shouldn't be TOO much harder to add bidirectional audio; I think it's simple uncompressed PCM but it seems to have it's own encryption functions.

Add the Touch functions from HU to AA and you can have a minimally capable HU I think. My guesstimate was a month or so of hard work to get a functional prototype. "Prototype" of course means that it's held together with software duct tape, and mostly intended as proof of concept and not something anybody should use in a car on public streets.
[Android Auto General] Schischu:
Yes h264 stream is working with 800x480. But very slowly. Need to optimize the receiver thread to achieve more throughput.

Also keyinput is working. Touch however not yet.

My aoatest is currently running on Ubuntu 1410 and connecting fine with nexus 5 (5.1) and nexus 7 (5.0).
[Android Auto General] Schischu:
New:

Now with smooth video streaming, touch input and daymode.

Todo:

Audio Streaming,

Figuring how to request higher resolution video

Navigation Handling

Bluetooth

And also this sensor stuff

Edit: AudioStreaming + Bluetooth works too. Seems that audio is always being streamed using bluetooth, and not over usb.
[Android Auto General] diagdave:
Would love to see the code so far.

Are you sniffing usb packets on a live head unit?

Thanks,

David
[Android Auto General] Schischu:
No unfortunately I don't have a AA capable headunit. I have to do it the hard way by try and error.

Which worked surprisingly well so far.

Turn-By-Turn Navigation works.

Now missing is Voice Search and Phone, both need BT HFP profile which is always a pain in the ass to get running with bluez...
[Android Auto General] diagdave:
Even more impressive.. I thought that profile was dropped in bluez? Are you still using Ubuntu or have you switched to android?

Thanks, d
[Android Auto General] brainscollector:
Any news ? I was and I'm still sure that there will be possibility of running it on tablet before this summer thanks to you guys, and I just can't wait for results :)
[Android Auto General] mikereidis:
I'm roughly on track for a "proof of concept" app within the next week or so.

I may be hesitant to release it too early due to liability concerns.

Sooner or later someone will smack their car up, and perhaps a few people, and figure I'm a ripe target for a multi-million dollar lawsuit,,,
[Android Auto General] Anton2079:
You should post a I'm not liable for ANYTHING all over it and on first run.
[Android Auto General] diagdave:
Or if you don't want to release an app maybe just the protocol docs. :) im still wanting to use it in Linux as an android based device won't work for what I need.
[Android Auto General] mikereidis:
Like that ever stopped anyone from suing in the US for millions over spilled hot coffee etc.

Some of the Alps crash relatives are trying to sue in the US for this reason.

Start a Pioneer head unit and it warns you with an OK press required EVERY dang time you start the car. One person did major reverse engineering to try to bypass that one little thing. While his efforts were impressive, and results interesting, he has yet to achieve the feat, 1+ year later.

This IMO is a major(/one of the) reason why Google is keeping the protocol secret.

And note that to put an AA enabled app on Play, you MUST submit it to Google for approval. They test to try and ensure nothing distracting happens, especially like popup ads that will distract.

Google needs to convince authorities all over the world that it's OK to run Android Auto while driving, and that safeguards can't be easily bypassed, for thinks like watching videos while driving.
[Android Auto General] mikereidis:
I'm not sure if you are aware that there are at least 2 independent efforts underway.

I am the OP of this thread, and I'm working very long hours to build an app that I expect to sell in order to continue (to try) and make a "living" as an independent app developer.

I have not made any commitments to open sourcing documents or code, but I've been trying to share information in this thread.

Schischu has posted on this thread that he is also reverse engineering the AA protocol. He has stated to the effect that he expects to document the protocol (and I presume release that document at some point), and that in the long term he may create an open source app.

At this point, our efforts are independent.

I finally achieved video transfer just a few minutes ago. :)

I may be behind him in some ways, but I may also be ahead in others. Right now my code is in an Android app; last he said his code was running on PC Linux. Unless he has changed his mind, he indicated that he might create an app in the long term.

I think Android Auto is very exciting and that it will be a major focus of Google. I just read an article about the $2,000 -$4,000 people are willing to spend on automotive technology: http://www.autoblog.com/2015/04/23/jd-power-consumers-safety-tech/

Right now I am very committed to this project and Android Auto in general. I WILL be releasing an app for Tablet HUs in the next few months, and maybe some demo code in the next month or so.

I worked on my Spirit FM apps for 4+ years now. FM is dying, at least insofar as my ability to make a minimum living wage from it.

I expect Android Auto to be my focus into the indefinite future. If I can't make sufficient income from an HU app, I will find other AA related opportunities. "The sky is the limit*".

*Humans could never operate flying cars; we have enough problems in 2 dimensions. But self-driving cars will eventually be self-flying...
[Android Auto General] diagdave:
Any chance you can share anything thing tonight? Was planning on having a go at working it out over the weekend but don't want to start from zero, not expecting a working program

Thanks,

D

Could you tell me how you found about the version request packet? I have a program that acts like an android accessory. Have the correct end points but not sure where to go from there. Even if you could just point me in the right direction?
[Android Auto General] mikereidis:
I found out about the version request packet, and all the other packets, by examining Googles' code. This code reading method takes a LOT of work.

Unless you have documents and/or some code to start with, that is the only viable option, unless you have a working head unit and can sniff the USB.

The version request packet is just the beginning and you can't do anything useful with it alone. You need to know about dozens of packets, their parameters and how they work to get to the point of projecting video and handling touchscreen inputs.

You can ask Schischu when he expects to release documents or source code.

At this time I am not expecting to release such information anytime soon. (But who knows...)

40 days have passed since I started this thread, and I'm sure I've put over 400 hours of work into this so far, working 70+ hour weeks.

I am married, with a house and 2 kids and need to support my family financially.

My ability to do that will be threatened IMO, if I just release for free the information I have worked so hard to obtain so far, and in the many months/years to come.

This is economic reality. We do not live in a Star Trek/post money/socialist utopia...

And it is very rare for developers to earn a decent income from donations. Paid apps are one of the few viable options, and even with these it can be VERY difficult to make a living.

I have been "barely scraping by" with my Spirit FM apps for the last 4 years, despite working 60-70 hour weeks for the full 4 years.
[Android Auto General] brainscollector:
Didn't you think to have some programming job as there is plenty of possible applications around ? Even though I live in Poland (yea...) there is a lot of job adverts for programmers even android and ios ones. I'm sure it's not that hard as finding job as graphic designer (as I do) and it's still very very possible to find some decent one very fast.

Also I don't want to sound offensive, just a thoughts after reading few comments about it.
[Android Auto General] diagdave:
A very disappointing and negative attitude. Good luck with your head unit app.
[Android Auto General] mikereidis:
Sorry, but I don't understand what you are saying.

I was reading the other day that good mobile app developers are "brokered" for as much as $160 per hour.

For the last 4 years I've been making about the same as the lowest paid workers at McDonalds; about $10 an hour given the long hours that I work.

Sucks to be an independent developer unless you are one of the lucky few with a major hit...

Financially, I'm an "idiot" to be just barely scraping by when I can make $100k+ a year on salary or around twice that being a "business-man" and keeping busy with other people's projects.

That said, I DO prefer to chart my own course.
[Android Auto General] and313:
You know what... That just did it... Check your pm in the coming months
[Android Auto General] mikereidis:
I was thinking about my reply long and hard this weekend, and kicking myself a bit for it.

XDA is often said to be about "sharing" and I understand and agree with that.

If you have read this thread you will see that I HAVE shared many technical details that I've learned, and there are very few details coming from anyone but me, except for the helpful advice about how to mount the Pioneer HU partition.

I saw the same 4 years ago when I started an XDA thread to share details about the still very undocumented FM chips and APIs. Nobody but me was "sharing" information. Everbody else either didn't care or didn't want to share what info they had.

The other investigator posting on this thread has shared his progress reports, but not his code or documents, so far at least. That's fine, we are all free to do what we want.

I am POSITIVE there are people reading this thread who would also like to create an app, but they are quietly reading instead of being vocal. They aren't sharing ANY info.

So please don't hold it against me if I decide to be honest and forthcoming about the fact that I will not release ALL of my hard won information.

What about Google ? Google is keeping their source code and documentation secret. Should we reject Google for that, or do we understand Google is a business making what are likely sensible business decisions ?