Jump to: navigation, search

Fixing OpenHU

Revision as of 07:13, 5 July 2016 by AdminTeam (talk | contribs) (Rollup on Encryption topics)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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?

Yes, but we're not convinced this is a blockade by Google. All Android Auto head units are encrypted two-way communicators, using the Android Debug Bridge (ADB) for device-to-device communication. This is facilitated by an OpenSSL certificate, that is then vetted by Google Play Services (or Google Mobile Services, aka GMS).

GMS has a file called libsslwrapper.so that vets security certificates. When GMS 9.2 is updated on a device, that is when OpenHU breaks. We can confirm this by swapping in the libsslwrapper.so from GMS 9.0, and suddenly OpenHU works again.

We aren't sure what, exactly, changed in libsslwrapper.so - It's an undocumented API and file. But something changed that is causing self-signed OpenSSL certificates stop working.

Technical experts in the community have raised (and tested) several theories. This is not meant to be a task list, but rather, some theories - and is not all-inclusive.

  • The OpenSSL implementation in OpenHU may be failing due to being out of date
  • The OpenSSL implementation (calls/format/etc) in OpenHU may be malformed
  • The self-signed certificate in Mike Reid's original source code has expired
    • Note: Replacing this certificate with a current certificate does not resolve the issue
  • The updated GMS 9.2 may be validating/searching now for a CA-signed certificate
  • The updated GMS 9.2 may be validating/searching now for an EV-level certificate
  • Google may have implemented a certificate whitelist (though we find this unlikely as libsslwrapper.so from GMS 9.0 still works)

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