selectProfile

Chooses which profile the session reads as.

A profile decides what the catalogue offers and keeps one user's downloads, reading progress and reading list apart from another's on a shared device. The SDK never picks one for you, so nothing is active until you call this — unless you asked it to, with SdkConfig.Builder.selectsProfileAutomatically, in which case this is rejected outright and the SDK's own pick stands. Choosing has one owner at a time.

A session with no active profile is fully supported, not a half-finished one to be cleared before showing content. Everything works; it is simply scoped to the account rather than to a profile — the catalogue is the account's, and downloads, reading progress and the reading list are shared by every session on the device that has no profile. So this is worth calling only if your accounts actually use profiles. If they do not, or if the user has not chosen yet, go straight to content after authenticate.

Selecting is immediate and local — nothing is sent to the server. Everything currently observed through Content notices and reloads against the new profile on its own; there is nothing to re-request. Call it again whenever the user switches.

Pass null to deselect and put the session back to account scope. That is what to do when you take the user somewhere no profile is reading — a profile picker, a switcher, an account screen — rather than leaving the previous profile active behind the UI. It is an ordinary call with an ordinary success: nothing is validated, and deselecting when nothing was selected is a no-op that still succeeds.

The SDK will also drop a profile on its own, but only one way: if authenticate or refreshProfiles finds it gone from the account — see refreshProfiles.

The id itself is not checked against anything here: which ids are valid is the backend's to decide, and it rejects one it does not know on the next request rather than the SDK second- guessing it locally.

Parameters