Multi-Flavors and CPU Architectures (ABI)

Enterprise Flutter applications frequently target multiple deployment environments (Gradle product flavors and Xcode schemes) alongside diverse hardware architectures (32-bit and 64-bit Android devices).

The tk-ota-push CLI natively orchestrates the complete multi-flavor and multi-architecture lifecycle (lib/src/cli/publisher.dart and test/flavor_build_args_test.dart), preventing cross-compilation errors and binary ABI mismatches.

1. Advanced Flutter Flavor Management

When your project uses build variants (e.g., dev, staging, prod), the CLI automatically relays the appropriate build flags to Flutter while resolving the matching app_id.

Relayed Build Options (`commonFlutterBuildArgs`)

CLI Option	Generated Flutter Argument	Description
`--flavor <name>`	`--flavor <name>`	Gradle variant (Android `productFlavors`) or Xcode Scheme / Configuration
`-t`, `--target <file>`	`-t <file>`	Dedicated Dart entrypoint (e.g., `lib/main_prod.dart`)
`--dart-define KEY=VALUE`	`--dart-define KEY=VALUE`	Compile-time Dart environment variable (repeatable)
`--dart-define-from-file <path>`	`--dart-define-from-file=<path>`	Configuration file in `.json` or `.env` format (repeatable)
`--build-name <version>`	`--build-name <version>`	Overrides the version name without altering `pubspec.yaml`
`--build-number <number>`	`--build-number <number>`	Overrides the build number without altering `pubspec.yaml`
`-- <arguments>`	`<arguments>`	Relays raw flags directly to Flutter (e.g., `--no-tree-shake-icons`)

Concrete Build Scenarios

# 1. Android Staging Release packaged as an Android App Bundle (AAB)
tk-ota-push release 2.4.0+10 \
  -p android \
  --flavor staging \
  -t lib/main_staging.dart \
  --artifact aab \
  --dart-define-from-file=env/staging.json

# 2. Android Production OTA Patch targeting a specific flavor
tk-ota-push patch 2.4.0+10 \
  -p android \
  --flavor prod \
  -t lib/main_prod.dart \
  --dart-define API_URL="https://api.banking.com" \
  -m "Fix OTP validation timing issue"

# 3. iOS Ad-Hoc Release with custom export method
tk-ota-push release 2.4.0+10 \
  -p ios \
  --flavor dev \
  -t lib/main_dev.dart \
  --artifact ipa \
  --export-method ad-hoc

2. Android CPU Architectures (ABI)

On Android, AOT-compiled Dart code (application binary) is native machine code targeting a specific processor architecture. tk-ota-push provides first-class support for both dominant mobile ABIs:

CLI Identifier (`--arch`)	Android ABI Directory	CPU Architecture	Target Devices
`aarch64`	`arm64-v8a`	64-bit ARM	Virtually all modern smartphones running Android 9+
`arm`	`armeabi-v7a`	32-bit ARM	Entry-level devices, POS terminals, and legacy phones
`all` (default)	Both directories	Multi-ABI	Builds and uploads artifacts for `aarch64` AND `arm`

How `--arch all` Works

By default, the CLI compiles a single multi-arch archive using the Flutter flag --target-platform android-arm,android-arm64.

During extraction, the CLI parses the compiled archive (.apk or .aab):

It extracts lib/arm64-v8a/application binary and computes its SHA-256 checksum.
It extracts lib/armeabi-v7a/application binary and computes its SHA-256 checksum.
It registers two separate releases or patches with the OTA server (arch=aarch64 and arch=arm).

Android build completed.
[aarch64] application binary extracted: 14.8 MB (SHA-256: 4a2b9f...)
[arm]     application binary extracted: 11.2 MB (SHA-256: 9e8c1d...)
Registering Android Release 2.4.0+10 (aarch64)... ✅
Registering Android Release 2.4.0+10 (arm)...     ✅

Why Are Patches Separated by ABI?

A application binary binary compiled for arm64-v8a cannot run on a 32-bit armeabi-v7a CPU (and vice versa). By publishing ABI-specific patches, tk-ota-push ensures:

Each device downloads only the diff payload matching its CPU.
Over 50% bandwidth savings compared to heavy fat/universal diffs.
Zero native crashes (SIGSEGV or SIGILL) at runtime.

3. Android Artifact Types: APK vs AAB

The CLI adjusts its extraction pipeline according to your packaging format via the --artifact option:

APK Format (`--artifact apk`, default)

Underlying Flutter command: flutter build apk --release
Binary path inside ZIP archive: lib/<abi>/application binary
Best suited for enterprise sideloading, private MDM distribution, and local testing.

Android App Bundle Format (`--artifact aab`)

Underlying Flutter command: flutter build appbundle --release
Binary path inside ZIP archive: base/lib/<abi>/application binary
Mandatory for publishing on the Google Play Store.

Using Dart's ZipDecoder from the archive package, tk-ota-push seamlessly inspects both lib/ and base/lib/ paths without requiring manual extraction steps:

# Register a Google Play Store-ready AAB Release
tk-ota-push release 1.0.0+1 -p android --artifact aab --flavor prod

4. iOS Architecture: ARM64 and Runner.app

On iOS, 64-bit hardware is the universal standard:

The target architecture is always aarch64 (arm64).
During a release, the CLI inspects the compiled application bundle Runner.app (located in build/ios/iphoneos/Runner.app or extracted from an IPA archive).
It extracts the App binary from Frameworks/App.framework/App, computes its SHA-256 hash, and generates the diff_base file needed for future differential patches.
During a patch, tk-ota-push compiles app.dill, invokes gen_snapshot_arm64 to produce out.aot, then runs aot-tools.dill link against the cached diff_base to create the final patch artifact patch payload.

1. Advanced Flutter Flavor Management​

Relayed Build Options (commonFlutterBuildArgs)​

Concrete Build Scenarios​

2. Android CPU Architectures (ABI)​

How --arch all Works​

3. Android Artifact Types: APK vs AAB​

APK Format (--artifact apk, default)​

Android App Bundle Format (--artifact aab)​

4. iOS Architecture: ARM64 and Runner.app​