# How to Contribute to the LiteRT Project: A Complete Developer Guide

> Learn how to contribute to the LiteRT project by following this developer guide. Sign the CLA, fork the repo, build locally, and submit your PR for our AI edge computing project.

- Repository: [google-ai-edge/LiteRT](https://github.com/google-ai-edge/LiteRT)
- Tags: how-to-guide
- Published: 2026-03-13

---

**Contributing to LiteRT requires signing the Google CLA, forking the repository, building locally using Docker or Bazel/CMake, and submitting a PR that passes the CI checks defined in `.github/workflows/`.**

LiteRT is Google AI Edge’s high-performance runtime for on-device machine learning and generative AI models. If you want to contribute to the LiteRT project, you’ll follow a standard GitHub workflow enhanced with Google’s legal requirements and specific build tooling. This guide walks through the repository structure, development setup, and submission process using actual source paths and build commands from the `google-ai-edge/LiteRT` codebase.

## Prerequisites: Sign the Contributor License Agreement

Before writing any code, you must sign the Google Contributor License Agreement (CLA). This is a mandatory legal step—GitHub will automatically block pull requests from authors who have not completed this process. Once signed, fork the repository and clone it locally to begin development.

## Understanding the LiteRT Architecture

Knowing the repository layout helps you place changes in the correct location. The codebase is organized around several core areas:

- **Core runtime**: C/C++ APIs for model execution and tensor buffers located in [`litert/c/litert_common.h`](https://github.com/google-ai-edge/LiteRT/blob/main/litert/c/litert_common.h) and [`litert/c/litert_tensor_buffer.h`](https://github.com/google-ai-edge/LiteRT/blob/main/litert/c/litert_tensor_buffer.h)
- **External weight handling**: The `weight_loader` namespace containing [`weight_loader/external_weight_loader_litert.h`](https://github.com/google-ai-edge/LiteRT/blob/main/weight_loader/external_weight_loader_litert.h) and its implementation in `external_weight_loader_litert.cc`
- **Build system**: Bazel entry points in `BUILD` files and CMake support via [`cmake_example/CMakeLists.txt`](https://github.com/google-ai-edge/LiteRT/blob/main/cmake_example/CMakeLists.txt)
- **CI/CD**: Automated pipelines in [`.github/workflows/linux_nightly_wheel.yml`](https://github.com/google-ai-edge/LiteRT/blob/main/.github/workflows/linux_nightly_wheel.yml) that build nightly Python wheels

When adding features, locate the appropriate namespace and follow existing patterns in the corresponding header and implementation files.

## Setting Up Your Development Environment

LiteRT supports two build systems: **Bazel** (primary) and **CMake** (alternative). For the most reliable results, use the Docker-based build script that replicates the exact CI environment.

### Building with Docker (Recommended)

The [`docker_build/build_with_docker.sh`](https://github.com/google-ai-edge/LiteRT/blob/main/docker_build/build_with_docker.sh) script provides a one-stop solution for reproducible builds:

```bash
git clone https://github.com/google-ai-edge/LiteRT.git
cd LiteRT
./docker_build/build_with_docker.sh

```

This script performs the following steps as implemented in the CI pipeline:
- Starts a container with the required Python version
- Configures Bazel cache directories (`BAZEL_OUTPUT_BASE`)
- Executes `bazel build` with the `--config=release_cpu_linux` flag
- Packages artifacts into Python wheels in `dist/*.whl`

### Building with CMake

For developers preferring CMake, use the provided example configuration:

```bash
mkdir -p build && cd build
cmake .. -DCMAKE_BUILD_TYPE=Release
make -j$(nproc)
ctest

```

The [`cmake_example/CMakeLists.txt`](https://github.com/google-ai-edge/LiteRT/blob/main/cmake_example/CMakeLists.txt) demonstrates the minimal configuration needed to link against LiteRT libraries.

## Implementing Changes: Extending the Weight Loader

A common contribution involves adding new external weight loaders. The `WeightLoader` abstract class in [`weight_loader/external_weight_loader_litert.h`](https://github.com/google-ai-edge/LiteRT/blob/main/weight_loader/external_weight_loader_litert.h) defines the interface you must implement.

Here is a minimal example showing the required method signatures:

```cpp
// my_weight_loader.h
#ifndef LITERT_MY_WEIGHT_LOADER_H_
#define LITERT_MY_WEIGHT_LOADER_H_

#include "weight_loader/external_weight_loader_litert.h"

namespace weight_loader {

class MyWeightLoader : public WeightLoader {
 public:
  explicit MyWeightLoader(const tflite::Model* model);
  ~MyWeightLoader() override = default;

  absl::Span<const WeightInfo> GetWeightInfo() const override;
  absl::Status PrepareAccess(const WeightAccessRequest& request,
                             LiteRtEnvironmentT* env) override;
  const WeightInfo* FindWeightInfoByBuffer(uint32_t id) const override;
  absl::Status SetExternalWeightByBuffer(uint32_t id,
                                         WeightAccess access) override;
  const WeightAccess* GetExternalWeightByBuffer(uint32_t id) const override;

 private:
  std::vector<WeightInfo> weight_infos_;
  std::unordered_map<uint32_t, WeightAccess> access_map_;
};

}  // namespace weight_loader
#endif  // LITERT_MY_WEIGHT_LOADER_H_

```

Your implementation file (`my_weight_loader.cc`) should follow the patterns in `external_weight_loader_litert.cc`, providing concrete logic for `PrepareAccess()` and weight lookup methods.

## Testing Your Changes Locally

Verify your changes pass the full test suite before submitting:

```bash

# From the repository root, using Bazel

bazel test //...

```

For CMake builds:

```bash
cd build
ctest

```

Running these commands ensures your changes work across the supported build configurations and prevents CI failures.

## Submitting a Pull Request

Follow these steps to submit your contribution:

1. Push your feature branch to your fork
2. Open a pull request against the `main` branch
3. Fill out the PR template with a concise description and reference any related issues (e.g., `Fixes #123`)
4. Confirm your CLA is signed (the check will appear in the PR status)
5. Wait for automated CI workflows to complete—these run the same tests and builds as the nightly pipeline in [`.github/workflows/linux_nightly_wheel.yml`](https://github.com/google-ai-edge/LiteRT/blob/main/.github/workflows/linux_nightly_wheel.yml)
6. Address feedback from LiteRT maintainers; approved PRs are squash-merged according to the policy in [`CONTRIBUTING.md`](https://github.com/google-ai-edge/LiteRT/blob/main/CONTRIBUTING.md)

## Summary

- Sign the Google CLA before opening any pull request to contribute to the LiteRT project
- Use [`./docker_build/build_with_docker.sh`](https://github.com/google-ai-edge/LiteRT/blob/main/./docker_build/build_with_docker.sh) for reproducible builds that match CI exactly
- Extend functionality through established interfaces like `WeightLoader` in [`weight_loader/external_weight_loader_litert.h`](https://github.com/google-ai-edge/LiteRT/blob/main/weight_loader/external_weight_loader_litert.h)
- Run `bazel test //...` or `ctest` locally to verify changes before submission
- Follow the PR template and reference related issues when submitting to `google-ai-edge/LiteRT`

## Frequently Asked Questions

### Do I need to sign a CLA to contribute to LiteRT?

Yes. Google requires all contributors to sign either an individual or corporate Contributor License Agreement before any code can be merged. The CLA check runs automatically on every pull request and will block merging if not completed. You only need to sign once for all Google open-source projects.

### Should I use Bazel or CMake for local development?

Both are supported, but **Bazel** is the primary build system used by the LiteRT team and CI pipelines. Use [`./docker_build/build_with_docker.sh`](https://github.com/google-ai-edge/LiteRT/blob/main/./docker_build/build_with_docker.sh) to run Bazel in a containerized environment that matches the CI exactly. CMake is available via [`cmake_example/CMakeLists.txt`](https://github.com/google-ai-edge/LiteRT/blob/main/cmake_example/CMakeLists.txt) for developers who prefer it, but Bazel offers the most consistent experience with the project's `BUILD` files and test targets.

### What is the typical review process for LiteRT PRs?

After you open a pull request against the `main` branch, automated CI workflows (defined in [`.github/workflows/linux_nightly_wheel.yml`](https://github.com/google-ai-edge/LiteRT/blob/main/.github/workflows/linux_nightly_wheel.yml) and others) run tests, lint checks, and wheel builds. A maintainer then reviews the code, potentially requesting changes. Once approved, the PR is squash-merged into the main branch. Ensure your commit messages follow the conventions described in [`CONTRIBUTING.md`](https://github.com/google-ai-edge/LiteRT/blob/main/CONTRIBUTING.md).

### Where can I find API documentation for implementing new features?

Reference the C and C++ API documentation in `g3doc/apis/*.md` and the header files in `litert/c/` such as [`litert_common.h`](https://github.com/google-ai-edge/LiteRT/blob/main/litert_common.h) and [`litert_tensor_buffer.h`](https://github.com/google-ai-edge/LiteRT/blob/main/litert_tensor_buffer.h). For weight loading extensions, study [`weight_loader/external_weight_loader_litert.h`](https://github.com/google-ai-edge/LiteRT/blob/main/weight_loader/external_weight_loader_litert.h) to understand the `WeightLoader` interface and `PrepareAccess()` method signatures.