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.
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.
Most commodity desktop computers won’t be able to build the Android Open Source Project in less than 4 hours, and most folk are on a budget when they build a new machine, so I’ve put together a few tips which will help you build a machine capable of building the AOSP in two to three hours. WWGD? The first question that most folk ask when considering a machine for building the AOSP is “What Would Google Do?
Buying disks has, if anything, become more confusing recently. Gone are the days when the only question was 2.5" or 3.5", now there are hardware and software interfaces to worry about as well. I’ve recently wandered into the maze of SSD buying, so I thought it might be useful for others if I shared what I learnt; 2.5" or 3.5" These two are relatively simple; They refer to the physical size of the disk housing (the thing which contains the disk itself), and the connector is, for anything recent, SATA.
Many CI systems allow you to build inside a Docker container, but creating the docker image which is used for the container can be a slow process. Various third party resources, like Docker Hub, may have rate limits, and fetching all the updates and new packages over the internet may take a while, but there are a few things you can do which will make building and testing your images faster.