I'm a consultant for teams working with embedded Android products.
I'm also available for more traditional mobile development projects, but embedded Android is where I find a lot of teams struggle to find resources.
-
I've found that many companies use Android-based hardware hoping to leverage the Android ecosystem's size, but run into roadblocks when people who are more accustomed to mobile development attempt to design for an embedded use case.
I've spent the majority of my career working on high-profile user facing Android products. I'm familiar with the unique challenges in the space, from old/outdated hardware, to reliability concerns, and more.
I'm available for up to 20 hours a week at this time, please reach out to [email protected]
-
And while I am interested in consulting/contracting, if you are currently searching for full-time embedded Android talent consider reaching out. I've found that when there is already a team in place, having someone familiar with the space available to drive high-level architecture can enable some pretty great outcomes without taking on additional headcount.
I'm recovering from a broken leg, so I can't easily follow a normal Peloton class.
There are guides for running non-Peloton applications on the tablet (which runs Android), but there's no way to keep track of any of my stats.
So I reverse engineered the official applications and found a route to send serial data to and from the bike's sensor module. From there I was able to retrieve live stats, and wrote an app that overlays those stats over other apps
The result is being able to watch content from any app that runs on Android while still getting the same live metrics as you would within the Peloton app
I got called into the administration office for running Linux off a USB stick. It wasn't for anything nefarious, I was hoping could have my development environment stick around, since the Windows environment would reset everything after you logged off
It was clear the principal had no idea what this "Linux" thing was, but the IT person did his best to make it as spooky and evil as possible unfortunately.
I don't remember what came of it, but later in the year a computer virus hit a few computers in the school, and I distinctly remember a multiple people thinking I had done it...
Of course I would never, I was the last person who would want a run in with that IT guy again all. But no call into the office that time, and in retrospect I wouldn't be surprised if it was a simple misconfiguration being called a "virus" since it allegedly only affected teachers' classroom PCs
There's not much to show though, I have a bad habit of not putting stuff in VC "because it's just a quick experiment"... then it becomes a long term project with no backups
I just moved to NYC from Durham, NC, and I braced for the change in COL.
But I don't think it's as bad as people say, and I think a big part is transportation.
The 1 month Metrocard costs about what I was spending on gas in a month of commuting with a 124 Spider (not the most fuel efficient car, but very far from a gas guzzler)
Once maintenance and insurance are included, the Metrocard is cheaper (as I take trips outside of work).
-
I can also walk to most errands I previously had to drive 15-20 minutes for (40+ minutes total after parking and traffic).
Besides saving money, the time saved is pretty valuable
Found the call that added the header for the API key to each request (even with Proguard's obfuscation string literals are preserved, so searching for "x-api-key" worked)
From there I followed the call chain to their transformer, then looked at the input for the transformer and it was loading a subset of bytes read from the same resource as the launcher icon (and sure enough, opening it in a hex editor there was some weird "garbage" that I'm honestly surprised Android doesn't choke on)
Unfortunately I don't have anything that would be helpful
Reverse engineering Android apps is pretty easy because there's a very well defined application format, and a ton of hints about the original source in the bytecode
Your situation sounds a little more complicated than that
I tried to get developer access via a form and never got a response, so I tried sending a message the head of the infotainment on LinkedIn
Thankfully he was able to get my application to the dev site moving... but unfortunately, they required a business use case to get an API key once you had access to the site.
So I tried to pick the API key out of the app.
They had the most novel obfuscation I've ever seen for an app's API key
The key was inside the image data for the launcher icon
There was a weird transformation applied to it too, so instead of trying to reverse engineer it I just fired up Charles and intercepted it from there
With the API key and the documentation for the API from the dev site I was able to write a program that started preconditioning my Volt when I left my apartment (the car was in an attached underground garage, so it'd be at the right temperature by the time I got down)
I've had success with clone ELM327 for reading stuff like RPM in real time, but it is hit or miss.
They're just generally slower and usually missing features of the newest ELM327 revisions.
The problem is if you just search for ELM327, most of them will be clones, so I just use the MCP2515 when I need lots of data, and use the ELM327 for basic stuff
You can get away with ELM327 based readers (the cheap bluetooth/Wi-Fi OBDII readers you see on Amazon/eBay) if you want fairly standard data like speed, and some manufacturer specific data in the form of PIDs (https://en.wikipedia.org/wiki/OBD-II_PIDs)
If you want more involved data, or to send messages, it's mostly sniffing, doing an action, and seeing what changes.
`can-utils` has a nice UI for this, which lets you filter messages that don't change easily.
(Also, I've actually never seen a `.dbc` file before, but it looks like a map of PIDs, usually you [or the community for your car] have to reverse engineer those with the sniffing method, afaik)
-
The ELM327 can technically stream all the CAN messages on the bus and do that type of sniffing, but it has a very small buffer and gets completely hosed with chatty cars.
I personally use the MCP2515 with a Raspberry PI for more involved car hacking.
The electrical modification mentioned is needed for the most common MCP2515 modules because the PI isn't 5v tolerant, but it's an easy enough fix
I have two of them hooked up to a Raspberry PI (one for each of my car's CAN busses, some cars have more), and that with `can-utils` has gotten me pretty far.
Remote: Yes
Willing to relocate: No
Technologies: Android, Embedded Android
Résumé/CV: On Request
Email: [email protected]
I'm a consultant for teams working with embedded Android products.
I'm also available for more traditional mobile development projects, but embedded Android is where I find a lot of teams struggle to find resources.
-
I've found that many companies use Android-based hardware hoping to leverage the Android ecosystem's size, but run into roadblocks when people who are more accustomed to mobile development attempt to design for an embedded use case.
I've spent the majority of my career working on high-profile user facing Android products. I'm familiar with the unique challenges in the space, from old/outdated hardware, to reliability concerns, and more.
I'm available for up to 20 hours a week at this time, please reach out to [email protected]
-
And while I am interested in consulting/contracting, if you are currently searching for full-time embedded Android talent consider reaching out. I've found that when there is already a team in place, having someone familiar with the space available to drive high-level architecture can enable some pretty great outcomes without taking on additional headcount.