Sources: To improve security, Google's making it (slightly) harder to contribute code to Android

By now, I'm sure you're aware that the Android operating system running on your phone is based on open source code provided by Google. The Android Open Source Project (AOSP) comprises the core OS framework, libraries, apps, and other files necessary to boot the Android OS on mobile phones and other devices with compatible hardware. The majority of AOSP code is licensed under Apache 2.0, a permissive license that allows anyone to freely use, distribute, and modify the code. 

Although AOSP is open source, Google chooses to develop large parts of the OS in private, only breaking their silence with source code drops every quarter (for Quarterly Platform Releases) and once a year (for major platform releases). New features and APIs are introduced to Android based on feedback and interest from users, developers, and device makers, but it's Google that oversees the bulk of this development and decides what code is ultimately added and what isn't.

That doesn't mean that external contributors (read: non-Googlers) are barred from contributing code to Android, though. In fact, almost anyone can contribute code to AOSP, though you'll have more luck getting your code committed if you're trying to fix a bug or security issue. Occasionally, Google even commits code from external contributors that implements new features, such as when Samsung introduced code in Android 12L that enabled dragging-and-dropping an app's notification to launch it in split-screen mode.

Google has detailed guides on how to download, build, and contribute code to AOSP over on source.android.com, but one thing I wanted to point out is how code ends up getting committed to AOSP. The exact process is documented by this chart I pulled from the "life of a patch" page.

I know there's a lot of steps here, so let's instead look at an actual code change submitted by an external contributor that got committed to AOSP. LineageOS developer Nolen Johnson submitted a patch to AOSP that fixes an issue with Bluetooth on the ADT-3, an Android TV development device. Since Nolen is an external contributor, he didn't have the ability to merge the code himself. 

Even if he was a Googler, though, his code would still need to be reviewed by other Googlers, especially those working on the specific component that the patch modifies (in this case, the AOSP Android TV device tree). Before the patch could be merged, it had to be given approval by one of the people listed in the OWNERS file for the affected component. Requiring code-owner approval before a patch can be committed is a good thing, as it ensures that people directly responsible for maintaining the affected file get to decide if the code should be merged. 

AOSP is a large and complex project with many intertwining parts, though, so sometimes bugs and even security vulnerabilities can slip by in code that was submitted by an external contributor and reviewed/approved by a single Google reviewer. That's why, according to two sources familiar with the matter, Google is going to make it slightly more difficult for external code contributions to make their way into AOSP. Evidently, starting next month, all external code contributions to AOSP will require approval from two Google reviewers before they can be submitted. The goal is to improve the security of AOSP's software supply chain and hopefully reduce the number of bugs and vulnerabilities that are inadvertently introduced and caught through techniques like fuzzing.

Google did not respond to a request for comment when I reached out to them regarding this change.

Thank you for your continued support. I decided to make this post a "timed exclusive" because I want developers in the open source community to be aware of this upcoming change. Restricting it to subscribers forever would be counterproductive, which is why this post will go public on Monday for everyone to read.