[New Feature Launch]: Android Lesson Progress, Study Guides & Worked Examples

[Neer-rn]

Product

Android

Brief description of the feature. Include links to PRD and TDD, where possible.

This is my GSoC 2026 project 4.1. It adds three things to the Android app that already exist on web. Each one is behind its own feature flag so they can be turned on independently.

1. Lesson Progress Visualization (flag: enable_lesson_progress_visualization)
A horizontal checkpoint progress bar in the exploration player that shows "X of N completed". The data for this is already there because PR #6185 added the is_checkpoint field to the State proto. I will be using StateGraph to find the main path (Dijkstra on labelled_as_correct answers, runs once per exploration and is memoized) and StateDeck to count how many checkpoint states the learner has completed up to the current state index. So the count goes down when the learner navigates backward and freezes during flashbacks, which matches what the learner is actually looking at.

2. Study Guides (flag: enable_study_guides)
Right now the Android revision card is one big block of HTML. Web already restructured this into sectioned study guides (heading + content pairs) in issue #5844. This adds a new app/topic/studyguide/ package that copies the structure of the existing revisioncard/ package but uses a RecyclerView with BindableAdapter so each section can be a separate item. The routing change is one conditional in TopicRevisionFragmentPresenter so when the flag is OFF the old revision card flow is untouched.

This one depends on issue #6105 (study guide support in the lesson export pipeline) being resolved before coding starts. Ben is handling that.

3. Worked Examples Rendering (flag: enable_worked_examples)
The <oppia-noninteractive-workedexample> tag currently shows nothing on Android because there is no handler registered for it. I am adding a new WorkedExampleTagHandler that renders the question and answer inline as bold "Question:" and "Answer:" labels using SpannableString (not collapsible, this is by design per the project description). The tricky part is that the inner question and answer HTML can itself contain other Oppia tags like images or math, so I am also adding a CustomHtmlParser interface that handles the nested HTML without re-invoking the full tag handler pipeline (would cause infinite recursion).

Out of scope / not changing:

• No new backend endpoints, no new calls to the web server
• No new user data stored, no new analytics events
• No new third-party libraries
• When any flag is OFF, the existing behavior is preserved exactly

Tracking issue: oppia/oppia-android#6104
Project entry on the GSoC wiki: https://github.com/oppia/oppia/wiki/Google-Summer-of-Code-2026#41-support-for-lesson-progress-study-guides-and-worked-examples

Proposal (also acts as TDD): Link

PRDs:

• Worked examples: https://docs.google.com/document/d/1QrqTsR1Ew3WfQvj7D83mh0k9HjW6xQ-2dpJGkbe8XqY/edit
• Lesson Player Mini-PRD (covers the lesson progress UX intent): https://docs.google.com/document/d/1922aE9_TEFTbHyA3jrXy9cTxo2JgvjfEvKHlxqxG-Rw/edit
• Study Guides has no standalone PRD. The closest spec is the GSoC 2025 study guides proposal: https://docs.google.com/document/d/1vSG2aMdDT7iqw6G3lEASas2trB1y4g98TNUQft4F9_M/edit

Link to the Pre-Launch Review Doc for this feature

Milestone 1 Pre-launch Doc Milestone 2 Pre-launch doc

Link to the ProdOps Drive folder for this feature

To be added

Link to the PR which moved the flag to the TEST feature stage

To be added

Link to the launch command channel for this feature.

To be added

Developer point-of-contact

Neer-rn

Dev Leads

• kevintab95
• U8NWXD
• HardikGoyal2003
• mon4our
• NITISH084
• BenHenning
• adhiamboperes
• subhajitxyz

Expected code-complete date

2026 Q3

Required roles for testing

• Curriculum admin
• Topic manager
• Question admin/coordinator
• Question reviewer
• Question submitter
• Translation admin/coordinator
• Translation reviewer
• Translation submitter
• Voiceover admin
• Blog admin
• Blog post editor
• None of the above

Feature flag name

enable_lesson_progress_visualization, enable_study_guides, enable_worked_examples

(Android only) Minimum supported Android version

21

(Optional) Is there anything else you would like the ProdOps team to know?

No response

Instructions for Dev Leads, Prod Ops and QA Teams

---

When you are assigned to this issue, please do the following. Tick each
checkbox item as you complete each step:

Tech-lead prep (to be done by a tech lead)

• Ensure that this issue is filed correctly. Ask for any missing info if needed.
• Confirm that the Drive folder is in the ProdOps Feature Launch folder.
• Confirm that the Drive folder contains the pre-launch review doc, PRD, and TDD (these should be the actual docs, not just shortcut links to them).
• Ask the developer and the relevant dev team leads to subscribe to this issue thread for updates, and ensure that they've done so. (You should also subscribe to it for the same reason.)
• Ask the developer and the relevant dev team leads to subscribe to comment/edit notifications on the pre-launch review doc for updates, and ensure that they've done so. (You should also subscribe to it for the same reason.)
• Ensure that the "Information for Testers" and "Information for Server Admins" pages of the pre-launch review doc are fully filled in.
• Ensure that the CUJs in the spreadsheet relating to this feature are updated. If any behaviour is hidden behind a flag, there should be a "Current" row and a separate row for the flag-hidden behaviour.
• Ask the PM team to verify the current/updated CUJs, to ensure that the diff from the old ones is correct (e.g. we haven't removed stuff from the old ones that we would actually like to keep).
• Verify that all the above CUJs are fully covered by acceptance tests, and that the implemented acceptance tests in the codebase match the ones documented in the spreadsheet. Fill in the "Evaluation of Automated Tests (by tech lead)" columns in the CUJ spreadsheet with your evaluation, and work with the developer to fix all remaining issues.
• If the feature launch will include manual steps (in addition to deploying to PROD and turning the flag on), create a tech launch plan with all the steps needed, similar to this one. Ensure that it is added to the Drive folder. This should consider any migrations or data upgrades that need to happen, as well as any launch-time changes that are needed for reliabilty, deployability, performance, scalability, and stability.
• Verify that the "test stage" PR has been merged (see the "Link to the PR which moved the flag to the TEST feature stage" field), and that it actually moves the feature flag to the TEST stage.

Tech-lead verification (to be done by the same tech lead)

• Once the "test stage" PR has been merged, deploy it to the backup-server.
• Enable the feature flag on the backup-server.
• Complete any steps in the tech launch plan (if one exists) on the backup-server.
• Verify that the feature's CUJs actually work technically on the backup-server (with the flag enabled). Clarify any CUJs that aren't clear with the developer.
• Set up a Google Space group chat for this feature launch. Title it "[Launch] Name_Of_Feature" (where Name_Of_Feature is replaced by the name of the feature you're launching).
• Invite the following people to the launch group chat: (a) the developer of the feature, (b) the relevant dev leads, (c) the ProdOps assignee, (d) the ProdOps leads, (e) any folks in UXD/UXR who were involved in the feature's design, (f) the QA assignee, (g) the QA leads, (h) the Marketing assignee, and (i) the Marketing leads.
• Click on the "Board" icon in the Google Space, and add the following resources in this order: (a) TDD, (b) PRD, (c) Drive folder, (d) link to this Launch Checklist issue (GitHub), (e) Pre-Launch Review Doc. (The resources will then appear in reverse order, so that the pre-launch review doc is at the top.)
• Send a message to @all to introduce the group chat and ask everyone in it to subscribe to the space with "Notifications" set to "All". Explain that the launch chat is where all communication about the launch will happen, and that the launch checklist on GitHub must be kept up-to-date. Provide a link to the GitHub launch checklist.
• Ask everyone in the launch chat (ProdOps, QA) to subscribe to comment/edit notifications on the pre-launch review doc for updates.
• Ensure that the ProdOps assignee has the correct permissions on the backup-server to do a dry-run of the feature.
• Hand off this issue to the ProdOps team (deassign yourself and tag/add the correct assignee from ProdOps). (Only mark this step as complete once the ProdOps assignee has acknowledged the handoff.)

Preparation and Dry-Run (ProdOps team)

• Verify that the Marketing team's tracker has a sheet for this product launch.
• Send an email to qa-leads@ to let them know that the feature is coming soon (subject to passing the ProdOps dry-run).
• [LATER, once analytics pipeline is set up] Set up the Looker Studio dashboard for the feature, and supplement it with metrics obtained using BigQuery queries, as needed.
• [LATER, once analytics pipeline is set up] Add a link to the backup-server Looker Studio dashboard in the instructions for testers.
• Do a full run-through of the feature, and make updates to clarify the CUJ descriptions as needed. Then, post a new comment to this thread with the testing report, and cc the developer and relevant dev team leads. Ensure that any bugs found during this process are filed and assigned to the developer. If you see design issues, it's fine to loop in the design team. If issues were discovered in the run-through, repeat the above as needed until there are no more issues. (Only mark this step as complete once that stage is reached -- at this point, ProdOps is saying "I'm happy with the feature, it can go to full QA.")
• [LATER, once analytics pipeline is set up] Verify that events from the testing were correctly recorded on the Looker Studio dashboard.

Full feature testing (ProdOps and QA teams)

• Send QA team (qa-team AT oppia DOT org) an email that a new feature is ready for testing. Send them the pre-launch doc (with CUJs) and request the list of tester usernames.
• Ask the tech leads to provide the necessary permissions (see "Required roles for testing", above) to the tester usernames on the backup-server.
• Ask QA leads to (a) start the feature testing process, (b) send updates to the group chat after each testing cycle, and (c) send a final update once they've confirmed that the full feature is working properly and is good to launch. If there are bugs found in the testing, they should inform the developer, who should fix the issues, add automated test coverage, and ask for a re-test. This continues until all issues have been fixed. (While this is happening, ProdOps should periodically check the Looker Studio dashboard to verify that metrics are being correctly recorded during feature testing, and adjust the metrics, if needed, to make them more useful.) (Note: Only mark this step as complete when the QA leads have notified the group chat that testing is complete.)
• Ask the tech leads to move the feature to PROD stage, and add a link to the PR here once it is merged: ______. (Only mark this step as complete once the tech leads have done this.)
• Perform a final Product review. Product should review the state of QA findings, including whether any bugs still exist, and look at the feature again if a lot of changes have been made. They should also understand any caveats (e.g. if anything has been disabled due to quality issues, etc.). They should also decide (in collaboration with the Campaign Strategy and UXR teams) whether the project needs a "trusted tester" phase.
• If the decision is made to include a "trusted tester" phase, run through this with the UXR/Marketing teams following the guidance in the Product/Marketing Communication Process document. (Only mark this step as complete when the "trusted tester" phase is complete, or if there is no "trusted tester" phase.)
• Formally greenlight the launch. (Only mark this step as complete when ProdOps has made the decision to greenlight.)

Rollout (ProdOps team)

• Agree on launch date with Marketing team and tech leads, and document it here.
  • Deployment date of binary (with the flag enable-able in PROD mode): _________.
  • Date for completing all marketing collateral: _______.
  • Launch date to users (must be after the above): _______.
• Turn on the feature flag for just the PM.
• PM verifies that the feature works correctly.
• [LATER, once analytics pipeline is set up] Check the ProdOps "CUJ health" analytics dashboard to verify that the new dashboards for this feature have been included in it.
• Work with the server admins team to flip the feature flag per the rollout schedule before the launch date, and confirm that the feature works in production. (Do partial rollout if desired, to make sure usage doesn't drop / support requests don't spike / system health is good.)
• Ask the server admins to permanently flip the feature flag to ON in the test/backup servers. (Only mark this step as complete when they confirm they've done that.)
• Once the feature is actually launched to all users:
  • Send out a congratulatory launch email, crediting all the folks involved in the launch. Show some pictures!
  • Update the rows for this feature in the master CUJ document to have a status of "Current" (rather than being gated behind a flag).
• Monitor post-launch metrics through the feature's Looker Studio dashboard (constructed above), filed GitHub issues, and Google Groups forum.
• 2 weeks after launch, compile a post-launch report and schedule a post-launch review with everyone on the command channel (design, developers, marketing, QA).
• Ask the tech leads to (a) remove the feature flag, (b) drop obsolete journeys from the CUJ sheet. Link to PR that removes the flag: _____.
• Close this bug. This concludes the feature launch, congratulations! 🎉