CardContentProvider was expanded to add two endpoints for cards:

• Expand CardContentProvider to return card IDs and cardinfo details #20112
• feat(content-provider): supports search cards and access card details by id #20175
  • /cards/
  • /cards/#

But additional fields were deferred, due to API design concerns.

        // docs trimmed, see https://github.com/ankidroid/Anki-Android/issues/20112
        public const val DUE: String = "due"
        public const val INTERVAL: String = "interval"
        public const val EASE_FACTOR: String = "ease_factor"
        public const val REVIEWS: String = "reviews"
        // there are more fields which the above issue did not handle

Due to my comment:

I'd strongly suggest splitting this PR into two parts:

1. Adding the public /cards/ endpoints: easy
2. Adding additional properties to /cards: harder

Specifically for (2), I would like to see the source/docs of upstream Anki Desktop AnkiConnect, and how the data is modelled there. This is how people are used to consuming our data.

#20175 (review)

The state of FSRS determines whether some properties for a card are valid or not (Ease = SM-2; Difficulty: FSRS)

Some properties had rather complex logic which we likley want to abstract in a more user-friendly manner:

    due             integer not null,
     -- Due is used differently for different card types: 
     --   new: the order in which cards are to be studied; starts from 1.
     --   learning/relearning: epoch timestamp in seconds
     --   review: days since the collection's creation time
     -- For cards in filtered decks, due represents the position of the card in the filtered deck. The value of due before moving to the filtered deck is saved as odue.
    ivl             integer not null,
      -- The interval of the card in days.
      -- For learning cards, it is 0.
      -- For relearning cards, it is the interval (in days) that the card will get after passing through all the steps.

-- https://github.com/ankidroid/Anki-Android/wiki/Database-Structure/#cards

This issue consists of three parts:

• Information gathering
  • Link the AnkiConnect API and list the properties which users expect. Explain how they model optional properties
  • Link Card.kt and list the properties which are available
  • Link our low-level and high-level API and determine the properties which it is missing
• Modelling
  • Document each property, whether it is useful with FSRS enabled, and potential differences in semantics based on the scheduling state
  • Plan how to select each property within the low-level and high-level API, and whether FSRS-based properties should be a first-class concern
  • Plan the data types
• API implementation
  • The simple part