AirForce Component Management and Release Platform Overview

The document describes the AirForce platform, which was created to solve information silos and cumbersome configuration files in component management and release processes for a large Android application.

Component Architecture : The app is divided into an App shell (main component), regular business components (e.g., user center, community, home), base business components (shared utilities such as BaseActivity, sharing, analytics), base function components (pure utility libraries like logging, file upload, networking), and auxiliary modules/scripts that define dependencies and version management.

Rules: higher‑level components may depend on lower‑level ones, but not vice‑versa, and components on the same level must not depend on each other to ensure decoupling.

Baseline Management : Baselines group a set of component versions, enabling parallel development. Two baseline types exist – public (shared) and private (forked for testing). Baselines have three states – Development, Pre‑release, and Published. Conflict detection originally used a traceId (UUID) attached to each change request, but high conflict rates led to a finer‑grained approach using a modification number (mod_number) per component record.

The platform provides a baseline comparison feature that converts component lists into HashMaps keyed by ID, computes added, removed, and changed components via set operations, and presents the results visually.

Component Management : After a component is published, the Gradle plugin reports metadata (git repo, author email, Maven coordinates, version, build folder, plugin type, branch, SHA‑1 hashes, etc.) to the AirForce backend, which stores the data, syncs commit info from GitLab, and sends notifications.

Release Management : The traditional release model required manual coordination between release engineers and business lines, leading to long cycles and errors. AirForce introduces a “shuttle release” model where business‑line owners select a candidate version, the platform performs checks, and release engineers only maintain basic version and date information. The system also integrates component checks during packaging to prevent runtime crashes.

Packaging Flow : Before AirForce, builds were performed manually in Jenkins, with static configuration and no distinction between test and production packages. AirForce centralizes build configuration, allowing dynamic classpath and implementation component selection per baseline. It supports both AirForce‑driven releases and local builds, intercepting baseline parameters in Gradle to keep plugin compatibility.

A pre‑packaging task generates component metadata (class signatures, access flags, inheritance, interface implementations, method descriptors) and runs a compare.jar to detect API changes, missing methods, or renamed classes across AARs, preventing runtime exceptions. Detected issues are reported as JSON and uploaded for notification.

Conclusion : AirForce ties together component management, baseline handling, release planning, and automated packaging, reducing manual effort, improving traceability, and enhancing overall development efficiency.