Disabled features - Almedia Launchpad

If your game hides part of the Link experience from some or all of its players - an A/B test of the entry point, a staged reward hub rollout, offers in one region only - declare it. To us an undeclared rollout looks like a broken integration: a population that saw Link and did not convert. Broken integrations get deprioritized, and holdout and funnel numbers for your game come out wrong. Declaring it costs one line and makes the backend do the hiding for you, so no entry point can lead to a screen that will not open. Declare permanent choices in Almedia → Settings → Disabled Features. Declare per-player choices in code:

Almedia.Initialize(new AlmediaConfig
{
    DisabledFeatures = { AlmediaFeature.Offer, AlmediaFeature.Notifications }
});

The two combine as a union: the asset is the floor for every player, code adds for the current player and can never remove what the asset declares. DisabledFeatures is never null and takes a collection initializer, as above.

Feature	What the player does not get
`Linking`	The linking entry point. Status reads `NotAvailable` with reason `Disabled`, so the bundled `LinkButton` hides. A player who already linked is untouched.
`RewardHub`	The reward hub. `CanShowRewardHub` is false on a `Linked` status and `ShowRewardHub()` is a no-op.
`Offer`	The offer screen. `CanShowOffer` is false on a `Linked` status and `ShowOffer()` is a no-op.
`Notifications`	Any Almedia notification, in the SDK’s UI or yours. Reward grants still arrive.

The set is declared at initialization only. There is no runtime call; a game whose remote config arrives late re-initializes with the new set, and Initialize with a different set already re-initializes. The backend enforces the declaration and the SDK reacts to the status it returns, so nothing else in your integration changes. In the Editor, AlmediaEditorMock.EmitStatus(new AlmediaStatus.NotAvailable("disabled")) models a player whose linking is disabled.