Migrating from v2.0 to v2.1

v2.1 is the Phase 3D release. The Android side now mirrors the iOS SDK shape introduced in v2.0. A single umbrella co.deepvoiceai:dvai-bridge AAR wraps the existing llama / MediaPipe cores plus a new bare-LiteRT backend behind a unified DVAIBridge Kotlin singleton.

Almost every v2.1 change is additive — new umbrella package, new LiteRT backend, new shared-core extraction. The only breaking change hits direct Kotlin consumers of @dvai-bridge/android-llama-core or @dvai-bridge/android-mediapipe-core. The OpenAI-compatible HTTP surface, the JS Capacitor shim, and the iOS SDK are all unchanged.

Quick decision matrix

If you are using…	Migration
@dvai-bridge/core (web)	None.
@dvai-bridge/transformers (web)	None.
@dvai-bridge/capacitor + capacitor-llama / capacitor-foundation / capacitor-mediapipe / capacitor-mlx	None.
@dvai-bridge/ios (Swift, v2.0)	None.
@dvai-bridge/android-llama-core directly (Kotlin)	Add import co.deepvoiceai.bridge.shared.core.* for HandlerContext / DvaiHandlers / HttpServer / CorsConfig.
@dvai-bridge/android-mediapipe-core directly (Kotlin)	Same co.deepvoiceai.bridge.shared.core.* import update.

Most apps fit the first four rows and need no changes.

What's new (additive — no migration needed)

• @dvai-bridge/android — standalone Android SDK. Drop it into a Compose / Views / KMP app, call DVAIBridge.start(...), point your OpenAI client at the returned baseUrl. Public DVAIBridge Kotlin object with the same 8-method surface as the iOS SDK — init, start, stop, status, downloadModel, addProgressListener, removeProgressListener, plus progressFlow / reactive properties. BackendKind enum (Auto / Llama / MediaPipe / LiteRT) with file-extension-based auto-resolution. DVAIBridgeReactiveState exposes StateFlow<*> for Compose / Lifecycle integration. See Android Native SDK guide.
• LiteRT backend (@dvai-bridge/android-litert-core). Bare LiteRT 2.x runtime for Llama-style stateful .tflite / .litertlm checkpoints — distinct from the bundled-task MediaPipe wrapper. Pinned com.google.ai.edge.litert:litert:2.1.4. The LiteRT-LM helper artifact doesn't exist standalone, so token-by-token decoding runs directly on CompiledModel with named tensors (input_ids, causal_mask, logits). Pure-Kotlin tokenizer.json BPE parser — no JNI dep. HF's tokenizers-android JitPack guess doesn't exist, and DJL's HuggingFace tokenizer ships no Android .so. Built-in LLAMA3 + PLAIN chat templates only — SentencePiece / Unigram tokenizers reject at load time. Use the MediaPipe backend for Gemma. See Android Native SDK guide § Backend-specific notes.
• @dvai-bridge/android-shared-core package — extracts HttpServer + HandlerDispatch + HandlerContext + DvaiHandlers
  • HandlerResponse + CorsConfig (with new CorsConfig.fromOpt companion) out of android-llama-core and android-mediapipe-core into a dedicated module. Mirrors the iOS Phase 3C DVAISharedCore extraction. Each core now declares api 'co.deepvoiceai:android-shared-core' so consumers see the moved types transitively. Internal refactor — if you only use the DVAIBridge umbrella you won't notice.

Breaking changes (only affect direct Kotlin consumers of the cores)

1. HandlerContext / DvaiHandlers / HandlerResponse / HttpServer / CorsConfig moved

Previously these public types lived in co.deepvoiceai.bridge.llama.core (and were duplicated under co.deepvoiceai.bridge.mediapipe.core). v2.1 pulls them into a new android-shared-core module — each backend package declares its dependency once and consumers see the moved types through a single canonical import path.

Before (v2.0)

import co.deepvoiceai.bridge.llama.core.HandlerContext
import co.deepvoiceai.bridge.llama.core.DvaiHandlers
import co.deepvoiceai.bridge.llama.core.HttpServer
import co.deepvoiceai.bridge.llama.core.CorsConfig

After (v2.1)

import co.deepvoiceai.bridge.shared.core.HandlerContext
import co.deepvoiceai.bridge.shared.core.DvaiHandlers
import co.deepvoiceai.bridge.shared.core.HttpServer
import co.deepvoiceai.bridge.shared.core.CorsConfig
// Or:
import co.deepvoiceai.bridge.shared.core.*

You don't need to add android-shared-core to your Gradle dependencies {} block manually. Both android-llama-core and android-mediapipe-core re-export it via api 'co.deepvoiceai:android-shared-core' — transitive resolution happens automatically.

Capacitor consumers using @dvai-bridge/capacitor-llama / @dvai-bridge/capacitor-mediapipe don't need to change anything. The plugins thread the new types through internally.

2. BackendKind enum gained .LiteRT

The Kotlin BackendKind enum (in @dvai-bridge/android) now includes LiteRT. If you exhaustively when-branch on it, add a LiteRT -> arm — or an else ->.

That's the only Kotlin-source breaking change visible to apps using DVAIBridge directly. Exhaustive when over a sealed surface was the only public API that could be affected by the new case.

Versioning

All Android module versions are now driven by dvaiBridgeVersion in each module's gradle.properties, propagated by scripts/sync-versions.js from the root package.json. Future bumps touch one file (root package.json) — not five build.gradle files.

CI

.github/workflows/*.yml.disabled are back to .yml. New per-module workflows for shared-core and litert-core. The existing llama / mediapipe workflows now seed shared-core to mavenLocal before running their tests. A new umbrella workflow runs the reflection-based API-shape + selector + progress-broadcaster unit tests after publishing all 4 cores to mavenLocal.

Pre-existing migration

Still on v2.0.x? See v1.6 → v2.0 migration for the iOS SDK + MLX + DVAISharedCore extraction details.