Jump to: navigation, search

Fixing OpenHU

Revision as of 23:50, 24 June 2016 by AdminTeam (talk | contribs)

OpenHU was broken by some undocumented change in Google Play Services 9.2. The best person to fix it, was the original author of OpenHU, Mike Reid. Sadly, he recently died. So we need the community's help to fix it.

Description of The Problem

Communication for Android Auto is actually not handled by the Android Auto app itself. It plays a role, but the device-to-device communications layer is actually handled by Google Play Services framework. OpenHU worked fine with Play Services 8.0, and Mike himself authored an update to react to changes in Play Services 9.0.

But, for some reason, Play Services 9.2 broke OpenHU. Google has not released a specific changelog for Play Services 9.2, but it does add the Nearby framework, which made many changes to the ADB and Android peer-to-peer communications subsystems.

More Specifics

With Play Services 9.2 installed, the OpenHU app will detect the presence of an Android Auto client via ADB. It enumerates the MAC address of the USB OTG client without issue.

Unfortunately, from there, Android Auto services (part of Google Play Services) fail to establish a connection.

We have isolated this to being a client-side issue, the presence of Play Services 9.2 on the host/OpenHU device does not cause an issue. And the latest versions of both the Android Auto app, and Google Play Store are not an issue. When we manually overwrite Play Services 9.2 with Play Services 9.0 on the client, everything works again.

Is it Encryption?

We don't think so. While most Android Auto head units today use digitally signed encryption, many early ones do not. Google would have had to make every owner, of everyone one of those cars, update their radio head units to plug that bypass - and mandate encryption.

Mike Reid himself commented that it is unlikely future breaks (like this one) will be due to encryption, but rather, due to the OpenHU app using some protocol in an undocumented manner - one that the Android Auto client (and Play Services 9.2) were not expecting.

This could become a cat-and-mouse game if Google was determined to block OpenHU... but again, that's not likely what happened here. It's far more likely some bad code in the OpenHU app simply is operating out of specification.

But, anything's possible. We aren't ruling out a code signing check just yet.

So you're offering $10,000 to fix it?

Pretty much. Mike wasn't just our "point man" on Android Auto R&D, he was the community's point man.

We don't have a replacement for him, and it's unlikely we'd be able to hire someone before Google stops allowing Play Services 9.0 to communicate with the Android Auto client app. So the best time to act, is now, and document what changed in the peer-to-peer communications system, and fix it.

Why?

Why are we offering $10,000 in goods and cash? We respect Mike's tireless efforts to keep Android Auto at least somewhat open-source. We want to see that continue, even after his passing. But we don't have people on our team that can do that - and time is of the essence here, especially as a future Android Auto client app update will likely block Play Services 9.0 from loading.

Where are the details?

Details are currently being posted to Console Developer Rewards. But in a nutshell, if we can get OpenHU up and running by the end of August, we'll divide the $5,000 in free gadgets, and $5,000 in cash, amongst the contributors that get it working.

And yes, a successful fix is a requirement. We're a tiny startup, we can't reward failure (sorry).