Jump to: navigation, search

Fixing OpenHU

Revision as of 23:44, 27 June 2016 by AdminTeam (talk | contribs) (Revised based on community feedback, realigned to final CDR terms)

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

Any Caveats?

A few. Mainly, the fixes have to be substantial to earn the full amount. If it's a few lines of code (and we'd be as thrilled as anyone else if that's all it will take), we reserve the right to award only 25% or 50% of the total amount, at our discretion. We'll try to be as generous as possible, without angering angel investors. This isn't part of our core line of business, so we have to watch the numbers.

While we appreciate documentation, API documentation or reverse-engineering documentation doesn't qualify. Only code does.

Where are the details?

Legal details and process for code submission are posted at Console Developer Rewards. But in a nutshell, if we can get OpenHU up and running by the end of August, we'll divide the $10,000 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).