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.
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.
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.
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.
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);
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”).
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.
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.
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.
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.