Read the console's sampling settings on HarmonyOS

[Fiona2016]

RUM on HarmonyOS collected at whatever rate the application was built with. Moving that rate meant shipping a release and waiting for it to roll out, while the other platforms could already turn the knob from the console. This adds the same remote configuration path here.

How it behaves

Settings are read from the RUM configuration endpoint at the rhythm of the sessions that consume them: once at start-up, once whenever a new session begins, and on return to the foreground when the console asks for it. What arrives is stored, so the first session of the next launch is already drawn under it.

A published rate applies to the next session drawn; a session already under way is never re-decided. View documents now report the rate the session was actually drawn with, plus the settings version, so extrapolation and audits line up with the draw that kept the session rather than with the values passed to init.

Nothing in this path can hold up initialisation or interrupt collection. A request that fails, times out or comes back unreadable leaves the stored values exactly as they were — wiping them on a bad minute would swing a whole fleet back to the values it was built with, which is the opposite of what someone who moved a knob deliberately wants. Retries are two per outage, spread by a jitter, then nothing until the next natural trigger.

Application-facing API

FlashcatRum.enable(new RumConfigurationBuilder(applicationId)
  .setSessionSampleRate(100)
  .setRemoteConfigurationEnabled(true)          // off by default
  .setBeforeSampling((context: BeforeSamplingContext): number | undefined => {
    // the last word on the rate: return one to override, or nothing to accept it
    return isBeingDebugged(context.custom) ? 100 : undefined;
  })
  .build());

GlobalRumMonitor.get().setForcedSession();      // keep this visitor whatever the fleet is on
GlobalRumMonitor.get().getRemoteConfig();       // the console's custom values, decoded

A hook that throws or returns a rate outside 0..100 is ignored: a mistake in the host application must not take collection down with it. setForcedSession() keeps a session the rate would have dropped, and does nothing while a forced session is already running.

Notes for reviewers

• Feature modules receive no HarmonyOS Context, so the credentials and the small amount of storage this needs come from the core, which already owns both: SdkCore gains an intake accessor and a two-method settings store.
• The layout mirrors the Android SDK (RemoteConfigStore / RemoteConfigController), with one deliberate difference: the drawn-configuration snapshot is held in memory rather than persisted, because nothing on this platform reads it back across launches.
• 23 unit tests cover the parsing, storage, retry, draw, hook and forced-session rules, including the failure paths that must leave stored values untouched. The demo application gains a scenario that drives the whole path from the command line.