CardContentProvider: Avoid eager materialization of search results

[david-allison]

Note

Assisted-by: GPT-6

Purpose / Description

As discussed:

A small AbstractCursor subclass holding just the cardIds, rendering one row on demand, so the CursorWindow bounds peak memory ,col.findCards() and projection validation stay eager so bad queries/columns still throw from query(). The other MatrixCursor sites are bounded and Schedule mutates the selected deck around its loop, so I will leave them

Fixes

• Fixes CardContentProvider: Avoid eager materialization of search results #20253

Approach

• Add a LazyCursor which handles the list of CardIds and only materializing the current row
• A further optimization to only returns the columns we requested from the card (in the case of rendered columns such as the question/answer)
• Add further validation
• ⚠️ Since we are now lazily returning data, handle deletion of a row:
  • Define it as the Id remains, all other calls return null

Important

Please review the changed API semantics carefully

How Has This Been Tested?

Heavily tested

Checklist

• You have a descriptive commit message with a short title (first line, max 50 chars).
• You have commented your code, particularly in hard-to-understand areas
• You have performed a self-review of your own code
• UI changes: include screenshots of all affected screens (in particular showing any new or changed strings)
• UI Changes: You have tested your change using the Google Accessibility Scanner

[david-allison]

⚠️ Needs to inform consumers & discuss
I suspect this won't be an issue due to consumer behavior, but it's a behavioural change

[mikehardy]

Hey David 👋

The search path was building a MatrixCursor of every matching Card (and rendering Q/A) before query() returned. LazyCursor holding the id list, loading one row on read, and letting CursorWindow bound peak memory is the #20253 plan. Eager findCards + column validation, _id-only fast path, and deleted-before-load rows keeping _id with nulls all look right, and the tests actually drive fillWindow / random access / the delete case.

On the self-thread: I think the CONTENT_URI KDoc is enough notice. I would not bump provider spec for this. Cross-process clients still get a window snapshot at fill time, and anyone iterating immediately never sees the live-reload edge. If a client holds the cursor across a collection mutation they can now see later values or nulls; that seems like the right trade for not OOMing large searches.

Thanks for keeping the other MatrixCursor sites out of this PR. LGTM

[david-allison]

I want to wait for @mikehardy and @ankidroid/reviewers for this one

Technically a breaking change in the API contract regarding concurrent updates and I'd like a few +1s to be sure I've not overlooked anything

[mikehardy]

I saw the demote — fair call if you want another set of eyes on the live-cursor edge.

From my side I am still +1 on the approach in the Approve: CONTENT_URI KDoc as the consumer notice, no provider.spec bump, and the trade for not OOMing large searches. Happy to leave this on Needs Second Approval until another reviewer lands.