Android Native Client

The Android client lives in clients/kotlin. It uses Jetpack Compose for native Android screens and Kotlin Multiplatform for shared networking, models, caching and a reusable Compose design system. The existing SwiftUI app continues to serve iOS and macOS; sharing its domain layer can happen incrementally.

Available workflows

Android 0.3 exposes all 21 Apple sections with native navigation. It is still a preview rather than full iOS feature parity.

• Mail includes mailbox selection, HTML reading, compose/reply, archive/delete and attachment opening. Documents support uploads and native PDF/image previews, plus system opening/sharing.
• Tasks, calendar and Wiki have native create/edit/delete forms. Tasks include comments, attachments and board/status/assignment controls; calendar supports previous/next week and native date/time pickers.
• Canvas and Word have content-only HTML editors with formatting and save. Whiteboard provides a native drawing surface, sticky notes, movement, zoom/fit and operation-based saving.
• Chat supports Markdown, attachments, tool activity and linked result cards. Coding Agents supports session creation, replies, approval decisions and a separate Changes view. Specialized agents can open their direct chat.
• Image Playground supports provider/model choice, generate/edit prompts and history. Video Studio supports core AI project and scene actions. Social Media supports drafts, account targets and explicit publishing/scheduling.
• Settings provides profile/preferences autosave and language selection on Android 13+. Issue Reporter has an explicit native report form.

Open a record and choose Ask Clapilot to pass its module and selected record into the existing agent chat contract. Lists usually load up to 100 entries; Word loads up to 200, and chat loads the most recent 200 history records. Search filters the loaded list.

Dashboard

The start screen is Dashboard, with task records and this week’s calendar entries. Navigation stays in the app sidebar or bottom navigation; Dashboard does not repeat a module menu or chat-history sidebar. Selecting a dashboard record opens its native module detail and retains the existing Ask Clapilot context.

Navigation and additional modules

Navigation stays available while a module or detail loads. Each module retains its data, selection and search/scroll state; fresh responses are reused for 60 seconds. Refresh keeps the current content visible. Enter just your instance name at login: the form displays the .clapilot.com suffix; custom HTTPS servers are also supported.

Notes supports rich-text editing and an explicit plain-text mode. Rich saves preserve formatting; choosing plain-text mode converts that page to paragraph HTML. Both paths preserve omitted drawing/audio/asset fields. Notes can be deleted through an explicit confirmation. Mail supports compose, reply and forwarding with provider-specific sender identities. Administrators can create specialized agents using a handle, name and instructions. Canvas and Word use their existing rich-document contracts; Canvas saves require the expected revision. Whiteboard sends individual object operations so unrelated objects are preserved.

The common Compose design system supplies native FDS colors, system typography, outlined surfaces, circular controls and canonical navigation icons. Menu order follows Apple. Page transitions use a short fade and respect disabled system animations. The existing Apple clients retain their SwiftUI components.

Foldable layouts

The app adapts to the actual window width, including the cover screen, unfolded screen, landscape and split-screen windows. Larger windows show a navigation rail and list/detail panes. Separating hinges are avoided. Separating horizontal folds can place list and detail in separate screen regions; the composer stays within its conversation pane. Drafts and selections survive activity recreation while the app process remains alive. Opening the keyboard preserves the active pane arrangement and focused editor instead of switching between compact and two-pane chat layouts.

Galaxy Z Fold8 hardware and Samsung One UI behavior require physical-device validation. Layouts do not depend on an assumed Fold8 resolution.

Accounts and privacy

HTTPS is required in release builds. Session cookies are origin-scoped and encrypted with Android Keystore; Android backups are disabled. Passwords are not saved. Transport failures retain the saved session and offer Retry connection; an authentication failure removes local session access. Data visibility remains enforced by the existing server: mail, calendar and chat are personal, while documents and task boards follow existing workspace/shared-private access rules.

Scope and verification

All sections have an entry point, but advanced Apple workflows remain incomplete: live voice, interactive generated UI, room membership controls, drawing/import/sharing tools, complete media editors, account connections, admin/runtime settings, background notifications and process-death recovery. The detailed, maintained inventory is clients/kotlin/PARITY.md.

Local UI tests use deterministic fixtures, including slow navigation and keyboard resize cases. These do not establish production feature parity. Hardware installation, folding, Samsung keyboard behavior and real-account workflows are tracked separately in clients/kotlin/QA.md.

HTML content runs without session cookies or network access. Canvas/Word use a constrained editing bridge; PDF/image previews stay in private app cache. Message drafts allow up to five attachments, with 10 MB per image, 25 MB per audio file and a 32 MB total limit. Logout removes local session access and cached preview files.

The Android app reuses existing agent execution and API contracts. See agent tool contracts and clients/kotlin/README.md for build instructions.

Test distribution and Google Play

Google Play preparation is documented in clients/kotlin/PLAY_RELEASE.md. The Android project can build release AABs with an external upload keystore; clients/kotlin/scripts/build-play-bundle.sh requires all signing credentials, runs checks and verifies the bundle signature. Signing credentials and keystores are not committed. Local preview APKs continue to use the debug certificate.

The intended first distribution track is internal testing. Account registration, app creation, upload signing, reviewer access and store declarations must be completed before a Play rollout. Building a bundle does not publish it. The current Play setup is pending and no tester opt-in link is available yet.