Mobile + AI (Android System IME) • Production Build

Aksira — Custom System-Wide Android AI Keyboard Embedding Flutter in Native Kotlin IME

A system-wide Android keyboard combining a native input method service with an embedded Flutter engine.

AndroidKotlinFlutterSupabaseGemini

Role: Solo mobile, native Android, and edge AI engineer
Production status: Production Android system IME build · package com.aksira.keyboard
Core stack: Kotlin InputMethodService · FlutterEngineCache · Supabase Deno Edge Functions · Gemini 2.5 · Android SpeechRecognizer · Text-to-speech
Business outcome: Built a system-wide Android keyboard that embeds Flutter in a native input method and supports in-place bilingual text transformations without switching apps.

The real-world problem

What the system had to solve

Standard mobile applications only operate within their own isolated application windows, preventing users from receiving AI assistance across third-party apps like WhatsApp or Gmail. Meanwhile, native Android keyboard development is historically restricted to Java or Kotlin UI code that lacks cross-platform flexibility.

What I built

Architecture shaped by the constraints

I developed a custom system-wide Android keyboard by embedding a FlutterEngine inside a native Kotlin InputMethodService. The keyboard communicates with Supabase Deno Edge Functions using request idempotency keys, sub-second latency controls, and cascading Gemini 2.5 model fallbacks for real-time Arabic grammar correction and tone shifting.

Production proof

Delivered system

Fully functional Android system IME build tested across 14+ UI screens, verifying low-latency keystroke handling, zero memory leaks, and stable background engine lifecycle transitions.

System flow

Architecture at a glance

Android InputMethodService

Native Kotlin keyboard lifecycle and operating-system integration.

Embedded Flutter engine

Cross-platform keyboard interface rendered within the native IME.

Supabase Edge Functions

Idempotent requests with Gemini model fallback.

Engineering decisions

Why the system works this way

Pre-warmed Flutter engine in the native IME

Constraint: A cold Flutter engine can take 400–800ms to start inside Android's InputMethodService and visibly freeze the keyboard when a text field receives focus.
What I engineered: Initialized and cached a FlutterEngine during service startup, then attached the warm engine to a FlutterView from onCreateInputView().
Production outcome: Reduced keyboard presentation latency to approximately 30ms across third-party apps.

Server-side model cascade with idempotency

Constraint: Direct client AI calls expose provider secrets and fail unpredictably under throttling or network timeouts.
What I engineered: Sent compact requests through Supabase Deno Edge Functions with request IDs and a Gemini 2.5 Flash-Lite → Flash → Pro fallback cascade.
Production outcome: Kept provider credentials on the server and made retries safe for the credit ledger.

Native bounded speech recovery

Constraint: Android SpeechRecognizer sessions stop after pauses, and Flutter speech plugins require an Activity unavailable inside an IME service.
What I engineered: Implemented a Kotlin coordinator with up to three restarts per 20-second window, an 800ms cooldown, and transcript merging across restarts.
Production outcome: Supported continuous Arabic and English dictation from the keyboard surface.

Discuss a similar system

Product walkthrough

A request from the keyboard to the edge

Step 1 of 3

Native Android bridge

InputMethodService receives the system focus event and attaches a warm FlutterEngineCache instance to the keyboard surface. The source reports an approximately 30ms warm start.