Third Party Reviews for Android

Where can third-party code be stored?

Only Apache-licensed code with the AOSP header can be included in the Android codebase outside of the dedicated third-party directories listed in this section.

If you don't have a really good reason to store it elsewhere, other code under one of the permitted licenses belongs in platform/external. That said, third-party source may also be stored in the following places in Android: toolchain/*, kernel/*, bionic/*, libcore/*, vendor/*, hardware/*, system/timezone/*, bootloader/* and device/*.

How to add new third party code to Android

Follow the below steps to create a special Gerrit change in the third-party-removed* project*.

NOTE: Different from the normal Gerrit review process, the importer is responsible for preparing/updating a complete repository containing the library to be imported while only the third party plugin is able to create and update the Gerrit change.

After the change is ready. The Licensing, Security, and Platforms teams will +1 the change. The architecture review committee (emailremoved@) will provide their approval. The Android Build Team have the final approval by way of fulfilling the request and creating the project after the other reviewers approve.

Third-party review step by step

  1. Stage the repo you want to add on Git-on-Borg. For example, to fork boringssl from GitHub to Git-on-Borg:

    $ gob-ctl create user/USERNAME/my-boringssl -reader all_users -fork https://github.com/google/boringssl.git

    See the gob-ctl User Manual for installation instructions if you don't have gob-ctl.

    If upstream isn't a Git project, omit the -fork:

    $ gob-ctl create user/USERNAME/my-non-git-project -reader all_users

    You can verify your repo was properly staged at link.

  2. Ensure that a LICENSE file exists at the root of the repo with the full text of the project's license. If the license is already present but named something else like COPYING or LICENSE.txt, add a symbolic link called LICENSE pointing to the existing file. Do not copy the existing file because they'll get out of sync. In the (unlikely) absence of an existing file, add a LICENSE file yourself.

    If the package is dual licensed then please follow the guidance on go/thirdpartylicenses#same.

  3. Use touch to create an empty MODULE_LICENSE_xyz file, where "xyz" is the license type, for example, MODULE_LICENSE_BSD, MODULE_LICENSE_GPL, or MODULE_LICENSE_APACHE2.

  4. Please create a METADATA file at the root of the repo. See go/thirdparty/metadata for a detailed explanation of the METADATA file and its fields.

    For github projects, the version field should be either an exact tag or a SHA. The semi-automated update process will upload a change whenever the upstream github project creates a newer tag if you use a tag, or to the latest SHA every few weeks if you use a SHA.

  5. Please add an OWNERS file to the root of the repository with the email addresses of at least two full-time Googlers. Refer to go/thirdparty/documentation#owners for more information.

  6. Update the staged repository to include the necessary files, e.g. user/USERNAME/reponame:

    git clone sso://user/$USER/my-boring
cd my-boring
# add/change the necessary files
git add .
git commit -m "Add metadata files"
git push origin main

  7. Use the admin page to add third-party code to Android Internal. Click the CREATE THIRD-PARTY CHANGE button and specify which staged repo to stage for review, which branch, and the name of the destination repo. For example:

    • Source Repository Url: "user/USERNAME/reponame"
    • Source Branch: "main"
    • Target Repository Name: "platform/external/reponame"

    If you are creating the project on more than one instance, such as AOSP and internal, just stage your code on Internal and add a comment in the change about the full set of hosts for project creation as a hint.

    NOTE: The "Target Repository Name" will be used directly during the clone. For example, if the expected repository is "platform/external/reponame", then the "Target Repository Name" should be exactly the same.

    NOTE: There isn't a visual indication that the repository is created when you click 'Confirm', and it might take a while to create the change. You can check this page to see your change's creation.

  8. After the change is created, it can be updated with the current content of the source branch of the source repository using the Third-Party: Sync button.

    The target repository can be renamed using the Third-Party: Rename button.

Third-Party: Sync button location

  1. After the change is ready, mandatory reviewers will review, and may ask you questions in the change. It helps to include some context explaining why you need the new project (a bug or doc link, for example).

    Please hold on to the change until the following 3 reviews are done:

    • Android-Architecture-Review
    • Security-Review
    • Third-Party-Review

    Escalations: if any reviewers take longer than 48 hours from the time that they were added to the change, ping the reviewer first, and if that fails:

    Third Party Review: emailremoved@

    Security Review: emailremoved@

    Anything else: emailremoved@

  2. Once you have all the reviews, someone from the build team will appear and give you Android-Build-Review +1. If they don't, ping the interrupt person on call.

    They'll also create a bug in issuetracker where they will ask for the following information:

    • The complete external source URL. Hint: You can copy+paste the source URL from the METADATA file. (example: https://github.com/shyiko/ktlint.git)

    • The name of the source branch (which they will assume is master, but in the rare cases where this isn't true you can correct them)

    • The target server(s): internal, AOSP, and/or partner

    They will set up the upstream-master branch to make updates easier.

    Once this bug is marked fixed, you will need to add your project to the appropriate repo manifest (AOSP or internal). See go/repo-manifests-explained for an explanation about repo manifests, and go/android-manifest for details on how to modify repo manifests.

    At this point, you can abandon your change on third-party-*removed* by using the Abandon button.

    For ongoing maintenance, the developer can create merge commits with, e.g.:

    git merge --no-ff --allow-unrelated-histories aosp/upstream-master

    And upload, review like any regular changes.

For issues with this policy or tooling, please email emailremoved@.

Reviewer standards

Please ensure that the repo to be cloned to platform/external only includes files under the following licenses. It is ok if the repo has many licenses as long as they all fall under one of the below.

If you see any other license types, or notice licensing abnormalities, please escalate for license review by adding "License-Escalation" to the Reviewers in the pending Gerrit. "License-Escalation" corresonds to the review assigner, emailremoved@. Alternatively, for a longer discussion you can email emailremoved@, referencing the linked change.

Any code that is released under a "public domain dedication" other than the Unlicense or CC0 or 0BSD must be escalated to emailremoved@.

  • Apache/Apache2
  • BSD
  • MIT
  • Eclipse Public License
  • LGPL 2.1
  • GPL 2.0
  • GPL 3.0
  • LGPL 3.0
  • Python Software Foundation License ("Python License")
  • ISC
  • Clang/LLVM
  • Unlicense
  • CC0
  • Any of the other 'notice' licenses listed under go/thirdpartylicenses#notice

What to do if you receive a message that the presubmit triggered

If the code has been flagged for non-Apache2 licensing, please review the above sections of this page as well as the guide below:

If the code is licensed under a non-Apache2 license? Do not submit the code.

You may either: Remove non-Apache 2 licensed portion of the code OR Submit the code to the appropriate third-party directory.
If you are unsure, please email emailremoved@ and -1 vote the code. If another review has given a +2 in error, you may need to vote -2.

If you are sure that the warning is a false-positive, and there is no other license than Apache2: You may submit once any two Android Engineers vote +2 on the Open-Source-Licensing label. Note that two +2 votes on the Code-Review label are not enough to trump the -1 vote on the license label. In addition to the vote, you can type a message explaining your decision.

If you aren't sure whether this is a false positive or an actual licensing issue: please email emailremoved@