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.

With JCenter closing down folks are looking at alternative places to host their build artifacts, and AWS can easily meet that need. AWS isn’t the only platform capable of hosting Maven artifacts, any hosting provide can do it, but AWS has the ability to scale to high levels and offers a free tier which means that you can get started very cheaply and, if your libraries are really successful, you don’t need to revisit the set-up unless you want to.

12 days after being told by my EM it could happen, something I’ve been expecting to happen for a few weeks has finally happened. Today I was told it is my last day working at Twitter.My EM hadn’t been inviting me to strategy meetings, afaik no-one has been offered a job on the team I was supposed to be seeding (apologies to those I referred), and, in my last few weeks, I was tasked with creating dashboards for management.

Ideas for a healthier engineering environment We’ve all had good and bad work experiences, but how many of us are learning from them? Having recently left Deliveroo I decided to put together some things I thought were good engineering guidelines based on the experiences I’ve had at several companies so I could try to find a future workplace which was in-line with my ideal way of working. Don’t assume you have complete knowledge No-one is part of every conversation in a company, and very few, if any, engineers remember every fact from every conversation they have, so assuming you know all of the reasons behind someones actions is always going to lead to mistakes.