AirForce Component Management and Release Platform Overview

Background: In component management and release processes, toolchains are isolated, configuration files are scattered, leading to errors. AirForce aims to improve stability and efficiency.

Component Architecture: The Android app consists of an App shell, regular business components, base business components, base function components, and auxiliary modules/scripts. Rules: upper layers depend on lower layers only; same layer components must not depend on each other.

Baseline Management: Baselines hold a set of component versions, supporting parallel development. Types: public and private. States: Development, Pre‑release (no SNAPSHOT), Released (no SNAPSHOT). Conflict detection uses a traceId; later refined to per‑component mod_number for finer granularity.

Baseline Comparison: Convert component lists to HashMaps keyed by ID, compute added, removed, and changed components via set operations.

Component Management: After publishing, the plugin reports git repo, author, Maven coordinates, version, gradle folder, plugin type, branch, SHA1s, etc., to the AirForce backend, which stores data and notifies via Feishu.

Release Management: Moves from manual Jenkins packaging to AirForce‑driven “bus‑car” releases. Business owners select a candidate version; the platform performs checks, packages, and uploads artifacts automatically.

Build Process: The build plugin distinguishes AirForce releases from local builds via parameters. It dynamically configures classpath and implementation components per baseline. A compare.jar analyzes AAR metadata (class signatures, access, inheritance, method descriptors) to detect API changes, missing methods, or renamed classes before packaging, reducing runtime crashes.

Conclusion: AirForce integrates component management, baseline handling, conflict detection, and automated packaging, streamlining the end‑to‑end mobile development workflow.