THE UK EV INFRASTRUCTURE NEEDS A LOT OF WORK

After an attempt to do a 170 mile round trip in my Nissan Leaf, it has now been consigned to a life of “less than 100-mile total distance” trips only. The first leg was fine up until the charge point. The initially selected InstaVolt charger was “temporarily out of service”, and a nearby ChargeYourCar charger was unfathomable to get working as the “Pay by Phone” phone number on the unit wasn’t working.

SO I DECIDED TO GET AN EV

After driving traditional combustion engine cars for more years that I care to mention I decided to take the plunge into the world of EVs. Given the moral positives and government encouragement I thought it’d be an easy switch; Go to a garage, trade my car in, arrange a wallbox installation, wait, profit. Unfortunately I was very wrong about how consumer friendly the process of switching is. This wasn’t a spur of the moment thing. I’d spent months looking at Teslas, Polestars, and drooling over the Kia EV6, but, in the end, I went for what I thought would be a sensible option; A Nissan Leaf. The Leaf family has been in production for over a decade, with the latest generation released three years ago, so, to me, that seemed like a strong signal that it would be a solid car and Nissans’ UK dealer network would be easily able to support EV owners. As with everything signals are not guarantees.

DISAPPOINTED WITH THE PIXEL 6

Having been a mobile ‘phone owner for more than a couple of decades, and recently “upgrading” to a Pixel 6 due to my old Pixel 3 going out of the security update support, I have to say I’m disappointed with where we’re at with Android phones. I’ve been writing code for Android since its public release. I owned a G1, I’ve owned companies which helped device manufacturers, so I understand some of the challenges. With all this knowledge I still feel we’re falling short of where Android could have been.

WHY YOU SHOULDN'T AUTO-INCREMENT YOUR DEPENDENCIES

Recently I saw this tweet which advocates for something I consider a dangerous development practice; Not fixing your builds to a version of its dependencies. There are three main reasons why I consider this dangerous; Supply chain attacks (e.g. 5 in https://dni.gov/files/NCSC/documents/supplychain/Software_Supply_Chain_Attacks.pdf) It breaks the Reproducible Builds principle (Tag X won’t build the code shipped to users after any new library release) It could cause unexpected build breakages unrelated to code changes. The most serious but least common is the first. Most developers, at some point, test on a device with VPN/CorpNet access, and so any malicious code would have access to a companies internal LAN.

ANDROID AUTOMOTIVE OS S

As part of my work at Snapp Automotive I’ve been helping create tools and process to make Android Automotive OS development easier. The tools and processes we have allowed us to create an Android Automotive OS version ‘S’ emulator in less than a day once Google had released the Android ‘S’ source code. Here are some screenshots showing the previous release (R, on the left), and the new version (S, on the right);

WHAT IS "LEVEL WORTHY"?

Over the weekend Gergely Orosz tweeted about “Promotion Driven Development”, which is a problem in many large tech companies, and is tightly coupled with one of my least favourite concepts from my time in large tech; Whether everything you do is “Level Worthy”, and how that shapes your work even if you’re not looking to be promoted. What are levels? For those of you who haven’t experienced large companies, they tend to grade people based on specified skill levels (the various levels are sometimes called a “Career Ladder”). You get promoted (go up the ladder) by doing work that maps to the level above where you’re currently considered to be, and you usually get shown the door if you’re not performing at the level you’re being paid for. Most companies want to see a couple of performance cycles worth of “above level” performance before promoting you; Slipping down a level is rarely an option, so they’d rather make sure you can handle the promotion as opposed to losing someone valuable because they couldn’t sustain their “above level” performance.

ADB BACKUP REMOVAL

Today I’ve submitted a patch to the AOSP to continue something which was probably, externally, one of the least popular things I did while I was at Google; Start eradicating adb backup support from Android devices. Why? The reason is I think it’s dangerous. Not for everyone, certainly not for a majority of folk, but for a small number of people there is a use case which I see as having potentially very serious consequences; Whistle-blowers, dissidents, and potentially even journalists reporting from less than friendly countries.

WORKING WITH ANDROID FIRMWARE

Occasionally I get asked “How do I make my own Android build?”. In this post I’m going to give you some tips and information which will hopefully give you a better idea of what’s needed. Step 1: Check your setup First off you’re going to need a machine capable of running Linux and has at least 500 GB of disk space and 16 GB of RAM. I’ve written a post before about what type of hardware is ideal, but, if you want to just test the water, you can use any machine with those specs.

BIG BUILD FARM ON A BUDGET

Being able to push a change to a server which builds and tests it can free you up to do other things, but getting the machines together to create a build farm for any large build can be expensive. If you have a long build, like the Android Open Source Project, a “from clean” build can take hours even when you have a powerful machine and a well designed build. There is a way to reduce those costs significantly though using a reference build and the overlay filesystem.

WHAT MAKES A GOOD BUILD

I’ve seen a number of different approaches to building programs, and between writing about the specifications of an Android firmware build machine, and how to create a cost-effective build farm, I thought it’d be worth covering a few things that I believe are important when trying to create a scalable build for your software. What is a “build”? When I talk about a build I mean the instructions that tell a machine how to take your source code and create an executable program. Not all languages need a build; Python, for example, allows you to write your program in a file and run it, but many languages (Java, Kotlin, C, Swift, etc.) need a set of instructions to convert the source code from a human-readable form into a machine form that users can then run.