Incremental Jetpack Compose adoption

[criticalAY]

Jetpack Compose for AnkiDroid incrementally, starting with a new shared :ui-compose module that houses the theme bridge and reusable UI components. Existing Views/Fragments stay; new screens and migrated leaf screens render in Compose hosted inside the current Fragment shells via ComposeView.

FYI: At I/O 2026 Google formally moved Android UI to "Compose First":

• Android Views, Fragments, RecyclerView, ViewPager, and android.widget are in maintenance mode critical bug fixes only, no new features (source).
• All new Android Studio UI tooling targets Compose (Layout Editor / Navigation Editor are frozen).
• Compose BOM 2026.04.01 (Compose 1.11) ships Grid, FlexBox, Style API, faster SlotTable runtime (release notes).
• The official guidance is interop-first incremental adoption via AndroidView / ComposeView (interop docs).

What its worth, AnkiDroid is well-positioned: AGP 9, Kotlin 2.3, minSdk 24, no Hilt/Dagger lock-in, view binding already enabled, small custom-View footprint.

Proposed approach

Phase 0 Foundations

• Enable Compose in :AnkiDroid build (compose BOM, kotlin-compose plugin, buildFeatures.compose = true)
• Create :ui-compose module (theme + shared components)
• Document conventions in docs/development/compose.md

Phase 1: Pilot leaf screens (separate PRs, one per screen)

Low-risk, no shared state, prove the patterns:

• AboutFragment (static content)
• LoadingDialogFragment, AsyncDialogFragment (dialogs)
• PageFragment (WebView + toolbar- proves AndroidView interop) ,etc

Phase 2: Mid-complexity

• Settings sub-screens (will need a strategy for custom Preference subclasses)
• Info / help screens

Phase 3: Lists

• Card Browser, Deck Picker- LazyColumn / LazyVerticalGrid

Phase 4: Stateful surfaces

• Reviewer, Note Editor, last, when patterns are well-established

New module: :ui-compose

AnkiDroid already has a :common / :common:android pattern, but a Compose-specific module deserves its own root-level name because its purpose is UI building blocks, not "common utilities." I'd propose:

ui-compose Module Implementation Tasks

• Build Setup

  • build.gradle: Apply kotlin-compose, set compose=true
  • src/main/AndroidManifest.xml: Add baseline manifest

• Theme (theme/)

  • AnkiTheme.kt: MaterialTheme wrapper
  • ThemeBridge.kt: Styleable & attribute reading helpers
  • res/values/compose_theme_attrs.xml: The <declare-styleable>

• Core Components (components/)

  • AnkiTopAppBar.kt: Unified toolbar style
  • AnkiAlertDialog.kt: AppCompat dialog convention wrapper
  • AnkiButton.kt: Text/filled buttons matching ?colorAccent

• Text Utilities (text/)

  • HtmlText.kt: AnnotatedString.fromHtml + custom link styles

• Previews & Testing

  • preview/AnkiPreviews.kt: @Preview helpers and theme variants
  • src/test/: Screenshot baselines for isolated components

:common semantically means "non-UI shared code." Putting UI components there is misleading. :ui-compose is unambiguous and matches Now in Android's core/designsystem convention.

[criticalAY]

1. State holder Fragment-held mutableStateOf for pilots, or commit to ViewModel + StateFlow from day one? (I prefer to do complete compose way @david-allison )
2. Navigation keep PreferenceFragmentCompat and Fragment transitions indefinitely, or plan an eventual move to Navigation Compose? (OPen to opinions)

[BrayanDSO]

CardInfoFragment (read-only info chance to try Compose 1.11 Grid)

That's an Anki web page

---

I don't like adding the Anki prefix to stuff because it doesn't mean nothing there.

---

About the rest, if it ain't broken, don't fix it.

Google put Views on maintanence mode, so every screen we have that is also in maintanence mode should be kept as is, even if they are something simple like AboutFragment ("Phase 1").

e.g. Migrating Settings would be a lot of work and the reward would be none. If someone wants to create a new settings screen in Compose, that's okay.

[criticalAY]

Views won't break, and if AnkiDroid wants to use any new platform feature in 2027/2028, having Compose infrastructure available matters. I was against Compose for AnkiDroid until the recent announcement, why to wait out we can slowly move towards it

• there is no deadlines, no mandate so its good IMO
• New screens default to Compose
• If a contributor wants to migrate an existing screen on their own time, the PR is welcome (We won't explicitly tell we want this or pick this issue but if they come across then welcome)
• When a screen needs significant changes anyway (refactor, redesign, bug-heavy area), Compose becomes one option for the rewrite

On top we have screenshot tests now, plus there won't be issue for this as David suggested in DM just like @NeedsTest

[BrayanDSO]

If a contributor wants to migrate an existing screen on their own time

That's pure churn. We have 250+ issues and ~90 PRs open. I'd rather direct work towards those.

The rest (new screens and migrating when there is meaningful changes) is okay

[lukstbit]

Agreed with Brayan. As I already commented, besides setting up the ui-compose module, we should probably postpone any compose migration until after the main ui Gsoc project finishes. This would allow some focus on the Gson project itself(so it gets completed) and time for other work to help with migrating to compose.

Some other notes:

New screens default to Compose

We don't have any new screens.

If a contributor wants to migrate an existing screen on their own time, the PR is welcome

We don't have issues with producing code, we have issues with reviewing code. Adding those PRs would just mean to dilute the reviewing effort even more and will not produce any direct value to our users.

Low-risk, no shared state, prove the patterns:

I think it would be better to start from the main screens and then work through the rest of the ui screens not the other way around.

Edit: Should probably also cancel PRs that update the UI for view, like #20962

[timrae]

We don't have any new screens.

Doesn't have to be a new screen, it could just be a new UI element. I quickly tried out using compose for the nav drawer in #21143 and my impression was it should be the default for new code.

I agree that it doesn't make sense to go and migrate all the old screens at once, but the adoption policy should be such that there's a path from A (current) to B (majority of code using compose) over a number of years. Same as most technical debt.

[david-allison]

Ref: https://android-developers.googleblog.com/2026/05/android-ui-development-is-compose-first.html

For context: the announcement threw me, I was expecting the app to mostly be multimodule before tackling this, which gave us obvious 'milestones' to work towards. I don't think we have capacity for heavy migration work currently, but I felt we would have capacity in a couple of years.

State holder Fragment-held mutableStateOf for pilots, or commit to ViewModel + StateFlow from day one? (I prefer to do complete compose way @david-allison )

I don't know enough about this to make a good decision

---

I feel the issue description goes too deep into implementation details (and is already heavily outdated). Let's rewrite this to give a summary of the docs,

• The general direction has been merged: docs: add compose direction notes #21141
  • New screens default to Compose
    • I'd propose delaying defaulting to Compose until this issue is closed - I wasn't expecting feat: Compose setup for project #21147 to be delayed
  • No guidance yet on components (we should discuss this here) ❓
  • Expectation: GSoC will remain in XML Views, potentially with one Compose-based component, for learning
    • After GSoC, we will migrate these screens to Compose

I'm not yet experienced with Compose, and I'd feel the most benefit from seeing examples of what a 'good' Compose screen looks like in the codebase.

@criticalAY [as our expert]: do you feel this pull request works to standardize patterns for us to evaluate and follow?

• [Compose] feat: Redesign shared deck download #21150

I'd also find a dialog useful, as those are the most likely to be created in the short term.

---

New components in Compose:

I'd like to focus on sample patterns of how to integrate a new component into an existing XML Views screen. Maybe this should be a separate issue, closed when the docs are updated.

---

Longer-term: Once we're all comfortable with 'compose-first', I'd like to spend some time each month migrating one aspect of the app to Compose, so we make it easier for new contributors to follow existing patterns. Dialogs seem sensible to start with