If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/flutter/engine shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Stale — last commit 1y ago

• 20 active contributors
• Distributed ownership (top contributor 42% of recent commits)
• BSD-3-Clause licensed
• Tests present
• ⚠ Stale — last commit 1y ago
• ⚠ No CI workflows detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live flutter/engine repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/flutter/engine.

What it runs against: a local clone of flutter/engine — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in flutter/engine | Confirms the artifact applies here, not a fork | | 2 | License is still BSD-3-Clause | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 468 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of flutter/engine. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/flutter/engine.git
#   cd engine
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of flutter/engine and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "flutter/engine(\\.git)?\\b" \\
  && ok "origin remote is flutter/engine" \\
  || miss "origin remote is not flutter/engine (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(BSD-3-Clause)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"BSD-3-Clause\"" package.json 2>/dev/null) \\
  && ok "license is BSD-3-Clause" \\
  || miss "license drift — was BSD-3-Clause at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "BUILD.gn" \\
  && ok "BUILD.gn" \\
  || miss "missing critical file: BUILD.gn"
test -f "assets/asset_manager.h" \\
  && ok "assets/asset_manager.h" \\
  || miss "missing critical file: assets/asset_manager.h"
test -f "build/dart/rules.gni" \\
  && ok "build/dart/rules.gni" \\
  || miss "missing critical file: build/dart/rules.gni"
test -f "DEPS" \\
  && ok "DEPS" \\
  || miss "missing critical file: DEPS"
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 468 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~438d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/flutter/engine"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

The Flutter Engine is a portable C++/Dart runtime that executes Flutter applications across mobile, web, and desktop platforms. It implements the core graphics pipeline (using Skia), Dart VM execution, platform channel IPC, accessibility support, and native asset management—serving as the low-level foundation that the Flutter Framework sits atop. Monorepo structured by platform and subsystem: assets/ handles asset bundling, benchmarking/ contains performance profiling tools, build/ holds GN/Dart build rules for cross-platform compilation. The bin/ directory contains CLI tools (et is the engine tester). Core engine code lives in the root alongside language-specific bindings (Java for Android, Objective-C++ for iOS, JavaScript for Web).

Flutter framework developers, engine contributors, and platform engineers who need to fix rendering bugs, optimize performance, add new platform support (Android/iOS/Web), or integrate native code. Also embedders building custom Flutter shells for non-standard platforms.

This repository is archived (per the README). The active Flutter Engine development has moved to flutter/flutter/engine. However, this was historically a mature, production-grade project with extensive CI (see .ci.yaml), comprehensive tests across multiple platforms, and years of contributions. The codebase shows professional patterns (clang-format rules, clang-tidy checks, CONTRIBUTING.md).

Critical Risk: This repo is no longer maintained—all engine work has migrated to flutter/flutter/engine. Opening PRs here will not be merged. The archived status means you cannot rely on it for bug fixes or security patches. If you're working on Flutter engine contributions, you must use the new monorepo location instead.

Nothing—this repository is archived. Active development occurs at https://github.com/flutter/flutter/tree/master/engine. If you see recent commits here, they are likely mirrors or documentation updates only. Check the new monorepo for current work on rendering, Dart VM updates, and platform integrations.

⚠️ Do not clone this repo for active development. Instead, clone the active repository: git clone https://github.com/flutter/flutter.git && cd flutter/engine. For historical reference only: git clone https://github.com/flutter/engine.git && gclient sync (uses depot_tools for dependency management, as indicated by DEPS file).

Daily commands: This repo is archived and cannot be built independently. Historical build process used GN: gn gen out/linux_debug && ninja -C out/linux_debug (platform-specific targets in BUILD.gn). For current development, follow instructions in https://github.com/flutter/flutter/tree/master/engine.

• BUILD.gn — Root build configuration for the entire Flutter engine; understanding GN build targets and dependencies is essential for any contributor.
• assets/asset_manager.h — Core abstraction for asset loading and resolution; foundational to how Flutter apps access resources at runtime.
• build/dart/rules.gni — Dart compilation and snapshot generation rules; critical for understanding how Dart code is built into the engine.
• DEPS — Dependency management and third-party library pinning; defines all external dependencies the engine relies on.
• README.md — Provides essential context that this repository is archived and the engine was migrated; prevents wasted effort on a deprecated codebase.
• build/secondary/flutter/third_party — Aggregates all third-party library integrations (benchmark, flatbuffers, glfw, imgui, etc.); understanding these dependencies clarifies engine capabilities.
• CONTRIBUTING.md — Documents contribution guidelines, code review expectations, and development workflow for the Flutter engine.

Add a new asset resolver strategy

1. Create new resolver class implementing the abstract interface (assets/asset_resolver.h)
2. Add concrete resolver implementation (similar to directory_asset_bundle.cc) (assets/asset_manager.cc)
3. Register resolver in asset_manager initialization (assets/asset_manager.h)
4. Add unit tests for new resolver strategy (assets/native_assets_unittests.cc)
5. Update BUILD.gn to include new resolver source files (BUILD.gn)

Add a new Dart compilation target

1. Define Dart build rule in the appropriate component's BUILD.gn (build/dart/rules.gni)
2. Specify snapshot generation parameters and output artifacts (build/dart/internal/flutter_snapshot.gni)
3. Configure frontend server invocation if custom compilation is needed (build/dart/internal/flutter_frontend_server.gni)
4. Add corresponding test definition for the compiled target (build/dart/internal/dart_test.gni)

Integrate a new third-party library

1. Add library path to DEPS for version pinning (DEPS)
2. Create BUILD.gn wrapper in build/secondary/flutter/third_party/<lib>/ (build/secondary/flutter/third_party/benchmark/BUILD.gn)
3. Reference the new dependency from main BUILD.gn targets (BUILD.gn)
4. Document the integration and update CONTRIBUTING.md if special setup is needed (CONTRIBUTING.md)

Add a new platform-specific build configuration

1. Create platform config file in build/config/<platform>/ directory (build/config/fuchsia/gn_configs.gni)
2. Define platform-specific compiler flags, include paths, and library paths (build/config/fuchsia/gn_configs.gni)
3. Reference the config in root BUILD.gn conditional on target platform (BUILD.gn)
4. Add CI pipeline configuration for the platform in .ci.yaml (.ci.yaml)

• GN Build System — Chromium's GN provides fast incremental builds and cross-platform toolchain management essential for a portable runtime targeting mobile, web, and desktop.
• Dart VM Runtime — Executes Flutter application code with JIT/AOT compilation, providing performance and fast iteration cycles during development.
• Skia Graphics Engine (via third-party) — Provides hardware-accelerated 2D graphics rendering and layer composition across all platforms with consistent visual output.
• FlatBuffers Serialization — Enables efficient inter-process communication and data serialization between engine components with minimal overhead.
• C++ (engine core) — Provides performance-critical runtime implementation with low-level platform integration and memory efficiency required for mobile and embedded platforms.

• Architecture is archived; engine was migrated to flutter/flutter/engine

  • Why: Consolidating multiple repositories into a monorepo simplifies dependency management and CI/CD for the Flutter team.
  • Consequence: This codebase is now read-only for historical reference; active development occurs in the Flutter repository.

• Snapshot-based Dart compilation for release builds

  • Why: Reduces startup time and APK/app bundle size by pre-compiling Dart to machine code.
  • Consequence: Trade longer build times and increased build artifact complexity for better runtime performance.

• Separate asset resolution abstraction layer

  • Why: Allows multiple asset bundle strategies (file-based, memory, network) without coupling to a specific transport.
  • Consequence: Adds abstraction overhead but enables flexible asset delivery mechanisms for different platforms.

• Does not provide UI widget framework (that is flutter/flutter repository)
• Does not handle app-level state management or reactive programming model (handled by Flutter Framework)
• Does not provide platform plugin system at this level (plugin bridge is in framework layer)
• Not a standalone graphics library; graphics are tied to Flutter rendering architecture
• Does not support real-time collaborative editing or live reload at engine level (dev mode features in framework)

This is an archived repo—no active development. If you attempt to contribute: (1) Builds require depot_tools (gclient), not just standard package managers; (2) Platform-specific builds (Android requires Android NDK, iOS requires Xcode) with version constraints in DEPS; (3) Dart SDK version pinned in DEPS—mismatches cause mysterious build failures; (4) No guarantees on CI—infrastructure may not run.

• Skia Graphics Pipeline — Flutter renders all UI through Skia's canvas abstraction—understanding layer compositing, rasterization, and GPU backend selection is critical for optimization and debugging rendering issues
• Dart VM Snapshot & AOT Compilation — The engine uses Dart snapshots (JIT) for development and AOT binaries for release—core to fast startup and code size; see build/dart/internal/dart_test.gni and flutter_snapshot.gni
• Platform Channels (Method Channel IPC) — Dart-to-native communication happens via named channels using binary serialization—required for any native integration (camera, sensors, payments); implemented across platform-specific layers
• Asset Resolution & Bundling — Apps package assets (images, fonts, JSON) via the asset resolver—engine must locate them efficiently; asset_manager.cc handles path resolution, caching, and platform-specific loading
• GN (Generate Ninja) Build System — Flutter Engine uses GN for cross-platform builds, not CMake or Make—critical to understand target dependencies, platform-specific rules, and GN templating for contributions
• Depot Tools & DEPS Management — Multi-repository synchronization via gclient sync and DEPS file—engine pins exact versions of Dart, Skia, and other dependencies; version mismatches break builds silently
• Warm-up vs. Actual Metrics in Benchmarking — Performance tests use warm-up iterations to reach steady state before measuring—critical for interpreting benchmark results without JIT compilation noise; see benchmarking/benchmarking.cc

• flutter/flutter — The active Flutter Framework and Engine monorepo—this is where all current engine development happens; the archived repo is obsolete
• google/skia — Graphics rendering library used by Flutter Engine for 2D drawing and composition—vendored dependency
• dart-lang/sdk — Dart runtime and compiler—integrated into the engine via DEPS; provides VM execution and hot reload
• flutter/plugins — Ecosystem of platform channel plugins (Firebase, camera, geolocation)—depend on engine's platform channel IPC

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive unit tests for native_assets.cc/h in assets/

The assets/ directory contains native_assets.cc and native_assets.h but only has native_assets_unittests.cc. Given that native assets are critical for Flutter's plugin architecture and platform integration, the test coverage appears minimal. This PR would add thorough unit tests covering edge cases for asset loading, validation, and error handling across different platforms (iOS, Android, Web, Desktop).

• [ ] Examine existing native_assets_unittests.cc to identify coverage gaps
• [ ] Add tests for error conditions (missing assets, corrupted files, permission issues)
• [ ] Add platform-specific tests for iOS/Android native asset resolution
• [ ] Add tests for concurrent asset loading scenarios
• [ ] Ensure tests integrate with BUILD.gn for CI/CD execution

Refactor and document the Dart build system in build/dart/

The build/dart/ directory contains multiple internal GN templates (application_snapshot.gni, dart_test.gni, flutter_frontend_server.gni, flutter_snapshot.gni) but lacks documentation. These are core to the Dart compilation pipeline. This PR would create a BUILD.md or similar documentation file explaining the purpose of each template, their dependencies, and provide examples of how they're used.

• [ ] Create build/dart/README.md or ARCHITECTURE.md
• [ ] Document each .gni file: purpose, inputs, outputs, and dependencies
• [ ] Add examples of how flutter_snapshot.gni and flutter_frontend_server.gni interact
• [ ] Document the dart_test.gni template and its role in test execution
• [ ] Link from main README.md to this build system documentation

Add missing platform-specific integration tests for asset_manager.cc

The assets/asset_manager.cc/h manages asset resolution across platforms, but there's no evidence of platform-specific integration tests (beyond unit tests). This PR would add integration tests in build/dart/test/ that verify asset loading works correctly with actual BUILD.gn asset declarations on Linux, macOS, Windows, iOS, and Android platforms.

• [ ] Create platform-specific test cases in build/dart/test/BUILD.gn for asset loading
• [ ] Add test fixtures for various asset types (fonts, images, manifests)
• [ ] Test asset_manager with directory_asset_bundle and other resolvers
• [ ] Add tests verifying asset resolution respects platform-specific paths
• [ ] Integrate tests into .ci.yaml for automated platform coverage

Do not contribute to this archived repo. Instead, work on the active engine at https://github.com/flutter/flutter/tree/master/engine. However, for learning: (1) Study assets/native_assets.cc and add missing unit tests in assets/native_assets_unittests.cc to cover edge cases in native library loading; (2) Document the GN build system by adding comments to build/dart/internal/dart_test.gni explaining test generation parameters; (3) Add platform detection tests in the benchmarking suite (benchmarking/benchmarking_test.cc) for unsupported platform graceful failures.

The Flutter Engine repository appears to be a well-structured C++ project with standard open-source security practices in place (CODEOWNERS, contributing guidelines, license). However, the critical issue is that this repository is archived and no longer actively maintained. The main security concern is the migration status - users should transition to the actively maintained flutter/flutter/engine repository to receive security patches. No obvious hardcoded secrets, SQL injection risks, or exposed sensitive configuration files were detected in the provided file listing. Secondary concerns include auditing Python build scripts and ensuring GN build configurations are properly validated. The codebase appears to follow reasonable security conventions for a large C++ project.

• Medium · Archived Repository Warning — README.md. The repository is marked as archived and the engine has been migrated to flutter/flutter/engine. Continuing to use this archived version may result in missing security patches, bug fixes, and feature updates that are available in the actively maintained version. Fix: Migrate to the active flutter/flutter/engine repository to ensure you receive timely security updates and maintenance.
• Low · Python Code Quality Configuration Present — .pylintrc, .style.yapf. The repository contains .pylintrc and .style.yapf configuration files, indicating Python scripts are used in the build process. While this is not inherently a vulnerability, Python build scripts should be reviewed for injection risks and secure coding practices. Fix: Audit Python build scripts (particularly in build/ directory) for command injection vulnerabilities, especially in files like build/git_revision.py, build/generate_coverage.py, and build/dart/tools/dart_pkg.py.
• Low · Build Configuration Complexity — BUILD.gn files throughout repository, build/config/, build/secondary/. The repository uses GN build system with complex configuration files scattered across multiple directories. This complexity increases the risk of misconfiguration and potential build-time injection attacks if build scripts are not properly validated. Fix: Implement secure build practices: validate all external inputs to build scripts, use pinned versions of dependencies, and regularly audit BUILD.gn files for suspicious patterns.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.